[CSE]  Advanced Operating Systems 
 COMP9242 2009/S2 
UNSW
CRICOS Provider
Number: 00098G

PRINTER Printer-Friendly Version
Administration                        
- Notices
- Course Intro
- Consultations
- Statistics
- Survey Results
 
Work
- Lectures
- Selected Papers
- Project Spec
- Exam
 
Forums
- Forums
 
Resources
Project Resources
Slug Lab
L4 Debugging Guide
Developing on a Mac
Developing on Linux
SOS source browser

 
Documentation
OKL4 reference manual
Elfweaver user manual
IXP42X hardware manual 
OKL Wiki
NSLU2-Linux HomePage
Intel IXP400 Software

 
Related Info
IBM OS Prize
OS Hall of Fame
 
History
2008
2007
2006
2005
2004
2003
2002
2000
1999
1998
- 1997
 
Staff
- Gernot Heiser
- Kevin Elphinstone (LiC)
- Guest Lecturers (TBA)
 
Stureps
- Student Reps

 
Valid HTML 4.0!

CISCO/Linksys NSLU2 (Slug) Lab

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.

Slug technical details

The Slug was designed by Linksys based upon Intel's IXP420 Network Processor. The device features:

  • An Intel XScale CPU, running at 133Mhz.
  • 32MiB of memory.
  • IXP420 Network Processor.
  • A debug serial to USB port.
  • A slightly modified RedBoot bootloader.
  • The PCI bus has a pair of High-Speed USB2 controllers.
  • Only one of the IXP420 network ports are active.

Modifications

The NSLU2 provided as part of the COMP9242 kit is identical to an NSLU2 available off the shelf, with the following modifications:

  • A USB to serial converter has been added inside the box, with a USB Mini-B connector on the outside. This connects to the NSLU2's 5V power, ground, UART TX, UART RX and reset signals.
  • Redboot, the bootloader has been re-built with the following modifications:
    • The default IP address has been changed from 192.168.0.1 to 192.168.168.2 (in order not to conflict with vmware setup on the CSE machines.
    • The default gateway IP address has been changed from 192.168.0.1 to 192.168.168.1 (see above).
    • The default boot command has been changed from boot; exec 0x01d00000 to load -r -v -b 0x00100000 -h 192.168.168.1 bootimg.bin; go

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.

Kit contents

The kit given out for COMP9242 contains the following items:

  • A modified NSLU2 (Mini-B USB port next to the power connector)
  • USB to Ethernet adapter.
  • USB-A to USB Mini-B cable.
  • USB-A to USB-B cable.
  • CAT5 Ethernet cable.
  • Power adapter for the NSLU2.

Setting up your host

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:

  • Mac OS X
  • Linux
  • Windows not available - (if someone wants to get it working, let us know!)

Setting up a Slug

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 minicom in one console window and nc -lup 26706 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 control.

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 -p /dev/PORTNAME if your usb-to-serial device is named something other than /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.

How to use - what is really happening

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:

  1. Plug in the Slug and power it on.

    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.

  2. In a terminal, launch minicom, % minicom.

    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.

  3. In another terminal, launch netcat, % nc -lup 26706.

    Not magical, nothing will happen though until you send something with libserial.

  4. Make your changes, (hint: learn cscope).
  5. Build, copy the bootimg and reset your Slug, % make.

    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

  6. Test your changes.

    'nuff said?

  7. Repeat from step 4 above until satified, or you fall over for lack of sleep.

    Are you wondering why you started this course now? Just think how good it will feel when you finish!

Booting Linux

The original installation of Linux has been left intact on the NSLU2. You might like to boot into Linux to play around.

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 nslu2 up 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 the exec 0x01d00000 command.

Visually...

Pictures of the modified slug, and the contents of the kit are shown below:


Last modified: 28 Jul 2009.