The Slug lab is organised around 32-bit computers, the ARMv5, based on a 133 MHz Intel XScale processor.
Linksys originally designed the Slug to be a lightweight network fileserver. They chose to use the Intel IXP420 system running the Linux operating system on it, which was fortunate for us as Linux is under GPL and Linksys/CISCO are required to release the operating system code. A thriving community has developed around the NSLU2 and they, affectionately, call the device a Slug. (NSLU2 and Slug will be used interchangeably).
UNSW has modified the basic Slug by installing a USB-Serial converter in it, to give direct access to the IXP420's serial port for debugging purposes. The USB-Serial board also allows the Slug's reset signal to be controlled using the DTR pin on the serial port. Lastly, the USB-Serial adapter provides power to the Slug using the 5V available from USB.
The Slug was designed by Linksys based upon Intel's IXP420 Network Processor. The device features:
The NSLU2 provided as part of the COMP9242 kit is identical to an NSLU2 available off the shelf, with the following modifications:
The USB to serial converter was custom designed by David Johnson at CSE. The schematics are available here. It uses an FTDI FT232RL chip operating at 3.3V, interfaced directly to the NSLU2.
The kit given out for COMP9242 contains the following items:
The CSE lab machines already have the required software installed (if it is not installed on the machine itself, then it is installed in ~disy/bin or ~disy/crossdev. See milestone 0 for development details.
Your host machine will require certain software and drivers to talk to the Slug. This is mostly machine specific:
Plug the Slug into your host machine's USB port using the Mini-B cable. If your host machine does not have a powered USB port, then you will also need to plug in the power adapter.
You need a network connection between the host and the Slug for downloading OS images, or using NFS filesystems, either using the USB/Ethernet dongle, or a direct Ethernet connection. In the CSE labs you will use the USB/Ethernet dongle. Connect an Ethernet cable cable from the Slug to the USB/Ethernet dongle.
Once the Slug is connected to your development machine you should launch
the two consoles that connect you to its output. Run
in one console window and
nc -lup 28706 in the other.
You may be required to change the settings for minicom. On linux, use
dmesg to work out which port the USB to serial converter has
been attached to (its usually
/dev/ttyUSB0). Then set minicom
to use that serial port, 115200 baud rate, 8N1, and no hardware flow
Press the power button on the front of the NSLU2. The power button should light up, but the other lights should remain dim.
When minicom connects to the serial port, the DTR line is changed so
that the NSLU2 is reset. It stays that way until you toggle the DTR line.
We have written a utility which will control the DTR line appropriately.
It is called
nslu2 and is in the ~disy/bin directory on CSE
lab machines, as well as in source
form. To boot the NSLU2, run
nslu2 up (use
/dev/PORTNAME if your usb-to-serial device is named something
/dev/ttyUSB0). The lights on the front of the NSLU2
should turn on, indicating that the device has entered redboot and is
booting. You should see some output in the minicom window.
A brief description of the development cycle can be found in Milestone 0. A lot is happening under the covers to allow you to easily develop an operating system:
On CSE machines this generates a hotplug event on the host's USB bus and results in the creation of the tty device. A cse script runs at this time and customises the tftpd and nfs server to your login sessions user name.
When minicom launches it opens the tty device and automatically raises DTR, which is a bit inconvenient as that causes the NSLU2's reset line to be asserted permanently, effectively halting it.
Not magical, nothing will happen though until you send something with libserial.
A lot is happening here under the covers, the Makefile will call nslu2 up and allow your Slug to boot, then it calls the build system, scons (via tools/build.py). Once the build is complete, make copies the build/images/image.boot.bin file to your tftpboot directory. Finally nslu2 reset is executed to reboot the Slug
Are you wondering why you started this course now? Just think how good it will feel when you finish!
To boot this image, you will first need to power your Slug up as usual
and break into the RedBoot bootloader environment. Do this by pressing the
power button on the front of the Slug, running the
command and then in the minicom serial console type
^c as soon
as a '
++' is displayed. Eg:
++ [during short delay - type ^c] Ethernet eth0: MAC address 00:14:bf:68:99:0f IP: 192.168.168.2/255.255.255.0, Gateway: 192.168.168.1 Default server: 0.0.0.0, DNS server IP: 0.0.0.0 RedBoot(tm) bootstrap and debug environment [ROMRAM] Red Hat certified release, version 1.92 - built 15:16:07, Feb 3 2004 Platform: IXDP425 Development Platform (XScale) Copyright (C) 2000, 2001, 2002, Red Hat, Inc. RAM: 0x00000000-0x02000000, 0x000723a0-0x01ff3000 available FLASH: 0x50000000 - 0x50800000, 64 blocks of 0x00020000 bytes each. == Executing boot script in 2.000 seconds - enter ^C to abort ^C RedBoot>
Linux is stored in flash memory. In order to load linux into RAM, run
the pre-defined boot script using the
boot command. This
uncompresses Linux to physical address 0x01d00000. In order to boot, run
exec 0x01d00000 command.
Pictures of the modified slug, and the contents of the kit are shown below: