Your first milestone is to write a basic timer driver. However, you should use this as an opportunity to get to used working with your partner, and probably work out exactly how you can work together so you don't end up duplicating work, or worse still not completing essential parts of the project.
By now you should have got yourself in a group and you should have a group account setup for you. We expect that you are using Git to maintain your source code, and that a repository be setup in your group account with the correct permissions and sticky bits set so that you can both access it. See our git overview page for suggestions.
You should consider using a merge tool such as the meld (or equivalent) as the default merge program to avoid painful merges.
The aim of this milestone is to design and implement device driver to accurately provide timeouts and trigger activities. You should add a file for the timer implementation and modify the main system call loop to handle timer interrupts. See the framework page for how to add a file to the SOS build system.
Applications will eventually need to be able to make sleep
system calls.
Your driver needs to export the interface specified
in libs/libclock/include/clock/clock.h
. There are the
following functions:
register_timer
.interrupt_ep
given to start_timer
The above interface is just an internal function call
interface. You do not need to export this interface to the
users. User programs will indirectly access the clock driver through
the sleep
syscall that is implemented in a later
milestone.
NOTE: After registering an interrupt, you must call
seL4_IRQHandler_Ack
to ensure the kernel in a sane initial
state.
Your main job is to learn how to program the timers provided on the OdroidC2's S905 system on chip (SOC). An overview of the parts in the OdroidC2 can be found here.
We have provided constants and definitions for the timer device in
projects/aos/libclock/include/device.h
. Use these constants, rather than those
from the manual, as these have been tested to work (based on the source code for the Odroid-C2 Linux branch, which is more accurate than the manual). However, still refer to chapter 26 in the
SOC manual to understand how the timer functions. We have tested
timer F through I, and recommend you use as many of these timers as you desire for this milestone.
Implementing a device driver really just a matter of learning about its registers, what values to read and write to those registers, and when to do it.
The minimal subset of a timer module's functionality that you must understand and use is listed below.
NOTE: This section is deliberately kept short (e.g., we do not dictate which timer to use or in what mode to use it in). The idea is for you to develop your own design and implementation. There are only two conditions that must be satisfied:
For this project you have been supplied with skeleton code to help you along the way. This code is intended as an implementation guide, not as a 'black-box' library.
It is important that you fully understand all provided code that you use. For the purposes of assessment, we treat any supplied code that you call as your code and as such you may be asked to describe how it works.
Now might be a good time to get familiar with the resources, especially the framework documentation
The seL4/ARM kernel exports specific interrupts to a user level interrupt handler via asynchronous notification.
You will need to perform a series of steps to register to receive interrupts and manage interrupts for the timer device.
irq_handler = cspace_irq_control_get_cap(cur_cspace,
seL4_CapIRQControl, irq, 1)
. The last argument is important as
it tells the kernel that this is an edge-triggered interrupt.ntfn
, as initialised in main_continued
. You should create a new badged
copy of this cap and pass it to start_timer
, who should
then register your new interrupt handler with the kernel
and direct it to forward the interrupt to the provided notification object.
An example of badging is done for network interrupts, see the call to
badge_irq_ep
in main.c
Before attempting this, you should read Chapter 6 of the sel4 documentation to gain an understanding of TCBs, and Section 8.1 to understand how interrupts are delivered.
In seL4/ARM, device registers are memory mapped. That is, hardware
registers can be accessed via normal load/store operations to
special addresses. To access device registers, you must first map
the device into the driver's virtual address space with the
appropriate attributes. A function to achieve this has been provided
for you in apps/sos/src/mapping.c
. You can also look at the
basic uart driver in apss/sos/src/devices/uart.c
.
You may need to resolve some or all of these issues:
For the remainder of the semester progress through the milestones is contingent on passing the demonstration requirements below, and not having any show stoppers.
In general, we don't mark down for milestones that don't meet minimal requirements. Instead, we'll point out what is required, which groups can then fix, and then submit the following week for a small late penalty. Thus less than perfect project marks usually come about via late penalties, not lower marks for poor solutions.
It's in your best interest to fix problems, rather than letting them snowball into something more problematic as the semester progresses.
Better solutions outlines (only) some potential differentiators of solution quality that are expected to have more favourable marks at the end of the semester, however they are not required.
In general, do not jeopardise the progression of your project by chasing better solutions at the expense of correctness of your project.
You should be able to show some test code that uses all the
functions specified in
the driver
interface. You may use the timestamp_*
functions
from projects/aos/libclock/include/clock/timestamp.h
to demonstrate
the accuracy of your timeouts.
Specifically set up and demonstrate:
timestamp_ms
every time this callback is
received.Note: Your
timestamps must be at least accurate to the nearest
10ms.register_timer
. Make sure the delay used is long
enough such that the system call loop is entered before these
wake up. These callbacks should just print out the current timestamp
as each delay expires. You will later
use register_timer
to implement
a sleep
system call for your user-level
processes.Note this is not a complete list. The following designs are considered unsatisfactory:
The following approaches are considered better than minimum, and favourably contribute to the final project mark.