Writing OS for ARM Processors

Question

I recently worked on a very simple OS for the x86 architecture. But then I realised to build it on a smaller scale for ARM boards (like the RPi).

I want to ask that how different is the ARM instruction set from x86?

Is there any BIOS even on ARM boards? If not is there any of other way to print outputs on screen or video memory?

What all I would have to change for programming the OS on a Raspberry Pi?

For a glimpse of what I know - I have created a simple OS that can print words on screen, read from the disk and load a kernel onto the memory and switch to 32 bit mode.

Answer 1

There is no layer equivalent to a PC BIOS that performs hardware abstraction, you will need to implement a driver for each particular peripheral/controller present in your processor.

In ARM, most peripheral access is memory-mapped. There's no concept of a separate I/O space, or separate IN and OUT instructions like x86 used traditionally (although PC peripherals increasingly use memory-mapped access also).

Getting a display working might consist of enabling an LCD controller peripheral, writing valid row count, column count, and clock divider values to match a mode your display supports, then writing to the framebuffer. There may be interrupts to handle, or you may be able to do without them if you don't mind tearing. On a PC, the BIOS would have written some valid values, on an ARM, it's likely the display controller is not even enabled until you do it in your code.

There will be an entire chapter in the Programming Guide for your processor chip dedicated to the display peripheral. Also, you may find that code has already been written for a bootloader such as u-Boot, in which case you can write your OS to start with whatever state is configured by the bootloader.

The unfortunate thing about the Raspberry Pi, from an embedded engineer's perspective, is that large parts of the its Programming Guide (everything to do with the VideoCore) are only available by signing an NDA.

You may have better luck using one of the other kits like a BeagleBone (with a TI OMAP processor) where documentation is publicly available.

Answer 2

First of all, the "ARM" denotes many different processors - they differ one from another much more, then first 8088 and newest "Pentium"-s.

The ARM-s instruction set is very different from x86's one. ARM may have two different instruction sets (Thumb and ARM native, many have the Thumb only) and, if both are implemented, a jump to an odd address causes execution of the Thumb, while a jump to an even address causes execution in of the ARM set. It has selective multiregister "push", "pop", "load", and "store" (e.g. "push {R0,R4-R11}" - x86 push either one or all registers) and conditional executing of usual instructions (needs prefix), but it does not have anything like "loop", "movsb", segment registers, specialized index registers, specialized I/O instructions...

ARM processors are fairly complicated - e.g. documentation of ARMv7-M architecture has over 900 pages (Intel 80386 - 126 pages; well, 64-bit Intel CPU "Instruction Set Reference" has over 2K pages, seems any document grows until its size exceeds capacity of intended readers), and another document describing on-chip peripherals has another 1500 pages - seems the single chip (not every) has more peripherals, than typical PC.

As BIOS is concerned: I am just exploring LPC-Link2 containing LPC4370 chip (which has 3 ARM CPU-s: Cortex-M4 and 2 Cortex-M0; only the first starts on power-on or reset, other must be activated by the first), and it has some BIOS - the BIOS can boot an OS from "SPIFI" (it is a kind of EEPROM, 1MB, external to the LPC4370, but put on the board; the SPIFI can serve as a "boot device" (the code is copied to chip's RAM and then executed), or as a memory from which the OS runs (directly, without copying) - the BIOS looks at its contents and uses it in one of these two ways), or via USB (with help of a program running on another machine and connecting the LPC-Link2 as an USB device). Many other chips have FLASH memory (internal to the chip) and boot or run an OS from it. Usually they have a serial interface which can be used for debugging (and it has e.g. 2 protocols, one of them being selected when the chip is reset).