Bonjour à tous,
Alors je me permets de venir sur ce forum car je suis a la recherche d'information sur les systèmes embarqués d'un point de vue "reverse" a titre d'apprentissage. Je m’intéresse au monde du libre depuis quelques années et maintenant j'aimerai approfondir mes connaissances en reverse.
Je cherche a faire fonctionner un "ancien" système (fonctionnant sur ARM) pour l'adapter sur RPI, par exemple mais ce n'est pas important pour le moment.
J'ai en ma possession
- U-boot.bin
- uImage (+vmlinux, +zImage, +system.map) > type little endians
- le système de fichier complet (qui était au format jffs2.img que j'ai extrait)
J'aimerai comprendre comment travailler les fichiers u-boot.bin, uImage afin de comprendre leurs fonctionnement et donc par conséquence, comprendre comment s'amorce ce système embarqué et l'adapter sur une autre plateforme ARM
Je ne sais pas trop comment continué, j'ai déjà commencé a analyser a l'aide de binwalk par exemple mais je ne sais pas qu'elles informations j'ai besoin pour comprendre, analyser ces fichiers
je fais un peu mes premiers pas à ce niveau là d'un système, je travail dans le développement en système embarqué (mais pas à ce niveau)
je sais que RPI ne fonctionne pas sur ce principe (u-boot) donc pour le moment le but est de comprendre comment est fait le noyaux, ce qu'il fait. Cela me permettrai d'adapter un nouveau noyaux par exemple en fin de phase
Pour le moment, quelles sont les informations nécessaires pour débuter ?
Si vous avez le temps de me conseiller :)
Merci d'avance et bonne journée
Cordialement,
Kriss
# POR->Boot process->Running
Posté par TheBreton . Évalué à 5. Dernière modification le 27 mars 2018 à 19:00.
Ton CPU reset, en général suivant l'état de certaines pins il exécute (grace à une rom interne) un chargement de binaire dans un format spécifique (contenant un en-tête indiquant l'adresse mémoire destination et la longueur du flux binaire au minimum). Les pins indique que le flux binaire est lu sur une flash spi, carte sd, usb ou encore uart.
Ce flux binaire est ton fichier u-boot.bin (et par exemple doit être en offset 0 de la carte SD ).
Ce U-Boot procèdes à l’initialisation d'unes partie des périphériques de ton micro (définitions des horloges de la DRAM par exemple) et en général à l'initialisation d'un uart pour avoir des traces, voir une interaction (mini terminal).
Il permet aussi des de pouvoir "mounter" un fs présent sur une emmc ou sdcard pour charger une image bootable d'un kernel linux et lui passer des paramètres (comme en ligne de commande) c'est ton fichier uImage (qui peut tout aussi bien avoir été stocké dans une flash spi, je dis juste "mounter" dans un sens très large du terme)
A tout système linux qui boot il faut un système de fichier pour lire/stocker les applications plus lourde,les lib systèmes etc… c'est le reste de ton jffs2.img
En bref,
La rom de ton cpu permet de charger et lancer u-boot
U-Boot demarre le minimum de chose pour charger (en mémoire ou execute in place)/démarrer le kernel linux
Le kernel initialise le reste et rend les services nécessaire aux applications
Nota : U boot est spécifique à chaque micro (car lié aux périphérique présent, controleur dram uart etc) il n'est pas transposable facilement du RPI à autre chose sans bien être sur que le micro cible n'est pas celui du RPI.
# J'ai envie de dire ... tu t'en fous
Posté par Mali (site web personnel) . Évalué à 2.
Que cherches-tu à faire concrètement ?
Remplacer to ancien système par un rpi ?
Quel service rendait cet ancien système ?
Faire booter un kernel opérationnel sur un rpi n'est pas vraiment le problème à mon avis, je me concentrerais d'abord sur l'analyse du user space, voir ce qui est lancé dans l'init, etc …
# Un lien sur ARM et reverse
Posté par palm123 (site web personnel) . Évalué à 1.
https://azeria-labs.com/
ウィズコロナ
# Insertion rootfs dans rom
Posté par Arvil . Évalué à 1.
Pourquoi veux-tu conserver ton ancien système ? Il y a peut être une alternative…
Cela dit U-Boot et le kernel devront probablement être recompilés spécifiquement pour la RPi. Comme la Raspberry Pi dispose de son propre bootloader intégré, seul le kernel sera réellement nécessaire.
Selon l'ancienneté et les particularités du vieux système il te faudra soit simplement trouver ou compiler un nouveau noyau (quitte à récupérer les sources de la même version du kernel compatible avec la RPi) ou faire d'autres adaptations.
Si j'étais toi je commencerais par essayer d'insérer mon rootfs dans une rom existante, probablement construite avec buildroot pour avoir quelque chose de relativement simple, puis à modifier les paramètres de boot et les fichiers de /etc si besoin est.
# réponse aux questions
Posté par krissZero . Évalué à 1.
Bonjour et merci à tous d'avoir pris le temps de me répondre.
Je vais essayé de répondre à tous le monde:
@TheBreton
Merci pour ces explications, c'est l'idée générale que j'avais, que vous me confirmez.
La carte ayant cramée, il n'est plus possible de récupérer le contenu de la ROM.
L'idée n'est donc pas de réinventer l'eau chaude.
Ayant en ma disposition u-boot, uImage (zImage + vmlinux), j'aimerai, à l'aide de ces fichiers, comprendre ce qu'il se passe pendant le boot, cad ce qu'ils font exactement, ce qu'ils chargent. Pour pouvoir après modifier un kernel déjà existant (RPI par exemple, simplement celle que j'ai dans mon tiroir) et de "merger/adapter" certaines fonctions spécifiques qui seraient chargé en bas niveau.
Donc je ne cherche pas a adapter u-boot et uImage sur RPI (qui fonctionnent spécifiquement sur la carte HS) a un autre système (ARM de même type); mais a l'aide de ces fichiers, comprendre ce qu'ils se passe et créer une alternative. + de précision dans la suite :
@Mali et @Arvil
Oui en réalité on s'en fou, plus ou moins, j'aime juste comprendre ce qu'il ce passe, comprendre les choses, la curiosité en fait.
Pour répondre à tes questions :
-J'ai en ma possession l'ensemble des fichier système rootFS et certaines parties des fichier du noyau, je cherche donc a analyser ce qu'il se passait en bas niveau qui permettait de rendre fonctionnel le système : ce que chargeait le noyau par exemple, ce qui etait spécifique a ce materiel pour merger/adapter
ces modif a un autre noyau prévu pour une architecture cible (ex RPI)
-L'ancien système fonctionnait avec une carte capteur : qui transmettait par bus SPI des données au cpu qui les traitait en temps réel. (Interface graphique couleur, un petit clavier avec quelques bouton pour se déplacer)
La carte capteur est intacte, je cherche donc a refaire fonctionner cette carte. Pourquoi sur l'ancien système ? car tout est déjà créer, interface, analyse, menu, fonction spécifique de mesure etc.
-Effectivement, l'analyse du système de fichier est ce que je fais depuis quelques jours pour comprendre ce qui boot en premier etc… mais je manque d'experience. Donc je cherche sans trop savoir ce que je cherche. J'analyse les dossier /bin et /sbin et le dossier /boot
De manière générale, le point d'entrée est situé sur le raccourci "init" ? Cad uImage vient tapé dans Init ?
Pour rejoindre ce que dit Arvil, au final, si je charge le kernel du RPI, standard, (qui englobe plus de fonctionnalités que nécessaire pour mon ancien système donc), cela peut il fonctionner avec mon ancien rootFS ? En mode dégrader probablement? Ce qui m'évite de "decompiler" le l'ancien noyau… (j'allais essayé dans la semaine
Est il possible, d'émuler un noyau et d'avoir une trace log de ce qu'il fait ? par exemple dans un dossier ou une partition y collé le uboot et uimage et emuler le machin pour voir ce que fait uimage (je regarde du coté de qemu pour ceci, sans succés)
J'espère avoir été assez clair,sinon n'hésitez pas à me le dire.
Grosso modo, c'est plus un defi pour moi qu'autre chose car je pourrai faire plus simple probablement effectivement. Mais j'aimerai comprendre le bas niveau de l'ancien système
L'ancien système était logiciellement parlant stable et terminé, donc pour moi l’intérêt est de la garder et de lui donner une 2nd vie sur RPI (par exemple)
Les deux systèmes sont basé sur ARM ARM1136JF-S v6 pour l'ancien et ARM1176JZF-S (ARMv6) pour la PI version A, d'ou mon intêret pour celle ci
Merci et bonne journée
Cordialement
[^] # Re: réponse aux questions
Posté par freem . Évalué à 2.
Je ne suis pas sûr pour les architectures ARM, mais à priori ça doit être la même chose.
Voici, (à peu près, j'essaie d'être générique, et vu mon niveau c'est évident que malgré mes efforts il y a des choses erronées dans ce laïus), ce qui se passe à partir de la mise sous tension d'un système:
PS: il y a un bouton répondre en dessous des commentaires, afin de répondre à une personne cible, ça rend les échanges plus faciles, et cerise sur le gateau, ça évite de réecrire un titre ;)
J'imagine qu'il faudrait voir pour améliorer la visibilité d'ailleurs, ça arrive régulièrement qu'un nouveau ne le remarque pas.
[^] # Re: réponse aux questions
Posté par Renault (site web personnel) . Évalué à 3.
Tu peux lire le code source du noyau ou de u-boot (et éventuellement leur doc ou des livres à ce sujet), ce sera plus digeste que d'essayer de décompiler pour comprendre.
De plus, le vendeur de ta carte doit te mettre à disposition les correctifs qu'ils ont apporté à U-boot et au noyau pour le rendre utilisable sur la carte. Donc tu pourrais voir ce qui est réellement liée à la plateforme que tu utilises.
Oui, cela peut être changé au démarrage en envoyant un paramètre au noyau pour lui demander de lire un autre logiciel par défaut. Mais en général c'est le programme "init".
Dans le noyau 4.7 tu peux le voir par exemple ce qu'il cherche par défaut : https://elixir.bootlin.com/linux/v4.7/source/init/main.c#L969
Ça peut fonctionner, oui.
Globalement le seul risque est que le logiciel que tu cherches à utiliser dépende trop du matériel, et donc éventuellement de certains pilotes qui n'existent plus ou qui ont changé.
Si c'est le cas, le noyau plus récent et différent du RPi peut le rendre peu fonctionnel. Sinon pas de raisons particulières que cela ne fonctionne pas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.