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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
