AnsweredAssumed Answered

Understanding VYBRID NAND Boot

Question asked by Jason Moss Employee on Sep 13, 2013
Latest reply on Sep 26, 2013 by Dan Douglass

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 ( 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 <>

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.



  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 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?