Tu te méprends sur ce qu'est la découverte de périphérique.
Le BIOS / UEFI permet d'initialiser le système sans devoir le décrire, le tout automatiquement. Tout simplement en utilisant des bus matériels permettant la découverte comme l'USB, PCIe, etc. et grâce au fait que certaines choses dans l'architecture PC sont standardisés.
C'est pas tellement lié en fait. Le device tree ne liste que les devices qui ne sont pas découvrables, donc sur des bus mémoires, i2c, spi, etc. Pour USB et PCIe, le seul truc qui est listé est le contrôleur. Tout comme ACPI.
C'est ce qui rend possible le fait d'avoir un OS unique qui peut booter (sur PC) sur à peu près n'importe quelle configuration de carte graphique, RAM, cartes réseaux, etc.
La discussion plus haut était juste sur le kernel, mais même pour un OS entier, c'est possible. Debian et Fedora (les premiers exemples qui me viennent en tête, il y en a surement plein d'autres) utilisent une seule image pour toutes les cartes supportées. La seule différence étant le device tree justement.
Le device tree est quant à lui statique. C'est un humain qui va décrire dans le noyau les adresses, les bus et les pilotes à employer pour chaque carte ARM. Si tu fais une carte ARM un peu différente, tu devras écrire un nouveau device tree (éventuellement par surcharge) pour exprimer cette différence.
C'est vrai, mais on pourrait utiliser exactement le même argument pour le BIOS / UEFI et les tables ACPI passées au kernel: il faut bien que quelqu'un les écrive pour les parties non-découvrables. Du coup, je vois pas trop où c'est un point fort.
A noter que le côté statique est quand même soumis à débat. Il n'y a pas (à ma connaissance) d'équivalent aux overlays avec ACPI.
Le noyau comme le SoC n'ont aucune idée sinon de ce qui doit être initialisé ou pas.
Si, en fait. Tout ce qui est listé dans le SoC et a un status = "okay" peut être utilisé. Si c'est effectivement le cas reste à charge de l'OS, mais tout est censé être utilisable.
Le device tree permet une plus grande souplesse :
Grâce à la surcharge, c'est facile de définir un SoC et ensuite les cartes mères qui se basent dessus sans trop se répéter ;
Possibilité de le mettre à jour indépendamment du noyau ;
Possibilité de partager un device tree avec différents OS ou chargeurs de démarrage (cas de U-boot et Linux) ;
Si les cartes mères permettent (via des GPIO par exemple) de dire quelle carte mère tu utilises, tu peux facilement charger le device tree correspondant à la bonne carte. C'est cela qui autorise une image unique pour plusieurs cartes, le chargeur de démarrage peut sélectionner la bonne description du matériel en fonction d'un élément discriminant.
Mais ce dernier point n'a pas la force, robustesse et flexibilité d'un BIOS ou UEFI. Si la carte mère ne fournit rient pour choisir le bon device tree, tu es bien emmerdé.
La "découverte" du DT en lui même est effectivement le seule avantage du BIOS / UEFI sur le DT. Il y a plein de boards qui n'implémentent pas ça. Par contre, ca pose la question plus philosophique de ce qu'est l'OS et de s'il doit inclure l'UEFI et le BIOS sur un PC. J'aurais tendance à dire que non, mais dans ce cas là, le bootloader sur ARM ne fait pas partie de l'OS non plus. Il commence au kernel, qui lui n'a pas à se soucier de la partie decouverte, on lui passe le DT en argument.
[^] # Re: Fragmentation risk
Posté par mripard . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 0. Dernière modification le 27 août 2018 à 16:56.
C'est pas tellement lié en fait. Le device tree ne liste que les devices qui ne sont pas découvrables, donc sur des bus mémoires, i2c, spi, etc. Pour USB et PCIe, le seul truc qui est listé est le contrôleur. Tout comme ACPI.
La discussion plus haut était juste sur le kernel, mais même pour un OS entier, c'est possible. Debian et Fedora (les premiers exemples qui me viennent en tête, il y en a surement plein d'autres) utilisent une seule image pour toutes les cartes supportées. La seule différence étant le device tree justement.
C'est vrai, mais on pourrait utiliser exactement le même argument pour le BIOS / UEFI et les tables ACPI passées au kernel: il faut bien que quelqu'un les écrive pour les parties non-découvrables. Du coup, je vois pas trop où c'est un point fort.
A noter que le côté statique est quand même soumis à débat. Il n'y a pas (à ma connaissance) d'équivalent aux overlays avec ACPI.
Si, en fait. Tout ce qui est listé dans le SoC et a un status = "okay" peut être utilisé. Si c'est effectivement le cas reste à charge de l'OS, mais tout est censé être utilisable.
La "découverte" du DT en lui même est effectivement le seule avantage du BIOS / UEFI sur le DT. Il y a plein de boards qui n'implémentent pas ça. Par contre, ca pose la question plus philosophique de ce qu'est l'OS et de s'il doit inclure l'UEFI et le BIOS sur un PC. J'aurais tendance à dire que non, mais dans ce cas là, le bootloader sur ARM ne fait pas partie de l'OS non plus. Il commence au kernel, qui lui n'a pas à se soucier de la partie decouverte, on lui passe le DT en argument.