U-boot for LS Pro
Contents
Background & Facts
What is U-Boot?
U-Boot, or Das U-Boot, is a open-source, universal bootloader that is used in the LinkStation Pro/Live/KuroPro and other ARM-based NAS devices that Buffalo Technology makes. It has become more widespread in its use in other brands as well. Pre-ARM LinkStations/Kuro's had a proprietary bootloader, though LinuxNotIncluded and other members of the community here worked to bring U-Boot to the PPC and Mipsel based LinkStation devices as well.
We are all looking forward to a new, clean port of U-Boot for the LinkStation Pro.
Why upgrade it?
The build of U-Boot that is stock on the LS Pro (v1 and v2) and its contemporaries has very limited features, at least in comparision to what we have for the PPC LinkStations. Some noteworthy limitations to and exclusions from its capabilities include:
- no NetConsole - with netconsole and NetCat, one can connect to the unit with serial-style console control, over the network
- maximum number of arguments is 16, making changes of some of the more complicated env vars from the U-Boot side difficult or impossible
- missing commands:
- run - run commands in an environment variable
- dhcp - invoke DHCP client to obtain IP/boot params
- bdinfo - print Board Info structure
- loadb - load binary file over serial line (kermit mode)
- loads - load S-Record file over serial line
- ping - send ICMP ECHO_REQUEST to network host
- coninfo - print console devices and information
- crc32 - checksum calculation
While some of these commands aren't really essential, the first few are quite advantageous to have, and missing them is an impediment. It is notable that LinuxNotIncluded's ports to PPC and Mipsel have all of these capabilities.
Acknowledgements
Thanks to jonli447, lb_worm and others who worked on this and left a trail to follow for the rest of us. Also, thanks to bbradley, Nicolas Pitre, Dominic Rath and others who are working on a clean port of U-Boot for Feroceon or doing great things w/ OpenOCD so we can have a better U-Boot for LS Pro's and the other ARM-based LinkStations. bbradley also helped out w/ some of problems I was having w/ flashing in Linux.
Ready-Made U-Boot Images for LS Pro
Untar any of these before using. Flash (at your own risk) using the directions below.
Stock
These are stock U-Boot images, with ID strings shown:
- for the LS Pro V1 u-boot_LSProV1-stock.bin.tar.gz
U-Boot 1.1.1 (Jun 12 2006 - 10:32:00) Marvell version: 1.10.8
- for the LS Pro V2 u-boot_LSProV2-stock.bin.tar.gz
U-Boot 1.1.1 (Apr 18 2007 - 18:35:44) Marvell version: 1.12.1 - TINY
Custom
for the LS Pro V2 with a wider array of U-Boot commands
u-boot_LSProV2_DG_BuffNASCentral-fullcommands.bin.tar.gz It has been tested in a LS Pro V2 and works w/ the stock firmware and foonas-em. Read the Brick Warning below and use at your risk. ID string:
U-Boot 1.1.1 (Mar 5 2008 - 22:04:56)DG Buffalo NAS Central - Marvell v1.12.1+ TINY
Forum thread and post pertaining to it: Custom U-Boot Image Available for LS Pro V2, along with info on it.
for the LS Pro V1 and V2 with Netconsole and more commands
This is functional and so far has not auto-bricked, but still in testing for quite a while. It has been tested with stock firmware & foonas/foonas-em. In addition, it is very possible that this will work in some of the TeraStations, but it has not be tested in them yet. Read the Brick Warning below and use at your risk - for now, only open to developers, admins, betatesters, etc. Note that this is not a finished product, and the part of the purpose of it limited release is just to get ideas on how to improve it.
Download it from here : Netconsole_enabled_UBoot-beta_4-12-08-1318.tar.gz
Features:
- Works w/ stockware and foonas, with commands built in for changing env var settings easily
- Has a working Netconsole, looks for netcat ip of 192.168.11.149, and automatically uses 192.168.11.150
- Can be switched back to serial console (manual for now)
- In case of hdd failure, auto-fallback to tftp-boot works with both stock firmware and foonas, and can be extended to other distros
- Full command set:
? - alias for 'help' base - print or set address offset bdinfo - print Board Info structure boot - boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' boot end . bootm - boot application image from memory bootp - boot image via network using BootP/TFTP protocol bubt - Burn an image on the Boot Flash. cmp - memory compare coninfo - print console devices and information cp - memory copy cpumap - Display CPU memory mapping settings. crc32 - checksum calculation date - get/set/reset date & time dhcp - invoke DHCP client to obtain IP/boot params diskboot- boot from IDE device echo - echo args to console erase - erase FLASH memory ext2load- load binary file from a Ext2 filesystem ext2ls- list files in a directory (default /) flinfo - print FLASH memory information go - start application at address 'addr' help - print online help ide - IDE sub-system loadb - load binary file over serial line (kermit mode) loads - load S-Record file over serial line loop - infinite loop on address range md - memory display micon -command(2byte hex) -data(witin 32byte hex) mm - memory modify (auto-incrementing) mtest - simple RAM test mw - memory write (fill) nm - memory modify (constant address) pci - list and access PCI Configuration Space ping - send ICMP ECHO_REQUEST to network host printenv- print environment variables protect - enable or disable FLASH write protection rarpboot- boot image via network using RARP/TFTP protocol reset - Perform RESET of the CPU run - run commands in an environment variable saveenv - save environment variables to persistent storage security -device -command -options -password setenv - set environment variables shutdown - Poff . tftpboot- boot image via network using TFTP protocol version - print monitor version
Utility scripts (env vars that can be run as scripts, e.g. run foohdb):
nc - switch to netconsole ser - switch to serial console foohdbb - set bootcmd for foonas hdd booting & boot ( bootcmd=ide reset; ext2load ide 0:1 0x00100000 /boot/uImage; setenv bootargs netconsole=6666@192.168.11.150/,@192.168.11.149/ root=/dev/sda1 rw ;bootm 0x00100000 ) footftp - set def_tftp for automatic fallback to foonas_em ( def_tftp=tftp 0x00800000 uImage_em ; setenv bootargs netconsole=6666@192.168.11.150/,@192.168.11.149/ root=/dev/ram0 rw ; bootm 0x00800000 ) keepalive - send a micon command to keep UBoot alive. Use this in the case you have no hdd attached or no initrd can be found.
Limitations:
- No minimal console (button on front/rear of LS)
- Because of hdd built-in search function and other factors, there is a 5-10 second lag to the first output from netconsole
Building U-Boot from ...
Buffalo GPL sources
1. Start by installing the Codesourcery Toolchain setup, shown here : Setting up the CodeSourcery Toolchain for x86-to-ARM Cross-Compiling. There is a handy auto-install script provided that is advantageous to use.
- Follow all the direction on the page linked to.
- By default it is the 2005q3 toolchain, and this is the (a) correct one to use for building U-Boot from the 1.1.1 source.
2. Adjust your environmental variables so that linking is correct.
3. Test your setup. It is suggested that you test your cross-compiler setup by building Linux 2.6.12 or 2.6.16, for instance. See this article for directions on how this is done. Both of these articles:
yield some good instructions and further hints.
Using the 1.1.1 Buff109 source
Now that your toolchain is set up, you have two choices for building U-Boot from Buffalo's GPL sources. The first choice, 1.1.1 Buff109, is ready to go, without any alterations needed and is known to work. The second choice, 1.1.4-working (the name of the directory inside the archive) is not quite ready for use, but is probably very close. While it was tempting to try to work with it, since NetConsole is in this source already, some of the underpinnings for the LSPro boards are not complete in this source, so at the moment it is looking like more of a dead end than a promising opportunity. It remains to be seen when (or if) Buffalo will release more GPL UBoot source.
4. Get the source ready and read up on U-Boot.
- Download and untar the source u-boot-1.1.1_buf109.tar.gz to wherever you are going to compile it, probably in COMPILING.
- Read the README in the source for a lot of useful information about configuring U-Boot.
- Read the documentation on U-Boot, like this U-Boot Reference/Manual from the developer Denx.
5. (Optional) Make any adjustments to include/configs/db88f5181.h that you want to. Tinkering with this can have serious consequences - like a broken U-Boot, so use caution.
6. In the script buffalomake.sh comment out the line third line to look like this:
#. /opt/cross.conf
7. Run the script.
./buffalomake.sh
OR configure manually and make.
8. After a few minutes you should find a u-boot.bin in the source directory.
9. Make sure you read the Brick Warning before you attempt to flash.
Using the 1.1.4 "working" source
4. Get the source ready and read up on U-Boot.
- Download and untar the source u-boot-1.1.4-lspro.tar.gz to wherever you are going to compile it, probably in COMPILING. When you untar it, you will notice a suffix "-working".
- Read the README in the source for a lot of useful information about configuring U-Boot.
- Also read the Release Notes for important tips on how this version has changed since the Buf109 source.
- Read the documentation on U-Boot, like this U-Boot Reference/Manual from the developer Denx.
5. In the source, some symlinks have to be added to get it to compile. Trying any make *_config command will reveal problems. In particular, you may need to change the following directories so that the names are symlinks rather than actual directories:
include/asm/proc include/asm/arch include/asm
pointing, of course to the ARM counterparts for these. Or just remove them.
6. Optional. Edit include/configs/mv_feroceon.h to your liking. See the README and docs for details on possibilities.
7. In this issue of Marvell's UBoot sources (see ReleaseNotes for details), the structure of the configure and make commands have changed:
cd u-boot-1.1.4 make mrproper make rd88f5182_NAS2_TINY_buffalo_hs_config TINY=256K_4K make
will yield a uboot.bin of around 230kb with the default options.
8. Note: This source is not in a finished state, and needs some work still to get it to form a complete, working UBoot.bin. It is not advisable to flash this to your LS at this point. It will start and load a kernel, but we haven't seen it boot a kernel yet, either from tftp or from the hdd.
Netconsole-enabled/Patched 1.1.4 Sources
U-Boot 1.1.4 has been patched with the board and cpu code from the above Buffalo Version 1.09 sources to yield a working prototype for a Netconsole-enabled U-Boot for LSPro (both V1 & V2). It is still in testing, but has been shown to work with both Pro versions. The source in its current state of development is available here. While experimentation is encouraged on this, it is important to remember that JTAG is necessary to recover from any serious problems - ie. it can be easy to brick one's box when messing with u-boot.
Directions for building U-Boot with this source are identical to those above in the Buff109 section.
Vanilla Sources
This is a work in progress. At least one community member is currently working on this.
Flashing U-Boot to Your LS Pro
|
From a Linux Box using JTAG
See this article on JTAG for the LS Pro for instructions and details. Normally, this is a last resort method for flashing U-Boot to ROM. It is used most often when one doesn't have a functioning U-Boot in ROM already.
From within U-Boot
1. Read the Brick Warning above first!. You brick it, you bought it.
2. Set up a tftp server and have your known valid u-boot image (called my_u-boot.bin here, adjust to your situation) sitting at its root directory. You may have to adjust either your U-Boot env vars or your network to have the tftp server at the correct ip given in U-Boots serverip variable.
3. While connected to the U-Boot console (either serial or netcat connection), from the U-Boot side issue the following commands (adjust my_u-boot.bin to your situation):
tftp 0x00100000 my_u-boot.bin
protect off 1:0-63
erase 1:0-63
cp.b ${fileaddr} 0xfffc0000 ${filesize}
protect on 1:0-63
saveenv
This should yield output similar to this.
Marvell>> tftp 0x00100000 u-boot_davy_02082008.bin
Using egiga0 device
TFTP from server 192.168.11.149; our IP address is 192.168.11.150
Filename 'u-boot_davy_02082008.bin'.
Load address: 0x100000
Loading: #################################################
done
Bytes transferred = 245776 (3c010 hex)
Marvell>> protect off 1:0-63
Un-Protect Flash Sectors 0-63 in Bank # 1
................................................................ done
Marvell>> erase 1:0-63
Erase Flash Sectors 0-63 in Bank # 1
................................................................
Marvell>> cp.b ${fileaddr} 0xfffc0000 ${filesize}
Copy to Flash... done
Marvell>> protect on 1:0-63
Protect Flash Sectors 0-63 in Bank # 1
................................................................ done
Marvell>> saveenv
Saving Environment to Flash...
.
Un-Protected 1 sectors
Erasing Flash...
.
Erased 1 sectors
Writing to Flash... done
.
Protected 1 sectors
From within Linux on your LinkStation Pro
1. Read the Brick Warning above first!. You brick it, you bought it. This method of flashing is not the safest one.
2. Not yet tested on all machines, this seems to work just fine on the LSProV2, running foonas-em. It should work on any ARM-based LS/Kuro that has the proper support in its kernel.
You need to change to the directory where your known good U-Boot image is, dd it to /dev/mtdblock0, and then compare or diff to make sure the results are what you expected. Note the block size (bs=4k), from the fact that there are 256k in the ROM chip, and 64 sectors (see U-Boot's flinfo command for this).
foonas-em$ dd if=ubootv14.bin of=/dev/mtdblock0 bs=4k 64+0 records in 64+0 records out foonas-em$ cat /dev/mtdblock0 > currentcontents.bin foonas-em$ diff ubootv14.bin currentcontents.bin foonas-em$
Also, note that if this method doesn't work for you, then you will need JTAG to recover. Fortunately, flashing from within Linux seems pretty reliable, but YMMV.
