Hi,
I am trying to enable FIT image verification by SPL on Rockchip 4B (U-Boot v2022.04) and I hit a couple of issues.
First, I noticed that spl_load_fit_image() may write memory outside the range given in the image node. For example on RockPi 4B I have the following FIT (irrelevant parts omitted):
/ { images { atf_2 { /* File size is 8024 bytes */ data = /incbin/("bl31_0xff3b0000.bin"); compression = "none"; load = <0xff3b0000> } } }
I expect SPL to load atf_2 into 0xff3b0000 - 0xff3b200b but due to the alignment of the source data in the MMC, spl_load_fit_image() writes one more block and later moves the data in place with memcpy(). What are the guarantees that it is a safe thing to do?
In my case, the image starts at offset 308 in the 512-byte MMC block (that offset is called 'overhead' in spl_load_fit_image()). As a result, (8204 + 308) / 512 + 1 = 17 blocks = 8704 bytes are read.
For some reason I can't explain, on my board only the first 8K of the 64K SRAM range 0xff3b0000 - 0xff3c0000 (INTMEM1) can be safely written to. Any data written after this point corrupt the lower 8K. I found nothing in the rk3399 TRM about this [1].
Anyways, I tried using a temporary buffer allocated on the heap to handle the first and last blocks at least (the load address is properly aligned for info->read() so the middle blocks can be read in one go). It works but not reliably. And that is the second problem. mmc_read_blocks() in mmc_bread() sometimes returns an error. If I read blocks one by one in a loop THE read randomly fails after a few blocks only. The error is -110 (-ETIMEDOUT) from dwmci_send_cmd().
Am I using the MMC read incorrectly?
[1] https://www.rockchip.fr/Rockchip%20RK3399%20TRM%20V1.4%20Part1.pdf
Thanks,