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

cancel
Showing results for 
Search instead for 
Did you mean: 

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

641 Views
andreacolomba
Contributor II

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?

Labels (1)
2 Replies

118 Views
igorpadykov
NXP TechSupport
NXP TechSupport

Hi Andrea

it is right, as every core starts from 0 address, it is handled by rom.

If you have sdk (one can obtain it entering service request), one can look

at attached sdk smp_primes and cpu_multicore examples.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

118 Views
andreacolomba
Contributor II

First of all thanks for the reply. I have given a look at the documentation and the examples provided in the SDK. 

So far I've been able to program SRC registers to provide the entry point address and the argument. Following the firware guide I tried to put the entry point to the reset handler function in the start.s assembly file of u-boot.

What I do not understand is about the assembly code provided with uboot: I have some assembly files vectors.s starts.s, lowlevel_init.s that are responsible for the startup of u-boot. I have tried to add some assembly code taken from the Firmware Guide at the very beginning of the reset function in order to check cpu id and branch to the desired function for the secondary cores but it doesn't seem to work.

I also tried to put in the SRC registers some address to a C standalone program that I load in RAM but it doesn't work.

Can you give me further suggestions please?

0 Kudos