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

[Stefano Babic <sbabic@denx.de>]

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

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================