This is a simple exercise designed to get you started on seL4. It contains very detailed instructions, together with the existing source code and the seL4 manual you should have no problem doing it.
Most of the 9242 binaries (eg. cross compilers) are in ~cs9242/crossdev/arm-2013.05. You can add this to your path with:
export PATH=$PATH:/home/cs9242/crossdev/arm-2013.05/bin export PATH=$PATH:/home/disy/bin # this one overrides cse's hg executable, so it needs to go at the front of your path export PATH=/home/cs9242/bin:$PATHFIXME: update for git
You should also modify your .hgrc (in your home directory, create one if you don't have it) to add the following lines, to avoid superfluous hg error messages:
[extensions] hgext/hbisect = ! hgext.imerge=!
If you are lazy you can just use the 9242 command for the cs9242 shell:
~ % 9242 newclass starting new subshell for class COMP9242... ~ % arm-none-linux-gnueabi-ld arm-none-linux-gnueabi-ld: no input files
Note: Your minicom should default to 115200, 8N1, no hardware flow control. If it doesn't then you will have problems talking to your Sabre.
hg
") for revision control and encourage you to use it too.
hg clone /home/cs9242/public_html/current/project/files/aos-2013
cd aos-2013
make aos_defconfig
make
hg
is in your $PATH
at CSE (as well as installed on your local machine!) before performing a check-out. Put this line in your .bashrc
(or equivalent):
PATH=/home/cs9242/bin:$PATH
hg clone --remotecmd "/home/cs9242/bin/hg" ssh://YOURLOGIN@login.cse.unsw.edu.au//home/cs9242/public_html/current/project/files/aos-2013
Booting your Sabre Lite for the first time is easy:
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 Sabre. Below is a typical development cycle, assuming the path changes to your login script:
The example skeleton operating system includes an application
tty_test
which starts up, prints out its name, and then
blocks itself forever.
The example includes a printf
implementation that outputs
data to seL4's debug console. In fact it uses the seL4 debug API
seL4_DebugPutChar
. 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 through the
operating system and 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.
apps/sos/src/main.c
and the code in the apps/tty_test
application directory.sos_write
.syscall_loop
in main.c
to recognise your new protocol, and print out a debug message when you
receive one of these messages.tty_test.c
so that it tests your
sos_write
function.tty_test
's output now goes to
the netcat console, not the console debugger.You will need to demonstrate user applications printing to the 2nd console via libserial, running on the Sabre Lite 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.
Note that since you do not have any form of memory management yet, your protocol will be fairly simple for now, but should be upgraded as more parts of the system are completed. Your tutor will be particularly interested in the details of your IPC interface with different sized blocks of data etc, and how you plan to improve it in future.
You will let the tutor know who your partner is so that group accounts can be created for you.