Davinci/Sitara/Integra Nand Boot FAQ
- 1 What is covered in this FAQ?
- 2 What are the steps to boot from NAND?
- 3 I am interested in using a particular NAND with a TI device. Will this NAND work?
- 4 What is ECC? Why is ECC required for NANDs?
- 5 What is the ECC support on DM/OMAPL13x/C678x?
- 6 Which part of the NAND boot can I control?
- 7 Why doesn’t TI certify specific NANDs that work with their RBLs?
- 8 What information about the raw NANDs is used by RBL?
- 9 What algorithms/methods are used by RBL to determine NAND geometry?
- 10 Does my TI device RBL supports ONFI NANDs? Does it support reading NAND parameters from SPI EEPROM?
- 11 What is 4th Byte ID?
- 12 My NAND doesn't work with a particular RBL. Does this mean that I can't use this NAND at all?
- 13 What are my options if I am not able to find a raw NAND that suits my needs?
- 14 Can I use managed NAND with this device?
- 15 Can I use a raw NAND with higher ECC requirements?
- 16 The NAND block size is a multiple of what the RBL interprets. Can I still boot through this NAND?
- 17 Why do I need to have multiple copies of the UBL and UBL descriptor?
- 18 My TI device specifies Chip Enable(CE) as "Don't care" for interfacing with NAND. Does that mean that I can not use "this" NAND?
- 19 What interfaces are available to flash the UBL?
What is covered in this FAQ?
This FAQ focus on various aspects of NAND bootmode in ROM bootloader (RBL) for Davinci/Sitara/Integra products. Some supporting wikis are:
- Determining compatibility between a version of RBL and a specific NAND.
- ECC support during boot.
- Managed NAND as an alternative for raw NAND.
- List of raw NAND devices supported by RBLs.
This FAQ does not cover boot related topics for UBL (User Boot Loader)/uBoot/Linux.
What are the steps to boot from NAND?
The NAND boot (or any other boot) is a multiple step process. Usually, a ROM Boot Loader (RBL) will load the user application which could be a User BootLoader (UBL) or any other user application. For applications using Linux, the following steps are usually followed:
- The ROM Bootloader (RBL) copies the User BootLoader (UBL) from the NAND flash to Internal RAM (IRAM).
- The UBL starts running and configures the DDR. It then copies u-boot from the flash to the DDR.
- u-boot starts running and copies the kernel from the flash to DDR. The kernel then starts running.
Users can choose to modify the above steps to suit their needs.
I am interested in using a particular NAND with a TI device. Will this NAND work?
There are two factors that determine compatibility of a NAND with TI device RBL:
- RBL ability to determine the NAND geometry/parameters. Please see Determining compatibility between ROM Bootloader (RBL) and Raw NAND devices for details.
- The Hardware ECC requirement of the NAND. If the NAND requires more ECC than the RBL provides, its advisable not to use this NAND. For example, DM335 RBL supports 4 bit ECC in hardware.
What is ECC? Why is ECC required for NANDs?
Please see Nand ECC.
What is the ECC support on DM/OMAPL13x/C678x?
DM/OMAPL13x/C674x device's EMIF hardware supports detection and correction for most of the devices. There is no software ECC generation in ROM Bootloader (RBL) in these devices as it is generated using the EMIF hardware. The following table outlines both the hardware detection and error correction capabilities available in the DM/OMAPL13x/C674x devices.
|Devices||Max ECC Detection (bits)||Max ECC correction(bits)||Algorithm|
Which part of the NAND boot can I control?
The flashing utilities, UBL, u-boot and kernel can all be modified by the user. Only RBL can't be changed.
Why doesn’t TI certify specific NANDs that work with their RBLs?
Due to the dynamic nature of the raw NAND market and the short life cycle of these raw NANDs (~2 years), it is not possible to certify the large variety of NANDs with each device RBL. However, we provide all of the details/help to enable the user to see if a particular NAND will work with a specific RBL.
What information about the raw NANDs is used by RBL?
RBL's need to know the NAND geometry to be able to read data from the NAND. Please see Background for details.
What algorithms/methods are used by RBL to determine NAND geometry?
Please see Various Approaches used in RBLs to determine NAND geometry for details.
Does my TI device RBL supports ONFI NANDs? Does it support reading NAND parameters from SPI EEPROM?
Please see RBL NAND support in TI devices.
What is 4th Byte ID?
Please see Methods used by NAND manufacturers.
My NAND doesn't work with a particular RBL. Does this mean that I can't use this NAND at all?
If a NAND doesn't work with a specific RBL, that doesn't necessarily mean that the TI device doesn't support the NAND. If the RBL features is the limiting factor, the user can choose to boot from another interface/memory (e.g. SPI EEPROM), download its UBL and still use the NAND.
What are my options if I am not able to find a raw NAND that suits my needs?
If you are not able to find compatible NAND to work with the RBL, you can do any of the following:
- Switch from NAND to NOR Flash
- Secondary Boot From I2C or SPI EPROM
- By having this "secondary boot loader" available, customers can use the datasheets for their particular NAND device, review the parameters/geometry needed to correctly interface to the NAND such as block size and page size, and pre-program those parameters into the EPROM as a means of initializing the parameters needed in our current ROM bootloader code to "talk" to the NAND appropriately.
- Secondary Boot from external Microcontroller
- Using a slave boot mode (like I2C or SPI slave boot or UART boot modes), customers could boot the SoC, by "pushing" the "secondary boot loader" code into the SoC. This is pretty much similar to the above Secondary Boot from a EEPROM, but in this case, the secondary boot loader is loaded to the device through a microcontroller.
- Switch to Managed NAND
- Move from a raw NAND support strategy to one that involves the use of "managed NAND" which includes a NAND controller that can perform the required ECC.
- Use NAND requiring higher ECC than is supported in Hardware (although this is not recommended)
NOTE: If you are already using a NAND, it is advisable to secure a lifetime buy for this NAND.
Can I use managed NAND with this device?
Managed NAND is a raw NAND with a memory controller and usually has an MMC/SD interface. The managed NANDs are popularly known as eMMC/eSD/moviNAND/iNAND. The ECC for managed NAND is handled in the memory controller (inside the managed NAND). Any device (microcontroller/microprocessor/DSP) which has a MMC/SD interface should be able to talk to managed NAND.
Many TI devices have MMC/SD support. Many of these even have an MMC/SD boot mode. These TI devices should support at least the basic read write operations with the managed NAND using the MMC/SD interface. For more details about the support, please refer to the TI device datasheets.
Can I use a raw NAND with higher ECC requirements?
There is risk of boot failure when a NAND with a higher ECC requirement than what is supported in the hardware/RBL of TI devices is used. Because the ECC errors might not be corrected, the NAND memory/pages that contain the UBL/user application can not be read by RBL and in this scenario the boot will fail.
Please check with the NAND manufacturer if this configuration can work with a particular NAND without risks of failure.
The NAND block size is a multiple of what the RBL interprets. Can I still boot through this NAND?
It's possible, provided the multiple is within the number of copies the RBL will read. For example, in the figure below, the block size is 64 KBytes. If the RBL interpretes the block size as 32 KBytes, it will find the UBL descriptor in Block 1, when it is trying to read the block assuming it is block 2 (for most RBLs, the RBL starts reading the NAND from block 1 (not block 0)). The red line indicates the block from where the UBL descriptor will be read.
In this example, if the block size is 64 KBytes and if the RBL interpretes the block size as 16 KBytes, it will find the UBL descriptor in Block 1, when it is trying to read the block assuming it is 4th block. The boot will be successful if the RBL makes at least 4 attempts (4*16KB = 64KB) to read the UBL descriptor in consecutive blocks.
In a real scenario, for MT29F8G08ABABA NAND and DM365, as in forum post:
Based on the 4th byte, the DM365 RBL will configure itself for 4K pages & 256K Blocks (i.e. 64 pages / block) but from the datasheet, the actual NAND configuration is 4K pages & 512K blocks. It's not identical but it is a multiple so DM365 is successfully reading it.
Please nore that the number of copies of UBL descriptor that RBL looks for varies from device to device. Please see the device documentation for details.
Why do I need to have multiple copies of the UBL and UBL descriptor?
Many RBL's suggest flashing multiple copies of the UBL descriptor and UBL. This is not a functional requirement. However, it is strongly recommended.
Multiple copies will ensure that the boot happens successfully even if some of the pages in the NAND have gone BAD or if some pages in the NAND have more ECC errors than expected/specified; e.g., if DM365 supports 4-bit hardware ECC and greater than 4 bits of error are being detected.
My TI device specifies Chip Enable(CE) as "Don't care" for interfacing with NAND. Does that mean that I can not use "this" NAND?
Not necessarily. Some TI devices do not support NAND Flash devices which require the chip select signal to remain low (during the tR time for a read). As an example and possible workaround for DM365, please see Section 126.96.36.199 in TMS320DM36x DMSoC Asynchronous External Memory Interface User's Guide (Rev. C).
What interfaces are available to flash the UBL?
TI usually provides a sample application to flash NAND through serial and/or JTAG interfaces. However, it is possible to flash NAND from any other interface (e.g. MMC/SD, Ethernet etc). For example SD card boot and flashing tool for DM355 and DM365 can be used to flash the NAND through an SD card.