Come avviare il core 1,2,3 in Raspberry Pi 2

Ho scritto un esempio multi core bare metal.

Codice, schema elettrico è qui - https://github.com/jeffreyantony/multipi/tree/master/Example_01

Nel mio esempio, ci sono 3 LED collegati ai pin GPIO del raspberry Pi. Ci sono totalmente 4 core in Raspberry Pi 2. A ciascun core è assegnato di lampeggiare il LED corrispondente.

Ho scritto l'indirizzo del codice che deve essere eseguito da ciascun core negli indirizzi seguenti 0x4000009C per core 1 0x400000AC per core 2 0x400000BC per core 3

Dopo aver compilato il codice, lampeggia solo il LED assegnato al core 1 (come in questo esempio, LED giallo). Altri no.

Ciò significa che il codice per Core 2 e 3 non è in esecuzione (poiché gli altri LED non lampeggiano). Inoltre, ho scoperto che il codice dopo l'avvio di tutti i core non è in esecuzione, ovvero core0_submain () - questa funzione dovrebbe far lampeggiare il LED ACT sul Raspberry Pi

Qualcuno potrebbe farmi sapere qual è il problema? È perché tutti e 4 i core cercano di scrivere nello stesso registro GPIO e solo il Core 1 sta vincendo nella scrittura?

Ho provato ad aggiungere " attributo ((nudo));" per core0_submain () ma non è stato utile.

Sto usando la toolchain da https://launchpad.net/gcc-arm-embedded

ancora una volta codice - https://github.com/jeffreyantony/multipi/blob/master/Example_01/main.c

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

Aggiornamento 20 ottobre 2015 : ho aggiunto il supporto per JTAG. Ma non è riuscito a ottenere l'interfaccia di debug
Aggiornamento 25 ottobre 2015 : il problema è stato risolto. Vedi la risposta

Schema elettrico

Aggiornamento 25 ottobre 2015:

Il forum Raspberry Pi mi ha dato la risposta .

1. Non esiste il concetto di _start quando si utilizza -nostdlib

2. il codice da eseguire per primo dovrebbe essere il primo file da passare al linker.

3. Se è necessario un controllo migliore, il codice deve essere inserito in una sezione init e chiedere al linker di copiare questa sezione 0x8000

Grazie a tutti per il supporto. Ho imparato molto sul compilatore GNU C.

Aggiornamento 24 ottobre 2015:

Quando ho cambiato l'ordine dei file dati per la compilazione nel Makefile, ho ottenuto l'ordinamento corretto (cioè 0x8000abbiamo la _startfunzione) con l' -O2ottimizzazione. Ma la mia domanda sotto stackoverflow relativa al _startsimbolo non è ancora risolta. Il nuovo codice è registrato.

Ho avuto un certo successo. Il nuovo codice viene archiviato in github .

L'esempio non è completamente in esecuzione. Ci sono alcuni problemi con la compilazione. Spiegherò ciascuno:

1. In realtà mi aspettavo che il _startsimbolo dal mio inizio personalizzato.S fosse preso. Ma non è stato così. Per questo motivo il puntatore dello stack non è stato configurato e il salto al main non è avvenuto.

Ho già fatto una domanda al riguardo. Ma non ho progredito molto. Quindi ho aggiunto un assembly inline per caricare il puntatore dello stack nella funzione principale.

2. Ma il codice non è stato ancora eseguito. Quando ho controllato l'elenco dell'assemblaggio, ho scoperto che all'indirizzo 0x8000(dove inizia l'esecuzione) di Raspberry Pi è il codice per Core 1 - void core1_main(void). La mia ipotesi era che a quel punto 0x8000ci sarebbe stata la _start(che non è dall'inizio file S non è presa per la compilazione) o almeno la funzione void main (void). Ciò accade a causa -O2dell'ottimizzazione di GCC. In GCC, con livelli di ottimizzazione più elevati, le funzioni vengono riordinate. Quando ho disattivato l'ottimizzazione ( -O0), quindi all'indirizzo 0x8000, era presente il principale.

Puoi leggere il riordino delle funzioni qui

Riepilogo: il codice corrente è solo una correzione. Problema principale da risolvere - Perché _start non viene chiamato dall'inizio.S? Se questo è risolto, 0x8000 _startverrà l' indirizzo . Con questo non dobbiamo preoccuparci dell'ordine delle funzioni fatto da GCC durante una maggiore ottimizzazione.

C'è anche un video dimostrativo dalla mia parte come prova. Sebbene le frequenze di lampeggiamento dei LED siano diverse e periodiche nel codice, poiché tutti i core tentano di scrivere negli stessi registri GPIO, ci sono alcuni conflitti che causano il lampeggiamento dei LED a intervalli casuali.