L'architecture ARM est un gros merdier alors qu'il domine sur les tablettes et téléphones. Son avantage de son faible coût et de sa faible consommation pour une puissance raisonnable l'ont rendu incontournable. Mais faute de BIOS ou équivalent disponible (l'UEFI arrive petit à petit mais c'est long et pas généralisé sur l'ARM64) rend toutes ces puces légèrement incompatibles avec le voisin avec peu de possibilités simples pour avoir un système unique qui s'adapte à la machine.
Si les PCs avaient connus la même situation, cela aurait été difficile. Imagine s'il fallait une image Linux spéciale pour les HP, Dell, Acer ou autres, voire entre HP avec un Intel i386 et AMD compatible i686. Je doute que Linux en serait là aujourd'hui. Car cela aurait complexifié la venue de contributeurs et d'utilisateurs et les développeurs perdraient du temps à gérer cette situation plutôt que d'ajouter des fonctionnalités intéressantes.
D'autant plus que le problème des téléphones est exacerbé par le fait que les fondeurs de puces type Qualcomm, Broadcom font du mauvais travail. Linux gère leur téléphone mais ce travail est fait à l'arrache faute de temps et de budget. Ce qui fait que le noyau Linux officiel ne peut bénéficier de ces travaux et peut difficilement fonctionner sur ces puces.
Moui... Pour moi c'est plutôt Linux qui a mis beaucoup trop de temps à réagir et à mettre en place les device trees pour les architectures ARM. Résultat, les constructeurs n'ont pas eu trop de choix que de bricoler avec ce qu'ils avaient sous la main.
Le BIOS n'y est pour rien, dans les PC il n'est quasiment pas utilisé par Linux (un peu par GRUB, mais c'est tout) et sur la plupart des machines ARM tu vas trouver un u-boot qui fait tout aussi bien et même mieux dans la plupart des cas (rappelons que le BIOS ça date des années 70, quand même).
La différence avec les PC, c'est la présence du bus PCI qui permet d'énumérer le matériel, et auparavant de l'ISA plug-n-play. Sur ARM, il n'y a pour l'instant (en général - on trouve des machines avec un bus PCI) pas d'équivalent pour ça. Du coup, la solution c'est le device tree, qui décrit le matériel et qui normalement permet d'utiliser le même noyau partout.
L'autre souci, c'est que pour Linux, tous les drivers devraient être intégrés dans le git de Linus Torvalds pour être maintenus. Mais ce n'est pas une approche réaliste pour plein de cas. Du coup, chaque fabricant préfère vivre avec son propre fork du noyau, ce qui coûte moins cher à court et moyen terme (et il y a peu de fabricants qui maintiennent leurs puces sur le long terme - c'est plus simple de les remplacer par des versions plus récentes).
Si Linux avait une API stable pour les drivers et qu'on pouvait les maintenir séparément et indépendamment de la version du noyau, ça serait simple de garder les drivers du fabricant et de mettre à jour le noyau.
Au final, pour un fabricant de puces, ça coûte moins d'effort de faire un truc rapide et pas propre et pas intégrable, et y'a pas vraiment de raison de faire autrement.
[^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 3.
Moui... Pour moi c'est plutôt Linux qui a mis beaucoup trop de temps à réagir et à mettre en place les device trees pour les architectures ARM. Résultat, les constructeurs n'ont pas eu trop de choix que de bricoler avec ce qu'ils avaient sous la main.
Le BIOS n'y est pour rien, dans les PC il n'est quasiment pas utilisé par Linux (un peu par GRUB, mais c'est tout) et sur la plupart des machines ARM tu vas trouver un u-boot qui fait tout aussi bien et même mieux dans la plupart des cas (rappelons que le BIOS ça date des années 70, quand même).
La différence avec les PC, c'est la présence du bus PCI qui permet d'énumérer le matériel, et auparavant de l'ISA plug-n-play. Sur ARM, il n'y a pour l'instant (en général - on trouve des machines avec un bus PCI) pas d'équivalent pour ça. Du coup, la solution c'est le device tree, qui décrit le matériel et qui normalement permet d'utiliser le même noyau partout.
L'autre souci, c'est que pour Linux, tous les drivers devraient être intégrés dans le git de Linus Torvalds pour être maintenus. Mais ce n'est pas une approche réaliste pour plein de cas. Du coup, chaque fabricant préfère vivre avec son propre fork du noyau, ce qui coûte moins cher à court et moyen terme (et il y a peu de fabricants qui maintiennent leurs puces sur le long terme - c'est plus simple de les remplacer par des versions plus récentes).
Si Linux avait une API stable pour les drivers et qu'on pouvait les maintenir séparément et indépendamment de la version du noyau, ça serait simple de garder les drivers du fabricant et de mettre à jour le noyau.
Au final, pour un fabricant de puces, ça coûte moins d'effort de faire un truc rapide et pas propre et pas intégrable, et y'a pas vraiment de raison de faire autrement.