Le mieux est encore d'avoir un u-boot par partition et le switch de l'une à l'autre hardwarement commandé (CPLD en travers du bus de la flash de boot), avec pour u-boot (ou une génération à des adresses fixes liées au vecteur de reset est souvent requise) un switch hardware, par exemple de 2 secteurs de flash nor (présentant l'un ou l'autre par tripatouillage de quelques lignes d'adresse).
Car il ne faut pas oublier que nombre de correctifs (errata processeur, mapping, reader de file-system...) imposent de pouvoir aussi changer u-boot de manière sécurisée. De même que des changements d'interface u-boot/kernel, même si l'usage des device-tree a bien réduit les dépendances.
Cela est particulièrement important sur des produits à durée de vie longue, susceptibles de connaitre des évolutions importantes (hardware de "reserve" activé après mise sur le marché, potentiellement demandeur de "workaround" dans le boot loader), si ce n'est les évolutions du noyau (interfaces au boot loader, file-systems) au fur et a mesure des mises à niveau logicielles...
Ce besoin est directement induit par la structure à un seul niveau de boot de u-boot, qui complique un petit peu le problème en le renvoyant hélas impérativement au hardware: Bien des boot loader passés utilisés dans l'industrie s'inspiraient un peu des 2 niveaux de celui d'un PC (dont le bios n'évolue généralement jamais, seul le ntldr/grub le faisant régulièrement).
Cela permettait un boot loader de niveau 1 aussi minimaliste que figé... tout le potentiellement variable (reader FS, mapping, quasi totalité des erratas, interface/paramètres OS) étant dans un boot loader de niveau 2, avec un exemplaire par partition (dans une sous-partition raw excluant les pb de FS-reader). Le switch de partition étant controllé par le niveau 1.
Le mieux est encore d'avoir un u-boot par partition et le switch de l'une à l'autre hardwarement commandé (CPLD en travers du bus de la flash de boot), avec pour u-boot (ou une génération à des adresses fixes liées au vecteur de reset est souvent requise) un switch hardware, par exemple de 2 secteurs de flash nor (présentant l'un ou l'autre par tripatouillage de quelques lignes d'adresse).
Car il ne faut pas oublier que nombre de correctifs (errata processeur, mapping, reader de file-system...) imposent de pouvoir aussi changer u-boot de manière sécurisée. De même que des changements d'interface u-boot/kernel, même si l'usage des device-tree a bien réduit les dépendances.
Cela est particulièrement important sur des produits à durée de vie longue, susceptibles de connaitre des évolutions importantes (hardware de "reserve" activé après mise sur le marché, potentiellement demandeur de "workaround" dans le boot loader), si ce n'est les évolutions du noyau (interfaces au boot loader, file-systems) au fur et a mesure des mises à niveau logicielles...
Ce besoin est directement induit par la structure à un seul niveau de boot de u-boot, qui complique un petit peu le problème en le renvoyant hélas impérativement au hardware: Bien des boot loader passés utilisés dans l'industrie s'inspiraient un peu des 2 niveaux de celui d'un PC (dont le bios n'évolue généralement jamais, seul le ntldr/grub le faisant régulièrement).
Cela permettait un boot loader de niveau 1 aussi minimaliste que figé... tout le potentiellement variable (reader FS, mapping, quasi totalité des erratas, interface/paramètres OS) étant dans un boot loader de niveau 2, avec un exemplaire par partition (dans une sous-partition raw excluant les pb de FS-reader). Le switch de partition étant controllé par le niveau 1.