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

PRINTER Printer-Friendly Version
Administration               
- Notices
- Course Intro
- Consultations
- 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
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!

Milestone 0: Familiarisation

This is a simple exercise designed to get you started on L4. It contains very detailed instructions, together with the existing source code and the L4 manual you should have no problem doing it.

Your Environment

Most of the 9242 binaries (eg. cross compilers) are in ~disy/crossdev/$ARCH. You can add this to your path with:

    ~ % arm5xdev=gcc-3.4.5-glibc-2.3.5/armv5b-softfloat-linux
    ~ % export PATH=$PATH:/home/disy/crossdev/$ARCH/$arm5xdev/bin
    ~ % export PATH=$PATH:/home/disy/bin
  

If you are lazy you can just use the 9242 command for the cs9242 shell:

    ~ % 9242
    newclass starting new subshell for class COMP9242...
    ~ % armv5b-softfloat-linux-ld
    armv5b-softfloat-linux-ld: no input files
  

Your minicom should default to 115200, 8N1, no hardware flow control. If it doesn't then you will have problems talking to your slug.

Building SOS

  • Get yourself a copy of the skeleton SOS.
  • tar xvzf aos-2008.tgz
  • cd aos-2008

Getting it Going

Booting your NSLU2 for the first time is easy:

  1. Plug in the slug (USB and Ethernet) and power it on.
  2. In a terminal, launch minicom, % minicom.
  3. Build, copy the sos image and reset your slug by just typing % make.
  4. You should see a successful boot of the sos skeleton. Now it is up to you to bring an entirely new operating system up, good luck.

Development cycle

We have developed a few tools to speed the development cycle along. The makefile can copy the sos operating system, known as a bootimage to your tftp directory and reset the slug. Below is a typical development cycle, assuming the path changes to your login script:

  1. Plug in the slug, don't forget the ethernet, and power it on.
  2. In a terminal, launch minicom, % minicom.
  3. In another terminal, launch netcat, % nc -lup 26706.
  4. Make your changes, (hint: learn cscope).
  5. Build, copy the bootimg and reset your slug with % make.
  6. Test your changes.
  7. Repeat from step 4 above until satified, or you fall over for lack of sleep.
  8. Ending the minicom session, ^A q, and ^C will end the netcat session.

The Milestone

The example skeleton operating system includes an application tty_test which starts up, prints out its name, and then goes into a loop.

The example includes a printf implementation that outputs data to L4's debug console. In fact it uses the L4 debug API L4_KDB_PrintChar. This function should only be used for internal SOS debugging, not as a console for applications, so, your task is to modify the sos_write function to send data across the network to your netcat(nc) console.

The second part of milestone zero is to find a partner for the rest of the project. The project is to be completed, in pairs, unless prior permission has been obtained from the LiC.

Recommended procedure

  1. Read (and understand) the code in sos/main.c and the code in the tty_test application.
  2. Read the documentation on libserial.
  3. Design an IPC protocol to transfer data from the user program to your operating system. (Recommended reading: OKL4 Reference Manual, sections A-6, D-5, D-7, D-15, D-3.1.1.)
  4. Write the client side implementation in sos_write.
  5. Change the syscall_loop in main.c to recognise your new protocol, and print out a debug message when you receive one of these messages.
  6. Edit tty_test.c so that it tests your tty_send_string function.
  7. Change the server side so that it now prints the data to libserial, which will send it onto the network.
  8. Test that all of tty_test's output now goes to the netcat console, not the console debugger.

Assessment

You will need to demonstrate user applications printing to the 2nd console via libserial, running on the slug hardware to the tutor during the demonstration period. You should be prepared to show your tutor which files you modified in your solution, and explain any design decisions you made. Your tutor will be particularly interested in the details of your IPC interface with different size blocks of data etc.

You will let the tutor know who your partner is so that group accounts can be created for you.


Last modified: 04 Aug 2008.