So starten Sie Core 1,2,3 in Raspberry Pi 2

Ich habe ein Bare-Metal-Multi-Core-Beispiel geschrieben.

Code, Schaltplan finden Sie hier - https://github.com/jeffreyantony/multipi/tree/master/Example_01

In meinem Beispiel sind 3 LEDs an die GPIO-Pins des Himbeer-Pi angeschlossen. In Raspberry Pi 2 befinden sich insgesamt 4 Kerne. Jedem Kern ist die entsprechende LED zum Blinken zugeordnet.

Ich habe die Adresse des Codes, der von jedem Kern ausgeführt werden soll, in die folgenden Adressen 0x4000009C für Kern 1 0x400000AC für Kern 2 0x400000BC für Kern 3 geschrieben

Nach dem Kompilieren des Codes blinkt nur die dem Kern 1 zugewiesene LED (gemäß diesem Beispiel gelbe LED). Andere nicht.

Dies bedeutet, dass der Code für Core 2 und 3 nicht ausgeführt wird (da die anderen LEDs nicht blinken). Außerdem habe ich festgestellt, dass der Code nach dem Starten aller Kerne ebenfalls nicht ausgeführt wird, dh core0_submain () - diese Funktion sollte die ACT-LED am Raspberry Pi blinken lassen

Könnte mich jemand wissen lassen, wo das Problem liegt? Liegt es daran, dass alle 4 Kerne versuchen, in dasselbe GPIO-Register zu schreiben, und nur Core 1 beim Schreiben gewinnt?

Ich habe versucht, " attribute ((nackt))" hinzuzufügen. für core0_submain () gab es aber keine Verwendung.

Ich verwende die Toolchain von https://launchpad.net/gcc-arm-embedded

noch einmal 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. Oktober 2015 : Ich habe Unterstützung für JTAG hinzugefügt. Debug-Schnittstelle nicht erfolgreich erhalten
Update 25. Oktober 2015 : Problem behoben. Siehe Antwort.

Schaltplan

Update 25. Oktober 2015:

Das Raspberry Pi Forum gab mir die Antwort .

1. Bei Verwendung von -nostdlib gibt es kein Konzept für _start

2. Der zuerst auszuführende Code sollte die erste Datei sein, die an den Linker übergeben wird.

3. Wenn eine bessere Kontrolle erforderlich ist, muss der Code in einem Init-Abschnitt platziert und der Linker gebeten werden, diesen Abschnitt zu kopieren 0x8000

Vielen Dank für die Unterstützung. Viel über den GNU C Compiler gelernt.

Update 24. Oktober 2015:

Als ich die Reihenfolge der Dateien geändert habe, die für die Kompilierung im Makefile angegeben wurden, habe ich die richtige Reihenfolge (dh 0x8000wir haben die _startFunktion) mit -O2Optimierung erhalten. Meine unten stehende Frage zum Stapelüberlauf bezüglich des _startSymbols ist jedoch noch nicht gelöst. Neuer Code wird eingecheckt.

Ich habe einige Erfolge gehabt. Der neue Code wird in Github eingecheckt .

Das Beispiel wird nicht vollständig ausgeführt. Es gibt einige Probleme mit der Kompilierung. Ich werde jeden erklären:

1. Eigentlich hatte ich erwartet, dass das _startSymbol von meinem benutzerdefinierten Start genommen wird. Das war aber nicht der Fall. Aus diesem Grund wurde der Stapelzeiger nicht konfiguriert und der Sprung zur Hauptleitung fand nicht statt.

Ich habe bereits eine Frage dazu gestellt. Aber ich bin nicht viel vorangekommen. Also habe ich eine Inline-Assembly hinzugefügt, um den Stapelzeiger in die Hauptfunktion zu laden.

2. Trotzdem lief der Code nicht. Als ich die Baugruppenliste überprüfte, stellte ich fest, dass an der Adresse 0x8000(wo die Ausführung beginnt) des Raspberry Pi der Code für Core 1 - ist void core1_main(void). Meine Annahme war, dass 0x8000es dort die _start(was nicht seit der start.S-Datei nicht zur Kompilierung genommen wird) oder zumindest die void main (void) -Funktion geben würde. Dies geschieht aufgrund der -O2Optimierung von GCC. In GCC mit höheren Optimierungsstufen werden die Funktionen neu angeordnet. Als ich die Optimierung ( -O0) ausschaltete , war an der Adresse 0x8000die Hauptfunktion vorhanden.

Informationen zur Funktionsumordnung finden Sie hier

Zusammenfassung: Der aktuelle Code ist nur eine Korrektur. Hauptproblem, das gelöst werden muss - Warum wird _start nicht von Anfang an aufgerufen? Wenn dies behoben ist, würde an Adresse 0x8000 _startkommen. Damit müssen wir uns nicht um die Funktionsreihenfolge kümmern, die GCC während einer höheren Optimierung ausführt.

Als Beweis gibt es auch ein Demo-Video von meiner Seite. Obwohl die LED-Blinkraten im Code unterschiedlich und periodisch sind, gibt es einige Konflikte, die dazu führen, dass die LEDs in zufälligen Intervallen blinken, da alle Kerne versuchen, in dieselben GPIO-Register zu schreiben.