Cette différence paraît faible mais elle est en fait fondamentale ! C'est cette différence qui est la source de tous les mots et qui rend le device tree obligatoire. Et qui complique la conception d'une image ARM universelle.
Oui, effectivement. Mais on est quand même un peu loin de l'affirmation de départ que c'est impossible de compiler une image du kernel générique.
Après, je comprends pas pourquoi on voudrait faire qu'une board ARM soit comme un PC justement. Un PC, c'est aussi un temps de boot catastrophique, une standardisation qui impose un use case (quand des CPUs ARM vont d'un contrôleur de disque dur à un serveur rackable) et un gros machin horrible qui tourne sous le kernel, est troué de partout et dit absolument rien de ce qu'il fait vraiment. On a rien sans rien…
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.
Le device tree ne change absolument rien. Le device tree décrit spécifiquement le contenu d'un SoC pour pouvoir fonctionner. Il est totalement impossible de "découvrir" les périphériques et aller chercher le bon driver.
C'est pourtant exactement ce que permet le device tree.
Pour le 2), non cela serait simplement une adresse mémoire fixe pour tous les ARM, avec la liste des périphériques (genre numéro unique, et adresse mémoire). Sur un soc, cela peut être de la "mémoire compilé".
Le dtb est compilé, et chargé en mémoire à une adresse passée au kernel, du coup, là encore, c'est exactement ce que fait le device tree.
Il n'y que moi que ça choque de parler dans une dépêche au sujet de pilotes libres d'un pilote sur lequel on n'a pas aucune info, pas même le code, en un peu plus d'un an maintenant (et de l'assumer totalement dans l'article) ?
Premièrement, je ne crois pas qu'on peut utiliser ces drivers closed source en mainline ou stable kernel (à confirmer)
Les drivers du Mali ne sont pas closed-sources. Ils sont dispos sur le site d'ARM, sous GPL. Ce qui est closed source, c'est l'implémentation d'OpenGL ES, qui est une librairie, et qui interagit avec ce driver.
C'est tout à fait utilisable en mainline, à partir du moment où on a le support pour le contrôleur d'affichage (et c'est un truc qui manquera pour l'A64, en tout cas au début).
Il n'y a pas de relation entre une interface graphique et le Mali. Le Mali est le GPU, il est en charge de l'accélération 3d (et uniquement de ça). Il y a un contrôleur complètement différent qui s'occupe d'afficher un truc sur l'écran. Le mali est une des sources possible, mais c'est loin d'être la seule.
Ni l'un ni l'autre. Jusqu'à récemment, c'était juste du boulot perso sur le temps libre. Depuis pas longtemps, on a un client qui nous fait bosser dessus, mais ça date de quelques semaines, donc y a pas vraiment eu d'effets visibles encore.
Tous les constructeurs de puces (même les chinois, Mediatek, Rockchip, Allwinner du moins) se mettent à pousser des morceaux dans Linux
C'est faux dans le cas d'Allwinner. C'est une communauté de développeurs volontaires qui pousse ces patches, contrairement à Mediatek ou Rockchip qui s'occupent de ça eux même.
[^] # 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é à -1.
Oui, effectivement. Mais on est quand même un peu loin de l'affirmation de départ que c'est impossible de compiler une image du kernel générique.
Après, je comprends pas pourquoi on voudrait faire qu'une board ARM soit comme un PC justement. Un PC, c'est aussi un temps de boot catastrophique, une standardisation qui impose un use case (quand des CPUs ARM vont d'un contrôleur de disque dur à un serveur rackable) et un gros machin horrible qui tourne sous le kernel, est troué de partout et dit absolument rien de ce qu'il fait vraiment. On a rien sans rien…
[^] # 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.
[^] # 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é à -1.
C'est pourtant exactement ce que permet le device tree.
Le dtb est compilé, et chargé en mémoire à une adresse passée au kernel, du coup, là encore, c'est exactement ce que fait le device tree.
# Tamil libre ?
Posté par mripard . En réponse à la dépêche Les pilotes graphiques libres : rétrospective et vue sur l’avenir. Évalué à 10.
Il n'y que moi que ça choque de parler dans une dépêche au sujet de pilotes libres d'un pilote sur lequel on n'a pas aucune info, pas même le code, en un peu plus d'un an maintenant (et de l'assumer totalement dans l'article) ?
[^] # Re: noyau
Posté par mripard . En réponse au journal A64 tous gagnants. Évalué à 4.
Pourquoi ? L'interface graphique marche très bien en mainline.
C'est encore un peu rustique, mais largement suffisant pour faire tourner un desktop dessus (et le côté "rustique" va très vite disparaître).
[^] # Re: GPU
Posté par mripard . En réponse au journal A64 tous gagnants. Évalué à 2.
Les drivers du Mali ne sont pas closed-sources. Ils sont dispos sur le site d'ARM, sous GPL. Ce qui est closed source, c'est l'implémentation d'OpenGL ES, qui est une librairie, et qui interagit avec ce driver.
C'est tout à fait utilisable en mainline, à partir du moment où on a le support pour le contrôleur d'affichage (et c'est un truc qui manquera pour l'A64, en tout cas au début).
[^] # Re: GPU
Posté par mripard . En réponse au journal A64 tous gagnants. Évalué à 2.
Il n'y a pas de relation entre une interface graphique et le Mali. Le Mali est le GPU, il est en charge de l'accélération 3d (et uniquement de ça). Il y a un contrôleur complètement différent qui s'occupe d'afficher un truc sur l'écran. Le mali est une des sources possible, mais c'est loin d'être la seule.
Et le driver de ce contrôleur est sous GPL.
[^] # Re: Snap 410
Posté par mripard . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 2.
Ni l'un ni l'autre. Jusqu'à récemment, c'était juste du boulot perso sur le temps libre. Depuis pas longtemps, on a un client qui nous fait bosser dessus, mais ça date de quelques semaines, donc y a pas vraiment eu d'effets visibles encore.
[^] # Re: Snap 410
Posté par mripard . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 3.
C'est faux dans le cas d'Allwinner. C'est une communauté de développeurs volontaires qui pousse ces patches, contrairement à Mediatek ou Rockchip qui s'occupent de ça eux même.