January 2, 2022
Orange Pi 4 (Rockchip 3399) how does it boot?
This is a rabbit hole that I always enjoy going down.
It can be a distraction though from doing what I intend to
do with the chip once I get it to boot my code.
The only thing that is truly important is to know where U-Boot
lives, so we don't ask U-Boot to load our image on top of itself
(or on top of the U-Boot stack). Once we are loaded, we are free
to nuke U-Boot entirely out of the way.
How to study the boot process
One thing I could do is to let U-Boot boot my code, then scan memory to
see if I can find U-Boot in memory. I could look for other things as
well. I could read out and disassemble the ROM bootloader.
Another approach is to find the scripts and such that write the
eMMC image and see how they arrange things. This can involve a fair
amount of research.
This could be my big chance to play with Ghidra!
This is reverse engineering tool provided by (of all people) the NSA!
I learn that a recent version of java (11.0.2, which I presume is a
recent version) and that somewhat cools my enthusiasm, especially
since I hate and despise Java, but you should never say never.
A generic outline of the boot scheme
Here is a short outline, with questions that
I hope to answer someday.
- The cores comes out of reset and begin to run some code.
- Do all the cores start at once, or just a primary core?
- Some SoC keep all but one core powered down until activated,
others start them all and park all but one somehow.
- Whatever the case, they will all end up running the
on chip bootrom code (sometimes called "MASKROM").
- In our case, the primary code scans SD cards and eMMC
looking for something it recognizes.
- In general it will find and run BL31.
- BL31 will in turn find and run U-Boot.
- In my case, U-Boot will try to fetch and run an image
via tftp over the network.
That is a brief outline, with lots of details left hanging.
Note that when the MASKROM runs (I like to simply call this the bootrom)
it has no idea what DRAM may be attached, so it needs to use a block
of static ram provided for it as part of the SoC.
It is likely to load the next stage into that static ram and run it.
This could be BL31 or who knows what. U-Boot often has a small first
stage loader that will fit into static ram that loads the full U-Boot
image into DDR ram. Lots of things are possible.
You ought to be asking, "what the heck is BL31?"
What is BL31?
This is part of what is called "ARM trusted firmware".
This gets involved in a bunch of things like secure versus insecure mode.
Various "execution levels". As near as I can tell, U-Boot as
well as my code run in EL3, but I do not know yet if I run secure
or insecure.
In the good old days, processors typically had two modes,
supervisor mode and user mode. Now we have at least 4 modes
(EL0,EL1,EL2,EL3) as well as secure and insecure.
All of this bears more and careful study.
But as for BL31, one might guess that "BL" stands for "boot loader".
There are apparently also BL32 as well as BL33, not to mention
BL1 and BL2. We don't have all of these (at least I don't think
we do) in play on the Rockchip.
The bootrom image is protected!
At least I get synchronous aborts when I try to dump it using U-Boot.
There is a way around this (see the link below).
By coincidence, I tripped across this great tutorial about how to analyze a synchronous abort that
has been caught by U-Boot in the U-Boot documentation!!
The trick is that ATF (ARM trusted firmware) has locked down the address space so you get faults when
you access the address range where the ROM is at. You could on one hand be annoyed (as I was),
or you could reflect on the fact that this is actually a good thing for most software that will
simply be screwing up if it tries to access these addresses.
Check the link for the workaround.
I got an email in December 2022 from a fellow who had managed to read out the RK3328 bootrom and also found an RK3399 image somewhere.
More concrete details about the boot scheme
I did some searching, hoping to find a document about the on-chip bootloader.
I found this fascinating discussion on the Rockchip Wiki:
Something they call "idbloader" is the first thing that runs after the bootrom.
A possible source of information is the README.rockchip file in the u-boot sources.
Note that mainline U-boot is said to support many rockchip Soc including RK3288, 3308, and 3399.
The Pine64 Wiki has interesting information. The firefly board is another RK3399 based little board
that may provide useful information.
And more !! 2-8-2022
Lots of links pile up in my browser as I search for things and find exciting tidbits:
Have any comments? Questions?
Drop me a line!
Tom's electronics pages / tom@mmto.org