Writing a custom bootloader

#1

Hi,
for a project of mine I want to write my own bootloader for the Rock Pi 5 that boots from eMMC. As far as I’ve understood, on reset, an Arm core executes from the stage 1 bootloader from BROM, I don’t want to touch that.

That BROM code then looks in the eMMC for the ID block. If found, the arms pc jumps there. Now my question. The boot is split into a spl and the actual uboot bootloader, why is that? I’ve also found that you can download the spl from RockPi’s git directly so it’s not even compiled with uboot, so is it proprietary?

I would love to replace both stages but I can’t find the spl’s code anywhere. If the spl is proprietary, can I then just put the provided spl in my img and put my bootloader at the here specified location(0x4000)?
Maybe knows some project where something like that has been done before?

regards Robert :slight_smile:

#2

Hey there, as far as I believe the Brom doesn’t deal with eMMC either. It just loads the stage1 from spl flash. The reason you have spl and stage2 (U-Boot) is that spl initializes and loads U-Boot from eMMC. This behavior can be changed with a differentl spl image that initializes and loads nvme, USB, microsd or even pxe boot via Ethernet.

#3

Ok so BRom loads the SPL from the “spl flash” but how come, that when building the img for the Rock Pi, the spl is included in there, if it’s not put on the eMMC but the spl flash? (because the image is then dd’ed on the eMMC or is the SPL part of the image automatically written to the SPL Flash? Resources describing the process in more detail would be great… :smile:

thx!

#4

That is a good question and I’d have to crawl through the image builder on what is done here, but I have two best guesses:
(1) the spl image is just included as a file for the user to manually install
(2) first boot of the image flashes the spl image to nor flash

#5

Ok, I really don’t want to debate or anything, so please just assume that I’m wrong.
But the radxa wiki states (below the ascii “graphic”) that when booting from eMMC: Boot from eMMC means all the firmware(including stage 2, 3, 4, 5) in eMMC;. So I assume that BROM really touches the eMMC but maybe that changed?

#6

Actually I had been looking for that wiki page as reference since I hadn’t messed with boot for a while, but this clarifies it rather well. Apparently spl image can be loaded from either spl flash or eMMC. This makes sense in a development environment since spl nor flash is hardwired to to board and has an extremely limited amount of write cycles(should be about a 1000-10000 writes). So if you’re working on that part of the boot process it makes sense to keep it on eMMC, which also makes updating it a lot easier. It would also allow to failsafe restore the rock if spl becomes corrupted. As for your original question as to why spl/U-Boot are split stages, that is rather simple: spl size is limited, and you might want to boot another os/use a different bootloader on the board. I do remember early 2000’s speedport w700vs that had a proprietary os that couldn’t boot from uboot, compared to their sister series w701v which was really just a rebranded fritz!box that did boot off uboot. But I am diverging. As said most likely reason it that you can replace uboot with other boot environments, such as UEFI for example

1 Like
#7

Ok, thank you!
My plan currently would then be to replace only the ppl, and not the spl. I I’m understanding the wiki correctly, therefor I would have to build everything as usual(with the idbloader.bin) but replace uboot with my bootloader/kernel.
The problem is that I’m still very unorianted in regards to the state of the soc/ memory at that point. When I’m understanding things correctly, my bootloader should then be loaded at 0x4000 in RAM at some trusted EL(3 probably) and I would have to relocate my kernel to 0x8000 and eret down somehow…
Is that remotely correct? :smile:

thank you so much for the help

#8

that sounds about right. if you want to skip uboot, it should be possible to just write a small piece of code in assembly that loads the kerne to 0x8000 and then jmp fars there - no warranty on that though, its been a decade :smiley:

1 Like