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.

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==

+

==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.

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

[http://buffalo.nas-central.org/download/Users/davy_gravy/u-boot_LSProV2_DG_BuffNASCentral-fullcommands.bin.tar.gz 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:

[http://buffalo.nas-central.org/download/Users/davy_gravy/u-boot_LSProV2_DG_BuffNASCentral-fullcommands.bin.tar.gz 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:

===='''for the LS Pro V1 and V2 with Netconsole and more commands'''====

+

===='''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".

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".

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.

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

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

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".

Limitations:

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.)

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'.

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:

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.

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

WARNING!

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):

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).

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.