Hi Stefano,
Am 2014-04-16 17:44, schrieb Stefano Babic:
On 16/04/2014 15:29, stefan@agner.ch wrote:
From: Stefan Agner stefan@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@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