December 4, 2025

Orange Pi R1 Plus LTS (RK3328) - starting up cores

I managed starting the second core on an Allwinner H3 (aarch32) and now would like to find out how the game is played on the Rockchip RK3328. Presumably the method will be similar for the RK3399 and I will be able to move on to that once I figure out the secrets.

The bootrom

Each and every core starts out running the bootrom at address 0xffff0000. The bootrom reads the mpidr_el1 register and examines the low 9 bits. This is the processor number. If it is zero, this is the first (main) core and it goes on to run the bootrom. If it is not zero, the core gets parked in a WFE loop examining a pair of locations in on chip memory. These locations are: 
ff090004 - wake up signal
ff090008 - address to run at
The loop watches ff090004 and if it sees 0xdeadbeaf, it fetches the value from ff090008 and branches to there to run. Simple enough.

As an experiment, I tried this with no result. This indicates one of two things. First, some other entity (bl31 or U-boot) has already grabbed the core and has it parked someplace else. Second, the core may simply not be powered up.

I think it is more likely that the core is just not powered up, but we shall see.

PSCI and CPU_ON

I am just learning about this. PSCI stands for "Power State Coordination Interface".

I use "run linux" from the U-boot prompt on my board to fire up debian (root password er3nae) and capture the boot messages.
I don't see any psci messages related to CPU, only these two sections: 

[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.2
[    0.000000] percpu: Embedded 35 pages/cpu s103256 r8192 d31912 u143360
[    0.000000] Detected VIPT I-cache on CPU0

[    0.043654] smp: Bringing up secondary CPUs ...
[    0.045235] Detected VIPT I-cache on CPU1
[    0.045553] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
[    0.047413] Detected VIPT I-cache on CPU2
[    0.047727] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
[    0.049785] Detected VIPT I-cache on CPU3
[    0.050106] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
[    0.050490] smp: Brought up 1 node, 4 CPUs
[    0.050631] SMP: Total of 4 processors activated.
[    0.050654] CPU: All CPU(s) started at EL2
What PSCI is, is a protocol for asking the secure monitor running at EL-3 to perform certain power management related services for us. In our case, the secure monitor is BL31 from "arm trusted firmware" and the service we might like is "CPU_ON". Calls are made to the "secure monitor" using the SMC instruction. 
	SMC	#imm4
It includes a 4 bit immediate value that the secure monitor can inspect. There is also an HVC instruction (with a 16 bit immediate value) that can be used to request services from a Hypervisor on systems that are using one.

Let's build BL31 from source!

Why not. We may learn something. We can search for 3328 in the build messages.
This took less than a minute:
Have any comments? Questions? Drop me a line!

Tom's electronics pages / tom@mmto.org