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

[Stefan Agner]

Hi Stefano,

Am 2014-04-16 17:44, schrieb Stefano Babic:
> On 16/04/2014 15:29, stefan at agner.ch wrote:
>> From: Stefan Agner <stefan at agner.ch>
>>
>> The i.MX V2 headers total size is 0x7fc. The header is placed
>> in front of the U-Boot binary which of course is aligned to
>> text base. Hence the header starting point is not page
>> aligned (e.g. at 0x3f400404). This is still a valid header,
>> which boots fine using serial loader. However, the image
>> fails to boot from NAND (tested on a VF61x SoC).
>>
> 
> Can you better explain this ? There is only one board in mainline with
> vf610. CONFIG_SYS_TEXT_BASE is set to 0x3f008000. I cannot get the
> offset in your example. Are you referring to NAND page ? But if the
> header must be aligned with the NAND page, this is pretty bad because we
> have to adjust the header depending on the selected NAND chip. I do not
> see this limitation in the manual.
I've not submitted my board yet, I altered it to use 0x3f400800 as
CONFIG_SYS_TEXT_BASE. I just realize that a header length of 0x7fc
doesn't fit with 0x3f400404 even though (that would be 0x3f400004 if
anything). But the mkimage utility reports
Load Address: 3f400420
Entry Point:  3f400800
I'm a bit confused now, why is the header only 0x400 now?

 
> You have also added FCB to the image to flash into the NAND. Are you
> sure that everything is fine there ?
> 
> As feeling, it seems that adding this integer you move the limit and you
> constraint the SOC to read more data as before.

Well, I use downstream U-Boot to create a FCB. Thats why I use
0x3f400800 as text base, so those two U-Boots are aligned. I only
flashed Mainline U-Boot (leaving FCB as is) and thats when I detected
this issue: Diffing the IVT headers I found out that downstream was
aligned to 0x400 while mainline was not.

Quite possible that an altered/correct FCB would actually work. But
speaking about FCB, is there already something for Vybrid? I'm currently
try to create an Image with FCB+IVT V2 header using the mxsboot utility,
which seems to create a similar FCB. However it doesn't worked in a
first try, there seem to be some subtle but relevant differences...

>> Most parts of the header have a length of a multiply of 16
>> bytes.The rest of the header is filled with 8 bytes long DCD
>> data.
> 
> I do not understand this phrase. The header is mainly composed by 32 bit
> fields. See the structure dcd_addr_data_t.
> 
>> Only the boot data header is 3 word long (12 bytes).
> /ivt_header>
> 
> ivt_header is defined as 32bit integer. What are you meaning here with
> boot data header ?
By boot data header I mean boot_data_t. The whole structure is filled by
the DCD table using an array of 121 dcd_addr_data_t. Since
sizeof(dcd_addr_data_t) == 8, the whole structure is not nicely filled
to be exactly 0x800... 


>> This patch makes sure the whole image is exactly 0x800 by
>> adding one padding word after the boot data header. Since
>> the individual data structures are referenced by pointers,
>> this still results in a valid i.MX V2 header while
>> maintaining page alignment.
>>
>> Signed-off-by: Stefan Agner <stefan at agner.ch>
>> ---
>> I'm not 100% sure wheather this is the right approach solving
>> this issue. This works for me, also tested with DCD data.
>>
>>  tools/imximage.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/tools/imximage.h b/tools/imximage.h
>> index 01f861e..b596fb1 100644
>> --- a/tools/imximage.h
>> +++ b/tools/imximage.h
>> @@ -149,6 +149,7 @@ typedef struct {
>>  typedef struct {
>>  	flash_header_v2_t fhdr;
>>  	boot_data_t boot_data;
>> +	uint32_t reserved1;
>>  	dcd_v2_t dcd_table;
>>  } imx_header_v2_t;
>>
> 
> The patch does not clarify the issue. It hides the problem, because
> adding this additional place you can boot your board, but without really
> understand why. What does it happen if you add additional fields before
> dcd_table ? If it continues to work, the header must not be aligned with
> the NAND page. But again, doing this, let the SOC reading more bytes as
> it does without this fix.
Ok, in the end this actually seems not to be an issue at all, more a
unfortunate circumstance.


--
Stefan