Adresses memoire du Raspberry
Modérateur : Francois
-
- Raspinaute
- Messages : 1587
- Enregistré le : dim. 10 mai 2015 18:44
- Localisation : Dans la campagne à côté d'Annecy
- Contact :
Re: Adresses memoire du Raspberry
"Bare métal" signifie de se passer de tout OS : il n'y a ni bootloader (*), ni routing de bas niveau.
J'avais joué un peu à ca dans ma jeunesse sur PC en me basant sur le bootloader de NetBSD. On ne peut pas faire plus instructif.
(*) je doute que ce soit possible d'aller aussi loin sur le rasberry car il me semble bien que le boot loader est proprio. Par contre, c'est évidement possible juste après, c'est a dire de remplacer le code tout au début d'un kernel.
J'avais joué un peu à ca dans ma jeunesse sur PC en me basant sur le bootloader de NetBSD. On ne peut pas faire plus instructif.
(*) je doute que ce soit possible d'aller aussi loin sur le rasberry car il me semble bien que le boot loader est proprio. Par contre, c'est évidement possible juste après, c'est a dire de remplacer le code tout au début d'un kernel.
- BananaPI : Gentoo, disque SATA de 2 To
- Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
- Multimedia par DNLA
- Et pleins d'idées ... et bien sûr, pas assez de temps.
-
- Raspinaute
- Messages : 735
- Enregistré le : lun. 22 déc. 2014 16:50
- Localisation : 67380 LINGOLSHEIM
Re: Adresses memoire du Raspberry
On peut faire beaucoup et, il y a peu de temps, j'avais signalé à François qui souligne régulièrement la parution d'un magazine, un article qui me semblait particulièrement passionnant.destroyedlolo a écrit : ...
(*) je doute que ce soit possible d'aller aussi loin sur le rasberry car il me semble bien que le boot loader est proprio. Par contre, c'est évidement possible juste après, c'est a dire de remplacer le code tout au début d'un kernel.
Faute de temps et certainement aussi de lecteurs potentiels, il n'a pas traité le sujet (ce que je comprends parfaitement). Comme le message ne comporte rien de personnel, je vous en donne une copie:
""
Le 5 avril 2017 à 01:16, Sylvain POURRE <spourre@gmail.com <mailto:spourre@gmail.com>> a écrit :
Bonsoir François,
Je voulais juste attirer ton attention sur un article du dernier
GNU/Linux Mag que j'ai acheté , un peu par hasard, mon épouse
m'ayant demandé de lui prendre un journal :
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.
Bien que non dédié strictement au Raspberry, ce numéro est assez
riche pour que chacun, quel que soit son niveau, trouve un ou
plusieurs articles à son goût.
Cordialement
"
Si l'exemple du "hello wordls" est classique, le second est plus bluffant car il n'agit ni plus ni moins que d'un raytracing utilisant le GPU. C'est donc la porte ouverte à des applications rapides qui peuvent afficher sur un moniteur HDMI.
Le seul bémol est que le débugg réseau fournit est limité et ne peut tracer les threads qui sont pourtant supportées par le logiciel qui constitue un environnement complet de cross distribution.
Des crosschains en bare metal sont aussi disponibles sous Linaro (ou générables pat CT-NG) mais cet ensemble forme un tout cohérent.
Sylvain
-
- Messages : 35
- Enregistré le : jeu. 19 oct. 2017 10:11
Re: Adresses memoire du Raspberry
Tout cela m'ouvre des possibilités phénoménales si on peut utiliser le rapsberry comme cela (ou peut être une abime sous mes pieds ...) car utiliser un programme sans OS ça veut dire reécrire un gestionnaire du clavier, un gestionnaire de l'écran etc.
Je vais continuer pour l'instant mon approfondissement de l'assembleur avec des appels à Linux et je verrais plus tard le développement sans OS.
Mais j'ai regardé les sujets de ce forum et je n'ai trouvé qu'un sujet sur les jeux en bare metal avec peu de rapport avec la programmation directe.
Merci en tous les cas de vos infos.
Je vais continuer pour l'instant mon approfondissement de l'assembleur avec des appels à Linux et je verrais plus tard le développement sans OS.
Mais j'ai regardé les sujets de ce forum et je n'ai trouvé qu'un sujet sur les jeux en bare metal avec peu de rapport avec la programmation directe.
Merci en tous les cas de vos infos.
-
- Raspinaute
- Messages : 735
- Enregistré le : lun. 22 déc. 2014 16:50
- Localisation : 67380 LINGOLSHEIM
Re: Adresses memoire du Raspberry
Vous avez certainement noté que la glibc est partie intégrante de cet environnement bare-metal. Cela ouvre tout de même de vastes horizons sur la gestion des IO (et même des threads).
Maintenant, il faut être logique. Comme je l'ai déjà souligné , un vrai système embarqué n'a pas forcement besoin d'une IHM compliquée avec écran HDMI, son, clavier et souris (parce que, bien souvent, l'humain ne sera pas devant).
Gérer un afficheur LCD et un clavier matricé de 16 touches ne demande pas des ressources débordantes et est trivial à programmer en C (et certainement en assembleur).
Manifestement, cette approche du Pi ne passionne pas les foules, du moins sur les forums FR. Si vous googolisez sur raspberry + bare-métal, en acceptant les réponses en anglais, vous aurez bien plus de résultats. Il y a même un wiki:
https://github.com/raspberrypi/firmware/wiki
Sylvain
Maintenant, il faut être logique. Comme je l'ai déjà souligné , un vrai système embarqué n'a pas forcement besoin d'une IHM compliquée avec écran HDMI, son, clavier et souris (parce que, bien souvent, l'humain ne sera pas devant).
Gérer un afficheur LCD et un clavier matricé de 16 touches ne demande pas des ressources débordantes et est trivial à programmer en C (et certainement en assembleur).
Manifestement, cette approche du Pi ne passionne pas les foules, du moins sur les forums FR. Si vous googolisez sur raspberry + bare-métal, en acceptant les réponses en anglais, vous aurez bien plus de résultats. Il y a même un wiki:
https://github.com/raspberrypi/firmware/wiki
Sylvain
-
- Raspinaute
- Messages : 1587
- Enregistré le : dim. 10 mai 2015 18:44
- Localisation : Dans la campagne à côté d'Annecy
- Contact :
Re: Adresses memoire du Raspberry
Ben sans aller jusque là, il n'y a qu'a voir le peu de personnes qui simplement utilisent les GPIOs par SysFS ou qui tripotent les modules kernel
De mon point de vue (qui n'engage que moi
), hormis pour apprendre, c'est bien de faire du Bare métal :
)
On ne s'en rend pas forcément compte du fait des langages obèses comme Java ou Python, sans compter la couche X, mais les *PI ont une telle puissance CPU et de telles ressources qu'on arrive a de très belles choses, y compris graphique en tapant dans les framebuffers, en restant sous Linux.
![Triste :(](./images/smilies/icon_e_sad.gif)
De mon point de vue (qui n'engage que moi
![Clin d’œil ;)](./images/smilies/icon_e_wink.gif)
- sur des machines où les ressources se comptes en koctets
- quand ... on fait un OS
- sur de l'embarqué.
![Sourire :)](./images/smilies/icon_e_smile.gif)
On ne s'en rend pas forcément compte du fait des langages obèses comme Java ou Python, sans compter la couche X, mais les *PI ont une telle puissance CPU et de telles ressources qu'on arrive a de très belles choses, y compris graphique en tapant dans les framebuffers, en restant sous Linux.
- BananaPI : Gentoo, disque SATA de 2 To
- Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
- Multimedia par DNLA
- Et pleins d'idées ... et bien sûr, pas assez de temps.
-
- Raspinaute
- Messages : 735
- Enregistré le : lun. 22 déc. 2014 16:50
- Localisation : 67380 LINGOLSHEIM
Re: Adresses memoire du Raspberry
Bonsoir,
Sans aller jusqu'au bare-metal, on n'est pas obligé de prendre une distribution 'usage général", obèse, peu optimisée par défaut, installant des kyrielles de logiciels peu utiles pour un usage "embeded" et basée sur le monstrueux systemd
Je viens, suite à une réponse à ma question sur la cross-compilation (sur debian-fr) de faire mon premier test de buildroot. C'est bluffant !
Reste à tester si le cross-compilateur généré saura compiler les lib(s) nécessaire carc'est un SDK, sans gestionnaire de packages.
En tout cas, le kernel est fonctionnel avec les paramèters par défaut pour le Raspberry, reste à creuser le reste, vaste programme comme aurait dit un personnage historique:
Sylvain
Sans aller jusqu'au bare-metal, on n'est pas obligé de prendre une distribution 'usage général", obèse, peu optimisée par défaut, installant des kyrielles de logiciels peu utiles pour un usage "embeded" et basée sur le monstrueux systemd
![Diable rieur :twisted:](./images/smilies/icon_twisted.gif)
Je viens, suite à une réponse à ma question sur la cross-compilation (sur debian-fr) de faire mon premier test de buildroot. C'est bluffant !
Reste à tester si le cross-compilateur généré saura compiler les lib(s) nécessaire carc'est un SDK, sans gestionnaire de packages.
En tout cas, le kernel est fonctionnel avec les paramèters par défaut pour le Raspberry, reste à creuser le reste, vaste programme comme aurait dit un personnage historique:
Code : Tout sélectionner
CPU: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq
Load average: 0.00 0.00 0.00 1/69 144
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
143 136 root R 1452 0% 0% top
144 2 root SW 0 0% 0% [kworker/0:0]
136 1 root S 1452 0% 0% -sh
1 0 root S 1448 0% 0% init
137 1 root S 1444 0% 0% /sbin/getty -L tty1 0 vt100
133 1 root S 1444 0% 0% udhcpc -R -n -p /var/run/udhcpc.eth0.p
84 1 root S 1440 0% 0% /sbin/syslogd -n
87 1 root S 1436 0% 0% /sbin/klogd -n
18 2 root SW 0 0% 0% [kworker/0:1]
65 2 root SW 0 0% 0% [kworker/0:2]
68 2 root SW 0 0% 0% [mmcqd/0]
3 2 root SW 0 0% 0% [ksoftirqd/0]
70 2 root SW 0 0% 0% [jbd2/mmcblk0p2-]
8 2 root SW 0 0% 0% [kdevtmpfs]
6 2 root SW 0 0% 0% [kworker/u2:0]
2 0 root SW 0 0% 0% [kthreadd]
12 2 root SW< 0 0% 0% [writeback]
5 2 root SW< 0 0% 0% [kworker/0:0H]
11 2 root SW 0 0% 0% [oom_reaper]
7 2 root SW< 0 0% 0% [lru-add-drain]
#
# uname -ar
Linux buildroot 4.9.36 #1 Mon Oct 30 20:04:04 CET 2017 armv6l GNU/Linux
#
-
- Raspinaute
- Messages : 1587
- Enregistré le : dim. 10 mai 2015 18:44
- Localisation : Dans la campagne à côté d'Annecy
- Contact :
Re: Adresses memoire du Raspberry
Salut,
Cependant, les *PI sont largement assez puissants pour faire compile locale, donc j'ai pris une autre voie : Distcc.
J'ai installé des cross compilo ARM sur mes différents PC, ce qui fait que seule la compilation elle-même est distribuée. Mais le "linkage", les options de compilations, tout ça reste local à chacune de mes machines.
Résultat, mon BananaPI compile un kernel ou PHP (bref, tout ce qui est bien gros) en quelques dizaines de minutes et non plusieurs heures comme j'ai pu le voir sur le net pour ceux qui s'acharne à le faire en locale.
J'ai du coup l'avantage de ne pas avoir a batailler avec les dépendances sur les configs vraiment différentes tout en ayant une durée de compilation largement suffisante.
**) l'exception est ma tablette qui n'avait pas suffisamment de RAM pour ça et une SD d'un Go. Mais ce n'était pas vraiment de la cross-compile , les CPU étant de la même famille, j'ai juste fait croire à ma Banane qu'il avait le CPU de la tablette (heureusement, la compatibilité ascendante est assurée sur les AllWinner) et j'ai compilé avec en local comme je le fais d'habitude en mettant la SD comme cible.
A+
J'ai abandonné l'idée depuis longtemps de tout faire en cross compile (à une exception pret **) car ayant une bonne dizaine de machines avec des config totalement différentes, ça posait des problèmes de dépendances de librairies et surtout, je perdais l'avantage que les binaires soient optimisés pour le CPU hôte.spourre a écrit :Je viens, suite à une réponse à ma question sur la cross-compilation (sur debian-fr) de faire mon premier test de buildroot. C'est bluffant !
Reste à tester si le cross-compilateur généré saura compiler les lib(s) nécessaire carc'est un SDK, sans gestionnaire de packages.
Cependant, les *PI sont largement assez puissants pour faire compile locale, donc j'ai pris une autre voie : Distcc.
J'ai installé des cross compilo ARM sur mes différents PC, ce qui fait que seule la compilation elle-même est distribuée. Mais le "linkage", les options de compilations, tout ça reste local à chacune de mes machines.
Résultat, mon BananaPI compile un kernel ou PHP (bref, tout ce qui est bien gros) en quelques dizaines de minutes et non plusieurs heures comme j'ai pu le voir sur le net pour ceux qui s'acharne à le faire en locale.
J'ai du coup l'avantage de ne pas avoir a batailler avec les dépendances sur les configs vraiment différentes tout en ayant une durée de compilation largement suffisante.
**) l'exception est ma tablette qui n'avait pas suffisamment de RAM pour ça et une SD d'un Go. Mais ce n'était pas vraiment de la cross-compile , les CPU étant de la même famille, j'ai juste fait croire à ma Banane qu'il avait le CPU de la tablette (heureusement, la compatibilité ascendante est assurée sur les AllWinner) et j'ai compilé avec en local comme je le fais d'habitude en mettant la SD comme cible.
A+
- BananaPI : Gentoo, disque SATA de 2 To
- Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
- Multimedia par DNLA
- Et pleins d'idées ... et bien sûr, pas assez de temps.
-
- Raspinaute
- Messages : 735
- Enregistré le : lun. 22 déc. 2014 16:50
- Localisation : 67380 LINGOLSHEIM
Re: Adresses memoire du Raspberry
Chaque approche a ses avantages et ses inconvénients.
Moi, je n'ai que 2 Raspberries 1B. Pas question de compiler du lourd là-dessus.
De plus, ces bécanes n'ont pas de port SATA, pas d'Ethernet 1Gbs, peu de RAM et un SOC poussif et une compil provoque de nombreuse écritures sur la carte SD
J'ai mentionné ce test de buildroot car cela me semble intéressant pour le PO. Il souhaite développer en assembleur sous Linux (encore une fois, son choix est respectable). Buildroot permet d'avoir un Linux bien plus léger que les distributions "généraliste" (polyvalent = bon à tout, propre à rien).
Comme de plus GCC permet de récupérer le code assembleur intermédiaire, il peut très bien cross-compiler et reprendre le code "à la main", pour essayer de faire mieux.
Sylvain
Moi, je n'ai que 2 Raspberries 1B. Pas question de compiler du lourd là-dessus.
De plus, ces bécanes n'ont pas de port SATA, pas d'Ethernet 1Gbs, peu de RAM et un SOC poussif et une compil provoque de nombreuse écritures sur la carte SD
![M. Vert :mrgreen:](./images/smilies/icon_mrgreen.gif)
J'ai mentionné ce test de buildroot car cela me semble intéressant pour le PO. Il souhaite développer en assembleur sous Linux (encore une fois, son choix est respectable). Buildroot permet d'avoir un Linux bien plus léger que les distributions "généraliste" (polyvalent = bon à tout, propre à rien).
Comme de plus GCC permet de récupérer le code assembleur intermédiaire, il peut très bien cross-compiler et reprendre le code "à la main", pour essayer de faire mieux.
Sylvain
Re: Adresses memoire du Raspberry
Merci à Vincent pour tout son travail et son partage.
Comment éviter les erreurs de segmentation dans les programmes en assembleur ARM?
Pi3 1Mb ram.
Comment éviter les erreurs de segmentation dans les programmes en assembleur ARM?
Pi3 1Mb ram.
-
- Messages : 35
- Enregistré le : jeu. 19 oct. 2017 10:11
Re: Adresses memoire du Raspberry
Les erreurs de segmentation sont en effet les plus fréquentes en programmation assembleur ARM.
Elles ont plusieurs sources :
1) Vous essayez d’accéder à une zone mémoire non autorisée : par exemple
ldr r0,[r1] avec le plus souvent r1=0 donc erreur !!
2) Vous essayez d’écrire dans une zone mémoire non autorisée :
Str r0,[r1] avec le plus souvent r1=0 donc erreur !!
3) Vous ne restaurez pas le même nombre de registres que vous avez sauvés dans une sous procédure., déphasage de la pile.
4) Lors du passage de paramètres par la pile à une sous procèdure, vous n’avez pas enlevé ces paramètres(ou pas le même nombre) à la sortie de la sous procèdure donc déphasage de la pile
5) Vous n’avez pas sauvegardé le registre lr à l entrée d’une sous procédure qui appelle elle-même une autre sous procèdure. Le registre lr ne contient plus la bonne valeur de retour à l’appelant principal (ceci peut aussi entrainer une boucle pas facile à trouver).
6) Vous avez manipulé l’adresse de la pile dans une sous procèdure (par exemple pour stocker une valeur interne) et vous ne l’avez pas remise à son état normal.
Il peut exister d’autres cas mais les plus fréquents sont les 1, 2 et 3.
Je n’ai pas de solution pour éviter ces erreurs sauf de faire attention lors de l’écriture et de mettre des traces lorsqu’une survient ( moi j’affiche le contenu de tous les registres pour trouver l’endroit et la cause de l’erreur).
Bon courage.
Elles ont plusieurs sources :
1) Vous essayez d’accéder à une zone mémoire non autorisée : par exemple
ldr r0,[r1] avec le plus souvent r1=0 donc erreur !!
2) Vous essayez d’écrire dans une zone mémoire non autorisée :
Str r0,[r1] avec le plus souvent r1=0 donc erreur !!
3) Vous ne restaurez pas le même nombre de registres que vous avez sauvés dans une sous procédure., déphasage de la pile.
4) Lors du passage de paramètres par la pile à une sous procèdure, vous n’avez pas enlevé ces paramètres(ou pas le même nombre) à la sortie de la sous procèdure donc déphasage de la pile
5) Vous n’avez pas sauvegardé le registre lr à l entrée d’une sous procédure qui appelle elle-même une autre sous procèdure. Le registre lr ne contient plus la bonne valeur de retour à l’appelant principal (ceci peut aussi entrainer une boucle pas facile à trouver).
6) Vous avez manipulé l’adresse de la pile dans une sous procèdure (par exemple pour stocker une valeur interne) et vous ne l’avez pas remise à son état normal.
Il peut exister d’autres cas mais les plus fréquents sont les 1, 2 et 3.
Je n’ai pas de solution pour éviter ces erreurs sauf de faire attention lors de l’écriture et de mettre des traces lorsqu’une survient ( moi j’affiche le contenu de tous les registres pour trouver l’endroit et la cause de l’erreur).
Bon courage.