Re: Experiences of armel on NSLU2
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
Reply to: