U-boot for LS Pro

From NAS-Central Buffalo - The Linkstation Wiki
Jump to: navigation, search

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/cumbersome
  • 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.


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 or LS Live

Untar any of these before using. Flash (at your own risk) using the directions below.


These are stock U-Boot images, with ID strings shown:

U-Boot 1.1.1 (Jun 12 2006 - 10:32:00) Marvell version: 1.10.8 
U-Boot 1.1.1 (Apr 18 2007 - 18:35:44) Marvell version: 1.12.1 - TINY


for the LS Pro/Live 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/Live V1 and V2 with Netconsole and more commands

This is functional and and works well. See "Limitations" below for one issue and its workaround. 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 necessarily a finished product, and the part of the purpose of it limited release is just to get ideas on how to improve it, or to hear that it is "good to go".

      • BAD LINK BELOW ***

Download it from here  : Netconsole_enabled_UBoot-beta_4-12-08-1318.tar.gz


  1. Works w/ stockware and foonas, with commands built in for changing env var settings easily
  2. Has a working Netconsole, looks for netcat ip of, and automatically uses
  3. Can be switched back to serial console (manual for now)
  4. In case of hdd failure, auto-fallback to tftp-boot works with both stock firmware and foonas, and can be extended to other distros
  5. 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@,@ 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@,@ root=/dev/ram0 rw ; bootm 0x00800000 )
keepalive - (not working at this time) send a micon command to keep UBoot alive.  Use this in the case you have no hdd attached or no initrd can be found.


1. It has been tested and we've discovered one minor anomaly with an easy workaround. It has the requirement to be able ping whatever host is at ncip at boot time. It does not require nc to be running on that host, just to be able to see it (arp ping?). Otherwise it works normally. The workaround for this is to make sure you have a host running at boot time that has the ip listed in ncip. (If you are wondering, ncip is a uboot env var that lists the value of the ip where a netcat/nc host might appear.) Users are strongly advised against changing the env var values for ncip, serverip, netmask or any other network associated value.

2. No button-based minimal console (ie, you can't choose boot modes with the buttons on front/rear of LS, as you can in LNI's PPC UBoot port).

3. Because of hdd built-in search function and other factors, at power-up there is a 5-10 second lag to the first output from netconsole.

4. Sometimes during the autoboot countdown, the input of keystrokes seems uneven or slow. This may be a quirk similar to what LNI had noted in the LS1's UBoot. At the moment I am unable to pin down the cause of it, or to fix it. The easy work-around is to hit 3 returns once you see 'egiga0'.

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.


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:


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

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


There is a possibility that you could brick your NAS with these instructions. Please make sure that you read the entire page carefully. WARNING: Modifying your LinkStation or Kuro can void your warranty. Incorrect flashing procedures can turn your unit into a Brick. Flashing success is not guaranteed. Do not flash your box unless your are willing to use JTAG to recover it, in the event that there is an unforeseen problem. JTAG recovery generally works well, but is not a guarantee of recovery from bricking one's box.

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

This should yield output similar to this.

Marvell>> tftp 0x00100000 u-boot_davy_02082008.bin                             
Using egiga0 device                                                             
TFTP from server; our IP address is               
Filename 'u-boot_davy_02082008.bin'.                                           
Load address: 0x100000                                                         
Loading: #################################################                     
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, but I have flashed w/ it 15 to 20 times now without any problem.

2. It has been tested on the LSProV1, a LSLiveV2 and on a KuroPro. It should work on any ARM-based LS/Kuro that has the proper support in its kernel. No guarantees, though and read the brick warning above.

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 

Note that if you use a u-boot.bin image that is not the full 256k in size, when you diff or cmp that image to the currentcontents.bin, it will flag it as different, since their sizes differ. Therefore, one may choose to flash a full 256k image instead of the 240k-ish ones that are created by compiling.

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.


Forum Threads Related to this Subject

Build System for U-Boot on LS Pro

U-Boot for LS Pro/Live

U-Boot for KuroPro

Exact Diffs Between LS Pro U-Boot for v1 & v2 Machines