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

PRINTER Printer-Friendly Version

Milestone 0: Familiarisation

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

Your Environment

If you haven't already you may want to take a look at Odroid C2 Lab, which provides details on the contents of your kit. Log into the CSE lab machine before you plug in the hardware, as this triggers the machine to run specific scripts for your project to work, on your account. If you have permission/tftp issues down the line, try unplugging/replugging the usb/serial adapter and ethernet adapter while logged in.

The required tools can be set up on a CSE lab machine by running 9242, as follows:

weill% 9242
Collecting jinja2
  Using cached https://files.pythonhosted.org/packages/7f/ff/ae64bacdfc95f27a016a7bed8e8686763ba4d277a78ca76f32659220a731/Jinja2-2.10-py2.py3-none-any.whl
Collecting MarkupSafe>=0.23 (from jinja2)
Installing collected packages: MarkupSafe, jinja2
Successfully installed MarkupSafe-1.0 jinja2-2.10
Collecting future
  Downloading https://files.pythonhosted.org/packages/00/2b/8d082ddfed935f3608cc61140df6dcbf0edea1bc3ab52fb6c29ae3e81e85/future-0.16.0.tar.gz (824kB)
    100% |################################| 829kB 827kB/s 
Building wheels for collected packages: future
  Running setup.py bdist_wheel for future ... done
  Stored in directory: /import/adams/1/cs9242/.cache/pip/wheels/bf/c9/a3/c538d90ef17cf7823fa51fc701a7a7a910a80f6a405bf15b1a
Successfully built future
Installing collected packages: future
Successfully installed future-0.16.0
Collecting ply
  Downloading https://files.pythonhosted.org/packages/a3/58/35da89ee790598a0700ea49b2a66594140f44dec458c07e8e3d4979137fc/ply-3.11-py2.py3-none-any.whl (49kB)
    100% |################################| 51kB 1.9MB/s 
Installing collected packages: ply
Successfully installed ply-3.11
newclass starting new subshell for class COMP9242...
weill% aarch64-linux-gnu-ld
aarch64-linux-gnu-ld: no input files
  

The above updates your path to include the cross compilers and other tools located in the cs9242 home directory, and python packages that the seL4 build depends on for your local user account. You will need to run 9242 each time you start a new shell on a lab machine in order to build the project successfully.

Get the source

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

On a CSE machine

git clone /home/cs9242/public_git/aos-2018

On other machines

If you are not using a lab machine, you will need to ensure that git 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

Once your PATH is setup, you can check out the code:

git clone ssh://YOURLOGIN@login.cse.unsw.edu.au//home/cs9242/public_git/aos-2018

Building SOS

Dependencies

The CSE lab machines have already been configured with all dependencies. To set up another machine, please see the Linux instructions or the virtual machine instructions for using a VM to run Linux in order to build the project.

Build the project

We use Cmake and ninja as our build system, which you can read more about on the seL4 docsite. Importantly, this build system does not build in the source tree: you create another directory (in this case build to build code in, and develop in the source directories. Follow these instructions to build SOS:

      cd aos-2018 # change to the project directory
      mkdir build # create a build directory
      cd build # change to the build directory
      ../init-build.sh # initialise the build directory
      ninja # init-build
    

There will be some ELFCLASS_32 errors on cse lab machines. These can safely be ignored

By default ninja builds in parallel. If you have a lot of build errors, trhis can cause confusing output. use ninja -j1 to build with only one thread, which will make the build slower but also serialise the output.

Getting it Going

Booting your Odroid-c2 for the first time is easy:

  1. Plug in the Odroid-c2. Use dmesg to observe the USB port name (usually /dev/ttyUSB0).
  2. In a terminal, launch picocom, % picocom -b 115200 /dev/ttyUSB0 .
  3. Reset the Odroid-C2 by disconnecting the power supply and reconnecting. Then, quickly enter input into the keyboard to stop U-Boot from immediately booting Linux. You should see the following output in picocom:
    --- UART initialized after reboot ---
    [Reset cause: unknown]
    [Image: unknown, amlogic_v1.1.3046-00db630-dirty 2016-08-31 09:24:14 tao.zeng@droid04]
    bl30: check_permit, count is 1
    bl30: check_permit: ok!
    chipidLoad bl33 from eMMC, src: 0x00034200, des: 0x01000000, size: 0x00074ae0
    : ef be ad de d f0 ad ba ef be ad de not ES chip
    [0.299622 Inits done]
    secure task start!
    high task start!
    low task start!
    NOTICE:  BL3-1: v1.0(debug):4d2e34d
    NOTICE:  BL3-1: Built : 17:08:35, Oct 29 2015
    INFO:    BL3-1: Initializing runtime services
    INFO:    BL3-1: Preparing for EL3 exit to normal world
    INFO:    BL3-1: Next image address = 0x1000000
    INFO:    BL3-1: Next image spsr = 0x3c9
    
    
    U-Boot 2015.01 (Sep 26 2017 - 00:56:33)
    
    DRAM:  2 GiB
    Relocation Offset is: 76f31000
    -------------------------------------------------
    * Welcome to Hardkernel's ODROID-C2
    -------------------------------------------------
    CPU : AMLogic S905
    S/N : HKC213254DFFB2AA
    MAC : 00:1e:06:35:ff:2a
    BID : HKC2211804
    -------------------------------------------------
    register usb cfg[1][0] = 0000000077f95190
    register usb cfg[0][1] = 0000000077f951b0
    vpu detect type: 5
    vpu clk_level = 7
    set vpu clk: 666667000Hz, readback: 666660000Hz(0x300)
    MMC:   aml_priv->desc_buf = 0x0000000073f29d30
    aml_priv->desc_buf = 0x0000000073f2bec0
    SDIO Port C: 0, SDIO Port B: 1
    [mmc_init] mmc init success
    In:    serial
    Out:   serial
    Err:   serial
    ----------------------------------
    MMC Size : 16 GB
    reading boot-logo.bmp
    ** Unable to read file boot-logo.bmp **
    movi: the partiton 'logo' is reading...
    
    MMC read: dev # 0, block # 61024, count 2048 ... 2048 blocks read: OK
    hpd_state=1
    [CANVAS]addr=0x3f800000 width=3840, height=1440
    
    set hdmitx VIC = 16
    hdmitx phy setting done
    set hdmitx VIC = 16
    hdmitx phy setting done
    Error: Bad gzipped data
    There is no valid bmp file at the given address
    Net:   Meson_Ethernet
    odroidc2#
    
  4. Now set U-boot to autoboot SOS instead of Linux, and set the expected ip addresses:
  5. setenv ipaddr 192.168.168.2
    setenv serverip 192.168.168.1
    setenv bootcmd 'tftpboot 0x10000000 sos-image-arm-odroidc2 && go 0x10000000'
    saveenv # write the new settings to the eMMC
    

    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 OdroidC2. Below is a typical development cycle, assuming the path changes to your login script:

    1. Plug in the Odroid-C2, including serial and ethernet.
    2. In a terminal, launch picocom, picocom -b 115200 /dev/ttyUSB0.
    3. Make your changes in the source directory, (hint: learn cscope).
    4. Build with ninja, in the build dir.
    5. Test your changes (from the build dir ../reset.sh) and launch netcat (nc -lp 26718). Note that every time you reset the board you must also restart netcat - the following makes this harder to forget (use CTRL-C / rinse / repeat):
    6. $ ../reset.sh && nc -lp 26718
    7. Repeat from step 3 above until satisfied, or you fall over for lack of sleep.

    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 LiC.

    Before you complete this milestone, be sure to spend time becoming familiar with the seL4 Debugging Guide. It will save you a lot of debugging effort throughout the project.

    Recommended procedure

    1. Read (and understand) the code in projects/aos/sos/src/main.c and the code in the projects/aos/apps/tty_test application directory.
    2. Read the documentation on libserial.
    3. Initialise libserial during SOS startup. Note that you need to initialise libserial after network_init is called.
    4. 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 10.1, 10.2, 10.3.1.9, 10.2.2.1). Note that an endpoint has already been set up between the tty_test application and sos.)
    5. Write the client side implementation in sos_write.
    6. 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.
    7. Edit tty_test.c so that it tests your sos_write function.
    8. Change the server side so that it now prints the data to libserial, which will send it onto the network.
    9. Test that all of tty_test's output now goes to the netcat 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 OdroidC2 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 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 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.

    Hint: sending a byte at a time is not a good solution.

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


    Last modified: 07 Aug 2018.