Advanced Operating Systems (LV 7680) -- Milestone description
M0 - Familiarisation
- Due: Week 4
- Marks: 4 (-1 for one week late, discontinue course if more than one week late)
- Milestone 0 involves familiarising yourself with the source code, build system, hardware and then writing a simple IPC protocol.
This is a first exercise designed to get you started on L4.
Your Environment
If you haven't already you may want to take a look in the wiki to set up your development environment and your hardware. You should use the Codesourcery cross compiler as indicated in the wiki. Start by installing / booting Linux on your platform. Connect the serial port adapter as shown in the wiki and test it using your favourite terminal program. Communications parameters should be set to 115000 bps, 8N1.
First Steps
- Locate the git repositories on the local gitlab server and talk your friendly supervisor into giving you developer access.
- Familiarise yourself with the sources and the repositories. They have been cloned from the official seL4 github repositories recently. Having our own local repositories has the advantage of being able to apply changes quickly and easily.
- Set up an efficient cross development process. Typically, you will want to
bootstrap your target via network (e.g.
tftpboot
) - Work your way through the seL4 Getting Started manual,
however:
- refer to the local gitlab repositories instead of the seL4 github.
- you may skip the CAmkES and the verification parts.
- use your development platform (rather than ia32)
- if you need to make changes, create a branch to commit your changes.
- Your first goal is to get the
sel4test
application running on your development platform.
Notes:
- You will need superuser rights to install the required prerequisites as indicated here.
- In the
make menuconfig
dialog, under ''seL4 Kernel -> seL4 Seystem''select your architecture (ARM) and platform (e.g. IMX6 SabreLite, IMX6 Wandboard Quad, AM335X BeagleBone, etc). - If you use a preinstalled cross-toolchain such as Codesourcery, it is better to set it up in the configuration
file rather than through the PATH environment, i.e. in the
make menuconfig
dialog under ''Toolchain Options'', select ''Cross compiler prefix'' and enter an appropriate Toolchain Prefix, e.g./opt/arm-2013.05/bin/arm-none-linux-gnueabi-
. - By default, the
make
command builds an ELF binary. Depending on your target platform, you may need a raw binary (-> usemake build-binary
) or a U-Boot uImage (-> usemake build-uImage
).
Building SOS
Get yourself a copy of the skeleton SOS. We use git for revision control for this project, and it will be simplest if you do also. You will be submitting patches/diffs for each milestone in the project. We support and expect only git generated patches/diffs. You will need to support yourself if you use any other tools.
You can find some pointers on using git on our git page.
git clone git@gitlab.cs.hs-rm.de:advanced-operating-systems/AOS.git
cd AOS
make aos_defconfig
make menuconfig
make build-binary
Note: currently, the only platform working out of the box in this way is the SabreLight board. All others need to have their Ethernet drivers added to the library. Stay tuned.
Booting SOS
Booting your board for the first time is easy:
- Plug in the board (also connect ethernet) and reset it.
- In a terminal, launch
minicom
,seyon
od any other suitable terminal emulator. - Build, copy the sos image and reset your board.
- 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
The Makefile
can copy the sos operating system, known as a bootimage
to your tftp directory. Below is a typical development cycle, assuming
the path changes to your login script:
- Plug in the development board, don't forget the ethernet.
- In a terminal, launch
minicom
,seyon
, etc. - In another terminal, launch
netcat
:% nc -lup 26706
. - Make your changes, (hint: learn cscope).
- Build, copy the bootimg and reset your board.
- Test your changes.
- Repeat from step 4 above until satisfied, or you fall over for lack of sleep.
- Ending the
minicom
session, ctrl-A q, and ctrl-C will end thenetcat
session. The Milestone
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 supervisor.
Recommended procedure
- Read (and understand) the code in
apps/sos/src/main.c
and the code in theapps/tty_test
application directory. - Read the documentation on libserial.
- Design a simple IPC protocol to transfer data from the user program
to your operating system (Recommended reading: seL4 Reference Manual,
Chapter 4 (all), Chapter 9 (Section 9.1, 9.2, 9.3.9, 9.3.10, 9.3.11).
Note that an endpoint has already been set up between the
tty_test
application and sos.) - Write the client side implementation in
sos_write
. - Change the
syscall_loop
inmain.c
to recognise your new protocol, and print out a debug message when you receive one of these messages. - Edit
tty_test.c
so that it tests yoursos_write
function. - Change the server side so that it now prints the data to libserial, which will send it onto the network.
- Test that all of
tty_test
's output now goes to thenetcat
console, not the console debugger.
Assessment
Milestone submission
See the milestone submission guidelines for instructions on submitting your milestone solution.
Milestone Demonstration
You will need to demonstrate user applications printing to the 2nd
console via libserial
, running on the hardware to the supervisor
during the demonstration period. You should be prepared to show
which files you modified in your solution, and explain any design
decisions you made.
Note that since you do not have consistent virtual memory management yet, your protocol will be fairly simple for now. However, it should be upgraded as more parts of the system are completed. Your supervisor 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.
Hint: sending a byte at a time is not a good solution.