Upgrading Embedded Xinu for the Multi-Core Raspberry Pi 3
Mentor: Dr. Dennis Brylow.
Background && Motivation
The Embedded Xinu infrastructure is a simple operating system designed to introduce students to many low level computing concepts, including Driver Creation, Exception and Interrupt Handling, and much more. Many universities have created Xinu Labs, classrooms running Xinu on multiple embedded devices (either Raspberry Pis or Linksys Routers). Marquette University uses one such Xinu Lab to teach its Operating Systems course.
Using information obtained from past studies, we expand on the current Xinu infrastructure. One of the main goals of this project is to modify Xinu to run on new multi-core Raspberry Pi 3s while still maintaining support for previous platforms. Another goal of this project is to create structures within Xinu which effectively and efficiently use multiple cores.
Understanding the Pi 3
In order to begin porting Xinu onto the new architecture of the Raspberry Pi 3, we first needed to understand the fundamental differences between the Pi 3 and its simpler predecessor, the Pi 1 (which currently runs Xinu in Marquette's Systems Lab). Here is a table of distinctions between the two:
|RPi 1 (Model B)||RPi 3|
|CPU||ARM 1176JZF-S||ARM Cortex-A53|
|Architecture||ARMv6 (32-bit)||ARMv8 (64-bit)|
Unfortunately, the documentation for the Raspberry Pi 3's System on Chip is sparse. However, deeper digging yielded more knowledge on how past Raspberry Pi systems have worked. With such information, it is safe to infer that the Pi 3's SoC is most likely similar to that of its predecessors. Below is a diagram of the Pi's boot order and compilation:
- Got a bare metal program to run on our Raspberry Pi 3
- - Using C programming: Turned on an LED light using GPIO pin 16 on our Pi
- - Reprocessed the C code into ARM64 Assembly code, and used it to turn on an LED using the same pins as before.
This proved that the boot process was indeed reaching the ARM64 Assembly code, but we grew skeptical that upon compilation, the Assembly code may have been the only code reached. We performed additional testing to pinpoint where exactly our program was reaching.
|Tested for:||Did it reach?|
|Busy wait in our Assembly code||Yes|
|Assembly branch to working C "hello world" code||Yes|
|Assembly branch to our own C code||No|
- - These results show that there is something incorrect with how our C code is turning on the LED. It could be that the Pi simply does not reach our C code branch, or our C code could contain a mistake.