Oui je connais bien tout ça, mais ça n'empêche pas.
(...)
Pour lancer Linux on n'a pas besoin de modifier son BIOS, sur un téléphone c'est pareil.
Donc non, manifestement tu ne connais pas très bien tout ça et tu n'as pas non plus lu mon post plus haut. Donc je répète : « contrairement au monde du PC, dans le monde ARM/MIPS il n'existe pas "one kernel to rule them all". La faute à l'absence de mécanisme d'introspection/abstraction (jouée par le BIOS/ACPI/UEFI dans le monde PC) qui fait que chaque SoC et chaque carte-mère est une machine à part nécessitant un kernel dédié. La situation évolue doucement avec le device-tree (qu'il est parfois possible d'extraire du firmware du fabricant), mais ça reste pas évident de recompiler son kernel avec les bons patches, et de l'installer (avec le DT, etc.). Bref, il n'existe aucun moyen de booter un linux ARM "générique" sur un device ARM/MIPS ».
(pour peu qu'il y ait un bootloader sympa qui accepte de booter une image non signée évidemment)
J'ai un vieux téléphone à base de chipset Mediatek d'un ODM taiwanais. Je n'ai pas les sources pour le kernel, et la description de la machine ne se basait certainement pas sur un device-tree mais sur des fichiers mach-*.c (dont je n'ai pas les sources). Je n'ai pas non plus de moyen d'extraire les drivers pour les différentes parties du SoC (pas seulement GPU, mais tout ce qui touche aux différentes clocks, à la gestion de l'énergie, etc.). Donc je n'ai aucun moyen de recompiler et booter mon propre kernel. Pourtant j'ai un bootloader "sympa".
Les blobs binaires, les modules kernel particuliers, ça se récupère d'une image existante, c'est toujours possible
Les blobs binaires, peut-être (comme le DT par exemple. Les modules (*.ko) ne te seront pas d'une grande utilité vu que les API noyau sont non stables. Le reste (ce qui est compilé en dur dans le kernel, que ce soit les drivers ou la description de la machine lorsqu'elle est faite dans des fichiers mach-* au lieu du DT) me semble également irrécupérable...
Ce que je voulais dire c'est que si on fait le même effort que les premiers qui ont sué à faire tourner X11 sur leur Matrox sous Linux avec le son sur une SoundBlaster en prime, tout cela sans l'aide d'aucun constructeur, on fera aussi tourner une Debian en natif sur un téléphone.
Si tu espères faire du reverse-engineering à l'aveugle, je pense que tu n'as pas idée du niveau de complexité à l'intérieur d'un SoC moderne !
[^] # Re: Application vs. Système
Posté par karteum59 (site web personnel) . En réponse au journal Mise à jour Samsung S5, Smart Manager de votre vie privée.. Évalué à 5.
Donc non, manifestement tu ne connais pas très bien tout ça et tu n'as pas non plus lu mon post plus haut. Donc je répète : « contrairement au monde du PC, dans le monde ARM/MIPS il n'existe pas "one kernel to rule them all". La faute à l'absence de mécanisme d'introspection/abstraction (jouée par le BIOS/ACPI/UEFI dans le monde PC) qui fait que chaque SoC et chaque carte-mère est une machine à part nécessitant un kernel dédié. La situation évolue doucement avec le device-tree (qu'il est parfois possible d'extraire du firmware du fabricant), mais ça reste pas évident de recompiler son kernel avec les bons patches, et de l'installer (avec le DT, etc.). Bref, il n'existe aucun moyen de booter un linux ARM "générique" sur un device ARM/MIPS ».
J'ai un vieux téléphone à base de chipset Mediatek d'un ODM taiwanais. Je n'ai pas les sources pour le kernel, et la description de la machine ne se basait certainement pas sur un device-tree mais sur des fichiers mach-*.c (dont je n'ai pas les sources). Je n'ai pas non plus de moyen d'extraire les drivers pour les différentes parties du SoC (pas seulement GPU, mais tout ce qui touche aux différentes clocks, à la gestion de l'énergie, etc.). Donc je n'ai aucun moyen de recompiler et booter mon propre kernel. Pourtant j'ai un bootloader "sympa".
Les blobs binaires, peut-être (comme le DT par exemple. Les modules (*.ko) ne te seront pas d'une grande utilité vu que les API noyau sont non stables. Le reste (ce qui est compilé en dur dans le kernel, que ce soit les drivers ou la description de la machine lorsqu'elle est faite dans des fichiers mach-* au lieu du DT) me semble également irrécupérable...
Si tu espères faire du reverse-engineering à l'aveugle, je pense que tu n'as pas idée du niveau de complexité à l'intérieur d'un SoC moderne !