# Unable to release secondary cores / HoneyComb LX2 **URL:** \ **Category:** NXP LX2160\ **Created:** [July 26, 2024, 8:50am UTC](https://community.solid-run.com/t/unable-to-release-secondary-cores-honeycomb-lx2/874 "2024-07-26T08:50:38Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![stephen](https://avatars.discourse-cdn.com/v4/letter/s/96bed5/32.png) [@stephen](https://community.solid-run.com/u/stephen)\ **Post date:** [July 26, 2024, 8:50am UTC](https://community.solid-run.com/t/unable-to-release-secondary-cores-honeycomb-lx2/874/1 "2024-07-26T08:50:38Z")
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. ---
**Author:** ![stephen](https://avatars.discourse-cdn.com/v4/letter/s/96bed5/32.png) [@stephen](https://community.solid-run.com/u/stephen)\ **Post date:** [July 26, 2024, 11:12am UTC](https://community.solid-run.com/t/unable-to-release-secondary-cores-honeycomb-lx2/874/2 "2024-07-26T11:12:24Z")
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. ---
**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\ **Post date:** [July 29, 2024, 7:59am UTC](https://community.solid-run.com/t/unable-to-release-secondary-cores-honeycomb-lx2/874/3 "2024-07-29T07:59:13Z")
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. ---
**Author:** ![stephen](https://avatars.discourse-cdn.com/v4/letter/s/96bed5/32.png) [@stephen](https://community.solid-run.com/u/stephen)\ **Post date:** [July 29, 2024, 8:04am UTC](https://community.solid-run.com/t/unable-to-release-secondary-cores-honeycomb-lx2/874/4 "2024-07-29T08:04:50Z")
There is no output when running the cpu release command. So yes, it looks like check\_psci is failing for some reason. ---
**Author:** ![stephen](https://avatars.discourse-cdn.com/v4/letter/s/96bed5/32.png) [@stephen](https://community.solid-run.com/u/stephen)\ **Post date:** [July 29, 2024, 9:05am UTC](https://community.solid-run.com/t/unable-to-release-secondary-cores-honeycomb-lx2/874/5 "2024-07-29T09:05:16Z")
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](https://github.com/u-boot/u-boot/blob/master/arch/arm/cpu/armv8/fsl-layerscape/cpu.c#L1064)) 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](https://github.com/u-boot/u-boot/blob/master/arch/arm/cpu/armv8/fsl-layerscape/mp.c#L300)) 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()) {`.