NOTICE: The Processors Wiki will End-of-Life in December of 2020. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.
RBL UBL and host program
DaVinci has an internal BootROM, where a small boot loader program is stored, which can be invoked by special jumper settings. With this BootRom it is possible to download SW to a DaVinci system where no code is actually stored in NOR or NAND flash the ARM processor can boot from. This can be used to download the first code ever to a DaVinci based board or to recover from broken system. This article collects information about this feature.
- 1 Naming
- 2 RBL
- 3 UBL and Flashing Utilities
- 4 Host program
While talking about this DaVinci BootROM feature, there are three SW parts involved. The naming for these are:
- RBL == ROM boot loader. This part is stored in ROM in DaVinci and therefore can't be changed by user. If needed, it can be activated by special jumper settings. It can be used to start system SW (download) via serial line, from NAND devices or HPI (Host Port Interface).
- UBL == user boot loader. The SW the RBL starts/downloads is called user boot loader. Download has to be done in a special format the RBL expects. UBL is limited in size. Sometimes UBL is called 2nd stage boot loader as well.
- Host program, known as serial host utility program as well. This SW runs on the development host (typically a PC with Windows/Linux) and communicates with RBL (and UBL) if RBL is used in UART (serial) line download mode.
RBL modes and info
The RBL supports 3 distinct boot modes depending on device configuration pins BTSEL[1:0]:
- BTSEL[1:0] = 00 - ARM NAND Boot
- BTSEL[1:0] = 11 - ARM UART Boot
- BTSEL[1:0] = 10 - ARM HPI Boot
If BTSEL[1:0] = 01 the ARM boots from NOR flash without RBL involved.
On DaVinci EVM these settings can be done by Jumper S3-1 and S3-2.
The DM355 supports boot from SD/MMC card rather than HPI. On the DM355 EVM the boot modes are selected by the pair of dip switches SW7.
Further info about RBL can be found in:
- TI document SPRUE14A - TMS320DM644x DMSoC ARM Subsystem Reference Guide (Rev. A), Chapter 12: Boot modes
- TI document SPRAAI0 - Basic Application Loading over the Serial Interface for the DaVinci TMS320DM644x
- TI document SPRAAI4 - Booting and Flashing via the DaVinci TMS320DM644x Serial Interface
- Programming via UART - mail from Rudy Reinsch at DaVinci mailing list.
RBL booting from NAND and ECC/Bad blocks
The RBL does not do any form of bad block checking/management. It will simply rely on using the HW ECCs generated during the page reads to verify that a page read was correct. This means that the HW ECC values generated during the reads of each 512 bytes of data will be compared against the ECC values that are stored in the spare bytes of the NAND page. If the RBL sees an ECC mismatch occur during a page read, it will abort the operation from that block and try the next block. It will do this up to block 5 of the NAND device, strting from block 1 (skipping over block 0). If there is an ECC mismatch, the RBL will NOT use the ECC values to do bit error correction, even though the mismatched values could be used to find and correct a single-bit error.
If the RBL can't get a successful read out of the first five blocks, the boot will fail and will default to attempting a UART boot. One recommendation would be to fill the first five blocks with the same header and UBL. Then if the first one ever goes bad, you'll already have four more copies ready to do the job. But if all five of those blocks go bad (which I think is VERY unlikely over the lifetime of the device) then the device won't boot.
But if a block does go bad, the ECC check should detect it, unless the data and ECC are both corrupted in such a way that they still match (which I think would be extremely improbable). So a corrupted image booting up should never be an issue.
Since the pages/blocks holding the UBL aren't going through read and write cycles on a continuous basis, they will probably last a good while, but I understand that blocks can lose their data after some time, so some kind of periodic rewrite of these blocks might be a good idea, like maybe every 1000th system shutdown, for example.
UBL and Flashing Utilities
For UBL there are various versions available. One key point to understand is that the flashing utility, which writes the UBL and u-boot image, and the UBL itself are intricately related. The UBL must understand what format the u-boot image was stored in, and where in the NAND blocks and pages to find the image. The TI UBL and flashing utilites, as an example, use a header scheme very similar to the one used for the UBL image. The UBL searches over a particular range of blocks to locate and parse this header, which provides the necessary info to locate and load the actual u-boot image. This is the same way the DM644x RBL looks for the UBL image. Any other scheme could be used, as long as the flashing program, which writes the u-boot image, and the UBL, which has to read and load the u-boot image, agree on what it is.
DaVinci Serial Boot and Flashing Utilities UBL
Support for DM35x, DM644x, and DM646x. Based on the original TI code, released under GPLv2.
The Serial Boot and Flash Loading Utility provides modular set of UBL programs to enable you to download and run code in RAM or to burn images to NOR and NAND flash. The project also provides a Host Application for downloading and running these UBLs via the UART Boot Mode.
TI UBL (original)
The TI UBL is contained as part of the DVFLasher flash utility. See below TI host program for more information about obtaining and using the DVFLasher utility and its UBL.
rboot from Rudy Reinsch from DaVinci mailing list
This is derived from U-Boot and has to be compiled with script rbm (in above posting as well). Together with matching open source host tool (see below) it is able to load a third stage loader.
This was repackaged by Dirk Behme together with windows and host tool to RBL UBL and host tool collection.
See posting on U-Boot mailing list.
There are several Host applications available to download the UBL using the DaVinci UART Boot Mode.
DaVinci Serial Boot and Flashing Utilities
Support for DM35x, DM644x, and DM646x. Based on the original TI host program (listed above).
The Serial Boot and Flash Loading Utility provides several modular UBL programs and the C# Host Download and Flash tools. The source code is hosted on http://sourceforge.net/projects/dvflashutils/ and it has been released under GPLv2. Parts of the development effort for this project have been sponsored by Texas Instrument, Inc. Thanks to TI for supporting an Open Source project!
TI host program (original)
The TI host program, DVFlasher, is written in C# and can be run on Windows with .NET or on Linux with mono. Under Windows, the application can use either the .Net Framework (provided for free at http://www.microsoft.com/) or the Mono Framework (available at http://www.mono-project.com/). Under Linux, the Mono Framework is the only option.
The DVFlasher program can be obtained at http://www.ti.com/dvevmupdates under "DM644x DVEVM" in the "DaVinci DM644x EVM Miscellaneous Components" section. See the readme.txt file contained in the DVFlasher package for more usage information. For a step by step example of how to use this utility to flash a new version of u-boot to NAND flash please see flashing NAND with DVFlasher.
For more information on the DVFlasher program please refer to TI document SPRAAI4.
Note: Code examples for TI document SPRAAI4 spraai4.zip contain a (older) DVFlasher as well. But this outdated and shouldn't be used any more. Use latest DVFlasher available via dvevmupdates above.
DV RBL UBL Host Tool (originally load.c and dv_host)
The original load.c and dv_host code was repackaged by Dirk Behme together with windows and host tool to RBL UBL and host tool collection. Some code released under GPLv2 (but not all files include a GPL license).
- load from Peter Wippich from DaVinci mailing list.
This is for windows console and has to be compiled on your own. It works in relation with rboot (see above) and tries to load hard coded u-boot_ram.bin (U-Boot image to be run from RAM only). In a fourth step (RBL -> UBL (rboot) -> u-boot_ram.bin -> Load and write "normal" U-Boot to NOR flash) this then loads and writes the final U-Boot to NOR flash. rboot isn't able to directly write NOR/NAND flash. Therefore, a special U-Boot version (RAM only) has to be used in third step which is capable to write NOR or NAND flash. U-Boot itself can't be an UBL because UBL has size restriction and U-Boot is to large for this.
Sergeys host tool
See posting on U-Boot mailing list.