[U-Boot] [PATCH] tools: make imxheader size align on page size

[Stefan Agner]

Hi Stefano,

Am 2014-04-23 17:19, schrieb Stefano Babic:
> 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.

FYI, on Vybrid, there is enough internal RAM for U-Boot. I don't have to
use a DCD table to setup the DRAM controller.


>> 
>> 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.
> 

I forgot to mention: This issue is _only_ when booting from NAND. I can
load and run the very same image using serial loader (over USB or UART).
The JUMP command that the serial loader sends at the end jumps to ...404
(IVT Header start in Memory). Also booting from SD-Card works with all
images.

This isolates the problem to the "NAND image loader" part of the ROM.
The fact that Vybrid's NAND peripheral is not the same as on other
i.MXes goes well with that assumption too (since other i.MXes don't have
that limitation).


>>>> 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.

No not yet. I need to setup an example. However, in the end they will
not change the ROM anyway, especially not on Vybrids already delivered
;-)

--
Stefan