Forum général.général C'est quoi le problème des plate-formes ARM ?

Posté par (page perso) . Licence CC by-sa
Tags : aucun
6
18
mai
2016

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 !

  • # Explications…

    Posté par (page perso) . É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 (page perso) . Évalué à 3.

      Merci. :-)

      Pour info, les choses ont tout de même un peu changé depuis, avec l'avènement de :

      1. device tree, qui permet au noyau de découvrir de façon générique le matériel disponible ;
      2. UEFI sur ARM, qui fournit une procédure de démarrage générique.

      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 (page perso) . Évalué à 4.

        device tree, qui permet au noyau de découvrir de façon générique le matériel disponible ;

        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 (page perso) . É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 (page perso) . Évalué à 3.

            Pour le noyau, ça permet de découvrir le matériel présent.

            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.

            Évidemment, quelqu'un doit rédiger ce device tree, mais ça, c'est le boulot du fabricant de la machine, non ?

            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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.