On Thursday 22 December 2022 19:36:58 Tom Rini wrote:
On Thu, Dec 22, 2022 at 10:02:42PM +0100, Pali Rohár wrote:
On Thursday 22 December 2022 13:22:50 Tom Rini wrote:
I suspect that how we fire up QEMU means that the issue you're noting isn't triggered since we don't boot it from flash but instead pass the binary.
Yes, this sounds like that problematic part is not tested. To spot this issue some end-to-end test is needed... For flash setup - booting directly from the qemu flash (execute in place) without initialized RAM and letting u-boot to do it. For SD card setup - booting via BootROM (like it is on the real HW). Seems that SD card BootROM is not available on internet and no idea if it can be dumped from some Freescale CPU (it is even legal to do it?). So some alternative bootrom implementation for such testing is needed... which is lot of work.
We do some things like this already, for other QEMU platforms (the flash_impl variable is set to the shell script to create a flash image) but, it's unlikely to be worth expending the effort here, the ROM QEMU uses here isn't the Freescale one, but from openhackware.
If somebody is interesting, Freescale P2020 Internal boot ROM for SDHC (maybe it is common with SPI) is at offset 0xFE000 in CCSR block. Hence it can be dumped from (32-bit) U-Boot by command:
=> md.b 0xffefe000 0x2000
At first 0x1000 bytes there is nothing and code starts at second part. During boot phase, it is mapped to the end of the (4GB) memory space and entry point is the last instruction. So boot rom is just 4kB long.
In case somebody wants this dump, just send me an email.