-
Notifications
You must be signed in to change notification settings - Fork 0
Overview
My name is Jonathan Cline and I am a Senior at George Ranch High school. This repository contains everything code and code documentation wise for our entry into the TSA event for Software Development. I have been programming for over six years and work best with C++ with Assembly following as a close second. I may or may not be working alone on this project.
The goal of the project is to develop a working generally usable Raspberry Pi system entirely from scratch. This means writing a kernel, drivers, OS, a few user-land applications, and even a compiler and assembler for on-system work. As an added challenge, IDEs and such are off limits. Cross-compilation tool chains can be used but all Makefiles must be handwritten. (Visual Studio Code is allowed for sanity's sake - but ironically there isn't a feature-rich extension for ARM support so I've had to write an extension to help with that).
Firstly, you need to go ahead and abandon your prior methods of developing as this project will require you to work a little. I promise it is easy once you are used to it.
The core tools we use are the following:
Visual studio code is an extremely lightweight editor with the ability to run extensions to add to its functionality. This is the tool I am personally using for working on the project. You are free to use something else but VSC is probably the best option available. I have an extension I work on from time to time that adds (very partial but still some) language support for Aarch64 and contains language support for ARM (a32).
Make is a lifestyle. Makefiles allow you to run commands through your system shell to build a project or do whatever is specified in said Makefile. Make is the program used to execute Makefiles. Make is really mostly used through your system shell so get comfortable with that command line! All build steps in this project use Makefiles (as of 12-28-2019).
The two tool chains listed above are what actually turn the assemble code into something the machine can read. The Arm-none-eabi tool chain is for building 32 bit ARM assembly and Thumb instruction set while the Aarch64-none-elf tool chain is for building 64 bit ARM assembly. These I hope to bundle with the project to make life easier on the noobs.
Due to an ever-present C++ mindset, a lot of the project structure is built around APIs and interfaces. I have no clue if my terminology is correct but I don't really care. The system I've laid out seems to be fairly solid.
The core layering is as follows (top is least abstract, bottom is most) -
- Physical Drivers
- Kernel
- Abstract Drivers
- OS
- User Applications
Provide some amount of API consistency across RPI boards. These are small and numerous. See the drivers module for more information on how the build system works and how these are organized. These are the building blocks of computer IO and peripheral access.
Manages low-level resources and starts the OS. Handles things like memory allocation and keeping track of which users (OS included) are using which regions of memory. Also handles direct system access and acts as the final barrier between the OS and the hardware.
Abstract Drivers implement a particular concept that makes use of Physical Drivers. An abstract driver for providing Timer functionality can be imagined. The Physical Drivers available that can provide this timer functionality change regularly between devices so we must add a layer of abstraction to make user-land applications more easily portable. These wrap physical driver functionality and are at about the same abstraction level as the OS.
Manages abstract resources such as files and user-land applications. OS forms a protective barrier between the user-land and the Kernel. OS also provides access to abstract drivers for use by applications to help promote code portability. OS can work with all previous layers.
Actual 'user' code to use on the machine. The goal of the below layers is to make this user-land code extremely portable and not system dependent. Ideally an application that works on one device running our code should work across all devices running our code (assuming any peripherals being used stay the same, if the USB ports aren't there than you're out of luck).