Sommaire
- 1) Le BIOS, mais késako
- 2) Des alternatives au BIOS/UEFI
- 3) L'absence de firmware, ça donne quoi
- 4) Et une exception dans le chaos ?
- 5) Le bad
- 6) Le ugly
- 7) The conclusion
Oui bon ça va hein, la traduction française elle passe pas pour le titre.
Bonjour !
Aujourd'hui, comme évoqué dans des discussions précédentes (et c'est mon deuxième journal avec plusieurs mois de retard), je voudrais vous parler de petitboot, mon bootloader préféré, en me focalisant sur la seule implémentation à laquelle j'ai accès aujourd'hui, avec ses problèmes mineurs et ses problèmes… pas majeurs, mais disons franchement ridicules.
On va donc parler de firmware dans le style du BIOS ou de l'UEFI. Mais avant de pouvoir faire ça, un petit rappel des faits est requis.
1) Le BIOS, mais késako
Le BIOS est une invention un peu spéciale de l'IBM PC. Lors de la conception du PC, IBM voulait utiliser du matériel disponible «sur l'étagère» : les premiers PCs étaient un assemblage de composants existants. Problème pour IBM : comment empêcher la création de clones du PC ?
La solution : le BIOS. Un composant logiciel intégré sur la carte mère, dont dépendra l'ensemble de la pile logicielle du PC (MS-DOS et ses applications, pour simplifier), et qu'IBM ne diffusera pas aux concurrents. Simple et efficace, non ? Et puis tant qu'à faire, autant y embarquer un interpréteur BASIC pour que la machine serve à quelque chose même sans disquette de système…
Le BIOS avait donc à la fois le rôle de bootloader (qui a évolué avec le temps, l'apparition des disques durs, du réseau, des CD-ROM…) et un rôle d'abstraction par dessus le matériel. Par exemple : pas besoin de pilotes pour utiliser un clavier USB sous DOS avec une application de 1980… Comment est-ce possible ? Grâce au BIOS, qui expose une API basique pour interagir avec le clavier, et fait abstraction du contrôleur clavier. De même pour l'accès à un disque dur PATA vs SATA…
Bien sûr, IBM n'avait pas anticipé la créativité et les compétences des ingénieurs de Compaq et Phoenix et la création de BIOS compatibles ne dépendant pas d'IBM. (Et leur tentative de rattraper la chose avec le PS/2 et son MCA n'a heureusement pas réussi)
Les systèmes d'exploitation «modernes» n'ont pas une telle dépendance au BIOS. Ils ont des pilotes pour gérer eux-même l'USB, le stockage… avec des bien meilleures performances. Mais pour cela, ils doivent être capables de découvrir le matériel. Et c'est là qu'intervient un rôle ajouté au BIOS, ou plutôt en parallèle du BIOS : la description du matériel, avec en particulier la norme ACPI. (Je sais c'est simplifié, il y a eu aussi l'ISAPnP, le concept de PnP intégré à PCI et à l'USB… mais c'est pas le but de ce journal).
Donc en résumé : deux rôles pour le firmware, bootloader et description du matériel. Notez bien cela, nous y reviendrons.
2) Des alternatives au BIOS/UEFI
Alors il faut bien reconnaître, ça ne court pas les cartes mères.
Il fut un temps où l'alternative la plus répandue était OpenFirmware, utilisé sur les machines SPARC, POWER, certains ARM… Pendant quelques années c'était même un standard IEEE, mais il est «rétracté» depuis. Lors de la mise en place de l'UEFI sur les PCs, des débats avaient eu lieu vantant cette solution, mais les chevaliers du NIH ne l'ont pas entendu de cette oreille.
Avec la fin d'OpenFirmware, une autre solution était nécessaire sur les machines OpenPower, et cette solution a été appelée OPAL, OpenPower Abstraction Layer. Avec OPAL, le boot est assez simple (après x étapes trop bas niveau pour ce journal) : il y a deux parties, skiboot avec un ensemble de services de runtime utilisables par l'OS, et skiroot le bootloader, composé d'un noyau Linux et d'un initramfs contenant Petitboot. Petitboot suit une idée simple elle aussi, similaire à l'idée de LinuxBIOS : puisque le firmware doit gérer le matériel, des systèmes de fichiers, du réseau… autant prendre un noyau complet, un système allégé, et utiliser ce dernier pour aller chercher un noyau, le mettre en mémoire comme il faut et faire un goto, avec l'appel système kexec().
Évidemment, il y a aussi les alternatives libres pour PC, mais avec les processeurs et chipsets modernes le travail est devenu assez difficile, surtout si l'on veut quelque chose d'entièrement libre. On peut donc citer les coreboot (ex-LinuxBIOS, qui reprenait déjà en 2001 l'idée de mettre un noyau Linux dans le firmware), Libreboot (version sans blob de coreboot), LinuxBoot (dérivé de NERF, qui élimine toute une partie de l'EFI pour la remplacer par un noyau Linux)…
3) L'absence de firmware, ça donne quoi
Nous avons parlé du firmware, maintenant parlons de l'anti-firmware, avec le désastre des cartes ARM.
On va prendre une distribution spécialisée ARM pour illustrer le problème, Armbian. Direction armbian.com, section téléchargement. Et il faut choisir la carte que l'on a, et on télécharge une image spécialisée pour cette carte.
J'insiste. Une image spécialisée. Parce qu'il faut avoir dans cette image le bootloader compatible avec la carte, les fichiers DTB (Device Tree Blob) décrivant la carte… C'est une calamité. Et ça, c'est pour les fabricants qui jouent le jeu, parce que si vous tombez sur une machine avec un SoC mediatek, vous avez un noyau d'il y a X années patché dégueulassement et démerdez-vous…
Microsoft, en proposant Windows pour ARM64, refuse cette situation (normal, ils ne veulent pas qu'on touche à leur noyau) et exige la présence d'un UEFI pour Windows, permettant donc la mise en place d'une image unique pour l'ensemble des cartes ARM compatibles.
J'ai suffisamment soupé d'UEFI et de ses bugs pour ne pas en vouloir plus sur mes machines, mais il faut bien reconnaître que l'absence de firmware n'est pas une solution acceptable (surtout quand on pense aux autres OS qui auraient un travail colossal à faire pour supporter l'armée de cartes ARM sur le marché). D'autant plus quand on rencontre des bugs avec le bootloader et qu'on se retrouve sans solution pour comprendre ce qu'il se passe… (non, le port série n'est pas une solution, ça fait disparaitre le bug dans mon cas, tristesse)
Pour les plus curieux, je vous invite à regarder à quoi ressemble un fichier DeviceTree. Je vais prendre en exemple une de mes machines ARM64, à base de puce Amlogic S905X3. Cette machine a heureusement un DTS (Device Tree Source) dans le noyau, donc elle est officiellement supportée «upstream» comme on dit.
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-sm1-odroid-hc4.dts
On observe une description de l'ensemble des composants, le ventilateur, les leds, les régulateurs de tension, les différents bus… Parce que la machine ne dispose d'aucune solution d'énumération du matériel. Et bien sûr, impossible d'aller au hasard sur les GPIO du SoC pour voir ce qui est branché où, c'est un coup à, au mieux, éteindre la machine soudainement (et au pire, à la détruire). Que ce soit clair : ce fichier DTS n'est pas spécifique à un SoC, il est spécifique à une implémentation d'un SoC ! Les odroid C4 et HC4, bien qu'extrêmement proches et avec le même SoC, n'ont pas le même DeviceTree, et il est probable que booter l'un avec le DT de l'autre ne marche pas du tout.
4) Et une exception dans le chaos ?
Au moins un fabricant de cartes ARM a compris qu'embarquer un firmware sur ses cartes était une solution simple pour améliorer beaucoup de choses. Ou alors pour simplifier son travail, je ne sais pas trop leur motivation. Il s'agit de hardkernel et de ses cartes odroid. L'intégration par défaut de petitboot est «relativement» récente, avec une annonce initiale en 2019 et une préinstallation qui a commencé dans les mois qui ont suivi.
Du coup, commençons enfin le sujet de ce journal, avec le bon.
Prenons mon serveur installé avec petitboot, et faisons un fdisk -l.
# fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 980 1TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 16384 bytes / 131072 bytes
Disklabel type: dos
Disk identifier: 0xc7716abe
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 * 2048 999423 997376 487M 83 Linux
/dev/nvme0n1p2 999424 1953523711 1952524288 931G 8e Linux LVM
Pas de partition FAT32. Une simple partition ext4 contenant /boot, et c'est réglé. Contrairement aux systèmes UEFI qui imposent une partition ESP à un format compris par l'UEFI, donc dans 99,9999% des cas en FAT.
J'eus pu faire avec une unique partition / et pas un /boot, mais je préfère mettre tout ce qui peut l'être en LVM.
Bien sûr, ce n'est pas grand chose, la partition FAT n'a jamais tué personne. Alors continuons avec un exemple très concrêt de ce que m'apporte Petitboot ici. Pour installer ma debian, je n'ai pas eu besoin de clé USB ou de carte SD à écrire sur mon PC. Non. J'ai pris ma carte ARM, j'ai vissé un disque NVMe, branché un écran, un clavier, un RJ45, et c'est tout (bon et l'alimentation hein, c'est pas de la magie).
Petitboot est apparu à l'écran. Je ferme l'écran de boot pour obtenir un shell, et je lance une commande fournie par hardkernel, netboot_default. Cette commande ajoute automatiquement des entrées au boot pour aller chercher l'installeur debian et l'installeur ubuntu en HTTP au démarrage. Je démarre l'installeur debian comme ça, j'installe mon système… et aucune clé USB ou carte SD à écrire. Très, très, très confortable.
Bien sûr, petitboot lui-même est super pratique : si vous cassez votre système, vous avez un shell, un noyau et un espace utilisateur connus, à partir desquels vous pouvez monter votre système et faire les réparations dont vous avez besoin.
Quelques photos du menu initial, du shell, et le menu une fois les entrées de netboot chargées et une carte SD insérée…
5) Le bad
Hardkernel ne fournit pas de méthode ou de documentation pour reproduire l'image Petitboot. C'est plusieurs fois dommage : cela ne permet pas de bidouiller facilement le système, de vérifier son contenu… Et c'est même en violation des licences des composants de Petitboot, ça risque de leur retomber méchamment dessus.
Pour ma part, ce point m'embête également pour régler un autre problème qui me semble vraiment "bad" pour le coup : pourquoi des utilitaires disque à mes yeux basiques ne sont pas inclus ? Cela fait presque 20 ans que j'installe mes machines avec du LVM, je sais que les installeurs ne mettent pas ça assez en avant, mais le gain en vaut largement la peine. Et petitboot le gère, mais la version de hardkernel oublie d'embarquer le binaire…
À la croisée entre ces deux problèmes, la validation du système et les disques : cryptsetup n'est pas pris en charge. Et c'est dommage, il serait possible d'avoir un disque intégralement chiffré, avec une passphrase demandée au boot, et transmise au noyau démarré pour qu'elle n'ait pas à être saisie deux fois.
Enfin, un dernier bad : dropbear n'est pas présent. Pour des machines sans affichage, cela simplifierait énormément les choses… Mais à nouveau, oubli bien dommage de leur part.
6) Le ugly
Vous noterez que je n'ai parlé que d'une des facettes principales du firmware (le bootloader) et un peu survolé la partie «outils pour diagnostiquer un problème».
Les plus attentifs d'entre vous auront noté que je n'ai pas parlé de la description du matériel et sa transmission au système démarré.
Et là, on entre dans le franchement ugly.
# ls /boot/*`uname -r`
/boot/config-6.2.0-odroid-arm64 /boot/dtb-6.2.0-odroid-arm64 /boot/initrd.img-6.2.0-odroid-arm64 /boot/System.map-6.2.0-odroid-arm64 /boot/vmlinuz-6.2.0-odroid-arm64
J'ai besoin d'un fichier dtb encore ? Mais pourquoi ! Pourquoi pourquoi pourquoi !
Rendez-vous compte, le firmware a déjà un DeviceTree ou équivalent pour booter son Linux. Et il fonctionne très bien. Alors pourquoi ? Vous étiez à deux doigts de pouvoir avoir des systèmes génériques, pire encore, à quatre doigts d'avoir une interface de configuration pour vos accessoires qui activerait au boot les bons morceaux de dtb… Et vous avez gâché cette opportunité. Et comme vous ne donnez pas le code source, impossible de rattraper votre bêtise crasse.
7) The conclusion
Je reste heureux de mes machines Petitboot, et il est hors de question que je retourne en arrière là dessus. Le gain en confort est indéniable, malgré les problèmes évoqués. De plus, ces problèmes ne sont pas insurmontables, et sont des problèmes d'implémentation, pas des problèmes fondamentaux sur le fonctionnement de Petitboot. Puis qui sait, avec un peu de chance, la future machine OpenPower 10 de Raptor Computing ne sera pas trop onéreuse… (ok, beaucoup beaucoup beaucoup beaucoup de chance)
J'entends par contre que cette solution ne soit pas optimale pour les plus petits OS qui n'ont pas nécessairement les moyens de développer une solution de boot supplémentaire spécifique, démarrable en kexec(). On pourrait imaginer pour ces cas là un kexec() vers un environnement UEFI éventuellement… (ou juste contribuer aux projets concernés, promis quand j'aurai du temps, mais pour le moment je rédige un journal linuxfr)
# U-boot
Posté par Psychofox (Mastodon) . Évalué à -1.
https://source.denx.de/u-boot/u-boot
[^] # Re: U-boot
Posté par Pinaraf . Évalué à 5.
Heu, oui ?
U-Boot est un bootloader concurrent de petitboot ou grub, avec le même problème que grub à savoir devoir dupliquer les implémentations de FS, je ne vois pas trop ce que veut dire ton commentaire du coup. À noter que Hardkernel l'utilise pour démarrer le Linux qui s'occupe de Petitboot.
[^] # Re: U-boot
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 21 novembre 2023 à 10:45.
Ça ne me parait pas clair dans ton journal l'intérêt d'avoir petitboot si tu peux avoir u-boot.
Et bon si U-boot est utilisé pour booter Petitboot, le critère de ne pas dupliquer les implémentations de FS part un peu à la trappe parce que tu le fais de toute manière.
[^] # Re: U-boot
Posté par Pinaraf . Évalué à 2.
Pas compris. U-boot ne fait que lire un cramfs, pas un FS linux complet.
[^] # Re: U-boot
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 21 novembre 2023 à 10:53.
J'ajoute que si sur les pc on se coltine grub en plus de UEFI, c'est pour garder un fonctionnement homogène avec les vieilles machines bootant depuis un bios et n'ayant pas UEFI[1]. Mais on n'a pas ça sur les SBC, c'est plutôt l'absence de standard qui pêche et pour le coup c'est plutôt du côté de U-Boot que le consensus a l'air de se faire. Du coup petitboot me parait ajouter une couche inutile pour le plaisir d'ajouter une couche inutile mais j'ai peut-être raté un détail important.
[1] et de plus en plus de distribs commencent à se dire qu'elles vont arrêter d'installer grub par défaut.
[^] # Re: U-boot
Posté par Pinaraf . Évalué à 3.
Pas du tout, c'est du révisionnisme historique d'affirmer ça.
C'est uniquement depuis 2012 et l'introduction du "stub UEFI" qu'on peut se permettre de retirer grub dans le cas d'une machine UEFI (avec le bon alignement des planètes au début, il a fallu du temps pour découvrir les bugs avant d'arriver à la situation actuelle où effectivement grub n'est plus utile). https://lwn.net/Articles/632528/
Tout à fait, un "détail" : u-boot ne règle pas non plus la question de la diffusion du device tree, et permettrait encore moins d'avoir une interface où le device tree pourrait être ajusté aux accessoires actuellement présents sur la machine. Petitboot a la possibilité de régler ce problème, mais l'implémentation de hardkernel pêche totalement.
Accessoirement, si mon Linux est HS, si je veux avoir tout mon système en LVM ou sur un RAID logiciel… au revoir u-boot.
[^] # Re: U-boot
Posté par Psychofox (Mastodon) . Évalué à 3.
Non, je parle au présent c'est tout. En 2023 on n'a pas besoin de grub[1] pour un boot depuis une machine ayant UEFI, point.
Tu veux dire sans partition /boot séparée? Je te rétorquerais que ta partition petitboot rempli le même usage et que du coup c'est bonnet blanc et blanc bonnet.
Reste la question du device-tree dans ton point 6) mais justement tu dis que petitboot et le kernel linux ont toujours besoin d'avoir chacun leur dtb…tout comme u-boot et le kernel linux. Du coup je sais pas :/
[1] ou autre bootloader installé sur le disque
[^] # Re: U-boot
Posté par Pinaraf . Évalué à 3. Dernière modification le 21 novembre 2023 à 12:09.
Et donc je te dis que c'est faux, ce n'est pas par cohérence avec le BIOS que les distributions gardent ce fonctionnement, c'est uniquement parce que c'est une évolution relativement récente et que c'est un pas très délicat à faire vu le champ de mines que ça a été.
Je n'ai pas de partition petitboot.
Je n'ai pas dit "chacun", justement, ils ont le même dtb. Alors qu'u-boot et le noyau Linux n'ont pas les mêmes DTB, cf. https://docs.u-boot.org/en/latest/develop/devicetree/control.html#history
[^] # Re: U-boot
Posté par Psychofox (Mastodon) . Évalué à 3.
Ah ouais j'ai mal lu. Mais dans ta démonstration tu as quand même du avoir une partoche séparée pour avoir LVM. Bon ça a l'air d'être l'implémentation hardkernel, pas petitboot en l'occurence.
Question bête, as-tu essayé de faire un montage loop de l'image pour voir ce qu'il y a dedans et pour y installer lvm et libcrypto?
Est-ce vraiment un problème que ce ne soit pas le même? U-Boot a un DTB réduit parce qu'il n'a pas vocation à faire tout ce que le kernel peut faire, mais au final osef non? Dans tous les cas on doit le charger deux fois.
J'ai l'impression que petitboot tel que présenté sur ton odroid et u-boot offrent les mêmes fonctionnalités, un bootloader, un shell mais sans valeur ajoutée vu les points bad et ugly.
[^] # Re: U-boot
Posté par Christophe . Évalué à 4. Dernière modification le 21 novembre 2023 à 13:15.
Alors désolé, mais là je suis perdu. J'ai l'impression que petitboot est finalement un bootloader intermédiaire, avec un joli menu, lancé par u-boot. Comme un systemd-boot, au final, avec quelques fonctionnalités en plus.
Donc la chaîne de boot serait:
SPL -> U-boot -> petitboot -> noyau de la distribution Linux installée
Avec U-boot et petitboot installés sur la eMMC de la carte odroid. Le grand changement ici étant que U-boot et petitboot viennent préinstallés sur la carte; ça me fait fortement penser aussi à Tow-Boot pour Pine64.
Cependant je ne vois pas comment le linux de la distribution pourrait se passer de la DTB spécifique à la carte odroid sur laquelle on démarre. Ou alors, le bénéfice c'est que cette DTB est donnée par petitboot ? Auquel cas il faudrait "juste" avoir un noyau plus ou moins générique, avec tous les drivers ARM possibles.
[^] # Re: U-boot
Posté par Marotte ⛧ . Évalué à 5.
Il y a un truc que je n’ai pas compris sur ce bootloader. J’ai installé une Debian il y pas très longtemps (une bullseye), et je me suis retrouvé avec ce truc comme bootloader, c’est d’ailleurs ainsi que j’ai appris son existence. J’aimerais bien comprendre pourquoi. J’ai installé une autre Debian plus récemment, une Bookworm, et c’est bien c bon vieux GRUB qu j’ai.
C’est toujours GRUB le bootloader par défaut de Debian ? Ça a été différent sur Bullseye ? Ça pourrait être lié au multiboot ?
La raison d’être de systemd-bootd c’est de répondre à des limitations de GRUB, ou c’est juste une volonté que systemd puisse remplacer l’intégralité des composants GNU ?
[^] # Re: U-boot
Posté par Renault (site web personnel) . Évalué à 6.
systemd-bootd est radicalement différent de GRUB.
Il ne fonctionne qu'avec des systèmes UEFI et il tire parti de cela, sa configuration est simple, il prend avantage de l'UEFI boot pour implémenter des fallback automatiques si le boot sur un système mis à jour foire, etc.
GRUB est plus complet car il fonctionne dans plus de cas différents mais n'offre pas les mêmes fonctionnalités car il est moins intégré avec la norme UEFI. Et le faire évoluer est loin d'être trivial.
# Standardiser le boot sur équipements embarqué/arm.
Posté par Tangi Colin . Évalué à 10.
Il y a aujourd'hui plusieurs standard en compétition pour standardiser la séquence de boot sur ARM.
La société ARM pousse avec Linaro pour implémenter la spec UEFI (ou la sous spécification d'UEFI qui est Embedded Base Boot Requirements pour être précis).
C'est très certainement le "sens" de l'histoire, ARM voulant de plus en plus se positionner aussi dans le monde des serveurs, on veut unifier avec le monde de X86 d'où l'UEFI et aussi de plus en plus de board avec support ACPI à la place des "Device tree".
Pour une état des lieux du support U-boot associé, ce billet de blog est un bon point de départ :
https://www.linaro.org/blog/journey-to-systemready-compliance-in-u-boot/
Je suis pas sur que l'embarqué en sorte gagnant, la moindre spécification UEFI fait 2000 pages et tu vas te retrouver avec des "EFI Stub" à charger et qui tournent en fond et qui seront certainement de beau binaire boite noire.
Je préfère encore la complexité d'un build custom par board u-boot avec les bon dts à charger. Ce qu'on va gagner en "simplicité (just work)", on va le perdre en capacité à bidouiller.
Heureusement un autre standard tente de se faire sa place en se reposant sur les mécanisme existant mais récent d'u-boot (FIT et bootflow), il s'agit de "Verified Boot for Embedded" : https://talks.osfc.io/media/osfc2022/submissions/ZTGCJG/resources/osfc22_VBE_-_Verified_Boot_for_Embedded_1BUma3C.pdf
Ma préférence va pour ce second "standard", j'espère qu'il sera de plus en plus connue et utilisé par les différents vendeurs de SOC.
Après quand je vois le temps qu'il a fallut pour que le format FIT soit connue et utilisé, la route est encore longue.
Un autre "standard" a noter est coté systemd (maintenant UAPI) concernant l'auto-discovery de partition : https://uapi-group.org/specifications/specs/boot_loader_specification/
[^] # Re: Standardiser le boot sur équipements embarqué/arm.
Posté par tao popus . Évalué à 1.
Uboot implémente aussi depuis quelques temps (mais pas eu de carte+boot l'utilisant) des fonctions graphiques, permettant d'initialiser l'écran et d'avoir des menus etc donc.
Contrairement à ce qui est dit dans l'article, il y a bien une unification par architecture avec Device Tree, dant queles pilotes sont dispo. Les versions spécifiques de ARMbian (ou d'autres distros), sont liés à certains périphériques pas encore présent dans le noyau mainline. Je boot personnellement du mainline sans bidouille sur plusieurs cartes ARM ou sur du RISC-V. Ça marche aussi bien avc U-Boot, LibreBoot, CoreBoot (ou OreBoot la version rust). RISC-V dispose aussi d'OpenSBI pour faciliter le standard, des fonctions d'aides génériques ouvertes.
Il y a aussi Linuxboot qui utilise le noyaux Linux pour le boot, permettant d'éviter d'avoir à dupliquer les pilotes du Device Tree. Mais ça peut être un peu lourd pour des systèmes limités si Linux n'est pas le système cible.
La légende du besoin d'UEFI pour arriver à un boot qui fonctionne sur différentes cartes/Soc utilisant la même ISA (instruction Set Architecture: ARM, RISC-V, Power, x86 etc) est tenace et fait perdre des ressources avec des devs qui s'engagent sur la mauvaise voie :(.
[^] # Re: Standardiser le boot sur équipements embarqué/arm.
Posté par tao popus . Évalué à 1.
J'oubliais un élément moins connu des cartes le SPI flash, une eeprom de quelques Mo qui contient un micrologiciel permettant, notamment, et sur certaines cartes de sélectionner l'ordre de boot entre eeprom (principale)/réseau/SATA/sd/USB/etc…
# dtb & alternatives
Posté par Ph Husson (site web personnel) . Évalué à 6.
Sur le fait de mettre le dtb ou non, est imo un problème épineux. Le kernel est censé garantir une compatibilité arrière, mais personne ne teste vraiment. Et lorsque le kernel rajoute le support de nouveaux composants (par exemple les Rockchip n'ont eu la déclaration Mali GPU dans le dts mainline plusieurs années après le support du reste du chip), il faut le modifier pour rajouter ce support. Ne pas s'autoriser l'upgrade après la sortie va pousser à faire comme l'ACPI/UEFI à avoir des workarounds horrible partout dans tous les drivers.
L'origine des device tree étant la même que le kernel, autant tout mettre ensemble IMO.
Pour autant, le bootloader devrait fournir un dtb par défaut, et ne prendre le dtb de /boot qu'en fallback. Mais c'est peut-être le cas de petitboot, ton journal ne le mentionne pas.
Sinon, je vais mentionner un "concurrent" de petitboot, qui est shippé par un concurrent d'Odroid: Pine64 shippe twoboot (sur les pinephones par exemple). Comme petitboot, c'est un bootloader graphique, qui peut booter sur les différents médias disponibles, qui peut booter un kernel depuis de l'ext4.
Par contre c'est "juste" un uboot, donc exit tous les hacks possibles décrits dans ce journal. Perso j'ai clairement une préférence pour les bootloaders à base de kexec, c'est infini plus modulaire (tu veux booter sur le dernier kernel + rootfs en https tiré du pipeline de CI, en SSL mutuellement authentifié avec ACK de lancement du boot pour mesurer le temps de boot, avec dump automatique du pstore pour les kernels panics? no problemo).
Pour éviter l'effet que tu mentionne d'avoir une image debian par carte embarquée, il faut embarquer le bootloader dans un autre stockage, typiquement une NOR en SPI. Hélas, ça a un coût non négligeable, d'où le fait que la plupart des cartes embarquées n'en ont pas. Si en plus, on prend une NOR suffisamment grosse pour stocker Linux, ça coûte encore plus cher.
Je trouve que ça en vaut largement le coût, mais je comprends que la plupart des cartes embarquées ne fassent pas ce choix.
# Apprximation
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Euh, ça me semble, comment dire… assez loin de la réalité.
Lors de la conception du PC, IBM n'avait pas envie de vendre beaucoup de machines. Ils préféraient de loin vendre des gros ordinateurs très chers, mais ils avait identifié tout de même une demande, et surtout, leurs concurrents commençaient à dire que peut-être IBM n'était tout simplement pas capable de concevoir un micro-ordinateur simple et peu cher.
Leur choix s'est donc dirigé vers des composants standards, non seulement pour le matériel, mais aussi pour le logiciel: au départ, c'est le système CP/M de Digital Research qui est envisagé. Ce système repose sur… un BIOS, un bout de code qui doit être fourni par le fabricant de la machine, et qui permet à tout le reste du système d'être indépendant du matériel. Ainsi, Digital Research livre le binaire de CP/M, et la spécification pour écrire le BIOS.
Cependant, la visite d'IBM chez Digital Research s'est mal passée (le patron n'était pas là, et la personne qui les a reçu a refusé de signer un NDA sans l'accord de son supérieur et n'a donc jamais pu savoir ce qu'ils voulaient). IBM s'est ensuite rendu chez Microsoft, et Bill Gates a bien joué son coup en vendant non seulement son BASIC (pour lequel Microsoft était connu à l'époque), mais en sous-entendant qu'il pourrait aussi très bien fournir CP/M ou un équivalent à un prix tout à fait acceptable. Microsoft s'est ensuite procuré QDOS (Quick and Dirty Operating System), un clone de CP/M en moins bien, et l'a modifié pour en faire MS-DOS. L'idée d'avoir un BIOS ne vient donc pas d'IBM, et ce n'était certainement pas dans le but de fermer la machine, c'était la pratique habituelle pour ce type de matériel.
Suite au choix de travailler avec Microsoft, le BIOS a pu intégrer plus de fonctions et se moderniser un peu par rapport à ce que proposait CP/M (oui oui, on partait de loin…). Cela dit, il était tout de même possible d'obtenir un PC avec CP/M, le BIOS restant compatible avec ce dernier au moins pour les premières générations de machines.
Ce n'est que plus tard que IBM a réalisé son "erreur" avec l'utilisation de composants standard et a essayé de reprendre la main sur l'architecture du PC. Ça a échoué, d'une part à cause des choix matériels complexes et coûteux, mais aussi suite au choix d'utiliser le processeur 286, qui était imparfait, ils se sont fait devancer par Compaq et lâcher par Microsoft sur le projet OS/2 (IBM a continué de s'enfoncer dans l'idée de le faire marcher sur 286 pendant que Microsoft est passé sur 386).
Bref, le but du BIOS n'était pas de fermer l'architecture du PC, au contraire, c'était la bonne chose à faire pour lancer un système standard: CP/M. Ça ne s'est pas vraiment passé comme prévu, et ça a probablement changé beaucoup de chose pour la suite de l'histoire de la micro informatique, dont la montée en puissance de Microsoft et de Windows qui a un peu écrasé toute la concurrence.
[^] # Re: Apprximation
Posté par Marotte ⛧ . Évalué à 7.
Ma question est certainement très con mais :
Comment un ordinateur peut fonctionner, pour commencer permettre qu’on le munisse d’un OS, s’il n’y a pas une une couche logiciel « basique » (comme l’indique le B de BIOS) pour permettre cela ?
On met un OS sur une ROM et roulez jeunesse ?
[^] # Re: Apprximation
Posté par flavien75 . Évalué à 4.
Dans le monde de l'embarqué, c'est parfois possible:
Quand l'image est stockée sur une flash NOR, le CPU la voit en intégralité comme "mappée mémoire". Au boot le CPU (j'ai eu ça sur iMx.27) peut alors exécuter le code à partir de l'adresse 0 de la flash. Le bootloader est réduit à sa plus simple expression.
Bon par contre les flash NOR sont hors de prix par rapport à leur capacité donc c'est difficilement envisageable au delà de quelques dizaine de mega-octets.
Si par contre l'image est stocké sur une flash NAND ou une mémoire type (e)MMC alors le CPU va charger quelque chose du style les premiers 256 ou 4046 octets et les exécuter. Le code devra alors charger en RAM le noyau avant de le démarrer. Un peu comme sur un boot MBR.
Une troisième voie serait d'avoir un bootloader compact stocké en permanent qui viennent charger le noyau depuis une mémoire NAND/eMMC. Mais là j'ai l'impression qu'on se rapproche de l'idée de petitboot.
Les vrais naviguent en -42
[^] # Re: Apprximation
Posté par Vincent Danjean . Évalué à 4.
Si je me souviens bien, le TO7-70 avait son système sur une "cartouche" (qui était probablement adressable directement par le processeur) avec, au choix, Basic ou Logo.
Et mon premier ordinateur à la maison (Atari 1040 STe) avait son OS en ROM. C'était un argument de vente : le code de l'OS ne prenait pas de place en RAM donc il restait plus de RAM pour les applis…
[^] # Re: Apprximation
Posté par GG (site web personnel) . Évalué à 5.
Les Mac Classic (peut être aussi les Mac Plus, SE et SE/30?) pouvaient booter en "rom".
Il fallait maintenir les touches Pomme, Option, Majuscule?, X O, et le bouton de la sourie (je le faisais donc avec le coude).
C'était alors un "vieux" système tout à fait fonctionnel, apparaissant comme une disquette sur le bureau, avec quelques outils comme un débugueur, qu'il suffisait de copier/glisser dans le dossier système pour l'avoir au reboot 'normal'.
Ce mode de debug pouvait s'activer sur les Mac Classic (et peut être les autres?) à l'aide d'un bouton discret situé à côté de celui du reset, sur la paroi de gauche de l'écran. Si on faisait s'afficher le code exécuté, ça ralentissait la machine mais on pouvait alors voir comment était dessiné chaque fenêtre, cadres etc. Passionnant.
Il y avait aussi l'outil d'analyse des applications, dans lesquelles on pouvait voir les lignes d'assembleurs avec des commentaires.
J'ai toujours trouvé MacOS de 5 à 7.6 (avant 8 et suivants) particulièrement soignés.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Apprximation
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 9.
Il y avait quand même une ROM interne (le "moniteur") pour afficher un écran demandant d'insérer une cartouche, et contenant du code commun permettant de faire les opérations de base (lire le clavier, afficher du texte, …). Un genre de BIOS, donc.
Particularité intéressante (ou pas): cette ROM fait seulement 6Ko et elle est intégrée dans le composant "PIA" 6846, qui regroupe aussi un timer et des entrées-sorties.
La cartouche est effectivement adressable directement. Mais cela utilise de l'espace mémoire qui aurait pu être attribué à de la RAM. Pas vraiment un problème sur le TO7 (la RAM était trop chère à l'époque pour remplir même seulement 64Ko d'espace mémoire avec), mais les machines suivantes vont ajouter tout un système de "banques" permettant de déconnecter la cartouche et de mettre de la RAM à la place. Par contre la ROM interne reste toujours en place, ce qui est bien dommage. D'autres ordinateurs permettent de n'avoir que de la RAM, et cela apporte une flexibilité bien appréciable.
Dans les ordinateurs qui n'ont presque pas de BIOS, on peut citer l'Amstrad PCW: seulement 256 octets de code, qui sont stockés dans le contrôleur de l'imprimante et envoyés au CPU dans un ordre fixe (pas directement addressables). Il y a juste de quoi lire un secteur de la disquette, et l'exécuter, après une initialisation minimale du matériel. Tout le reste est chargé depuis la disquette. Si le lecteur de disquette ne fonctionne pas, la machine devient complètement inutilisable et ne peut même pas afficher un message d'erreur.
[^] # Re: Apprximation
Posté par Arkem . Évalué à 4. Dernière modification le 10 décembre 2023 à 12:28.
Pour ajouter une bille aux autres réponse ci-dessus, l'Amiga avait aussi l'essentiel de son système, accompagné d'un shell texte, dans une ROM (Read Only Memory, pour rappel). Ce composant ne coûtait pas très cher et était monté sur support, il était donc relativement simple d'"upgrader" son système en changeant la ROM. Il n'était pas question de NOR à l'époque, en tout cas pas sur ces machines.
Si on voulait l'environnement graphique complet, par contre, il fallait le charger à partir d'une disquette bootable, ou l'installer sur disque dur.
Certaines cartes d'extension permettant d'ajouter de la RAM dite "Fast" (utilisable directement par le processeur sans passer par le contrôleur DMA du chipset), proposaient de copier le système en RAM pour accélérer son exécution. Les plus grosses ROM système faisaient 512 Ko.
[^] # Re: Apprximation
Posté par lym . Évalué à 4.
Pour avoir fait du vxWorks sur PowerPC brut de fonderie, on bootait sur une flash NOR sur bus parallèle en raw (pas de FS) et le boot-loader était limité peu ou prou à un fichier assembleur nommé rominit.S, de mémoire!
Bon, ça c’était au début. Bien entendu pour faire un produit commercial derrière on avait voulu un flash file system, même minimaliste, avec une partition active et une backup pour ne pas se planter sur un upgrade foireux (et un système de reset-loop-counter RAZ par une probation en toute fin de boot OS, tout l'applicatif et liens réseau de supervision lancés, qui assurait un swap de partition si ce RLC dépassait 3).
D'où une architecture plus classique de boot loader à 2 niveau avec un premier, non upgradable (en fait, des bugs processeur sur des trucs à initialiser très tôt nous avaient contraints à mettre un mécanisme d'upgrade en place, même si ce fut rare et avec des risques de briquer du matériel déployé) et commun aux 2 partitions, fut un héritier du rominit.S (inits minimales de base et contrôleur DDR) ajoutant la gestion du swap de partition et l'appel à un second niveau, il y en avait 1 binaire en face de chaque partition, incluant le gros des inits matérielles hors DDR et les trucs qui peuvent évoluer avec l'OS ou nécessiter des corrections de bug (reader de file-system utilisé etc…), ainsi qu'un support réseau basique pour le boot TFTP (en développement/fabrication, voir dépannage).
Bon, c'est clairement une simplicité qui se perds avec les mécanismes de boot sécurisés ou on rajoute bien des étages (tournant éventuellement sur des processeurs de service qui ne sont même pas les principaux, contenant les FW de gestion pré-boot, énergie etc) à la fusée qui décolle (ou pas!)…
[^] # Re: Apprximation
Posté par lym . Évalué à 1. Dernière modification le 15 décembre 2023 à 14:45.
Je ne savais pas que CP/M avait besoin d'un boot-loader lui fournissant des services (ces fameuses "interruptions BIOS", pas vraiment au sens matériel mais du nom de l'instruction permettant de les appeler avec leur numéro, correspondant aux system-call actuels des boot sécurisés) pour tout, comme le DOS (tout ce qui tapait dans le matériel y passait: frappes clavier, gestion écran/stockage…).
Car ensuite le duo wintel, qui avait lâché ce fonctionnement (Linux n'en a jamais eu vraiment besoin, sauf récemment avec les services liés aux enclaves sécurisées justement) ayant fait le nid des virus dits de secteur de boot, a été prompt à le remettre avec les runtime services UEFI (sous ensemble des boot services complets, actifs avant le lancement de l'OS, destinés à pouvoir être appelés par l'OS) avec l'arrivée du secure boot (permettant de limiter les risques passés du concept!).
CP/M était d'ailleurs fourni avec mon Amstrad CPC6128 d'ado, qui n'avait pas de BIOS, même si je ne l'ai jamais utilisé pour ma part???
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.