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 tool collection
RBL, UBL and host tool collection is a collection of ready to use tools to deal with DaVinci RBL boot mechanism. This collection is one of several different implementations available. Other implementations are MMS UBLs and Flasher, Sergeys UBL and host tool and TIs DVFlasher.
Latest RBL UBL and host tool collection is version 0.2. It is available from DaVinci mailing list archive. Save binary attachment as dv-rbl-ubl-host-tool_v0.2.tar.bz2 and extract it using
tar xvfj dv-rbl-ubl-host-tool_v0.2.tar.bz2
This tool collection contains
- rboot UBL from Rudy Reinsch <Rudy.Reinsch_at_AuPix.com> written in ARM assembly.
- Windows host tool from Peter Wippich <pewi_at_gw-instruments.de> written in C.
- Port of windows host tool to Linux from Dirk Behme <dirk.behme_at_gmail.com> written in C as well.
All tools are included in source and precompiled binaries (except windows host tool) for easy quick start without compilation. Additionally, a precompiled U-Boot 1.3.0 binary for RAM usage is included. U-Boot has to be compiled specifically if not intendended to be started from NOR. The U-Boot binary can be loaded and started by UBL directly in RAM. It then works the same way as if started initially from NOR.
Linux only, windows untested: Configure DaVinci board for UART boot mode (S3-1: ON, S3-2: ON). Then go to bin_linux directory of extracted dv-rbl-ubl-host-tool_v0.2 and type
./dv_host <serial port> e.g. ./dv_host /dev/ttyS0
with serial port DaVinci is connected to. Now enable DaVinci power and UBL download should start:
> ./dv_host /dev/ttyS0 TI DaVinci host RBL and UBL tool (c) 2005 G&W Instruments for Windows version (c) 2007 Dirk Behme <firstname.lastname@example.org> for Linux port Using port /dev/ttyS0 to connect to DaVinci - okay Read 3000 bytes from: rboot.bin - okay Waiting for BOOTME message from Davinci (press key to stop) .... BOOTME - okay Sending ACK - okay Waiting for BEGIN message from Davinci BEGIN - okay Sending empty CRC table - okay Waiting for crc DONE message from Davinci DONE - okay Sending rboot.bin - okay Waiting for data DONE message from Davinci DONE - okay Waiting for UBL message from Davinci ee Rboot-> - okay Sending u-boot_ram.bin with size of 142920 bytes ............................................................ - okay Waiting for data DONE message from Davinci UBL lDone - okay Waiting for UBL message from Davinci . # Rboot-> - okay Starting uboot at 0x81080000 ... - okay Waiting for U-Boot message from Davinci g U-Boot - okay Start terminal program now, e.g. minicom - Bye >
After u-boot_ram.bin is loaded and started, host tool terminates. U-Boot is now running in target RAM. Then, start a terminal program (e.g. minicom or kermit) on same serial port like above (e.g. /dev/ttyS0) with 115200 8N1. Hit return once to connect to running U-Boot and you should get U-Boot command prompt. Now you can use U-Boot normally, e.g. to load something via TFTP (Linux kernel, U-Boot for ROM), to start Linux or flash resident U-Boot to NOR or NAND:
To automatically start bootloader U-boot every time board is powered, it can be saved in NOR or NAND flash. Then, RBL, UBL and host tooling is only used once to get U-Boot stored on a completely empty board. Next times, board uses permanently stored U-boot in NOR or NAND to start.
For this, U-Boot running from RAM like described above is used to write (other) versions of U-Boot to NOR or NAND. First, these (other) versions to be stored to NOR or NAND have to be downloaded e.g. via TFTP using U-Boots tftpboot command. For how to use tftpboot and install PC TFTP server necessary see TIs DVEVM getting started guide, section A.4 for PC TFTP server setup.
Note: On the DVEVM, the DM644x CS2 pin is connected to one of four places, based on the setting of the J4 jumper. If set to "FLASH" the CS2 (also sometimes called CE2) connects to the chip enable of the NOR flash. Set to "SRAM", it is an enable for the SRAM. Set to "NAND", it is the chip enable signal for the NAND flash. Set to DC, it is routed to the daughter card expansion. In all cases the memory map of the DM644x sees the CS2 space spanning 0x02000000 to 0x03FFFFFF. Only one device can be used at a time because the J4 jumper allows the CS2 to route to only one of the four locations at any given time. The unconnected chip enables are all pulled up high.
To permanently store UBL to NOR flash, first make sure that
- jumper J4 is set to FLASH
- S3-1 and S3-2 are set to ON (serial UART boot)
- S3-3 is set to ON (16-bit CS2 bus width)
Then use U-Boot running from RAM downloading and flashing NOR version of U-Boot:
U-Boot > tftpboot 0x80000000 u-boot_rom.bin TFTP from server 192.0.0.1; our IP address is 192.0.0.2 Filename 'u-boot_rom.bin'. Load address: 0x80000000 Loading: ########## done Bytes transferred = 142852 (22e04 hex) U-Boot > protect off 0x02000000 +0x23000 Un-Protected 3 sectors DaVinci EVM RAM > erase 0x02000000 +0x23000 ... done Erased 3 sectors U-Boot > cp.b 0x80000000 0x02000000 0x23000 Copy to Flash... done U-Boot > protect on 0x02000000 +0x23000 Protected 3 sectors U-Boot >
Note: u-boot_rom.bin is NOR version of U-Boot. This the "normal" u-boot.bin you will get using make davinci_dvevm_config. Resulting u-boot.bin was renamed to u-boot_rom.bin (to distinguish from RAM version loaded by UBL) and then placed in hosts /tftpboot directory.
Note: Flash unprotect/erase/write/protect size, e.g. 0x23000 above, has to be the size (or here slightly larger) than u-boot_rom.bin size (22e04 hex).
After u-boot_rom.bin is now written to NOR flash, set S3-2 OFF to initially boot from NOR flash, power cycle your board and U-Boot should start in ROM.
To permanently store UBL in NAND flash, first make sure that
- jumper J4 is set to NAND
- S3-1 and S3-2 are set to ON (serial UART boot)
- S3-3 is set to OFF (8-bit CS2 bus width)
Note: If no working NAND UBL is NAND, you can also set S3-1 and S3-2 to OFF (NAND boot). If RBL doesn't find a valid NAND UBL, it switches back to serial UART boot. So with empty NAND S3-1 and S3-2 to OFF (NAND boot) has the same effect than S3-1 and S3-2 to ON (UART boot). But attention: Once there is a valid working UBL in NAND, this will be started and to re-write NAND UBL again, you really have to use S3-1 and S3-2 to ON (serial UART boot) then.
If NAND UBL is written now, switch S3-1 and S3-2 to OFF (NAND boot) now and power cycle the board. NAND UBL should start now.
You cannot use u-boot's NAND drivers to write the UBL because the RBL (that loads the UBL) expects a non-standard ECC format.