Bonjour,
J'ai une petite question à propos des processeurs ARM. Je ne suis pas un spécialiste de l'architecture et j'aimerais comprendre pourquoi je ne peux pas, comme sur une plateforme x86, installer une distribution particulière d'Android sur mes tablettes et mes téléphones ?
Pourquoi je dois attendre que le constructeur de mon matériel décide de me proposer les mise à jour ?
J'imagine qu'il y a une raison, mais elle m’échappe.
Merci !
Forum général.général C'est quoi le problème des plate-formes ARM ?
18
mai
2016
# Explications…
Posté par chimrod (site web personnel) . Évalué à 8.
Pour ne pas répéter un très bon commentaire, je t'invite à un peu de lecture qui répond en partie à ta question.
[^] # Re: Explications…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Merci. :-)
Pour info, les choses ont tout de même un peu changé depuis, avec l'avènement de :
Il semble que le device tree soit maintenant un standard de fait pour les nouveaux modèles, j'ignore en revanche ce qu'il en est de l'adoption d'UEFI.
[^] # Re: Explications…
Posté par Renault (site web personnel) . Évalué à 4.
Non, un device tree c'est un listing du matériel disponible, plateforme par plateforme. Cela ne permet pas de découvrir magiquement ce qu'il y a sur la carte (car il est écrit à la main, il n'y a pas de procédure d’énumération ou de découverte du matériel).
Le device tree en fait remplace les fichiers .c et .h qui abondaient dans la section arch/arm pour décrire le matériel. Chaque plateforme avait du code source pour dire que sur cette carte, l'I2C a tels périphériques à telles adresses, l'adresse de base de la RAM est de tant, il y a de l'Ethernet avec tel pilote associé, etc.
Le device tree a l'avantage par rapport à l'ancienne méthode d'être plus simple et élégant qu'un code équivalent en C. En plus il est plutôt souple, on peut facilement faire un device tree générique qui sera étendu par des cartes semblables mais pas identiques.
Mais le device tree, comme avant, nécessite qu'un développeur renseigne ces éléments à la main. Parfois il est généré automatiquement pour certaine plateforme via des programmes adaptés mais c'est un humain qui renseigne les champs suivant la carte cible.
[^] # Re: Explications…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Pour le noyau, ça permet de découvrir le matériel présent. Évidemment, quelqu'un doit rédiger ce device tree, mais ça, c'est le boulot du fabricant de la machine, non ?
[^] # Re: Explications…
Posté par Renault (site web personnel) . Évalué à 3.
Je n'aime pas le terme découvrir dans ce cas. S'il y a une erreur dans le device tree, il n'a pas le moyen de détecter automatiquement ce qui ne va pas et comment le corriger par exemple.
Cela reste différent du x86 où le noyau et le processeur gèrent cela automatiquement sans intervention humaine. ;)
Pour le device tree, ce n'est pas nécessairement le fabricant qui s'en charge (bien que ce soit souvent le cas). Puis si ton entreprise fait une carte dérivée de la carte de démonstration du fabricant, tu dois refaire le device tree ou l'étendre pour que cela colle.
Les constructeurs en général ne s'occupent que de la carte de démonstration dite EVM.
# parce que... ARM n'est pas x86
Posté par NeoX . Évalué à 7.
https://fr.wikipedia.org/wiki/Architecture_ARM
en fait, ARM ne fait que le design du processeur,
ensuite chaque fondeur fait sa cuisine autour d'un concept de processeur,
et il y a donc toutes les couches autour qui sont "specifiques" au constructeur/fondeur du processeur (le bootloader, certaines interfaces de peripheriques)
et donc contrairement aux bios/uefi, ce morceau là n'est pas standard => besoin du constructeur pour avoir certaines infos.
et non, tu n'es pas obligé d'attendre le constructeur de ton smartphone, tu peux tres bien installer des ROMs alternatives que la communauté aura developpé (ex cyanogenmod, replicant, etc)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.