A talk about my GSoC project with lowRISC - ORCONF Conference 2015

It was great to give a talk about my Google Summer of Code project with lowRISC at the fourth instance of ORCONF conference held this year in CERN, Geneva, Switzerland. ORCONF is concerned with open-source digital design hardware and embedded systems, motivated by the great success of open-source software. lowRISC, my GSoC organization, which aims to produce a fully open hardware system, was one of the participant organizations over there.

During my talk at ORCONF 2015

The conference was of great success, having about 30 talks ranging from physics, up to software. There was also an interesting discussion about how to adapt open-source software licenses to hardware designs.

lowRISC, based in the University of Cambridge, has first participated in GSoC this year as an umbrella organization to include open-source projects like: RISC-V, seL4, Rump Kernels, jor1k and YosysJS. I was fortunate enough to be one of the three students who have been accepted to work with lowRISC out of 52 GSoC applicants there. This gave me the chance to have a great rewarding experience working on Porting seL4 to RISC-V/lowRISC.

During GSoC’15 program, I had the chance to work on the world's first formally verified operating system kernel—seL4, which is also open-source, to port it to run on lowRISC/RISC-V that are open hardware architectures. The project also implied some coding with the open-source muslc C library. I even worked on some digital design tasks out of curiosity. My mentor, Stefan Wallentowitz, and the lowRISC organizers: Alex Bradbury and Robert Mullins have been of great help even after GSoC has ended.

The outcome of the project was good enough to present about at ORCONF. After my talk (see the slides), I got some positive feedbacks and future ideas, had interesting discussions, and spoke with people who want to build on, and make use of, my project.

Right after I returned back to York, I received my GSoC T-Shirt and certificate.

GSoC'15 T-Shirt and certificate 

I’d like to take this opportunity to thank GSoC, lowRISC and ORCONF organizers, and I am looking forward to continuing to work/participate with them.

Thoughts on Supporting Rump Kernels on RTEMS

Introduction 

So, once I had heard about Rump kernels [1] from Gedare Bloom (one of RTEMS maintainers), I started to do some research about it, and whether RTEMS can have a support for such a new architecture. Rump kernel is a way to run unmodified NetBSD kernel drivers virtually anywhere. So, for a platform that can support Rump kernels, a developer can just pick up some NetBSD drivers (that have been tested and proven to work properly), compile and link it without any modifications to the source code or the host kernel itself. Moreover, these drivers can be even upgraded from NetBSD upstream without any significant effort. So, what's exactly Rump kernel, Anykernel and a so-called platform?

Rump kernel is not a fully-featured OS neither a complete virtual machine like KVM or VirtualBox. It's a minimal thin implementation that enables the host platform (see the platform section) to emulate the system calls layer that NetBSD drivers expect/call. Rump kernel is hardware-agnostic, meaning that it does not depend on specific hardware features like virtualization and cache-coherence. For example, kernel drivers need some way of allocating memory (using rumpuser_malloc), it doesn't really matter whether this is a virtual/logical memory (allocated address space using page-table), or fixed physical addresses; it depends on the platform, what concerns Rump kernels is to freely allocate, use and free this area of memory. That's, Rump kernels try to make use of the underlying software platform features as possible as could be in parallel with giving the illusion (and of course working work-arounds) to the drivers that they get what they need! At this point you may be wondering about the structure of Rump kernels and how it depends/relates to the platform. The following figure [2] may make it clearer. Please note that libc and the layers above it are optional.

Figure 1: Rump Kernel Environment

As you can see, the Rump kernel support is stacked. At the top of the stack comes the application that can be POSIX-compliant. In the next section some of these stack components are illustrated and how RTEMS (as an example platform) can and Rump kernels work together.

Platform

So what's the platform? Basically, the platform can be anything like a raw hardware, Virtual Machines or an OS like Linux. Actually, there are currently some implementations for such platforms. So, Rump kernels can run on some POSIX userspace like "Linux, Android, NetBSD, FreeBSD, OpenBSD, Dragonfly BSD, Solaris (+ derivates) and Windows (via Cygwin)" [3]. There are some implementations that run on bare-metal machines like KVM,VirtualBox or hypervisors like Xen. Genode OS has been modified to support Rump kernel [4] and similarly Minix. So, can RTEMS be the next platform? The simple answer is yes!

RTEMS is an POSIX-compliant RTOS, so with a small effort, Rump Kernel can run above this RTEMS/POSIX environment. However, it would make more sense from performance, control and code density perspectives to discard this POSIX dependency and write the whole hypercall layer (see figure 1). Userspace POSIX platforms here [5] have another POSIX library (userpsace libraries on the previous figure) as well as the host POSIX library. As the authors of Rump Kernels say, it's enough for a platform to just implement the hypercall layer to support the whole Rump kernel stack. So, theoretically, if RTEMS implemented this very thin ~1000-lines-of-code hypercall layer, all other NetBSD code can be imported, providing NetBSD drivers, libc, and even unmodified POSIX library.


The hypercall (AKA rumpuser) layer [7] is divided into basic and IO operations. The complete interface can be found here [6]. Almost all of the functions mentioned in that link can be implemented by using/wrapping existing RTEMS features. Some of the interfaces are mentioned below.

Memory Allocation

int rumpuser_malloc(size_t len, int alignment, void **memp) 

void rumpuser_free(void *mem, size_t len)

These functions can easily be mapped to RTEMS libcsupport implementation of (malloc/free). Other memory managers like Partition and Region managers can also be used.

Files and IO

int rumpuser_open(const char *name, int mode, int *fdp)

int rumpuser_close(int fd)

int rumpuser_getfileinfo(const char *name, uint64_t *size, int *type)

void rumpuser_bio(int fd, int op, void *data, size_t dlen, int64_t off,
     rump_biodone_fn biodone, void *donearg)

int rumpuser_iovread(int fd, struct rumpuser_iovec *ruiov, size_t iovlen,
     int64_t off, size_t *retv)

int rumpuser_iovwrite(int fd, struct rumpuser_iovec *ruiov,
     size_t iovlen, int64_t off, size_t *retv) 

int rumpuser_syncfd(int fd, int flags, uint64_t start, uint64_t len) 

The previous IO functions can be implemented by wrapping IMFS and some stubs, most embedded system applications do not need a complete featured file system, but if it's needed, the option of wrapping the correct RTEMS filesystem is still there. How to configure and enable Rump kernel features is an implementation tradoff, but currently rump-posix is doing it by starting a Rump kernel server with a command line flag of which features are needed from the Rump Kernel. For example this command line does such a job (loading a filesystem driver when starting the server)

rumpremote (unix:///tmp/rumpctrlsock)$ ./rumpdyn/bin/rump_server -lrumpvfs unix:///tmp/rumpctrlsock

Clocks

"The hypervisor should support two clocks, one for wall time and one for monotonically increasing time, the latter of which may be based on some arbitrary time (e.g. system boot time). If this is not possible, the hypervisor must make a reasonable effort to retain semantics." [6]

All of the required clock services are provided by RTEMS such as _Watchdog_Ticks_since_boot. RTEMS provides enough time management libraries like Watchdog, Time, Clock manager, Timer benchmark (which may or may not depend on the Clock manager) and CPU Counter (deprecated?). Hence, there are more than enough implementation to support Clocks interface part of the hypercall.

Console output 

"Console output is divided into two routines: a per-character one and printf-like one. The former is used e.g. by the rump kernel's internal printf routine. The latter can be used for direct debug prints e.g. very early on in the rump kernel's bootstrap or when using the in-kernel rou- tine causes too much skew in the debug print results (the hypercall runs outside of the rump kernel and therefore does not cause any locking or scheduling events inside the rump kernel)." [6]

 Both are there!

Threads

int rumpuser_thread_create(void *(*fun)(void *), void *arg,
const char *thrname, int mustjoin, int priority, int cpuidx,
void **cookie)
void rumpuser_thread_exit(void)
int rumpuser_thread_join(void *cookie)
void rumpuser_curlwpop(int enum_rumplwpop, struct lwp *l)

Mainly, all thread management is directly mapped to the host threading implementation. So, when Rump kernel driver creates a thread, the host will actually create this thread and schedule it according to its policy. It does not matter how the host implements threading. For RTEMS, all of these functions can be easily mapped to corresponding ones, no big deal.

Synchronization and Mutexes

Normal mutex operations are provided by RTEMS. There is also a need for Read/Write locks and conditional variables. 

What then?

If we had this hypercall layer on RTEMS, there's no other effort needed. The other BIG NetBSD code can be linked AS IS! At this stage we can try out some NetBSD drivers. We can have some fun by making use of Rump Kernel Remote/Client mode which separates the kernel from the clients (applications). So, for example we can have a bare-metal client connecting to Rump Kernels on RTEMS or vice versa communicating using IPC and TCP/IP. This platform can be setup using some simulators or real hardware. 

One other interesting way is using Rump Kernels to tackle the scalability issues that RTEMS currently faces, providing another solution other than the complex fine-grained locking. We can have cores with attached IO devices that can have Rump kernels on it, and act as servers for other clients (on other cores), communicating together (using inter-processor interrupts, message passing, shared-memory communication or whatever). 

References

[1] http://rumpkernel.org/
[2] Rump Kernels No OS? No Problem!
[3] Rump Kernels Platforms
[4] Genode OS and Rump Kernels.
[5] Userspace (POSIX) Rump kernel.
[6] rumpuser - NetBSD Manual Pages
[7] https://github.com/rumpkernel/buildrump.sh/issues/59

[HOWTO] build and run RTEMS on or1ksim

This post describes how to build, configure RTEMS to run on or1ksim emulator. Installing the tool-chain is a prerequisite before applying the steps in this post; if you have not already installed them, check out the steps here and do it. Once the tool-chain are installed and seen in the executable path, you may proceed with the following steps.

1- Set up the work space.

$ mkdir ~/rtems-dev
$ cd ~/rtems-dev

2- Clone my RTEMS project repo

This is temporary, by the end of the project, all the code at my repo should be upstreamed to RTEMS.

$ git clone git@github.com:heshamelmatary/rtems-gsoc2014.git
$ cd rtems-gsoc2014

3- Switch to or1k branch

I have created a branch for the project to help me with arranging and generating patches against master; meanwhile, keep master branch synchronized with remote.

$ git checkout or1k

4- bootstrap

$ bootstrap -p
$ bootstrap

5- Configuring and building 

$ cd ../
$ mkdir b-rtems
$ cd b-rtems
$ ../rtems-gsoc2014/configure --target=or1k-rtems4.11 --enable-rtemsbsp=or1k_or1ksim --disable-posix --disable-itron --disable-networking --disable-smp

You should get hello and ticker applications in their executable form. Other applications/tests will fail to compile because of other features/implementations that are not supported yet.

Running and debugging hello.exe

1- First you should have an or1ksim configuration script suitable for or1ksim BSP. This is the sim.cfg file I use at this stage of the project. It should be placed at your home directory. Note that as long as more features like: FP, cache manager, MMU manager are added, this file has to be changed to simulate these functionalists on or1ksim.

2- Run hello application on or1ksim.

The configuration file uses RSP (remote protocol) to enable GDB to connect to or1ksim. So, when running or1ksim, it reads configuration script, loads the program into the proper addresses, and waits for GDB to connect.

$ cd $HOME/rtems-dev/b-rtems/or1k-rtems4.11/c/or1k_or1ksim/testsuites/samples/hello/
$ or32-elf-sim -f ~/sim.cfg hello.exe

You should get something similar to the following picture:

3- Run GDB and connect to or1ksim 

From another terminal run GDB and connect to or1ksim

$ or1k-rtems4.11-gdb $HOME/rtems-dev/b-rtems/or1k-rtems4.11/c/or1k_or1ksim/testsuites/samples/hello/hello.exe

From gdb, attach it to or1ksim

(gdb) target remote :50001 

(gdb) continue

UART should emit the string output to or1ksim (and any other channel you provided in configuration script)

References 

[1] Porting RTEMS to OpenRISC - Introduction 

[2] My github project repo (RTEMS).

[3] RTEMS or1k tool-chain status.

[4] HOWTO build or1k-rtems4.11 tool-chain.
[5] RTEMS kernel status.

RTEMS kernel port for OpenRISC | Status Report - 25062014

As introduced before, this year I'm porting RTEMS to OpenRISC 1000 architecture during GSoC program. Other than getting the tool-chain built for RTEMS, the project is mainly about RTEMS kernel. In this post, I'll list the latest updates, concerning RTEMS kernel, that have been achieved so far. The current status is that RTEMS hello and ticker samples can run on or1ksim (see HOTWO build and run RTEMS for OpenRISC).

The code is in its earlier stages, and there is a lot more to do; though, the current code is fairly simple enough that allows anyone to build RTEMS and get hello and ticker samples exes. The project is spread out across RTEMS main components (directories):

CPUKIT

Other than generic APIs, this directory should include shared stuff for any CPU that RTEMS supports; and now it includes or1k. Mainly, it provides details, definitions, configurations, and code for each CPU family for a given architecture. For or1k, the only family is OR1200. It contains processor configurations and properties embedded in .h, .c .S files like:

• In which direction the stack grows. For or1200 the stack is growing down.
• FP unit presence. There is no handling code for FP currently, it's on my TODO list.
• Endianess. Big endian.
• Context Control. This is a structure containing necessary processor context (registers) to be saved/retrieved during context switches. Currently, all general purpose registers are saved as well as supervision register; this is to be optimized in the future.
• Processor definitions. This includes macros for first group of registers that all architectures should implement; most notably supervision register. 
• Context Initialize. This function is implemented to support RTEMS multi-tasking. Initially, it sets elements of Context Control struct including: beginning address of the stack into sp (stack pointer) register and fp (frame pointer) register, loading lr (link register) and sr (supervision register). It's called part of the process of starting multi-tasking.
• Context Switch. The most important function for multi-tasking. Functionality of context switching is supplied via an assembly file called or1k-context-switch.S. This file contains or1k assembly instructions for saving/restoring processor context. It's always invoked for any multi-tasking application.  

There is not any cache or MMU managers currently, this is on my TODO list.

LIBBSP

libbsp is directory that includes every BSP (Board Support Package) for each architecture. For or1k, a new or1ksim BSP is added as an interface to or1k port; it's intended to run on or1ksim emulator. The new BSP contains:

start code

start code is the entry point for the program; it's resposible for providing abstract ISR handlers. For or1ksim, reset and timer handlers are the only statically installed handlers currently. _reset simply jumps to _start which does the following:

1. Load stack and frame pointers.
2. Clear .bss section. 
3. Call bootcard function.

bootcard is a major part for linking BSPs and CPUKIT libraries, it acts as a coordinator from the beginning of initializing the board along with initializing RTEMS data structures, initializing drivers, multi-tasking, etc. The steps an application goes through from the time the first BSP code is executed until the first application task executes are illustrated in the following figure.

linkcmds

This is the linker script describing how the exe code will fit into memory, defining linker symbols that are used in other areas of RTEMS, and handling alignments. The structure of how or1ksim BSP utilizes memory is described in the following figure.

linker symbols 

linker-symbols.h externs all linker symbols for other RTEMS components that may use it. For example, this file is required for initializing context control (in cpukit), zeroing .bss section, and initializing stack and frame registers.

Console driver

Console driver is using UART. For or1ksim simulator, a configuration script is provided to map UART registers to base address 0x90000000. It's working on 115200 baud rate. The process of initializing the console driver includes initializing UART control. Also, the driver implements send_char(), which is used to implement printf, printk within higher layers. Currently, this is the only way we can get output to stdout. or1ksim can be configured to use xterm, tty0, or other channels for rx and/or tx.

Clock driver

Clock driver is essential for RTEMS scheduling purposes and some applications like ticker. The current clock driver implements initialization and tick facility. It should install the tick timer handler into the proper vector location and generate timer interrupt every N ticks. Number of ticks that fire an interrupt is calculated from some RTEMS configurations and the board frequency (100 MHz for or1ksim).  

The clock driver currently is not working in real-time, however, it makes multi-tasking and scheduling working. This issue is to be fixed soon. Also, on my TODO list, the implementation of RTEMS timer benchmark.

IRQ 

IRQ implementation is almost null; once creating IRQ manager for or1ksim (next task), I will generate patches for or1k port to RTEMS to be upstreamed.

In the following post, I will describe HOWTO get, configure, install, run, debug RTEMS application samples (hello and ticker) from my repo. Eventually (by the end of the project), all this code should be upstreamed to RTEMS so that anyone can build RTEMS for or1k like any other target.

References 

[1] Porting RTEMS to OpenRISC - Introduction 

[2] My github project repo (RTEMS).

[3] RTEMS or1k tool-chain status.

[4] HOWTO build or1k-rtems4.11 tool-chain.

[HOWTO] Build RTEMS tool-chain for OpenRISC targets

This post provides two methods of building RTEMS tool-chain for OpenRISC 1000 architecture: 1) building from RSB (RTEMS Source Builder) and 2) building each tool/program separately by downloading official tools' releases and apply our RTEMS specific patches to them. Merely, RSB is responsible for all the stuff including: setting up the environment, downloading releases, applying patches, configuring, building, and installing all the tools. The resulted tools should be program prefixed with or1k-rtems4.11-*. You may want to have a look at OpenRISC ELF GNU tool-chain; but note that RTEMS applications can't be built via these tools. The tool-chain has been tested and used on Fedora 20 and Ububtu 12.04 LTS. 

The tools/programs releases in the time being this post was written are:

• binutils-2.24
• gcc-4.8.2
• newlib-2.1.0
• gdb-7.7
• or1ksim-github-head

Building RTEMS from RSB

Please have a look at RSB documentation here. It provides details in a thorough manner about RSB: how to download RSB, check environment, build RTEMS tool-chain for a specific target. Also, it gives a clear picture how RSB works internally.

1- Setup development and work space

$mkdir ~/rtems-dev

$cd ~/rtems-dev

2- Clone RSB 

$ git clone git://git.rtems.org/rtems-source-builder.git
$ cd rtems-source-builder

3- Check host environment

Check if host environment is setup correctly.

$ source-builder/sb-check

This command will tell you if any packages are required to be installed, if you miss any, please install them and try again, once every thing is Ok, you should have the following message:

$ source-builder/sb-check
RTEMS Source Builder environment is ok

 4- Building

$ cd rtems
$ ../source-builder/sb-set-builder --log=l-or1k.txt --prefix=$HOME/rtems-dev/rtems/4.11 \ 4.11/rtems-or1k

5- Check if all tools are installed successfully. You should get the following results

$ ls $HOME/rtems-dev/rtems/4.11
bin include lib libexec share or1k-rtems4.11
$ ls $HOME/development/rtems/4.11/bin

 

6- Add the newly installed tool-chain to the executable PATH

$ export PATH=$PATH:/$HOME/development/rtems/4.11/bin

Building RTEMS manually 

Currently, all or1k and RTEMS related patches are not upstreamed. So, we have to download official releases and apply patches to support or1k and RTEMS to them. I have worked on combining both or1k and RTEMS patches for all the tools against official tool releases. The following method of building the tools should be temporal. Eventually all patches including or1k and RTEMS should be upstreamed and tools should be built without patches provided here. 

1- Setup development and work space

$mkdir ~/rtems-dev

$cd ~/rtems-dev

2- Get the sources

• binutils-2.24
• gcc-4.8.2
• newlib-2.1.0
• gdb-7.7

3- Get the patches

Download all patches for the previous binutils, gcc, newlib, gdb releases from my repo; preferably, the latest patches (with respect to commit time). Put them in the same directory. 

4- Unpack archives 

$ tar xf binutils*.tar.* 
$ tar xf gcc*.tar.* 
$ tar xf newlib*.tar.* 
$ tar xf gdb*.tar.*

5- Apply patches

$ cd binutils-2.24
$ cat ../binutils*.diff | patch -p1
$ cd ../gcc-4.8.2
$ cat ../gcc*.diff | patch -p1
$ cd ../newlib-2.1.0$ cat ../newlib*.diff | patch -p1
$ cd ../gdb-7.7
$ cat ../gdb*.diff | patch -p1

 $ cd ../ 

6- Configure and build tools

• Create build directories for all the tools

$ mkdir b-binutils b-gcc b-gdb

• Configure and build binutils

$ cd b-binutils
$ ../binutils-2.24/configure --target=or1k-rtems4.11 --prefix=$HOME/rtems-dev/rtems/4.11
$ make
$ make install

• Setup the PATH to include binutils binaries 

$ export PATH=$PATH:/$HOME/rtems-dev/rtems/4.11/bin

• Link newlib into gcc directory

$ cd ../gcc-4.8.2/
$ ln -s ../newlib-2.1.0/newlib .

• Configure and build gcc and newlib

$ cd ..
$ cd b-gcc
$ ../gcc-4.8.2/configure --target=or1k-rtems4.11 --prefix=$HOME/rtems-dev/rtems/4.11 --with-gnu-as --with-gnu-ld --enable-languages="c,c++" --enable-threads --disable-libssp --with-newlib --with-system-zlib --disable-libstdcxx-pch --disable-nls --without-included-gettext --disable-win32-registry --disable-lto --enable-newlib-io-c99-formats

$ make 

$ make install

• Configure and build gdb

$ cd ../
$ cd b-gdb$ ../gdb-7.7/configure --target=or1k-rtems4.11 \
--prefix=$HOME/rtems-dev/rtems/4.11 \
--verbose --disable-nls \
--without-included-gettext \
--disable-win32-registry \
--disable-werror \
--disable-sim} \
--without-zlib \
--with-expat \
--with-python} \
--prefix=$HOME/rtems-dev/rtems/4.11

Building or1ksim

You can follow instructions here to build and configure OpenRISC simulator- or1ksim. Patch for building or1ksim from RSB is on its way to be commited soon.

 

References 

[1] Porting RTEMS to OpenRISC - Introduction 

[2] My github project repo (RTEMS).

[3] RTEMS or1k tool-chain status.

[4] HOWTO build or1k-rtems4.11 tool-chain.

RTEMS (or1k-rtems4.11-*) tool-chain for OpenRISC | Status Report - 25062014

Part of my GSoC project: Porting RTEMS to OpenRISC, I worked on hacking GNU tools to be able to build these tools for RTEMS targeting OpenRISC 1000 (AKA OR1K) architecture. These tools include: binutils, GCC and GDB. Besides, I had to work on Newlib port for OR1K since RTEMS depends on it. or1ksim (OR1K main emulator) is also part of the tool-chain. Currently, all the tools are working fine.

First I will list the status of each tool/program separately. After that (in the next few posts), we will come to the process of building the tool-chain. The following descriptions are concerned with some specific releases:

• binutils-2.24
• gcc-4.8.2
• newlib-2.1.0
• gdb-7.7
• or1ksim-github-head

binutils

There has a been a small patch for binutils to support building it for RTEMS. No big deal with it. Recently, supporting or1k for binutils has been upstreamed; so the next task for RTEMS is to push our patch for review and be upstream to binutils cvs repo.


Newlib

RTEMS depends on Newlib as a library instead of the big libgcc one. Mainly, only Newlib/newlib is necessary for RTEMS. libgloss is not used because RTEMS should provide all the functions and systems calls there. There are some issues regarding Licences and a possibility that the or1k Newlib port may not be upstreamed consequently. Hence, I had to revert back to an old patch to avoid such conflicts. Also, I did not include all of libgloss code. Moreover, I had to write setjmp.S from scratch for the same reason.


GCC

Most of GCC work was about configurations. Some other definitions had to be added to include the proper headers for RTEMS and avoid others from OR1K. libgloss libraries for BSPs provided by OR1K are no longer linked by default (since RTEMS does not use any of them). To test my Newlib port, I had to link bare-metal applications with libnosys.a. Eventually GCC is working fine with Newlib.


GDB

A minimal effort was spent on GDB. It should be built without or1ksim embedded as built-in library. Instead, the current method of debugging with GDB, is to remotely attach it to or1ksim emulator via RSP protocol.


OR1KSIM

The OpenRISC simulator is just used as is from github. Anyone who uses or1ksim should provide a configuration script for his or her target. This is the current sim.cfg script I use to run or1ksim RTEMS BSP. It should be added to your home directory or the current directory you run the simulator from.


RSB (RTEMS Source Builder)

In the time being, all of the previous tools (excluding or1ksim) can be built from RSB; it's the latest modern tool RTEMS uses to build all the tool-chain for targets that RTEMS support. Therefor, I had to add support to RSB to build rtems4.11-or1k-* tool-chain. The patch for such a purpose is committed, so any one can clone RSB and build the entire tool-chain from it. Building the tool-chain from RSB is the easiest way.

In the next few posts, I will introduce some tutorials HOWTO build the tool-chain both manually and from RSB.

References

[1] Porting RTEMS to OpenRISC - Introduction 
[2] My github project repo (RTEMS).
[3] RTEMS or1k tool-chain status.
[4] HOWTO build or1k-rtems4.11 tool-chain.
[5] or1k/rtems related stuff.
[6] tool-chain patches

[GSoC] Porting RTEMS to OpenRISC - Introduction

This year (2014) I’m participating in GSoC program with RTEMS. The project—Porting RTEMS to OpenRISC— (as its name indicates) aims to port RTEMS to OpenRISC architecture. Porting a well-known open source RTOS software like RTEMS for a big open source hardware architecture such as OpenRISC would be of useful to both HW and SW communities. The new port will target a broad range of users and fields (hobbyists, digital designers, computer architecture, embedded systems, industrial applications, etc).

In order to have a successful long term RTEMS port for OpenRISC that people can use, there are main goals (increments) to achieve during the project:

1- Integrate OpenRISC toolchain into RTEMS

To be able to compile and build RTEMS for OpenRISC architecture, some tools need to be added to RTEMS toolchain first. OpenRISC has its own tool-chain independent of RTEMS. So, the job would involve integrating both OpenRISC and RTEMS tool-chain, and make the necessary modifications/additions that fit for RTEMS. These tools include:

• binutils
• gdb
• newlib 
• gcc
• RSB (RTEMS Source Builder)

2- Porting low-level pieces of RTEMS

This includes writing start assembly, device drivers, interrupt handlers, context save, etc. The main components in RTEMS which this goal have to deal with are:

score/cpu: To define general/common OpenRISC architecture's functions.
libcpu (optional): To contain cache and MMU managers.
libbsp: BSPs code.

3- Writing a BSP for a board that OpenRISC supports

A simple BSP that can run hello world and ticker would be needed to be a front-end interface to OpenRISC and RTEMS users. Two BSPs can implemented:

openrisc_or1ksim: This BSP should be for simulation and debugging purposes only.
openrisc_atlys: I have Atlys board which can be used during the project to be the first OpenRISC BSP on RTEMS. Atlys is supported by OpenRISC and libgloss port and can run linux kernel.

4- Setup simulators and debuggers for OpenRISC.

This task includes writing sim-scripts to use openrisc or1k tools, simulators, debuggers. Software and hardware debugging should supported at this stage.

Environment 

• Platform: Fedora 20 and Ubuntu 12.04 LTS.
• Toolchain: Latest toolchain for OpenRISC.
• Simulators: or1ksim and/or qemu.
• Debuggers: gdb connected to or1ksim (OpenRISC tools). Also I should be debugging at real HW (Atlys board) by gdb via JTAG channel.
• Hardware: Atlys FPGA board (supported by OpenRISC).

If you are interested, I should be posting any updates for the project here in my blog. Also, you may want to have a look at project source code at my github account. Project link at RTEMS also exists.

My experience with GSoC

Back to 2012, I was already familiar with some interesting program called GSoC that Google organizes for students to do open source software projects. Like most of CS and Computer Engineering students, GSoC was a great opportunity: only if I could have the chance to participate in. The expectation of being accepted was almost null for me. But why not giving a try? What will I lose? So, I decided to take a step.

Embedded Systems, Operating Systems, RTOS, C: all the keywords I needed to find an accepted organization which matches my interests, and that's exactly what RTEMS tags include in the melange website: the official host for GSoC program. Immediately, I clicked on the link to the RTEMS website, read what RTEMS is about, and searched for open projects. Not surprisingly, there was an open project that appealed to me. To be able to write down a good proposal, I started to read more documentations. After having some headlines in the proposal, it was gradually increasing in size, details and consistency in parallel with reading more about the project details and grasping more concepts. "Nice, now I think I can submit my proposal," I said to myself. Fortunately, submitting my proposal was early and, later, I knew this was one lucky move; I got a lot of valuable and detailed comments from the folks of RTEMS community. That's how things became serious.

The comments made me feel that what I proposed was something important, and needed by users; a feeling that I never had before. I began to try to understand comments, ask about more details, read more and more; consequently, these comments dramatically re-factored my proposal structure and details. After a few weeks of discussions and modifications, the proposal was ready. Once the deadline of application period hit, I was comfortable with what I did. I thought I could not have done better. Few weeks later, the accepted projects were announced, and guess what? I had been accepted! Absolutely, that was a turning point in my life.

I got to do new things and learn interesting stuff about software engineering, how design phase is very important, the benefits of feedback and discussions, why it’s useful to frequently interact with the community via mailing list and IRC. Moreover, I learned a lot about technical issues and coding. Exclusively to my project with RTEMS, my technical hands-on experience has been enriched in a variety of areas like: C programming, RTOS, gdb, gcc, simulators, hardware, embedded systems, git, source control, documentation, other open source tools, and a lot more. Making connections with some great mentors there was one great aspect of participating in GSoC.

I enjoyed having commitments, deadlines, challenges and troubles. That's what GSoC is partially about (other than encouraging students to work with open source software): a real world work experience. People in RTEMS, and any other organization, want you to complete your project successfully. They are thrilled to help you with every challenge you face. Thanks to my mentor, I was able to pass midterm and final evaluations, and I could brag that I am a former GSoC participant.

Statement of accomplishment - GSoC'2012

Next year (2013), I applied to GSoC with RTEMS (again!) and I have been accepted. Right after GSoC, I participated in GCI--Google Code In--as a mentor, not surprisingly, with the same organization. This year (2014), I have applied to GSoC with RTEMS and I am currently awaiting the announcement of accepted students (wish me luck).

GCI'2013

For me, GSoC made what it aims/claims to achieve:

(a) I learned much about open source software.
(b) Now I am stuck to open source and RTEMS.
(c) Got hands-on experience with real world software process.
(d) Made connections with great developers.
(e) Achieved a glory (and got a nice paycheck).

If you are a student and you're considering applying to GSoC, here is my two cents:

(a) Do not worry about your modest experience, you're ought to learn in the first place. Basics are enough.
(b) Make a proposal and get in touch with the organization community. Do both early!
(c) Your proposal should be well structured and detailed. It should explain how will you work on the project and give a clear and reasonable timeline as well as deliverables. Most organizations provide a template for writing proposals.
(d) Choose a project that 1) appeals to the organization and its users, 2) match your interests. Most likely it will be one of the projects ideas.