How to start core 1,2,3 in Raspberry Pi 2

Question

I have written a bare metal multi core example.

Code, circuit diagram is here - https://github.com/jeffreyantony/multipi/tree/master/Example_01

In my example, there are 3 LED's connected to the GPIO pins of the raspberry Pi. There are totally 4 cores in Raspberry Pi 2. Each core is assigned to blink its corresponding LED.

I wrote the address of the code to be executed by each core in the below addresses 0x4000009C for core 1 0x400000AC for core 2 0x400000BC for core 3

After compiling the code, only the LED assigned to core 1 is blinking(as per this example, yellow LED). Others are not.

This means the code for Core 2 and 3 are not running(since the other LEDs are not blinking). Also I found that the code after starting all the cores is also not running i.e core0_submain() - this function should blink the ACT LED on the Raspberry Pi

Could anyone let me know what is the problem ? Is it because all the 4 cores tries to write to the same GPIO register and only Core 1 is winning in the write ?

I tried adding "attribute((naked));" for core0_submain() but there was no use.

I am using the toolchain from https://launchpad.net/gcc-arm-embedded

once again code - https://github.com/jeffreyantony/multipi/blob/master/Example_01/main.c

makefile - https://github.com/jeffreyantony/multipi/blob/master/Example_01/Makefile

Update 20 Oct 2015: I have added support for JTAG. But not successful to get debug interface
Update 25 Oct 2015: Issue is fixed. See answer.

Circuit diagram

Answer 1

Update 25 Oct 2015:

Raspberry Pi forum gave the answer to me.

1. There is not concept of _start when using -nostdlib

2. the code to be executed first should be the first file to be passed to the linker.

3. If better control is needed, the code needs to be placed in an init section and ask linker to copy this section to 0x8000

Thanks all for the support. Learned a lot about the GNU C Compiler.

Update 24 Oct 2015:

When I changed the order of files given for compilation in the Makefile, I got the correct ordering(i.e at 0x8000 we have the _start function) with -O2 optimization. But still my below stackoverflow question regarding the _start symbol is not yet solved. New code is checked in.

I have had some success. The new code is checked into github.

The example is not completely running. There are some issues with the compilation. I will explain each:

1. Actually I was expecting that the _start symbol from my custom start.S will be taken. But it was not the case. Because of this the stack pointer was not configured and the jump to main didn't happen.

I have already asked a question about this. But I haven't progressed much. So I added an inline assembly to load the stack pointer in the main function.

2. But still the code didn't run. When I checked the assembly listing, I found that at address 0x8000 (where the execution begins) of the Raspberry Pi is the code for Core 1 - void core1_main(void). My assumption was that at 0x8000 there would be the _start (which is not since the start.S file is not taken for compilation) or at least the void main(void) function. This happen because of the -O2 optimization of GCC. In GCC, with higher optimization levels, the functions are reordered.. When I switched off the optimization (-O0), then at address 0x8000, the main was present.

You can read about function reordering here

Summary: Current code is just a fix. Main issue to be solved - Why _start is not called from start.S ? If this is fixed, at address 0x8000 _start would come. With this we don't have to care about the function order done by GCC during higher optimization.

There is also a demo video from my side as a proof. Though the LED blinking rates are different and periodic in the code, since all the cores tries to write to the same GPIO registers, there are some conflicts which causes the LEDs to blink at random intervals.