Lenny/armel with Debian kernel on Buffalo Linkstation Pro v2

[Tim Small-2]

Hi,

After much wailing and gnashing of teeth, I have a Lenny/armel
user-space with a stock-ish Debian kernel on a Buffalo Linkstation Pro v2:

~# grep ^Hardware /proc/cpuinfo && uname -a && cat /etc/debian_version
Hardware        : Buffalo/Revogear Kurobox Pro
Linux linkstation 2.6.25-rc8-orion5x #2 Sat Apr 5 20:02:55 UTC 2008
armv5tel GNU/Linux
lenny/sid

The hardware is pretty cheap now - the "Linkstation Live" version seems
to be available for $143 and ukp 100 in the US, and UK respectively,
according to froogle (2xUSB2/1xGigEther/250G SATA/400MHz/128M).  I used
a Nokia DKU-5 USB/serial cable for the serial console (3 ukp), but the
more widely available "Nokia CA-42" should work as well.

I don't think I'll have any time soon to work on the kernel package
install script etc. but hopefully these notes will be useful when it
comes to creating this:

A serial console is advised, but not (hopefully) essential for this
procedure.

For the kernel build, I used the tar ball from
http://photon.itp.tuwien.ac.at/~mattems/linux-2.6_2.6.25~rc8.orig.tar.gz 
and the debian dir from
svn://svn.debian.org/svn/kernel/dists/trunk/linux-2.6/debian

I started off with freelink, and replaced the root with lenny/armel
using deboostrap.  Here are the rest of my notes:

These notes assume you are starting with Freelink, and the Buffalo
kernel image v 2.6.16 (other versions have not been tested).
n.b. The buffalo "emergency mode" functionality will be lost (as that
comes from the Buffalo initrd).

. Install Lenny Armel userspace (debootstrap etc.) and micro_evtd (not
yet Debian packaged, but source available - fan speed control etc.)

. Build Debian kernel 2.6.25-rc8 or later - only the orion5x kernel is
needed (comment out the rest of the flavours from
linux-2.6-2.6.25~rc8/debian/config/armel/defines)

. Install the kernel packages, and mkinitramfs, also install the
"devio", and "uboot-mkimage" packages.

. Make Debian initramfs for the new kernel using mkinitramfs as usual.

. Create the uboot images:

.. Kernel:

devio > mach-change-shim.tmp 'wl 0xe3a01c05,4' 'wl 0xe38110e5,4' && cat
mach-change-shim.tmp lsboot/vmlinuz-2.6.25-rc8-orion5x >
shimmedimage.tmp && mkimage -A arm -O linux -T kernel -C none -a
0x00008000 -e 0x00008000 -n 'Linux-2.6.25-rc8-orion5x' -d
shimmedimage.tmp uImage.buffalo

n.b. devio fixes up the machine ID, and this currently needs to be
0x05e5 (not 0x0630 etc. until the kernel has been fixed).


.. initramfs:

mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000
-n 'initrd-2.6.25-rc8-orion5x' -d initrd.img-2.6.25-rc8-orion5x
initrd.buffalo

.. Modify the boot environment (default boot prevents the initramfs
loading - the kernel says "checking if image is initramfs...it isn't
(bad gzip magic numbers); looks like an initrd" - however I'm not really
sure why).
The modified boot environment appears to works with both Debian, and the
Buffalo kernel+initrd - although I've only tested the 2.6.16 buffalo
kernel + initrd) - n.b. this can also be done with the serial console,
and the setenv command.  The nvram command is from the original Buffalo
initrd (I think freelink leaves this mounted on /initrd by default, but
if not, you can extract this by "dd if=initrd.buffalo.original bs=1
skip=64 | gzip -cd > /tmp/initrd.ext2" and then use mount -t ext2 -o loop).

.. Remove the initrd=0x00800040,15M parameter (check that your env look
like those below), and verify

TestBox-linkstation:/# chroot /initrd
TestBox-linkstation:/# nvram -c get bootargs_root
bootargs_root=root=/dev/sda2 rw initrd=0x00800040,15M panic=5
TestBox-linkstation:/# nvram -c set bootargs_root "root=/dev/sda2 rw
panic=5"
 >nvram_set:bootargs_root = root=/dev/sda2 rw panic=5
TestBox-linkstation:/# nvram -c get bootargs_root
bootargs_root=root=/dev/sda2 rw panic=5

. Install the new uImage.buffalo and initrd.buffalo into /boot

. Reboot.

Cheers,

Tim.


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Per Andersson-3]

Hi!

Basically what you meantion is what I have
proposed[0] in my Google Summer of Code
application for the Debian NAS[1] project.

I have also contacted the author of micro_evtd
(lb_worm) and asked for permission to package it.


Cheers,
Per Andersson

[0] http://oshw.org/usr/avtobiff/gsoc/08/debiannas
[1] http://wiki.debian.org/SummerOfCode2008/DebianNAS

On Wed, Apr 9, 2008 at 1:54 PM, Tim Small <tim@...> wrote:

> Hi,
>
>  After much wailing and gnashing of teeth, I have a Lenny/armel user-space
> with a stock-ish Debian kernel on a Buffalo Linkstation Pro v2:
>
>  ~# grep ^Hardware /proc/cpuinfo && uname -a && cat /etc/debian_version
>  Hardware        : Buffalo/Revogear Kurobox Pro
>  Linux linkstation 2.6.25-rc8-orion5x #2 Sat Apr 5 20:02:55 UTC 2008
> armv5tel GNU/Linux
>  lenny/sid
>
>  The hardware is pretty cheap now - the "Linkstation Live" version seems to
> be available for $143 and ukp 100 in the US, and UK respectively, according
> to froogle (2xUSB2/1xGigEther/250G SATA/400MHz/128M).  I used a Nokia DKU-5
> USB/serial cable for the serial console (3 ukp), but the more widely
> available "Nokia CA-42" should work as well.
>
>  I don't think I'll have any time soon to work on the kernel package install
> script etc. but hopefully these notes will be useful when it comes to
> creating this:
>
>  A serial console is advised, but not (hopefully) essential for this
> procedure.
>
>  For the kernel build, I used the tar ball from
> http://photon.itp.tuwien.ac.at/~mattems/linux-2.6_2.6.25~rc8.orig.tar.gz and
> the debian dir from
> svn://svn.debian.org/svn/kernel/dists/trunk/linux-2.6/debian
>
>  I started off with freelink, and replaced the root with lenny/armel using
> deboostrap.  Here are the rest of my notes:
>
>  These notes assume you are starting with Freelink, and the Buffalo kernel
> image v 2.6.16 (other versions have not been tested).
>  n.b. The buffalo "emergency mode" functionality will be lost (as that comes
> from the Buffalo initrd).
>
>  . Install Lenny Armel userspace (debootstrap etc.) and micro_evtd (not yet
> Debian packaged, but source available - fan speed control etc.)
>
>  . Build Debian kernel 2.6.25-rc8 or later - only the orion5x kernel is
> needed (comment out the rest of the flavours from
> linux-2.6-2.6.25~rc8/debian/config/armel/defines)
>
>  . Install the kernel packages, and mkinitramfs, also install the "devio",
> and "uboot-mkimage" packages.
>
>  . Make Debian initramfs for the new kernel using mkinitramfs as usual.
>
>  . Create the uboot images:
>
>  .. Kernel:
>
>  devio > mach-change-shim.tmp 'wl 0xe3a01c05,4' 'wl 0xe38110e5,4' && cat
> mach-change-shim.tmp lsboot/vmlinuz-2.6.25-rc8-orion5x > shimmedimage.tmp &&
> mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n
> 'Linux-2.6.25-rc8-orion5x' -d shimmedimage.tmp uImage.buffalo
>
>  n.b. devio fixes up the machine ID, and this currently needs to be 0x05e5
> (not 0x0630 etc. until the kernel has been fixed).
>
>
>  .. initramfs:
>
>  mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n
> 'initrd-2.6.25-rc8-orion5x' -d initrd.img-2.6.25-rc8-orion5x initrd.buffalo
>
>  .. Modify the boot environment (default boot prevents the initramfs loading
> - the kernel says "checking if image is initramfs...it isn't (bad gzip magic
> numbers); looks like an initrd" - however I'm not really sure why).
>  The modified boot environment appears to works with both Debian, and the
> Buffalo kernel+initrd - although I've only tested the 2.6.16 buffalo kernel
> + initrd) - n.b. this can also be done with the serial console, and the
> setenv command.  The nvram command is from the original Buffalo initrd (I
> think freelink leaves this mounted on /initrd by default, but if not, you
> can extract this by "dd if=initrd.buffalo.original bs=1 skip=64 | gzip -cd >
> /tmp/initrd.ext2" and then use mount -t ext2 -o loop).
>
>  .. Remove the initrd=0x00800040,15M parameter (check that your env look
> like those below), and verify
>
>  TestBox-linkstation:/# chroot /initrd
>  TestBox-linkstation:/# nvram -c get bootargs_root
>  bootargs_root=root=/dev/sda2 rw initrd=0x00800040,15M panic=5
>  TestBox-linkstation:/# nvram -c set bootargs_root "root=/dev/sda2 rw
> panic=5"
>  >nvram_set:bootargs_root = root=/dev/sda2 rw panic=5
>  TestBox-linkstation:/# nvram -c get bootargs_root
>  bootargs_root=root=/dev/sda2 rw panic=5
>
>  . Install the new uImage.buffalo and initrd.buffalo into /boot
>
>  . Reboot.
>
>  Cheers,
>
>  Tim.
>
>
>  --
>  To UNSUBSCRIBE, email to debian-arm-REQUEST@...
>  with a subject of "unsubscribe". Trouble? Contact
> listmaster@...
>
>

--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Martin Michlmayr]

* Tim Small <tim@...> [2008-04-09 12:54]:
> n.b. devio fixes up the machine ID, and this currently needs to be 0x05e5
> (not 0x0630 etc. until the kernel has been fixed).

FWIW, I've put the Linkstation patch into SVN in the meantime.

> .. Modify the boot environment (default boot prevents the initramfs loading
> - the kernel says "checking if image is initramfs...it isn't (bad gzip magic
> numbers); looks like an initrd" - however I'm not really sure why).
...
> .. Remove the initrd=0x00800040,15M parameter (check that your env look like
> those below), and verify

The reason is probably that it tells the kernel that the ramdisk is
15M long, but the Debian ramdisk will be much smaller.  You could try
padding the Debian ramdisk to 15 MB with zeros to see if that works.
--
Martin Michlmayr
http://www.cyrius.com/


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Tim Small-2]

Martin Michlmayr wrote:
>> .. Remove the initrd=0x00800040,15M parameter (check that your env look like
>> those below), and verify
>>    
>
> The reason is probably that it tells the kernel that the ramdisk is
> 15M long, but the Debian ramdisk will be much smaller.  You could try
> padding the Debian ramdisk to 15 MB with zeros to see if that works.
>  

The problem turns out to be with the initramfs code - whereas in the
case of an initrd, only a single gzip archive is looked for, the
initramfs code overlays the contents of multiple concatenated gziped
cpio archives, and so expects the whole 15M to be filled with valid gzip
data....  Whilst it would be theoretically possible to make up a file
which is padded with valid empty gzipped cpio archives up to a size of
exactly 15M, this sounds quite hard, and in fact, it doesn't seem that
the uboot firmware is able to load a file of this size either from disk,
or by tftp - 12M or so seems to be the limit.

The only reasonable thing I can think of (assuming you don't want to
delete this env setting, which is pointless anyway) is to modify the
command line, or ignore it...

I've come up with the attached patch to ignore it, which WorksForMe
(tm).  It maybe that this bogus parameter also exists on other Buffalo
hardware (and as such the patch should be expanded to include other
hardware numbers), but I don't have any to test on.

Cheers,

Tim.

Signed-off-by: tim@...



--- fresh/linux-2.6-2.6.26~rc6/arch/arm/kernel/setup.c 2008-04-17 02:49:44.000000000 +0000
+++ linux-2.6-2.6.26~rc6/arch/arm/kernel/setup.c 2008-06-21 16:49:39.000000000 +0000
@@ -447,9 +447,12 @@
  start = memparse(*p, p);
  if (**p == ',') {
  size = memparse((*p) + 1, p);
-
- phys_initrd_start = start;
- phys_initrd_size = size;
+ if (start == 0x800040 && size == 0xf00000 && machine_arch_type == 0x0631) {
+ printk(KERN_WARNING "Ignoring bogus Buffalo Linkstation Pro/Live initrd=0x00800040,15M parameter\n");
+ } else {
+ phys_initrd_start = start;
+ phys_initrd_size = size;
+ }
  }
 }
 __early_param("initrd=", early_initrd);

[Martin Michlmayr]

* Tim Small <tim@...> [2008-06-21 18:35]:
> The problem turns out to be with the initramfs code - whereas in the
> case of an initrd, only a single gzip archive is looked for, the
> initramfs code overlays the contents of multiple concatenated gziped
> cpio archives, and so expects the whole 15M to be filled with valid
> gzip data....

Yeah, it's a feature in the sense that it allows you to simply cat
multiple gzipped cpio archives together and have all of them loaded.
However, I wonder whether it would be possible to modify the code so
it won't ignore the ramdisk it has found if it finds invalid data
later on.

> I've come up with the attached patch to ignore it, which WorksForMe (tm).  
> It maybe that this bogus parameter also exists on other Buffalo hardware
> (and as such the patch should be expanded to include other hardware
> numbers), but I don't have any to test on.

Such a specific patch has about zero change to be accepted in the
mainline kernel (although a patch that would do the thing would imho
be a good idea).

But anyway, what's the problem with simply padding the ramdisk to 15MB
with zeros?

--
Martin Michlmayr
http://www.cyrius.com/


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...