Second CPU core missing - Technexion PICO-PI-IMX7 - Yocto

This image runs uni-proc on the i.mx7d. Any special flag to enable the second core?

This image is only for the cortex a7, if you want to generate an image for the m4 cortex, you can do it here: https://github.com/TechNexion/freertos-tn/tree/freertos_1.0.1_imx7d

Shouldn’t I see two CPU listed:

root@imx7d-pico:~# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 48.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

Hardware : Freescale i.MX7 Dual (Device Tree)
Revision : 0000
Serial : 0000000000000000
root@imx7d-pico:~#

[ 0.005950] CPU: Testing write buffer coherency: ok
[ 0.007378] CPU0: update cpu_capacity 1024
[ 0.007408] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.009626] Setting up static identity map for 0x80100000 - 0x80100078
[ 0.010502] rcu: Hierarchical SRCU implementation.
[ 0.012360] smp: Bringing up secondary CPUs …
[ 0.014741] smp: Brought up 1 node, 1 CPU
[ 0.014771] SMP: Total of 1 processors activated (48.00 BogoMIPS).
[ 0.014793] CPU: All CPU(s) started in SVC mode.

I’m moving to the Technexion BSP:

Seems normal with mainline kernel in fact.

Sounds like u-boot is missing something, as I was using the u-boot build artifact from this build.

I have tried this suggestion and it brings up the second core:

https://forum.digikey.com/t/pico-pi-imx7d-booted-with-only-1-cpu-at-1-0ghz/7634/4

Couple of questions,

  1. “Non secure” sounds as if it is something to avoid doing, can someone explain me what the weight of this setting is?
  2. If this is a proper method, how do I set this in the Yocto project? Because now it only works temporarily after changing the environment variable in the u-boot menu at boot.
  3. Is there an alternative approach to this? I would expect this (the soc using both cores) to work by default. Do I need to change the kernel?

I am building from the tutorial by Joris on the warrior branch at the moment.

I have tried this suggestion:

Three observations:

  • The 2nd core does indeed start, both CPU’s in HYP mode.
  • If I only update my board with the .mender file the u-boot config does not get updated. So on reboot the old u-boot config still applies. I need to replace the bootloader and SPL with dfu to the new version. Is this behaviour expected? I was expecting the new u-boot to get updated with the .mender file as well.
  • caam behaves differently depending on CONFIG_ARMV7_BOOT_SEC_DEFAULT

CONFIG_ARMV7_BOOT_SEC_DEFAULT=y: (so single core active)

root@imx7d-pico:/lib# dmesg | grep caam
[    2.444686] caam 30900000.caam: Entropy delay = 3200
[    2.450039] caam 30900000.caam: Instantiated RNG4 SH0
[    2.509452] caam 30900000.caam: Instantiated RNG4 SH1
[    2.514527] caam 30900000.caam: device ID = 0x0a16030000000000 (Era 8)
[    2.521108] caam 30900000.caam: job rings = 3, qi = 0
[    2.672765] caam algorithms registered in /proc/crypto
[    2.687239] caam_jr 30901000.jr0: registering rng-caam
[    2.694308] caam 30900000.caam: caam pkc algorithms registered in /proc/crypto

CONFIG_ARMV7_BOOT_SEC_DEFAULT not defined: (dual core active)

[    2.515625] caam 30900000.caam: Entropy delay = 3200
[    2.551627] caam 30900000.caam: failed to acquire DECO 0
[    2.556969] caam 30900000.caam: failed to instantiate RNG

The rescue image from Technexion does boot up the board with the two CPU’s in SVC mode, but it is unclear for me how they do that.

I have tried to narrow this down. It looks like SMP it actually trying to get cpu1 up but is failing when invoking callbacks.

Looking at the call below to cpu_up for cpu 1, it returns an error code -38 although the return value is not used in the code normally. I have verified this by printing the value for cpu and the return value with pr_info on the terminal.

This traces all the way back to the moment the callback is invoked for CPUHP_BRINGUP_CPU (cpuhp_state #85) where ret get’s the value -38, which if I’m not mistaken means ENOSYS.

The callback invocations for this list below did pass without this error just before that:

1; CPUHP_CREATE_THREADS
2; CPUHP_PERF_PREPARE
35; CPUHP_WORKQUEUE_PREP
37; CPUHP_HRTIMERS_PREPARE
40; CPUHP_SMPCFD_PREPARE
41; CPUHP_RELAY_PREPARE
44; CPUHP_RCUTREE_PREP
62; CPUHP_TIMERS_PREPARE

Hopefully someone will see my post and share some experience in the matter, or point me to a place where this question might best be answered.

@Bart @jwinarske

I also have this board. I’ve used (I’m using it) Yocto mender dunfell and Yocto technexion Hardknott and I’m very interested in using OS on m4 for 1 RPMsg project I have.