Adresses memoire du Raspberry

On peut difficilement être plus proche du cœur du CPU qu'avec l'assembleur...

Modérateur : Francois

destroyedlolo
Raspinaute
Messages : 1583
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

Re: Adresses memoire du Raspberry

Message par destroyedlolo » sam. 28 oct. 2017 17:22

"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.
  • 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.
Un descriptif de ma domotique 100% fait maison.

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: Adresses memoire du Raspberry

Message par spourre » sam. 28 oct. 2017 19:25

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.
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.
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

VincentLeboulou
Messages : 35
Enregistré le : jeu. 19 oct. 2017 10:11

Re: Adresses memoire du Raspberry

Message par VincentLeboulou » lun. 30 oct. 2017 14:36

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.

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: Adresses memoire du Raspberry

Message par spourre » lun. 30 oct. 2017 17:15

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

destroyedlolo
Raspinaute
Messages : 1583
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

Re: Adresses memoire du Raspberry

Message par destroyedlolo » lun. 30 oct. 2017 18:15

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 :
  • sur des machines où les ressources se comptes en koctets
  • quand ... on fait un OS
  • sur de l'embarqué.
Et sur ce dernier point, je dois avouer qu'en ce moment, je prend mon pied comme pas possible avec des ESP8266. On n'est pas encore au niveau du Bare Metal car l'IDE arduino ou le SDK ont déjà bien taillé dans le gras, mais ca se rapproche des bidouilles que je faisais ados (souvenirs, souvenirs :) )

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.
Un descriptif de ma domotique 100% fait maison.

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: Adresses memoire du Raspberry

Message par spourre » mar. 31 oct. 2017 18:07

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 :twisted:

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
# 
Sylvain

destroyedlolo
Raspinaute
Messages : 1583
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

Re: Adresses memoire du Raspberry

Message par destroyedlolo » mar. 31 oct. 2017 18:40

Salut,
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.
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.
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.
Un descriptif de ma domotique 100% fait maison.

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: Adresses memoire du Raspberry

Message par spourre » mar. 31 oct. 2017 23:33

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 :mrgreen:

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

jps17
Messages : 1
Enregistré le : jeu. 29 nov. 2018 05:58

Re: Adresses memoire du Raspberry

Message par jps17 » lun. 3 déc. 2018 04:44

Merci à Vincent pour tout son travail et son partage.

Comment éviter les erreurs de segmentation dans les programmes en assembleur ARM?
Pi3 1Mb ram.

VincentLeboulou
Messages : 35
Enregistré le : jeu. 19 oct. 2017 10:11

Re: Adresses memoire du Raspberry

Message par VincentLeboulou » mar. 18 déc. 2018 21:54

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.

Répondre

Retourner vers « Assembleur »