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. 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