Hi Stefan,
On 23/04/2014 04:34, Stefan Agner wrote:
The header total size is 0x3fc (sizeof(imx_header_v2_t)) right now. This patch would make alter it to be exactly 0x400.
This renforces my suspect. Making the image bigger, it seems that the SOC loads more data as before.
However, reading in the manual, the initial load image (what the SOC should load initially) is 4K (Table 19.37), and adding 4 bytes should have no influence.
I'm still trying to figure out what the real problem is here. I could not alter the FCB to boot the default IMX V2 image (with IVT header). Inside the FCB one can only specify the page offset where the image starts. Within that page, the Boot ROM expects a IVT header at exactly 0x400. However, on NAND, the IVT header _is_ exactly at 0x400.
I also think the Boot ROM can read the IVT header but the jump to the entry point of U-Boot fails somehow. If the IVT header is not correct, the Boot ROM usually enters serial loader, in my case this doesn't happen. I have no JTAG environment ready, so I can't easily debug this.
That is true - another possible cause could be that for some unknown reason to us, the IVT header is read but reading the whole U-Boot image fails.
We could also know if the IVT header is read and parsed correctly if the DRAM controller is set up even when boot fails. That means that the DCD data is read and applied. Rather I have no idea how to proof this without a JTAG debugger.
I also try shorter versions of the IVT header by alter the dcd_addr_data_t array inside dcd_v2_t. interesting is, that a total length of 0x3f8 works, while 0x3fc or 0x3f4 do not work.
Strange enough - sure I have seen not 8-byte alignment on other i.MXes.
In case this discussion ends up adding this padding word, I will send a new patch with correct numbers and better description.
It is not clear what is the cause of the issue and then which is the solution. Adding the pad at the moment seems only a work-around for you.
For me it seems as if Vybrid requires the header base in memory requires to be at 8 byte boundary. Probably there is also a nicer solution enforce this rather than just extend the struct.
Have you tried to ask Freescale about this issue ? It is quite strage and it seems Vybrid-related.
Best regards, Stefano Babic