i.mx6Solo booting from NAND issues

[JimMalone]

Hi All,

We are currently struggling to get our custom board booting from NAND.  I've attached the latest status that I have sent to my Freescale FAEs but wanted to see if anyone in the community has run into similar issues.  We are using a Samsung K9GBG08U0B MLC NAND 4GB (8K pages with 1K oob).  The details are in the attachment, but here is a brief summary of issues.

1) FCB seems to have 2 extra bytes in front of the valid FCB data.  We are using the default 10 bytes of metadata.  DBBT and u-boot have the 10 bytes of metadata as expected.

2) Logic Analyzer captures of the NAND bus activity at power on shows that the first read attempt is started during the busy period after the initial reset command.  Second FCB reads correctly (with the issue 1 present).  First DBBT reads correctly and that is all we have captured on the logic analyzer so far.

If anyone could provide some hints as to what may be our issue, I would very much appreciate it.

[xuminmin]

hello Jim:

     Have you solved the problem? I Meet the same question as you . Can you tell me how to resolve it?

[KeshavaGN]

Hi Jim,

Whether you found the solution for your problem?

Now do you have any idea why 2 extra bytes added to FCB?

Regards,

Keshava

[JimMalone]

Hi Keshava,

We do have the system working at this point.

The most important note is that if you dig in the kobs-ng code on how in encode/encrypts the FCB data, it is using a software hamming code with a 10 byte metadata field.  Since it is software based, it does not use the BCH engine on the SoC.  The BootRom also aligns the metadata to a 4 byte boundary so adds 2 extra bytes to the 10 byte metadata for a total of 12.

We never solved the reset issue of the NAND and missing the first FCB.  I am pretty sure this is a bug in the BootRom code and we have an open.

I have been working on compiling my notes on this effort to hopefully help others, but it is not quite complete yet.  If you have any other questions, please let me know.

Jim

[KeshavaGN]

Hi Jim,

Thank you for quick reply.

Actually i'm working on boot from NAND in WinCE on imx.6q.

So, I'm comparing the data (FCB and DBBT) written on NAND using kobs with that using WinCE (MFGTool).

Here i found this Metadata size difference.

In WinCE, only 10 metadata found, which is according to the METADATA_SIZE which is set to 10.

In kobs also METADATA_SIZE is 10, but while reading NAND i found 12 metadata bytes.

In WinCE it is not booting, and going to usb download mode.

So i want to know whether this difference making the problem?

I posted my issue here : iMX6Q NAND Boot issue in WinCE

Please give me some ideas.

Thanks.

With regards,

Keshava

[JimMalone]

Hi Keshava,

Since teh Bootrom is agnostic to what it will load, the FCB should be the same no matter what writes it to the flash.  Therefore, it should have 12 bytes of metadata for the FCB only.  The FCB contains the Hardware BCH (or should contain if it is a correct FCB) that everything else that gets loaded from NAND uses.  This includes the DBBT, u-boot in my case and WinCE image in your case.

The only way I was able to get a clear picture of what was happening during boot was to hook up a logic analyzer to the complete NAND GPMI bus to see what the Bootrom was looking for and in what order.

Some other items I have run across:

Table 8-11 BOOT_CFG[1:0] Should have the description Row Address Cycles.  This should not count the number of column address cycles.

Table 8-12 BCHType actually selects the Galois Field level that the Bootroom uses to load everything other than the FCB.  It uses this value of 0 (BCH20 in the description in the table) for Galois Field of 13 and a value of 1 (BCH40 in the description) for Galois Field of 14.  Not intuitive at all.

[KeshavaGN]

Hi Jim,

Do you know how (and where in source code) "metadata" is written in NAND?

Can we edit it?

Thanks.

With regards,

Keshava G N

[JimMalone]

Hi Keshava,

Sorry for the delay in responding but I have been sick.

Currently the GPMI (Linux driver in my case) driver only uses a single byte of the metadata when the bad bloack marker swapping feature is enabled.  The swapping routines swap the first byte of the OOB area into the first byte of metadata.  These swapping routines are easily searched for in the code and are the only places I have found where metadata is actually written.

Theoretically you could write what you want in the remaining metadata bytes.  By default metadata is 10 bytes total so you have 9 bytes.  You would need to write the code into the driver to both write the metadata and retrieve the metadata when you need it.

Make sense?

Jim

[KeshavaGN]

Thank you Jim!

Sorry for the delay in responding but I have been sick.

Sorry for the trouble... Are you alright now?

Currently the GPMI (Linux driver in my case) driver only uses a single byte of the metadata when the bad bloack marker swapping feature is enabled.  The swapping routines swap the first byte of the OOB area into the first byte of metadata.  These swapping routines are easily searched for in the code and are the only places I have found where metadata is actually written.

Theoretically you could write what you want in the remaining metadata bytes.  By default metadata is 10 bytes total so you have 9 bytes.  You would need to write the code into the driver to both write the metadata and retrieve the metadata when you need it.

Make sense?

Got it... Thanks..

With regards,

Keshava G N

[KeshavaGN]

Hi Jim,

Do you know how (and where in source code) "metadata" is written in NAND?

Can we edit it?

Thanks.

With regards,

Keshava G N

[KeshavaGN]

Hi Jim,

Thank you for reply.

I will try Logic analyzer and will update.

Regards,

Keshava G N