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:
- Load stack and frame pointers.
- Clear .bss section.
- 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
