Pour avoir fait du vxWorks sur PowerPC brut de fonderie, on bootait sur une flash NOR sur bus parallèle en raw (pas de FS) et le boot-loader était limité peu ou prou à un fichier assembleur nommé rominit.S, de mémoire!
Bon, ça c’était au début. Bien entendu pour faire un produit commercial derrière on avait voulu un flash file system, même minimaliste, avec une partition active et une backup pour ne pas se planter sur un upgrade foireux (et un système de reset-loop-counter RAZ par une probation en toute fin de boot OS, tout l'applicatif et liens réseau de supervision lancés, qui assurait un swap de partition si ce RLC dépassait 3).
D'où une architecture plus classique de boot loader à 2 niveau avec un premier, non upgradable (en fait, des bugs processeur sur des trucs à initialiser très tôt nous avaient contraints à mettre un mécanisme d'upgrade en place, même si ce fut rare et avec des risques de briquer du matériel déployé) et commun aux 2 partitions, fut un héritier du rominit.S (inits minimales de base et contrôleur DDR) ajoutant la gestion du swap de partition et l'appel à un second niveau, il y en avait 1 binaire en face de chaque partition, incluant le gros des inits matérielles hors DDR et les trucs qui peuvent évoluer avec l'OS ou nécessiter des corrections de bug (reader de file-system utilisé etc...), ainsi qu'un support réseau basique pour le boot TFTP (en développement/fabrication, voir dépannage).
Bon, c'est clairement une simplicité qui se perds avec les mécanismes de boot sécurisés ou on rajoute bien des étages (tournant éventuellement sur des processeurs de service qui ne sont même pas les principaux, contenant les FW de gestion pré-boot, énergie etc) à la fusée qui décolle (ou pas!)...
[^] # Re: Apprximation
Posté par lym . En réponse au journal Petitboot sur ARM, le bon, le bad et le ugly. Évalué à 4.
Pour avoir fait du vxWorks sur PowerPC brut de fonderie, on bootait sur une flash NOR sur bus parallèle en raw (pas de FS) et le boot-loader était limité peu ou prou à un fichier assembleur nommé rominit.S, de mémoire!
Bon, ça c’était au début. Bien entendu pour faire un produit commercial derrière on avait voulu un flash file system, même minimaliste, avec une partition active et une backup pour ne pas se planter sur un upgrade foireux (et un système de reset-loop-counter RAZ par une probation en toute fin de boot OS, tout l'applicatif et liens réseau de supervision lancés, qui assurait un swap de partition si ce RLC dépassait 3).
D'où une architecture plus classique de boot loader à 2 niveau avec un premier, non upgradable (en fait, des bugs processeur sur des trucs à initialiser très tôt nous avaient contraints à mettre un mécanisme d'upgrade en place, même si ce fut rare et avec des risques de briquer du matériel déployé) et commun aux 2 partitions, fut un héritier du rominit.S (inits minimales de base et contrôleur DDR) ajoutant la gestion du swap de partition et l'appel à un second niveau, il y en avait 1 binaire en face de chaque partition, incluant le gros des inits matérielles hors DDR et les trucs qui peuvent évoluer avec l'OS ou nécessiter des corrections de bug (reader de file-system utilisé etc...), ainsi qu'un support réseau basique pour le boot TFTP (en développement/fabrication, voir dépannage).
Bon, c'est clairement une simplicité qui se perds avec les mécanismes de boot sécurisés ou on rajoute bien des étages (tournant éventuellement sur des processeurs de service qui ne sont même pas les principaux, contenant les FW de gestion pré-boot, énergie etc) à la fusée qui décolle (ou pas!)...