40 lines
1.3 KiB
Plaintext
40 lines
1.3 KiB
Plaintext
|
|
See the top level README file for more information on documentation
|
|
and how to run these programs.
|
|
|
|
Derived from uart05
|
|
|
|
This is specific to the Raspberry Pi 2 as it experiments with the
|
|
multiple processor cores.
|
|
|
|
So the little additional information we have from Broadcom about
|
|
the raspberry pi 2 processor, shows some mailbox addresses, a set for
|
|
each core. Thanks a lot to the folks at the bare metal forum for
|
|
educating me on this. Currently it appears the other cores are sitting
|
|
in the loop between 0xCC and 0xD4, waiting for the value in a mailbox
|
|
to change from zero.
|
|
|
|
c0: e3a03000 mov r3, #0
|
|
c4: e7853200 str r3, [r5, r0, lsl #4]
|
|
c8: e2855040 add r5, r5, #64 ; 0x40
|
|
cc: e7954200 ldr r4, [r5, r0, lsl #4]
|
|
d0: e1540003 cmp r4, r3
|
|
d4: 0afffffc beq 0xcc
|
|
|
|
So we have to be careful not to trash the beginning of ram so long
|
|
as the other three cores are using it.
|
|
|
|
So if you write to address
|
|
|
|
0x4000009C for core 1
|
|
0x400000AC for core 2
|
|
0x400000BC for core 3
|
|
|
|
With the address to the entry point for the code you want that core
|
|
to run...it will start that core.
|
|
|
|
This example starts up the other three cores, lets them fight over the
|
|
memory location at address 0x40. Core 0 reads 0x40 and prints out
|
|
when it sees it change. It is going to look somewhat random.
|
|
|