It might seem perverse to boot a NAS without disks, but I'm keen to use my Slug as an audio controller, where disk noise would be intrusive. Instead, let's keep the storage in the server room, and let the NSLU2 get everything over the network.

What you need:

• A NSLU2, obviously
• A Linux box (our server) with NFS and TFTP servers installed.
• A working ARM cross-compiler (optional)

To get this working, I first installed Debian on the Slug using a USB disk unit borrowed from another project; I'm hoping that what I've learnt will enable us to skip this step and go diskless from the start.

In order to reduce the amount of flash wear whilst experimenting, I thought that TFTP would be the best way to load the kernel. The APEX boot-loader can supposedly load kernels and ramdisk images from TFTP, so let's play with that. The first thing I did was compile apex using the standard configuration (to be sure that I can compile it correctly). Byte-swap apex.bin, but don't prepend the 16-byte header. Drop the swapped Apex into your TFTP server (in my case, using Debian's atftpd, this is /var/lib/tftpboot/apex_swapped.bin).

%_swapped.bin: %.bin
	devio '<<$<' 'xp $$$$,4' >$@ 

Now we're ready to try out our new Apex, in the same way as we would test a kernel. First telnet into RedBoot, then tell the Slug about your network:

 ip_address -h 192.168.0.2

(substitute the address of your TFTP server; it needs to be on the 192.168.0.* network if you're using telnet, as you can't change the Slug's address without dropping your connection - if you have serial, then you'll have more freedom)

Now load apex:

 load -r -b 0x01d00000 apex_swapped.bin

and run it:

 go

If everything has worked, your slug should boot up just as it does without intervention. All we've done is prove that we can load a new second-stage bootloader that we've compiled.

Now we're ready to experiment with Apex without having to flash the image every time. In your Apex build directory, you can make menuconfig and remove a few features. For instance, I stripped out everything related to interactive command editing. compile apex again, byte-swap and copy to the TFTP directory, then [telnet into RedBoot] and test as above.

Assuming that has worked, we can try adding the necessary configuration to net-boot from Apex. make menuconfig and select "IXP4xx NPE Ethernet" under "Generic Drivers". This will give a new section, "Ethernet Networking" with sensible default settings. If we compile again and boot, we should get the same results as earlier, because we haven't told Apex to use the networking code.

Now, configure Apex with code in the "Environment" section. You can start the Ethernet code by adding configuration to the "Startup command prefix". I added "ipconfig 192.168.0.1" and Apex worked. However, if I tell Apex to set a different address (say "ipconfig 192.168.0.4" then it hangs and I don't know why (maybe someone with a serial port can help?).

One should be able to set the "Source region for kernel" to something like "tftp://192.168.0.2/vmlinuz" and have Apex request the kernel by TFTP; this doesn't work for me. I wonder if it's because RedBoot has left the Ethernet port configured, and Apex expects it to be uninitialised?