Buffalo NAS-Central Forums

First of all you will need a serial cable to do this.

Fetch mkimage from:
http://buffalo.nas-central.org/download/LSPro_ARM9/DevelopmentTools/CrossToolchains/mkimage

Debian Installer ramdisk found on:
http://www.applieddata.net/forums/topic.asp?TOPIC_ID=2442
The Ramdisk:
http://www.applieddata.net/developers/linux/files/debian/install-armel-2007-08-28/ramdisk.gz

The ramdisk must be converted to a u-boot image:


Install a cross compiler and build the kernel as described on:
http://buffalo.nas-central.org/index.php/Buffalo_ARM9_Kernel_Port

Remember to pick a cross compiler that makes EABI targets.


Put kernel and initrd in /tftpboot on a tftp-server that has the IP address 192.168.11.1


Connect to the Linkstation Pro/Live through a serial connection:


Boot the Linkstation and press any key to switch to tftp boot and stop the
autoboot. The Linkstaions beeps annoying. Press the power button shortly to
stop the noise. Now you are in u-boot.
In u-boot do:


Do NOT make a saveenv within uboot when it is in tftp-mode. Some of the
environment variable has been changed when the bootloader switches to
tftp-mode. You will not easily get back to the mode where it will try to
boot from the harddisk first.



The normal Debian netboot installer now boots

Debian mirror found on:
http://wiki.debian.org/DebianPorts/Mirrors
I picked:
http://ftp.easynet.be/ftp/gnuab/debian
In expert/manual mode I formatted an ext3 partition on sda6 that I mounted on /.
I didn't use the other partitions.
I couldn't set the time correctly.
You will get warnings that the installer couldn't find a kernel, a
bootloader and kernel modules. Skip these warnings and continue your
install.

-----------------------------
After installation:

In u-boot you can boot in tftp mode again like this


Booting from harddisk would probably look like this (untested):


Missing:
Watchdog support. Reboot and shutdown doesn't work. I need a link to the new MICON-driver.
kernel + modules should be put into a Debian package and put on a repository on the net.
A packed version of the Miconv2 driver should be there as well.
Feel free to reuse this on the WIKI.
A method to do this safely without the need for a serial cable would make Debian available on the Linkstaion Pro/Live for more people.

very valuable info.

made sticky until someone transfers into the wiki.

Here is what I now use i u-boot to make it boot from disk the following times:



All this is needed because the bootcmd environment is overloaded when it switched to tftp-mode.

two questions:

(1) are you just restoring the u-boot environmental variables back to
the default values that the Linkstation came with, or is there a significant change needed?

(2) will Debian (sid?) armel work with a (stock or recompiled with extra options)
buffalo 2.6.16 kernel (eabi,cross-compiled on 2005q3 toolset of course).
for example, the one I made at
ftp://ftp.dmik.org/pub/common/buffalo/lspro/duncan_h/kernel-2.6.16.57-lsp_eabi-dh_v4.tar.gz


It would be good to try a "simple" switch of Freelink rev 2 from (etch) arm to (sid) armel,
for people who want iptables to work (doesn't work using debian-arm with oabi legacy support
on the eabi kernel).

My guess is that the Freelink initrd, which is the buffalo one, slightly adapted, is already eabi,
and only the Freelink rev2 rootfs is oabi. Maybe a simple swap of the rootfs could
be made?

Is there a simple way to determine if a binary is eabi or oabi?

Edit: even better, I see that the ADS site seems to have a Debian Etch armel version!
I did not know this existed - or is it just debian-arm OABI packages running with legacy OABI support
on an EABI kernel, just like freelink?. I'm downloading the ABS rootfs to examine it.
If it really is full EABI Etch, maybe one could just replace the contents of /lib /bin /usr/bin and the like
on Freelink rev2 with the corresponding EABI binaries from the ADS rootfs?


Edit2: I'm fairly sure that the Etch rootfs 2008-01-xx. on ADS site is not EABI,
only the sid 2007-08-xx is.

I am switching alost back to the initial default values. The only important change is root=/dev/sda6 instead of root=/dev/sda1 and ram=128M.
I choose not to repartitionate the disk, but only switch sda2 and sda6 to jfs. On sda1 I place the kernel and initrd just as Buffalo use to do. It is important that this partition is ext2/ext3 as u-boot only can read ext2.

I introduce the variable bootargs_disk only because you can't set a variable with 18 arguments. 16 argument is the limit. So if you really really would like to have 18 argument then you have to flash the full u-boot image - and I didn't want to take this risk.



I haven't tried. udev support is important, so you could give it a try. Remember to compile all modules you would like to use during install into the kernel, as the kernel and modules can't be found of the gnuab archives.

The armel architecture isn't official in Debian yet. But I expect it to be soon. And yes it is sid packages that you can find precompiled for armel.


Yes the original buffalo initrd is eabi and the Freelink rootfs is oabi. As I see it you don't need a buffalo derived initrd. You can use a native debian installer armel initrd.
The micro_evtd need to be put into a Debian package and a linkstation/kurobox kernel.

That's good to know, I have a spare ext3 /dev/sda8 which I can put the armel-sid rootfs on and not
mess with the working rootfs on on /dev/sda2, and just use u-boot setenv rootfs=/dev/sda8 kernel=...
etc for testing without permanently changing the u-boot variables.

Is the ram=128M a change from the LinkStation default? (and why?)

Yes it is a change. It is only needed by the 2.6.24-rcX git kernels. They won't boot without it.

Of cause it would be possible to build a patch to the kernel where it defaults to ram=128M, but then this kernel most probably wouldn't work on a Linkstation pro duo, which seems to only have 64MB ram.

There is a patch to fix that at http://marc.info/?l=linux-kernel&m=120097480415595&w=2.

Gonna try this to get full distro on my TS Pro - finally!

One question. Can I use the rootfs from the ADS site or will there be some drivers missing?
The alternative will be the LS rootfs for Freelink

You need to compile a kernel with all the modules that you need during installation to be linked into the kernel.
then just use the ramdisk.gz as initrd as I pointed out in the first post in this thread. You don't need an initial rootfs as in the Freelink case. The Debian netboot initrd will create a rootfs for you.

Thanks. Reading the ADS pages you refer to I can see that installing via an USB mem stick is an option too. I think this might be easier for the TS Pro not at least due to the raid layout etc. This MIGHT even give me a fair chance of preserving all my data (yes I'd back it up!)... I'd copy some of the etc files like mtab and fstab to the mem stick to obtain this.
This method will however require a rootfs - should the be the ADS one or the LS freelink one?

Regarding the shutdown problem, you should apply this patch to the kernel :
http://terastationpro.free.fr/kuroboxpro/micon.patch
Then, the correct way to shutdown will be "shutdown -hP now" (-P tell that the machine to power down)

Is there a way to do this (using serial teminal access to u-boot) without replacing initrd.buffalo in /boot (/dev/sda1)

I created initrd.armel in /dev/sda1

I expected that, after getting the u-boot prompt, I could do

setenv initrd initrd.armel
bootd

printenv confirms that initrd=initrd.armel, but when bootd (which references $(initrd) ) runs , it stll uses initrd.buffalo.

Since setenv kernel uImage.whatever does change the kernel that is used, I was surprised that
I failed to change the initrd with this method.


(I want to preserve the working boot into Freelink, and set up an experimental armel rootfs on
a spare partition which I can select to use using u-boot; If I replace initrd.buffalo, and it
fails, I'll need to mount the disk on a pc to fix it - I would prefer to avoid that)

This is great to see. This makes an intersting post: http://nchip.livejournal.com/10735.html

Still some work to get the packages upto date. More users will help and this will be a great move forward for ARM.

Just a correction to my initial post. It's really a good idea to mount the root partition as read-only instead of read-write. When you crash your filesystem, e.g. because of a power failure, then the initrd can't mount the root filesystem read-write.
A debian installation will during it's bootscripts do a fsck on the disk and then remount it read-write. So you should use: