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.

Availability

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

Contents

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.

Usage

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 <dirk.behme@gmail.com> 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:

Permanent storage

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.

NOR

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.

NAND

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.

tbd.

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.