Understanding VYBRID NAND Boot

[JasonMoss]

Does anyone have a clear understanding of Vybrid NAND Boot that can explain what's actually happening during boot from NAND?  I have several Vybrid customers actively designing boards, that are planning to boot from NAND but can't make sense of the documentation.  After spending a day reading and re-reading trying to bring some clarity there are several things I don't quite understand (questions near the bottom).

After reading a related question (https://community.freescale.com/message/343519#343519) I decided to look through the U-boot source code from TimeSys, which doesn’t really clarify if there are specific limitations or discrepancies between the NFC Controller chapter in the Reference Manual (Chapter 31) or the Boot Chapter (Chapter 19)  or describe how NAND boot is supposed to work (it appears to still be a Work In Progress).  There are clearly things missing that have been present in the i.MX BSP for quite a while that deal with some of the finer details of block management, such as support for BI swap, etc.

For reference on the below questions, a few notes about the U-boot source code from the

From the TimeSys U-boot Patch for the 7/29/2013 BSP Release:

From 04590d57b4cde278d85d3c8ac0c7c55b4fe4db31 Mon Sep 17 00:00:00 2001

From: Dan Douglass <dan.douglass@freescale.com>

Date: Wed, 12 Jun 2013 15:58:17 -0500

Subject: [PATCH] NAND Boot: - nb_update tool in fsl_nfc driver rewritten to

write FCB, BBT, and image to NAND. - vybrid_nand board config added. - NAND

read commands added to DCD that force NFC controller to read NAND page twice

to prevent NFC hang

Notes about U-boot source:

1. FCB is written to the first page with HW ECC in bypass mode
2. BBT and image written with HW ECC enabled
3. DBBT is disabled in the current bootloader code – there is a lot of support code there for creating the DBBT and writing the DBBT to flash, but it’s all commented out for the latest release and the DISBBM bit is set in the FCB so the ROM disables the bad block search.

Below are quite a few conceptual questions looking for clarify - answers to some may automatically answer most if not all others in the list.

Questions:

1. Section 19.5.6, which is describing the ROM behavior during boot seems to suggest that Vybrid NAND boot behaves similar to the i.MX6, with less configuration options, where Section 31.4.4 discusses how the NFC controller operates at a lower level that is really abstracted and may only be relevant to the ROM code.
   1. Is this an accurate interpretation of these two sections at a high level?
2. Section 31.4 (Functional Description), near the end suggests ‘Page size at boot is set to 1056 bytes to be compatible with a large number of NFC devices, without needing additional power-on reset flags to indicate boot device’.  If this is accurate, as long as the NAND flash page size is a multiple of 1K, with at least 32bytes of spare area for per 1K of page data size (1024 byte page + 32 byte spare) that Vybrid can boot from that NAND (i.e. common configurations would be: 1K page with 32-bytes of SPARE/ECC per page (1056 bytes), 2K page with 64-bytes of SPARE/ECC per page (2112 bytes),  4K page with 128-bytes of SPARE/EC per page (4224), 4K page with 224-bytes of SPARE/ECC per page (4320 bytes).
   1. What is the actual limitation on what configuration of NAND is supported for boot?  Is it limited by the NFC or the ROM?
   2. Note:  The U-boot bootloader uses hard-coded values matching the 2112-byte page configuration for the device on the tower card, so it's not clear what the NFC/ROM can or can't handle.
3. Between the two sections in the RM (31.4.4, 19.5.6) and the bootloader source code it’s not clear what exactly happens when booting from NAND (between the NFC controller and the ROM boot code).
   1. Does the NFC controller automatically read 4K (4 x 1024data+32spare) into the NFC SRAM and validate this using hardware ECC?
   2. This would happen before the ROM code starts executing, so by the time the ROM code gets to handling the NAND boot the data in the NFC SRAM buffer is already valid and should contain at least a valid FCB, correct?
4. If the first block of a given device could be “theoretically” be BAD, how does the NFC would automatically determine what block read next looking for a HW ECC match?
   1. The RM says in Section 31.4.4 ‘If there is an ECC failure detected, the process is started again at the next boot block’.  Does the NFC use the NAND Boot eFUSES for BOOT SEARCH COUNT (BOOT_CFG[4:3]) to determine how many blocks from the beginning of the device to search?
   2. The NFC doesn’t care what the block size is as long as the pages are at least 1024 bytes with at least 32 byte spares for each page, correct?
5. The U-boot source code creates a 2K memory buffer initialized with 0xFF for every byte, that contains only the FCB.  The entire page gets written to the first page of the NAND flash (writing 0’s) with HW ECC in bypass mode.  The write occurs using the nand_write_skip_bad() function so it could actually get placed in a page other than the very first page if it were somehow marked FACTORY BAD.
   1. What’s the purpose/rationale for writing the FCB to flash with HW ECC in bypass?
   2. What’s the purpose of the NFC controller’s HW ECC at boot if the ROM is also going to run software ECC on the FCB?
6. Section 19.5.6.6 on Bad Block Handing in the ROM, Table 19-34, the first entry for 2112-byte per page NAND (2048 bytes + 64 spare) suggests you do not need to account for the factory bad block marker swap since the virtual buffers line up such that the factory bad block marker is in the right spot so no compensation (BI relocation) is required.
   1. Can you confirm that for (BBOFF[NVP] != 0) that any software that WRITES to NAND needs to compensate for this mis-alignment to preserve the factory bad block markers in the flash?
   2. The Vybrid TOWER Card (TWR-VF65GS10) uses the Micron Part MT29F2G16ABAEAWP (1056-byte page size + 32 words x16).  The part is also offered in a x8 configuration (2112-byte page size, 2048 data + 64 spare) – both configurations line up nicely according to Table 19-34 so no BI swap is needed.  Code to handle other configurations that require BI swap is not included in U-boot.  Is support for this planned at some point?  If so, When?

Jason

317.908.5314

[dan_douglass · Accepted solution]

Questions:

1. Section 19.5.6, which is describing the ROM behavior during boot seems to suggest that Vybrid NAND boot behaves similar to the i.MX6, with less configuration options, where Section 31.4.4 discusses how the NFC controller operates at a lower level that is really abstracted and may only be relevant to the ROM code.
   1. Is this an accurate interpretation of these two sections at a high level?    Yes, I believe this is accurate, with the caveat that i.MX6 and Vybrid use completely different NAND controllers.
2. Section 31.4 (Functional Description), near the end suggests ‘Page size at boot is set to 1056 bytes to be compatible with a large number of NFC devices, without needing additional power-on reset flags to indicate boot device’.  If this is accurate, as long as the NAND flash page size is a multiple of 1K, with at least 32bytes of spare area for per 1K of page data size (1024 byte page + 32 byte spare) that Vybrid can boot from that NAND (i.e. common configurations would be: 1K page with 32-bytes of SPARE/ECC per page (1056 bytes), 2K page with 64-bytes of SPARE/ECC per page (2112 bytes),  4K page with 128-bytes of SPARE/EC per page (4224), 4K page with 224-bytes of SPARE/ECC per page (4320 bytes).
   1. What is the actual limitation on what configuration of NAND is supported for boot?  Is it limited by the NFC or the ROM?    The limitation is in the ROM. The ROM configures the NFC for 2k page sizes to perform the FCB search.
   2. Note:  The U-boot bootloader uses hard-coded values matching the 2112-byte page configuration for the device on the tower card, so it's not clear what the NFC/ROM can or can't handle.   There are many things hardcoded. I would treat it as a reference.
3. Between the two sections in the RM (31.4.4, 19.5.6) and the bootloader source code it’s not clear what exactly happens when booting from NAND (between the NFC controller and the ROM boot code).
   1. Does the NFC controller automatically read 4K (4 x 1024data+32spare) into the NFC SRAM and validate this using hardware ECC?   No. I describe the ROM boot flow below.
   2. This would happen before the ROM code starts executing, so by the time the ROM code gets to handling the NAND boot the data in the NFC SRAM buffer is already valid and should contain at least a valid FCB, correct? No, nothing happens before the ROM code is executing.
4. If the first block of a given device could be “theoretically” be BAD, how does the NFC would automatically determine what block read next looking for a HW ECC match?
   1. The RM says in Section 31.4.4 ‘If there is an ECC failure detected, the process is started again at the next boot block’.  Does the NFC use the NAND Boot eFUSES for BOOT SEARCH COUNT (BOOT_CFG[4:3]) to determine how many blocks from the beginning of the device to search?   Yes, the ROM uses these fuses to determine the search limit.
   2. The NFC doesn’t care what the block size is as long as the pages are at least 1024 bytes with at least 32 byte spares for each page, correct?   To perform the FCB search the ROM's initial configuration for the NFC is 2k page size.
5. The U-boot source code creates a 2K memory buffer initialized with 0xFF for every byte, that contains only the FCB.  The entire page gets written to the first page of the NAND flash (writing 0’s) with HW ECC in bypass mode.  The write occurs using the nand_write_skip_bad() function so it could actually get placed in a page other than the very first page if it were somehow marked FACTORY BAD.
   1. What’s the purpose/rationale for writing the FCB to flash with HW ECC in bypass?   The ROM FCB search is done with HW ECC disabled. Once the FCB is located it performs a software ECC check to verify the FCB.
   2. What’s the purpose of the NFC controller’s HW ECC at boot if the ROM is also going to run software ECC on the FCB?   The HW ECC mode is configurable through the FCB. The FCB is read and then the HW ECC is configured by the ROM based on the FCB. All subsequent reads are done with the FCB's indicated configuration.
6. Section 19.5.6.6 on Bad Block Handing in the ROM, Table 19-34, the first entry for 2112-byte per page NAND (2048 bytes + 64 spare) suggests you do not need to account for the factory bad block marker swap since the virtual buffers line up such that the factory bad block marker is in the right spot so no compensation (BI relocation) is required.
   1. Can you confirm that for (BBOFF[NVP] != 0) that any software that WRITES to NAND needs to compensate for this mis-alignment to preserve the factory bad block markers in the flash?   I cannot confirm this at this time. It will require some investigation.
   2. The Vybrid TOWER Card (TWR-VF65GS10) uses the Micron Part MT29F2G16ABAEAWP (1056-byte page size + 32 words x16).  The part is also offered in a x8 configuration (2112-byte page size, 2048 data + 64 spare) – both configurations line up nicely according to Table 19-34 so no BI swap is needed.  Code to handle other configurations that require BI swap is not included in U-boot.  Is support for this planned at some point?  If so, When?   Also unknown at this time.

NAND Boot Steps:

1. ROM configures the NFC to 2k page size and samples fuses for configurable values.

2. ROM performs FCB search. If found, performs software ECC check to validate.

3. ROM uses the FCB to configure the NFC as indicated by the FCB. This includes HW ECC levels and page size. See the FCB structure for other NFC options.

4. ROM reads 4k of data from the firmware start address indicated in the FCB.

5. The 4k contains the IVT and DCD, this is evaluated and processed by HAB.

6. The remaining image is loaded based on the IVT.

[timesyssupport]

JeffKudrick - on prior engineering calls regarding Vybrid and NAND boot support, you had provided a rather detailed explanation of the NAND boot process, as you were working through issues at the time getting it functional, before releasing. Are you able to provide a summary of that process? If it is not readily available, we can take the time to step through the code map the boot process.

Regards,

Timesys Support

[karina_valencia]

timesyssupport can you help on this case?

[karina_valencia]

Adding ioseph_martinez who also will help to provide follow up on this case.

[karina_valencia]

ioseph_martinez do you have an update on this case?

[karina_valencia]

Timesys Support can you help on this case?