NSLU2-Linux
view · edit · print · history

I'll start with a review of the NSLU2 camps:

  1. Want full Linksys compatibility (including future releases), can load firmware images through the web interface and telnet in to run ipkg, have no clue about RedBoot.
  2. Can telnet into RedBoot and use Linux.
  3. Power user, but no JTAG and no custom RedBoot images.
  4. Bleeding edge - custom RedBoot images, no need or desire for Linksys compatibility.
  5. RedBoot bootloader replacement beginning with APEX.

The key point regarding OpenSlug booting is that camp #2 and #3 are supposed to be versed with telneting into RedBoot.

This key feature allows users to recover from bad kernel builds or a trashed rootfs. The biggest drawback to this approach is that it requires the use of the 192.168.0.1 address and not the user defined IP address which is in the Linksys system configuration block.

I'm in camp #5 or a seriously modified RedBoot camp #4 for learning, fun, and practical reasons to me like security of a server device on the Internet.

Goals for OpenSlug Users in camp #3 and some in #4

Camp #5 and most of camp #4 are highly customized. People in these area have special needs and can or are learning to do things for themselves. Camp #3 and part of camp #4 will use either standard or just slightly modified kernel configurations. Why is this important ? Because it defines a key issue of support:

  1. Camp #5 and high-tweak #4's are making lots of kernel changes and testing / reflashing those kernels is an important issue.
  2. Camp #3 and low-tweak #4's are using known good or virtually known good kernels.

Camp #3 and low-tweak #4's are stuck with 1 kernel being loaded from RedBoot. When a kernel is changed for this camp, and its bad, the only recovery options are:

  1. Telent to RedBoot
  2. Upgrade from RedBoot via serial connection

Upon some consideration, I think these OpenSlug users need to do the following:

  1. Just live with it, because this is the reality of living with the stock RedBoot constraints:
  2. Get someone to champion an OpenSlug maintenance initial ramdisk, similar to switchbox but OpenSlug specific.

For camp #5 and #4 high-tweak they'll add a very simple /linuxrc like giel's below:

(giel editing now :))

This is my linuxrc, for booting from an USB HDD. I use it with the kernel command line containing rootfs=/dev/ram0 init=/linuxrc. Also, please make sure your init program is in /sbin/init, and that you've put the needed modules in your switchbox. If there's no HDD plugged in, we boot from JFFS2. If you're considering using this linuxrc, I take it that you've got enough knowledge to edit it to your needs (for instance, always booting from JFFS2).

 #!/bin/sh

 /bin/mount -t proc proc /proc

 # the following lines are commented out on purpose
 # uncomment them if you want to have telnet access before the boot
 # process begins. THIS IS ONLY FOR DEBUGGING

 # we borrow the ixp drivers from jffs2
 #/bin/mount -rt jffs2 /dev/mtdblock4 /mnt/jffs2

 #/sbin/insmod /mnt/jffs2/lib/modules/2.6.9/drivers/ixp400/ixp400.ko
 #/sbin/insmod /mnt/jffs2/lib/modules/2.6.9/kernel/drivers/net/ixp425_eth.ko
 #/sbin/ifconfig eth0 up 192.168.1.2 netmask 255.255.255.0
 #/sbin/telnetd

 #exec /bin/sh
 #exit 0

 # now, for the real stuff
 /sbin/insmod usbcore
 /sbin/insmod scsi_mod
 /sbin/insmod sd_mod
 /sbin/insmod ohci-hcd
 /sbin/insmod ehci-hcd
 /sbin/insmod usb-storage

rwhitby: shouldn't all these modules be compiled into the kernel? if the device is on the slug hardware already, why make it a module?

 # wait for hdd to be recognized, tune this to your needs
 sleep 3

 /bin/mount -rt ext2 /dev/sda2 /mnt/newroot
 if [ ! -x /mnt/newroot/bin/init ] && ! [ ! -L /mnt/newroot/bin/init ] ; then
        /bin/umount /mnt/newroot
        /bin/mount -rt jffs2 /dev/mtdblock4 /mnt/newroot
 fi

 /bin/umount /proc
 cd /mnt/newroot
 /sbin/pivot_root . mnt/initrd

 # if you've got serial you might want to add
 # < dev/console > dev/console 2>&1 to the following line
 exec /usr/sbin/chroot . /sbin/init

 exit 0

(giel out)

What's really needed for OpenSlug but is missing

An better upgrade mechanism. Currently, we've got a great first flash capability. A mechanism needs to be provided for upgrading the Camp #3 and low-tweak Camp #4 users.

N.B. This mechanism should have very little impact on the OpenSlug build process. Like a tiny little web app that runs in an initrd.

view · edit · print · history · Last edited by tman.
Based on work by beewoolie, tman, rwhitby, giel, and g2.
Originally by g2.
Page last modified on July 23, 2005, at 07:43 AM