Re: Experiences of armel on NSLU2

[Rod Whitby <rod@whitby.id.au>]

Laz wrote:
> I've been testing Debian armel on a Linksys NSLU2 over the past couple of 
> days. I built a kernel with EABI support and this seems to work fine both 
> with the normal arm port and with the armel rootfs in a chroot environment.
> 
> I have now mounted the (USB) disk on another Debian box and replaced the 
> original root with the armel one. The Slug now refuses to boot fully: the 
> LEDs flash and there is lots of disk activity but it ends just sitting there 
> with the "status" LED yellow and the "Ethernet" one green.
> 
> input: ixp4xx beeper as /class/input/input0
> IXP4XX NPE driver Version 0.3.0 initialized
> IXP4XX Q Manager 0.2.1 initialized.
> ixp4xx_mac driver 0.3.1: eth0 on NPE-B with PHY[1] initialized
> eth0: NPE-B not running
> eth0: NPE-B not running
> 
> The equivalent from a full boot with the old (working) rootfs:
> 
> ixp4xx_mac driver 0.3.1: eth0 on NPE-B with PHY[1] initialized
> eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
> Link of eth0 is full-duplex
> 
> For some reason, the network interface isn't coming up properly, even though 
> the module seems to be loading without any errors. I have both link and 100 
> MBit LEDs lit on the switch it is attached to and the Slug's ethernet LED is 
> also lit. Running wireshark on another box shows no traffic from the Slug at 
> all.

Looks like you're not loading the microcode.

I believe the Debian initramfs loads it from a file.  See
http://www.nslu2-linux.org/wiki/Debian/BuildImage for hints on where to
get the microcode file (NPE-B) and where to put it.  Note that it's not
available for download from a Debian site cause the Intel microcode is
not DFSG compliant.

The nslu2-linux SlugOS distribution stores it in the last block of flash
and has the kernel load it directly (so as to prevent this type of
situation).  I hope to convince Martin to do it that way for the Debian
kernel too ...

-- Rod