We’re looking to run different bare-metal applications on each of the cores, however whilst we are able to use the primary core we are unable to start applications running on the secondary cores.
Within U-Boot we have loaded an binary for the secondary cores at address 0xA100_000 and are using the command cpu 1 release 0xa1000000 to attempt to start the application running on a secondary core. However the core is not released.
Debugging with a JTAG probe (CodeWarrior TAP) we can see that all of the secondary cores remain blocked on a “wfe” instruction at address 0x0000_1048 even after issuing the U-Boot cpu release command. This address is within the BL1 stage of the ATF, i.e. it appears that U-Boot has failed to release the core from the initial boot ROM.
We are running U-Boot as supplied in the 20240530-3fbd680 images.
Any help on how to release the secondary cores would be greatly appreciated.
A follow-up on this. I have now been able to get code running on secondary cores, but only by manually executing calls to the PSCI CPU_ON function through the the bare-metal application running on core 1.
The U-Boot cpu release command should be doing exactly this, but clearly isn’t working.
This looks to be a bug in the build of U-Boot for the for the HoneyComb / ClearFog boards.
when running cpu release are you getting any output? If check_psci fails then standard asm calls are used to the release the core. Otherwise you should see a message “begin to kick cpu core…” and the call to psci should happen.
There is no output when running the cpu release command. So yes, it looks like check_psci is failing for some reason.
I think I see the problem, looks to be a bug in the upstream U-Boot code.
check_psci (u-boot/arch/arm/cpu/armv8/fsl-layerscape/cpu.c at master · u-boot/u-boot · GitHub) returns 0 if a PSCI version is successfully received and 1 otherwise (i.e. in the failure case).
However, the cpu_release function (u-boot/arch/arm/cpu/armv8/fsl-layerscape/mp.c at master · u-boot/u-boot · GitHub) interprets the response code from check_psci backwards, i.e. it uses the spin table method if check_psci returns 0 when it should be using the PSCI method.
The check in cpu_release (mp.c line 309) needs to be corrected from if (check_psci()) { to if (!check_psci()) {.