Sur le fait de mettre le dtb ou non, est imo un problème épineux. Le kernel est censé garantir une compatibilité arrière, mais personne ne teste vraiment. Et lorsque le kernel rajoute le support de nouveaux composants (par exemple les Rockchip n'ont eu la déclaration Mali GPU dans le dts mainline plusieurs années après le support du reste du chip), il faut le modifier pour rajouter ce support. Ne pas s'autoriser l'upgrade après la sortie va pousser à faire comme l'ACPI/UEFI à avoir des workarounds horrible partout dans tous les drivers.
L'origine des device tree étant la même que le kernel, autant tout mettre ensemble IMO.
Pour autant, le bootloader devrait fournir un dtb par défaut, et ne prendre le dtb de /boot qu'en fallback. Mais c'est peut-être le cas de petitboot, ton journal ne le mentionne pas.
Sinon, je vais mentionner un "concurrent" de petitboot, qui est shippé par un concurrent d'Odroid: Pine64 shippe twoboot (sur les pinephones par exemple). Comme petitboot, c'est un bootloader graphique, qui peut booter sur les différents médias disponibles, qui peut booter un kernel depuis de l'ext4.
Par contre c'est "juste" un uboot, donc exit tous les hacks possibles décrits dans ce journal. Perso j'ai clairement une préférence pour les bootloaders à base de kexec, c'est infini plus modulaire (tu veux booter sur le dernier kernel + rootfs en https tiré du pipeline de CI, en SSL mutuellement authentifié avec ACK de lancement du boot pour mesurer le temps de boot, avec dump automatique du pstore pour les kernels panics? no problemo).
Pour éviter l'effet que tu mentionne d'avoir une image debian par carte embarquée, il faut embarquer le bootloader dans un autre stockage, typiquement une NOR en SPI. Hélas, ça a un coût non négligeable, d'où le fait que la plupart des cartes embarquées n'en ont pas. Si en plus, on prend une NOR suffisamment grosse pour stocker Linux, ça coûte encore plus cher.
Je trouve que ça en vaut largement le coût, mais je comprends que la plupart des cartes embarquées ne fassent pas ce choix.
# dtb & alternatives
Posté par Ph Husson (site web personnel) . En réponse au journal Petitboot sur ARM, le bon, le bad et le ugly. Évalué à 6.
Sur le fait de mettre le dtb ou non, est imo un problème épineux. Le kernel est censé garantir une compatibilité arrière, mais personne ne teste vraiment. Et lorsque le kernel rajoute le support de nouveaux composants (par exemple les Rockchip n'ont eu la déclaration Mali GPU dans le dts mainline plusieurs années après le support du reste du chip), il faut le modifier pour rajouter ce support. Ne pas s'autoriser l'upgrade après la sortie va pousser à faire comme l'ACPI/UEFI à avoir des workarounds horrible partout dans tous les drivers.
L'origine des device tree étant la même que le kernel, autant tout mettre ensemble IMO.
Pour autant, le bootloader devrait fournir un dtb par défaut, et ne prendre le dtb de /boot qu'en fallback. Mais c'est peut-être le cas de petitboot, ton journal ne le mentionne pas.
Sinon, je vais mentionner un "concurrent" de petitboot, qui est shippé par un concurrent d'Odroid: Pine64 shippe twoboot (sur les pinephones par exemple). Comme petitboot, c'est un bootloader graphique, qui peut booter sur les différents médias disponibles, qui peut booter un kernel depuis de l'ext4.
Par contre c'est "juste" un uboot, donc exit tous les hacks possibles décrits dans ce journal. Perso j'ai clairement une préférence pour les bootloaders à base de kexec, c'est infini plus modulaire (tu veux booter sur le dernier kernel + rootfs en https tiré du pipeline de CI, en SSL mutuellement authentifié avec ACK de lancement du boot pour mesurer le temps de boot, avec dump automatique du pstore pour les kernels panics? no problemo).
Pour éviter l'effet que tu mentionne d'avoir une image debian par carte embarquée, il faut embarquer le bootloader dans un autre stockage, typiquement une NOR en SPI. Hélas, ça a un coût non négligeable, d'où le fait que la plupart des cartes embarquées n'en ont pas. Si en plus, on prend une NOR suffisamment grosse pour stocker Linux, ça coûte encore plus cher.
Je trouve que ça en vaut largement le coût, mais je comprends que la plupart des cartes embarquées ne fassent pas ce choix.