File-systems and ELF loading

File-systems and ELF loading
Milestone 7: File-systems and ELF loading
Fall Term 2014
Assigned on: 28.11.2014
Due by: 12.12.2014
In this milestone you will bring together the bits and pieces you’ve implemented so far and make the last
steps towards a complete operating system. You’ll receive a simple block driver for the SD-Card reader on
the Pandaboard and write a filesystem for the driver. After that, you will use your file system to read ELF
binaries and be able to spawn them as processes inside your system. This exercise will be the last exercise
where you’ll need to implement something. We will leave you much freedom in how you do the things we
want from you as a minimal requirement, and also give you a lot of room for additional bonus objectives.
In any case, try to finish the minimal requirements first before starting with other projects. You’ll have two
weeks to complete this exercise.
Getting prepared
For this exercise you will be using an additional driver, to communicate with the SD Card. The driver
should be already part of your codebase.
The Filesystem
Traditionally, file-systems build on top of a block device driver that is able to read and write byte buffers
(usually 512 bytes), so called blocks, from and to a disk, flash drive, SD-card or another storage medium.
In this exercise you’ll receive a block driver for the SD-card reader on the Pandaboard. The driver has a
simple interface to read and write one block at the time. Use the API in usr/mmchs_driver/mmchs.h
to interface with the driver.
Unfortunately, the block device driver you’ll get is very simple and slow. Fortunately, during this course,
you have now mastered all the necessary skills to write a fast device driver. We will award bonus points
for any improvements you can do in the driver. This includes for example reading / writing more than one
block at the time, or using DMA and interrupts to transfer data to and from the card instead of polling.
Be sure to measure the performance improvements you get from your changes and show them to us in the
All the necessary information to complete these assignments can be found in the OMAP4460 TRM. Most
relevant parts are Chapter 24, especially the MMC/SD/SDIO Programming Guide in Section 24.5 and the
SD Specification Part 1 (interesting Sections are 4.7.4 and Both manuals can be found on the
course website.
Your task is to write a file-system for the block device driver. We want you to implement a file-system
that can read a FAT32 partitioned SD-card. For the exercise, you only need to support read-only filesystem operations. Note that a correct read also works with directories in the path. The header file in
include/barrelfish/aos_rpc.h should now list the following prototypes that you have to implement
and gives a description on how they should behave:
errval_t aos_rpc_open(struct aos_rpc *chan, char *path, int *fd);
errval_t aos_rpc_readdir(struct aos_rpc *chan, char* path,
struct dirent **dir, size_t *elem_count);
errval_t aos_rpc_read(struct aos_rpc *chan, int fd, size_t position, size_t size,
void** buf, size_t *buflen);
errval_t aos_rpc_close(struct aos_rpc *chan, int fd);
You find a link to the official FAT32 specification from Microsoft on the AOS website. FAT is a fairly simple
file-system (the specification is only 34 pages!) and therefore well understood and well documented. You
will also find an abundance of information and reference implementations on the web if you search for it.
We will award bonus points for any additional file-system functionality you implement (i.e., create(),
write() and delete() API calls, see include/barrelfish/aos_rpc.h for the actual RPC signatures). We also award bonus points if your file system supports the VFAT extension (i.e., support for long
In order to test your file-system, you need to create a FAT32 file system on the SD cards we handed out to
you. On a Linux system, you do that by issuing the following command:
mkfs.vfat -I -F 32 -S 512 -s 8 /dev/sdX
This command creates a FAT image on the SD-Card with a logical sector size of 512 bytes and 8 sectors
per cluster. Make sure you use the right device from /dev when formatting! You can use dmesg to figure
out which device was recently mounted. Once you have partitioned the card you can start the provided
mmchs driver from the hand-out. If everything worked correctly, the driver will print the contents of the
first sector. You can easily verify that you’re dealing with a FAT disk in case the first byte on the block is
235 (0xEB) and the third byte is 144 (0x90).
For the exercise, you do not have to worry about partitions on your SD-card (-I command line switch in
mkfs.vfat) and proceed with the assumption of having just one FS on your card. For this extra challenge
you need to have support for reading the partition table of your SD-Card and support access to multiple
file-systems on your card at the same time. This will involve having some sort of virtual file system on top
of your FAT implementation and a mount command that lets you specify the partitions on your SD-card
and the mount point.
Performance Evaluation
As a last step you’ll have to evaluate the read performance of your file-system. Your evaluation should at
least contain the maximum read bandwith you achieved. You need to be able to explain your results, where
the potential bottlenecks are in your implementation and how you could improve them.
We provide a very simple driver for the Cortex-A9 global timer (see Cortex-A9 MPCore TRM, p4-8ff).
To use this driver you’ll need to add the omap_timer library to the program (in addLibraries in the
Hakefile) in which you will use it. Here’s a very simple example:
#include <omap_timer/timer.h>
int main(void)
// initialize the timer
// enable the timer
uint64_t start = omap_timer_read();
// do work
uint64_t end = omap_timer_read();
uint64_t time = end - start;
// do analytics on elapsed time.
ELF loading
Now that your file-system is working, you are able to add ELF loading support to your OS. Until now,
your build system assembled a multiboot compliant boot image at compile time which contained a set of
modules (i.e., the ones you specified in your menu.lst file inside your build directory), those modules are
already just regular ELF files, therefore you can think of it as an archive of ELF files. In a real system
we do not want to load only binaries that ship with the kernel. Using your file-system, you can now add
support to load ELF files from an SD-card. That involves loading an ELF file from your card into memory,
then doing necessary ELF relocation and setting up the the address space of your newly allocated process
in a way that it can execute the binary. Note that how you implement this part and also how much work
you have to do for this assignment depends a lot on how your system looks like at this point (especially the
process management, your file and memory management subsystems).
We will provide you with code that already does much of the ELF handling for you (have a look at the ELF
library in lib/elf). For an example of how to use the library, you can have a look at how the kernel code
loads the init process from the multiboot image.
Lab demonstration
You are expected to demonstrate the following functionality during the lab-session:
• You have an implementation of a read-only FAT32 file-system. You can demonstrate this by providing two shell commands, ls and cat, that list the files of a directory and read a file and print it out on
the console.
• You can demonstrate that you are able to load ELF images from your SD-Card and spawn it as a new
process using your command line interface.
Once your code is demonstrated, you should submit it over Online submission system (accessible only
from ETHZ network) on Friday 12.12.2014 midnight (23:59h).
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF