This is an old revision of the document!


U-BOOT Monitor

Monitor Mode

  • Type the two keys SPACE and 1 before the monitor 3 second timeout.

Enabled Commands

The standard U-Boot on my B1 hardware has the following commands enabled:

Marvell>> ?
?       - alias for 'help'
bootm   - boot application image from memory
cp      - memory copy
echo    - echo args to console
erase   - erase FLASH memory
loadb   - load binary file over serial line (kermit mode)
md      - memory display
printenv- print environment variables
run     - run commands in an environment variable
setenv  - set environment variables
Marvell>> 

It is pretty limited, but is enough to recover a failed firmware installation.

There is mention made of additional commands which may be enabled through setting the environment variable “enaMonExt” to “yes” (“setenv enaMonExt yes” at the U-Boot prompt). Examination of the Marvell sources confirm this variable name, and what it is supposed to do.

Unfortunately, it simply results in the following output for any “advanced” commands:

Marvell>> tftpfs
Unknown command 'FSrun' - try 'help'
Marvell>> blah
Unknown command 'FSrun' - try 'help'
Marvell>> 

As you can see, the command is being translated to “FSrun”, which indicates that the “enaMonExt” code path is being followed, but unfortunately, the version of U-Boot that I have was compiled without support for the “FSrun” command, which means that this has no meaningful effect on this hardware.

Exploring U-Boot

The version of U-Boot provided by DLink (on the B1 hardware) is EXTREMELY limited. Pretty much the only way to do anything in the bootloader is to chainload an additional program, because not even the “go” command is supported.

One way to achieve this is to build a new version of U-Boot, wrap it in a suitable header using “mkimage”, and then booting the new U-Boot.

Until recently, there was no support for the Orion architecture in U-Boot trunk. That changed with the addition of support for the LaCie edminiv2, which is also based on the same SoC.

While the basic SoC is the same, the flash part is different. Once I have managed to determine the correct configuration to allow the flash chip to be recognized by U-Boot, I will contribute a patch to the U-Boot maintainers to enable that support.

Here are some basic steps that can be followed to build your own U-Boot loader. The build platform was Ubuntu 10.04, on i386.

First, obtain a suitable cross compiler. The easiest way to do this is to get them from the Emdebian project.

Add the Emdebian repo to your /etc/apt/sources.list:

deb http://www.emdebian.org/debian/ lenny main

Then update the repositories:

sudo apt-get update
sudo apt-get install gcc-4.3-arm-linux-gnueabi
sudo apt-get install binutils-arm-linux-gnueabi
sudo apt-get install uboot-mkimage

Tell U-Boot which compiler you are using:

export CROSS_COMPILE=arm-linux-gnueabi-

Not knowing whether this image would work on more than just the B1 hardware, I chose to name it more specifically than less.

make clean mrproper dns323_b1_config
make
mkimage -A arm -O u-boot -T kernel -C none -a 0x8000 -e 0x8000 -n "UBoot dns323" -d u-boot.bin uImage.bin

The dns323_b1 board config specifically omits the low level initialisation code so that it can be chain loaded from an existing U-Boot loader. The image resulting from this process CANNOT be used to boot from poweroff!

In order to execute this new boot loader, it has to be uploaded to memory, using kermit. It goes without saying (I hope) that this requires a console cable already connected.

Here is my kermit connect script:

#!/usr/bin/kermit
echo connecting /dev/ttyUSB0 .....
set line /dev/ttyUSB0
set speed 115200
set serial 8n1
set carrier-watch off
set flow-control none
set handshake none
set prefixing all
set streaming off
set parity none
connect 

Once you are connected to the console, and have interrupted the boot process as described above (Press space, 1), you can then download this new boot loader into RAM:

loadb

Then press Ctrl-\ (Control-Backslash), followed by “c” to return to a Kermit prompt. Then:

send /path/to/uImage.bin

The “send” command takes a few seconds to actually start, but then it should show the progress of the upload. Once it is finished, type “c<Enter>” to return to the U-Boot console.

Now we can execute the new image:

bootm 0x100000

The address 0×100000 is the default address used by “loadb”. If your “loadb” uses a different address, you should update the “bootm” command above.

Now the new image should execute, and return you to a boot prompt, with a fully featured U-Boot loader ready to obey your commands, without having to run the risk of flashing something that may not boot, and having to recover using JTAG.

Current U-Boot now includes network support for Orion5x chips, and can easily be configured in a dns323 board config to enable DHCP, TFTP, etc. Work is under way to support booting from SATA as well as USB on the LaCie ED Miniv2, which is a very similar device to the DNS323.

Flash support is still lacking. Anyone who knows how to properly address the Spansion flash chip as used in the DNS323, and who would like to get this working in U-Boot is invited to post to the U-Boot list.


Navigation

Personal Tools