Comment démarrer le core 1,2,3 dans Raspberry Pi 2

J'ai écrit un exemple multicœur nu.

Le code, le schéma de circuit est ici - https://github.com/jeffreyantony/multipi/tree/master/Example_01

Dans mon exemple, il y a 3 LED connectées aux broches GPIO du raspberry Pi. Il y a totalement 4 cœurs dans Raspberry Pi 2. Chaque cœur est affecté à clignoter sa LED correspondante.

J'ai écrit l'adresse du code à exécuter par chaque cœur dans les adresses ci-dessous 0x4000009C pour le cœur 1 0x400000AC pour le cœur 2 0x400000BC pour le cœur 3

Après avoir compilé le code, seule la LED affectée au noyau 1 clignote (comme dans cet exemple, la LED jaune). D'autres non.

Cela signifie que le code pour Core 2 et 3 ne fonctionne pas (car les autres LED ne clignotent pas). J'ai également constaté que le code après le démarrage de tous les cœurs ne fonctionne pas, par exemple, core0_submain () - cette fonction devrait faire clignoter la LED ACT sur le Raspberry Pi

Quelqu'un pourrait-il me faire savoir quel est le problème? Est-ce parce que les 4 cœurs essaient d'écrire dans le même registre GPIO et que seul le cœur 1 gagne en écriture?

J'ai essayé d'ajouter " attribut ((nu));" pour core0_submain () mais il n'y avait aucune utilité.

J'utilise la chaîne d'outils de https://launchpad.net/gcc-arm-embedded

encore une fois le code - https://github.com/jeffreyantony/multipi/blob/master/Example_01/main.c

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

Mise à jour 20 octobre 2015 : j'ai ajouté la prise en charge de JTAG. Mais pas réussi à obtenir l'interface de débogage
Mise à jour 25 octobre 2015 : le problème est résolu. Voir la réponse.

Schéma

Mise à jour du 25 octobre 2015:

Le forum Raspberry Pi m'a donné la réponse .

1. Il n'y a pas de concept de _start lors de l'utilisation de -nostdlib

2. le code à exécuter en premier doit être le premier fichier à être transmis à l'éditeur de liens.

3. Si un meilleur contrôle est nécessaire, le code doit être placé dans une section init et demander à l'éditeur de liens de copier cette section dans 0x8000

Merci à tous pour le soutien. J'ai beaucoup appris sur le compilateur GNU C.

Mise à jour du 24 octobre 2015:

Lorsque j'ai changé l'ordre des fichiers donnés pour la compilation dans le Makefile, j'ai obtenu l'ordre correct (c'est-à-dire que 0x8000nous avons la _startfonction) avec -O2optimisation. Mais ma question de stackoverflow ci-dessous concernant le _startsymbole n'est toujours pas résolue. Le nouveau code est archivé.

J'ai eu un certain succès. Le nouveau code est archivé dans github .

L'exemple ne fonctionne pas complètement. Il y a quelques problèmes avec la compilation. Je vais vous expliquer chacun:

1. En fait, je m'attendais à ce que le _startsymbole de mon début personnalisé soit pris. Mais ce n'était pas le cas. Pour cette raison, le pointeur de pile n'a pas été configuré et le saut vers principal n'a pas eu lieu.

J'ai déjà posé une question à ce sujet. Mais je n'ai pas beaucoup progressé. J'ai donc ajouté un assemblage en ligne pour charger le pointeur de pile dans la fonction principale.

2. Mais le code ne fonctionnait toujours pas. Lorsque j'ai vérifié la liste des assembleurs, j'ai constaté qu'à l'adresse 0x8000(où l'exécution commence) du Raspberry Pi est le code du Core 1 - void core1_main(void). Mon hypothèse était qu'il 0x8000y aurait _start(ce qui n'est pas depuis le fichier start.S n'est pas pris pour la compilation) ou au moins la fonction void main (void). Cela se produit en raison de l' -O2optimisation de GCC. Dans GCC, avec des niveaux d'optimisation plus élevés, les fonctions sont réorganisées. Lorsque j'ai désactivé l'optimisation ( -O0), puis à l'adresse 0x8000, le principal était présent.

Vous pouvez lire sur la réorganisation des fonctions ici

Résumé: Le code actuel n'est qu'un correctif. Problème principal à résoudre - Pourquoi _start n'est pas appelé depuis start.S? Si cela est corrigé, l'adresse 0x8000 _startviendrait. Avec cela, nous n'avons pas à nous soucier de l'ordre des fonctions effectué par GCC lors d'une optimisation supérieure.

Il y a aussi une vidéo de démonstration de mon côté comme preuve. Bien que les taux de clignotement des LED soient différents et périodiques dans le code, puisque tous les cœurs essaient d'écrire dans les mêmes registres GPIO, il y a des conflits qui font clignoter les LED à intervalles aléatoires.