Porting MINIX3 to Raspberry PI

Student: Nikita Korobov
Mentors: Jean-Baptiste Boric, Sambuc Lionel
git repository: https://github.com/nekorobov/minix/tree/rpi_clean

The MINIX3 has already supported the ARM-based platforms such as the BeagleBoard. The goal of this project is port the MINIX3 to the RaspberryPi. The task requires changing the booting process, because it doesn't allow have more than one platform. The MINIX3 should be more flexible OS, port to the new platform shouldn't require change boot process, kernel files, etc. Only drivers must be written. A device tree is suitable technology for this purpose.

Also, some of the RaspberryPi drivers such as USB, SDCard, SPI, I2C, etc. must be implemented. It's the most long-term issue.

The previous implementation of booting doesn't allow to have more than the one platform, because there were the different phys_base constants, the different hardware initialization functions with conflict names, which prevent compiling all sources of the MINIX into one .elf.

Now the kernel sets a page table on the early bootstrap stage in assembly and only the one file is unmapped. The all hardware-dependent functions called from exemplar of a special table. This table is initialized at runtime depending on platform, where the MINIX runs. We know the platform-depending constants and other platform information from a device-tree. I've imported external libfdt under BSD license to parse the dev-tree quickly.

The device tree is parsed in the pre_init stage. Machine type, memory constants, CPU amount and some necessary platform information are set up in this stage. Each driver, which use the platform depending constants (almost all drivers) should get these constants from the device tree. The earm/fdt.c allows get some parameters without knowledge how the device tree works and how parse it.

It will be good to have the general bootloader for all platforms, we thought. And it will be better to have a general structure in main with information about memory size, platform, framebuffer, etc.for each architecture.

Thus, a kernel-loader parse the device tree on the ARM, packs information into a multiboot2 format, which are compatible with any architecture. Other information(which can't be packed into the multiboot2) the kernel-loader packs into special structure, which is available only for the ARM platforms. The loader passes these structs to kmain, where multiboot2 format unpacks and constants are set.

The paging is also enabled in the kernel-loader. It means that the kernel doesn't contain unpaged code anymore. It makes the linker script easier and the kernel more consistent for each architecture.

The mailbox driver is a character device. Other servers can communicate with it by open/read/write/close. Servers have to make structure with request to the Mailbox driver according to rules, which is described https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface. They have to open /dev/mailbox with read/write permissions and firstly write there request, then read it. You can find an example https://github.com/nekorobov/minix/blob/rpi_clean_driver/minix/drivers/video/fb/arch/earm/fb_arch_rpi.c

• Cleanup existing pull request to MINIX proof of concept port
• Remove dirty hack from kernel
• Make loader more independent

• Improve tty
• Clean up booting process

• I2C driver
• Mailbox driver

• SD card driver

• PCM audio driver
• SPI driver

• USB driver

• Cleanup code, etc.

Arm reference manuals http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.architecture.reference/index.html
RaspberryPi peripherals reference manual https://cdn-shop.adafruit.com/product-files/2885/BCM2835Datasheet.pdf
SDCard description http://users.ece.utexas.edu/~valvano/EE345M/SD_Physical_Layer_Spec.pdf
The Mailbox tags list https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface