Booting from NAND flash on i.MX6-based platforms
With respect to the NOR flash memories, NAND devices are known to be quite challenging with regard to the reliability. This is especially true when the NAND flash is used as the boot device. Several techniques such as wear leveling and bad block management have to be implemented to achieve an acceptable reliability.
This document provides information about the NAND device management, in order to handle it properly when it is used as the boot device on NXP i.MX6-based products.
Even though the example shown here refers to an i.MX6SoloX board, the approach is substantially the same across all the i.MX6 family.
The test bed used in this example consists of an i.MX6SoloX-board equipped with a 512MB 8-bit asynchronous 1-bit ECC SLC NAND memory which is connected to the EIM bus of the SoC. The boot firmware image is the U-Boot binary file (
mx6sx_board_nand_u-boot.imx). Its size is about 400 kB. From the point of view of MTD partitions, the boot partition is
mtd0 which is 8MB.
Boot partition organizationEdit
The following image shows the organization of the boot partition.
The bootrom plays a major role in the boot process of any i.MX6 SoC. In case the NAND memory is the boot devices, this implies that the boot partition must be organized in order fulfill the bootrom requirements. Specifically, it contains:
- A 1MB area (named Flash Control Block, FCB) which, in turn, includes
- A data structure called NAND Control Block (NCB)
- Three addresses which indicate where are located
- The Discovered Bad Block Table (DBBT) which is the data structure used to manage the bad blocks of the NAND flash
- The first copy of the firmware to load
- The second (redundant) copy of the firmware to load
- The DBBT
- The first copy of the firmware
- The second copy of the firmware.
For more details about the bootrom e the NAND boot process, please refer to the System Boot chapter of the Reference Manual of the specific i.MX6 Application Processor.
The following section will describe how to burn the boot partition in practice.
How to burn the boot partitionEdit
|This application note was validated before XELK 4 kit version which is using u-boot SPL. Instruction ha to be modified according to Standalone boot from NAND page.|
The burning of the boot partition is performed by the
When the NAND flash is not burned yet, the product is usually configured in order to boot from a different device such as an SD card or through serial download mode. Once the Linux kernel is up and running, the
kobs-ng can be run as shown in the following example:
./kobs-ng-5.4 init -x -v -w --chip_0_device_path=/dev/mtd0 mx6sx_board_nand_u-boot.imx MTD CONFIG: chip_0_device_path = "/dev/mtd0" chip_1_device_path = "(null)" search_exponent = 2 data_setup_time = 80 data_hold_time = 60 address_setup_time = 25 data_sample_time = 6 row_address_size = 3 column_address_size = 2 read_command_code1 = 0 read_command_code2 = 48 boot_stream_major_version = 1 boot_stream_minor_version = 0 boot_stream_sub_version = 0 ncb_version = 3 boot_stream_1_address = 0 boot_stream_2_address = 0 -- We add the 1k-padding to the uboot. .tmp_kobs_ng: verifying using key '00000000000000000000000000000000' .tmp_kobs_ng: is a valid bootstream for key '00000000000000000000000000000000' mtd: use legacy raw access mode mtd: opening: "/dev/mtd0" NFC geometry : ECC Strength : 2 Page Size in Bytes : 2071 Metadata size : 10 ECC Chunk Size in byte : 512 ECC Chunk count : 4 Block Mark Byte Offset : 2028 Block Mark Bit Offset : 2 ==================================================== mtd: opened '/dev/mtd0' - '(null)' mtd: max_boot_stream_size_in_bytes = 3670016 mtd: boot_stream_size_in_bytes = 398380 mtd: boot_stream_size_in_pages = 195 mtd: #1 0x00100000 - 0x00480000 (0x0016142c) mtd: #2 0x00480000 - 0x00800000 (0x004e142c) FCB m_u32Checksum = 0x00000000 m_u32FingerPrint = 0x20424346 m_u32Version = 0x01000000 m_NANDTiming.m_u8DataSetup = 80 m_NANDTiming.m_u8DataHold = 60 m_NANDTiming.m_u8AddressSetup = 25 m_NANDTiming.m_u8DSAMPLE_TIME = 6 m_u32PageDataSize = 2048 m_u32TotalPageSize = 2112 m_u32SectorsPerBlock = 64 m_u32NumberOfNANDs = 0 m_u32TotalInternalDie = 0 m_u32CellType = 0 m_u32EccBlockNEccType = 1 m_u32EccBlock0Size = 512 m_u32EccBlockNSize = 512 m_u32EccBlock0EccType = 1 m_u32MetadataBytes = 10 m_u32NumEccBlocksPerPage = 3 m_u32EccBlockNEccLevelSDK = 0 m_u32EccBlock0SizeSDK = 0 m_u32EccBlockNSizeSDK = 0 m_u32EccBlock0EccLevelSDK = 0 m_u32NumEccBlocksPerPageSDK = 0 m_u32MetadataBytesSDK = 0 m_u32EraseThreshold = 0 m_u32Firmware1_startingPage = 512 m_u32Firmware2_startingPage = 2304 m_u32PagesInFirmware1 = 195 m_u32PagesInFirmware2 = 195 m_u32DBBTSearchAreaStartAddress = 256 m_u32BadBlockMarkerByte = 2028 m_u32BadBlockMarkerStartBit = 2 m_u32BBMarkerPhysicalOffset = 2048 m_u32BCHType = 0 m_NANDTMTiming.m_u32TMTiming2_ReadLatency = 0 m_NANDTMTiming.m_u32TMTiming2_PreambleDelay = 0 m_NANDTMTiming.m_u32TMTiming2_CEDelay = 0 m_NANDTMTiming.m_u32TMTiming2_PostambleDelay = 0 m_NANDTMTiming.m_u32TMTiming2_CmdAddPause = 0 m_NANDTMTiming.m_u32TMTiming2_DataPause = 0 m_NANDTMTiming.m_u32TMSpeed = 0 m_NANDTMTiming.m_u32TMTiming1_BusyTimeout = 0 m_u32DISBBM = 0 m_u32BBMarkerPhysicalOffsetInSpareData = 0 m_u32OnfiSyncEnable = 0 m_NANDONFITiming.m_u32ONFISpeed = 0 m_NANDONFITiming.m_u32ONFITiming_ReadLatency = 0 m_NANDONFITiming.m_u32ONFITiming_CEDelay = 0 m_NANDONFITiming.m_u32ONFITiming_PreambleDelay = 0 m_NANDONFITiming.m_u32ONFITiming_PostambleDelay = 0 m_NANDONFITiming.m_u32ONFITiming_CmdAddPause = 0 m_NANDONFITiming.m_u32ONFITiming_DataPause = 0 m_NANDONFITiming.m_u32ONFITiming_BusyTimeout = 0 m_u32DISBBSearch = 0 m_u32RandomizerEnable = 0 m_u32ReadRetryEnable = 0 m_u32ReadRetrySeqLength = 0 DBBT m_u32Checksum = 0x00000000 m_u32FingerPrint = 0x54424244 m_u32Version = 0x01000000 m_u32DBBTNumOfPages = 0 Firmware: image #0 @ 0x100000 size 0x61800 - available 0x380000 Firmware: image #1 @ 0x480000 size 0x61800 - available 0x380000 -------------- Start to write the [ FCB ] ----- mtd: erasing @0:0x0-0x20000 mtd: Writing FCB0 [ @0:0x0 ] (840) * mtd: erasing @0:0x20000-0x40000 mtd: Writing FCB1 [ @0:0x20000 ] (840) * mtd: erasing @0:0x40000-0x60000 mtd: Writing FCB2 [ @0:0x40000 ] (840) * mtd: erasing @0:0x60000-0x80000 mtd: Writing FCB3 [ @0:0x60000 ] (840) * mtd_commit_bcb(FCB): status 0 -------------- Start to write the [ DBBT ] ----- mtd: erasing @0:0x80000-0xa0000 mtd: Writing DBBT0 [ @0:0x80000 ] (800) * mtd: erasing @0:0xa0000-0xc0000 mtd: Writing DBBT1 [ @0:0xa0000 ] (800) * mtd: erasing @0:0xc0000-0xe0000 mtd: Writing DBBT2 [ @0:0xc0000 ] (800) * mtd: erasing @0:0xe0000-0x100000 mtd: Writing DBBT3 [ @0:0xe0000 ] (800) * mtd_commit_bcb(DBBT): status 0 ---------- Start to write the [ .tmp_kobs_ng ]---- mtd: Writting .tmp_kobs_ng: #0 @0: 0x00100000 - 0x00161800 mtd: erasing @0:0x100000-0x120000 mtd: erasing @0:0x120000-0x140000 mtd: erasing @0:0x140000-0x160000 mtd: erasing @0:0x160000-0x180000 mtd: The last page is not full : 1068 mtd: We write one page for save guard. * mtd: Writting .tmp_kobs_ng: #1 @0: 0x00480000 - 0x004e1800 mtd: erasing @0:0x480000-0x4a0000 mtd: erasing @0:0x4a0000-0x4c0000 mtd: erasing @0:0x4c0000-0x4e0000 mtd: erasing @0:0x4e0000-0x500000 mtd: The last page is not full : 1068 mtd: We write one page for save guard. *
In this case, the boot partition–
/dev/mtd0, indicated as a parameter of the command line–is 8MB. For this reason, the secondary firmware image is stored at the address 0x480000, that is at the half of the available space after the first MB ( (0x800000-0x100000)/2 ).