We had bought the Raspberry Pi Model B rev 2.0 board for a long time (this is the first Rpi 1) and even took the first steps in porting: the UART, interrupt controller, timer, and even framebuffer were implemented in some form. But the data on how to start it was lost, so I had to remember / understand it again.
Firstly, they launched on the QEMU emulator. Regular QEMU has raspi2 machine support, but no raspi. But when there was a porting process, just raspi support was added. We still have the version in our repository, though we had to draft commits to compile it to the modern environment, but in the end we got a version of the QEMU emulator that has rpi1 support – the “-M raspi” machine (you can see how to run it on our computer wiki) As a result, Embox was launched there and drew a gradient in the video memory.
There was a question about starting on iron. How to boot was not clear at first, so we decided to try the standard Raspbian. From official site download 2020-02-13-raspbian-buster-lite.img. All downloads occur from a microSD card, so we prepare it – copy the resulting image
dd bs=4M if=2020-02-13-raspbian-buster-lite.img of=/dev/sdb conv=fsync
where “/ dev / sdb” is the SD card.
If you look at lsblk now, there will be something like this:
sdb 8:16 1 14,6G 0 disk ├─sdb1 8:17 1 256M 0 part └─sdb2 8:18 1 14,3G 0 part
Let’s mount sdb1 and see what lies there:
$ sudo mount /dev/sdb1 /mnt $ ls /mnt/ bcm2708-rpi-b.dtb bcm2710-rpi-3-b.dtb COPYING.linux fixup_db.dat start_db.elf bcm2708-rpi-b-plus.dtb bcm2710-rpi-3-b-plus.dtb fixup4cd.dat fixup_x.dat start.elf bcm2708-rpi-cm.dtb bcm2710-rpi-cm3.dtb fixup4.dat issue.txt start_x.elf bcm2708-rpi-zero.dtb bcm2711-rpi-4-b.dtb fixup4db.dat kernel.img bcm2708-rpi-zero-w.dtb bootcode.bin fixup4x.dat LICENCE.broadcom bcm2709-rpi-2-b.dtb cmdline.txt fixup_cd.dat overlays bcm2710-rpi-2-b.dtb config.txt fixup.dat start_cd.elf
As you can see, there is a whole set of * .dtb for all occasions – for different versions of Raspberry. We also see the bootloader – bootcode.bin, and kernel.img is Linux.
We connected the monitor via HDMI to the board, booted, saw Raspbian, everything is fine. Next, you need to copy our binary with Embox to kernel.img so that the bootloader loads it. Build Embox:
make confload-arm/rpi1-model-b make
Copy the resulting binary:
cp build/base/bin/embox.bin /mnt/kernel.img
We insert the SD card back into Rpi and turn on the power – on the monitor, the square that should have been drawn by the Embox did not appear. Well, let’s try to connect via the serial port and debug our binary. To do this, use the RDC1-USB-UART adapter. We connect it to the board as follows:
RDC1 Rapi GND <---> GND 5V <---> 5V RX <---> TXD0/GPIO14 TX <---> RXD0/GPIO15
Here You can see the pinout in the picture so that it is forgiven. Now it turns out that the power to the USB adapter comes from the USB hub of the PC, and the power to the Rpi, in turn, is supplied from the USB adapter.
Turn on. Connect via minicom:
sudo minicom -d /dev/ttyUSB0
No conclusion is visible. There must be some kind of problem with the serial port driver. We try to disable register initialization, and use what was configured by the bootloader, fill in a new image on the SD card – the output has appeared. Everything is clear, it means it’s connected correctly, but the serial port driver is not programmable correctly. I will not talk about how we repaired the PL011 serial port driver, but I will note a couple of points that may be useful when developing for this platform. Firstly, the base addresses on Rpi are computed somehow confusing, they can’t be found immediately in the documentation, so a good way to check the base address of the registers is to look at them in Linux:
pi@raspberrypi:~$ ls /sys/bus/amba/devices/20201000.serial
We see that the address is 0x20201000.
The second point is that there is Linux modified for Rpi, which you can compile and copy to kernel.img – www.raspberrypi.org/documentation/linux/kernel/building.md
In the case of the serial port, it really helped to understand the frequency of the input UARTCLK necessary for programming the baud rate – just insert printk () in the right place in drivers / tty / serial / amba-pl011.c.
As a result, without any significant changes, we managed to launch the same image as for QEMU on iron.
That, perhaps, is all, since it makes no sense to disassemble the driver sources, because you can simply study them in our repository. In general, it seems that under Raspberry there are very few ports of other non-Linux OS. For example, I did not find either FreeRTOS (it turned out that some kind of repository is on GitHub’s, but not in official releases), neither for NuttX, nor anything like that. Yes, and discussions on the forums suggest that RTOS is supposedly not needed there and take better to play Arduino – www.raspberrypi.org/forums/viewtopic.php?t=201540
Osdev example turned out to be idle, so if someone wants to do something on bare metal, then look at the examples with us better 🙂
Full support for the new Rpi 2/3/4 is still in our plans. But some support is likely to be provided as part of GSoC 2020, one of the most popular ideas among students. Actually, for GSoC, we restored Rpi1 support in Embox. If someone has thoughts about why they need Rpi RTOS, write in the comments, we will be happy 🙂