AnsweredAssumed Answered

iMX.6Q SabreSD enable core1, 2 and 3 in u-boot

Question asked by Andrea Colomba on Nov 9, 2016
Latest reply on Nov 10, 2016 by Andrea Colomba

Hello iMX community,

I am working on a university project with the imx6 sabreSD board and I'm trying to enable secondary cores 1,2 and 3.

On core0 I have u-boot running, which is loaded from an SD card. My goal is to run a standalone bare-metal program on the secondary cores.

I have written a custom command on u-boot in order to enable the secondary cores. For example if I want to enable core1 I setup SRC registers in the following way:

- I write the address of the startup function in the register SRC_GPR3 and I write the address of the argument of the startup function in the register SRC_GPR4;

After this I load a binary standalone program (the Hello World standalone example provided with u-boot) in the memory address 0x17800000 (which is the same address that I put in SRC_GPR3), and then I enable the bit 22 in SRC_SCR in order to enable core1 and run the standalone example on core1.

I expect that core1  runs the Hello World program and prints a message on the u-boot console after tetting the bit in SRC_SCR but nothing happens.

By looking at bit 1 of IOMUXC_GPR5 it looks like core1 is being set to WFI (wait for interrupt) after I run the command.

I have also found this very similar thread ( Reset Core 1, 2 and 3 in iMX6) but I wasn't able to solve my problem.

Any suggestions? Can you help me? 

Thank you in advance,

Andrea

 

[EDIT] After looking at the i.MX6 Firmware Guide I saw that the following description:
1. Initialize persistent bits for the secondary core being activated.

2. Set the core_enable signal for each of the cores in the SRC Control Register (bits 22:24, for core1, core2, and core3 respectively).

3. Once the enable bits are set, the corresponding core is released from its reset state, and it executes the boot ROM (at 0000 0000h).

4. The boot ROM determines if it is a secondary core and uses the presistent bit registers to determine what to execute next.

I guess it has something to do with the boot ROM. At the moment I haven't changed anything yet in the u-boot setup code in order to support multi-core, I guess I should have a look at that isn't it?

Outcomes