Figure 1: System startup configuration diagram
This document describes the provided SOS framework. This is provided to make it easier for you to get started with the project. The source code itself should be reasonably well commented, and you should ensure that you understand the provided source code.
Note that the structure of the project and the build system are intimately linked. Although you are free to change the build system and layout of the project it is discouraged for the following reasons:
Figure 1: System startup configuration
diagram
sos will run.We have provided a fairly comprehensive build system for you, however you will need to edit the Makefiles and Kconfig/Kbuild files throughout your project as you add new libraries and applications. For the most part you should be able to work out how to alter them.
The root Makefile builds all of the separate applications as
separate binaries. It then uses a program called cpio to link all
of these binaries into one image, bootimg.bin. All of the other
Makefiles are used to specify source and header file locations for
each library or application, which are then used in
the common.mk general purpose Makefile.
The Kbuild/Kconfig files are used to manage dependencies, select libraries and applications for building and adjust build options.
Whenever you change one of these files you need to
make menuconfig to pick up the changes. This
will open a dialogue that allows you to configure your
project.
The network configuration of SOS is setup via Kconfig. To change these settings, follow the menu options as shown in the figures below.
sosh or to the name of a
testing application that you may have created.
Alternatively, the configuration can be modified manually with:
$ cd aos-2014 $ vim .config $ make oldconfig
You have been provided with three applications; sos, tty_out and sosh.
All applications are placed in the apps directory.
See milestone 7 for details on how to add a new application.
Most of the code you will write will be in the sos
directory. Currently there is a very minimal operating system
implemented, which should help get you started. The following
section presents a brief overview of each file. Find more details
in the source!
tty_test application).network_init function, which you should ensure
is called on startup.
The first stage of initialisation involves a call
to ut_table_init. This function arranges untyped
memory objects into a linear space. Untyped memory can then be
referenced by a single address rather than the tuple of
{untyped capability, offset}. Once
initialised, ut_steal_mem can be used to reserve
memory, however, this memory can never be freed.
The second stage of initialisation involves a call
to ut_allocator_init. This function initialises a
bit field driven buddy allocator system which allows calls to
ut_alloc and ut_free to reserve and
free untyped memory respectively.
ut_alloc and ut_free both
require sizebits as a parameter. The memory
reserved or freed by these calls will have a size
of 2sizebits. Valid values
for sizebits are:
Sizes 14, 12 and 10 are each implemented as a bit field that divides all of managed memory into partitions of the corresponding size. A bit with a value of 0 means that the corresponding partition is available and can be allocated. A bit with a value of 1 means that the corresponding partition is unavailable. A partition may be unavailable either because the partition has already been allocated or because the partition is not currently being managed by the bitfield.
In the example shown in the image below, the 214 size partitions marked as A and B may be allocated as 4 212B frames or they may be allocated to objects of an alternate size. The 214 size partition marked with C is clearly reserved for 212B frames, two of which have already been allocated. The 214 partition marked with D is currently available and is not managed by the 212 bitfield. It may be used as a 214 object or it may be used to provide an available memory region to a bit field that manages an alternate size.
When allocating from a bit field that has no bits marked as available, a 214B memory region is requested. The value of the returned address is then used to mark corresponding partitions as available. One of these newly available partitions will be marked as unavailable and the corresponding address is returned to the caller.
When freeing a memory region, the corresponding partition in the appropriate bitfield is marked as available. If enough partitions in this bitfield are marked as avaiable, the memory region will be returned back to the 214 pool for recycling.
Sizes 9 and 4 are implemented in a similar way except that, in an effort to reduce book keeping overhead, a linked list of bit fields is maintained rather than maintaining a bit field to address all of allocator managed memory.
#define verbose X.
sys_brk used within SOS.All of the libraries are provided in the libs
directory. Libraries depend on each other, so the Kconfig file in the
root of each library directory defines any dependencies.
In order to add a new library, you need to do the following:
make menuconfig to select your library and include it
in the build.
LIBS
list in the applications Makefile and modifying the applications Kconfig
depends on line in to include your library.So that you don't have to write everything from scratch, we provide you with some libraries to get you going. Some of the libraries are directly relevant to you, in that you will be implementing and extending them. Others are used by other components of the system, but you are free to investigate the source out of interest (or while debugging). All of the libraries are listed here with brief descriptions, in order of relevance to your project.