RockPi4B: spl_load_fit_image() writing past end of buffer & MMC errors

[Jerome Forissier]

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,
-- 
Jerome