framboise314.fr

Bonjour.
Suivant vos suggestions de l'année dernière, j'ai commencé à développer en assembleur ARM sur le raspberry sans aucun OS (voir chapitre 40 et 41 de mon blog : https://assembleurarmpi.blogspot.com/). Suivant les exemples trouvés sur Internet, l'adresse de démarrage du premier module (souvent c'est _start) peut être 00000000 ou 0x8000. J'ai testé les deux et les deux fonctionnent. Mais je me demande à quoi correspond cette adresse 0x8000 car après le chargement de l'image kernel.img, rien n'est chargé dans la mémoire du Raspberry. Peut être c'est historique !! Quelqu'un a t'il une explication ?

Bon, a nouveau, je ne connais pas les spécificités des ARM et encore moins de la Framboise.
Cependant, vu que je doute que tu ais beaucoup de réponse ... je risque une hypothèse

Sur beaucoup de proc, les adresses basses contiennent les vecteurs des interruptions que ce soit matériel ou logiciel : peux etre (on notera l'énorme conditionnel) que le 0x8000 correspond justement à la fin de ses vecteurs et donc la 1er adresse vraiment dispo.
Peut-etre, peut-etre pas ...

Salut VincentLeboulou.

J'émets aussi une hypothèse.
L'adresse 0x0000 doit correspondre au noyau (premier module) et l'adresse 0x8000, peut-être à un second module, voire une application personnelle, que l'on désire exécuter au démarrage, après le noyau.

Dans votre cas, utilisez l'adresse 0x0000.

Très intéressant votre blog.

@+

Merci de vos réponses et de vos encouragements.
Et jusqu'a présent, je n'avais pas approfondi le sujet des interruptions sur les processeurs arm car le sujet me paraissait trop complexe.
Et donc j'ai regardé cela d'un peu plus prés et en effet j'ai vu qu'il fallait charger à l'adresse 000000 une table d'adresses de procédures pour gérer les différents types d'interruptions ce qui veut dire qu'il ne faut pas dans ce cas utiliser l'adresse 00000000 comme début d'exécution. Comme pour le développement baremétal, il faut tout gérer par soi même, je vais voir exactement ce qu'il faut faire. Mais cela semble coton !!! Et pas évident à tester !!!

Bonjour,

AMHA le N° 203 de Linux Mag devrait vous intéresser:
https://boutique.ed-diamond.com/en-kios ... e-203.html

Le titre de l'article de la page 48 est assez peu accrocheur au
premier abord:
IoT & Embarqué
p. 48 Programmation embarquée sur Raspberry Pi sans sonde JTAG

En fait, c'est un vrai bijou, à cent lieues des thèmes vus et
revus, ici ou ailleurs. C'est la première fois que je trouve un
article expliquant la cross-compilation (on en trouve un peu), le
cross-debug (déjà moins courant) et, cerise sur le gâteau, le
développement bare metal (c'est à dire sans OS).

Un premier exemple classique, le sempiternel "hello word " en C,
est suivi par un morceau de choix, un raytracer en frame buffer,
exploitant le GPU.

Évidemment, adieu aux libs (wiringPi, bcm ..) qui mâchent le
travail. Il faut tout se faire à la main, à travers la glibc. Par
contre, c'est la porte ouverte vers des programmes rapides, sans
la surcharge d'un OS obèse pas toujours nécessaire.

J'ai testé sans problème l'environnement et les 2 exemples. Essayez de trouver ce numéro dans votre entourage pour vous faire une idée avant de le commander.

--
Sylvain

Hum,

ca me met l'eau a la bouche.

Mais c'est centrée Raspberry ou SBC ARM en générale ? Car le boot du Rasberry est vraiment différent de tous les autres SBC ARM

A+

destroyedlolo a écrit : ↑

lun. 3 sept. 2018 15:06

...
Mais c'est centrée Raspberry ou SBC ARM en générale ? Car le boot du Rasberry est vraiment différent de tous les autres SBC ARM
....

De mémoire, c'était dédié au Raspberry mais je vais ressortir ce numéro pour te le confirmer.
A+

--
Sylvain

Merci de la référence à cette revue. Je vais essayer de la trouver pour voir cet article bien que j'ai progressé dans la programmation baremetal maintenant.
J'ai commencé à intégrer les interruptions dans un module pour tenter de faire clignoter la led activité à partir du timer du BCM2835 : cela parait simple mais quand ça marche pas c'est pas évident de trouver où est le problème !! Mais je vais y arriver.
Je confirme bien que les adresses du vecteur d'interruption sont à charger à l'adresse 00000000 et donc que nos programmes ne peuvent être chargés qu'après.

Bonsoir,

Désolé pour le retard mais il m'a fallu retrouver la revue et relire l'article
L'article ne parle que du pi.
L'adresse 0x8000 est l'adresse par défaut où le bootloader charge le fichier kernel.img. Cette adresse est modifiable par une directive dans le fichier config.txt.
Il s'agit d'une chaîne de cross compilation basée sur les outils GNU et la société farjump fournit un serveur GDB bootable sans OS sur le Raspberry.
Une fois le programme débuggé, il peut être transformé en fichier kernel.img. La libc utilisée (newlib) et l'initialisation (runtime) autorisent des appels "systèmes" limiés alors qu'il n'y a pas d'OS.

l'ensemble est disponible dans un dépôt GIT:
https://github.com/farjump/raspberry-pi.

Personnellement, comme toujours avec ce genre d'essai, j’ai testé dans une VM afin de ne pas polluer et compromettre la stabilité de ma tour (Debian).

--
Sylvain

Bonjour.
Excusez-moi pour cette réponse tardive, mais je n'avais pas regardé cette partie du forum depuis un moment. J'ai regardé le projet que vous indiquez et il me semble particulièrement intéressant surtout pour le gdb mais c'est du C et pour l'instant, je suis dans l'écriture des fonctions nécessaires en assembleur ARM. Dès que j' aurais un peu plus de temps libre, je testerai ce projet sur mon raspberry.
Merci à vous.