This is an old revision of the document!
U-BOOT Monitor
- See also serial connections.
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.