CoreBoot 4.12 est là et prend en charge 49 cartes et plus

Après six mois de la dernière version annoncée, la sortie de la nouvelle version de CoreBoot 4.12 a été annoncée dans lequel une série d'améliorations ont été ajoutées, telles qu'un meilleur support, l'élimination du code obsolète et plus encore.

Pour ceux qui ne connaissent pas CoreBoot, sachez que c'est une alternative open source au système d'E / S de base traditionnel (BIOS) qui était déjà sur les PC MS-DOS 80s et le remplaçant par UEFI (Unified Extensible). CoreBoot est également un micrologiciel analogique propriétaire gratuit et est disponible pour une vérification et un audit complets. CoreBoot est utilisé comme micrologiciel de base pour l'initialisation du matériel et la coordination du démarrage.

Y compris l'initialisation de la puce graphique, PCIe, SATA, USB, RS232. Dans le même temps, les composants binaires FSP 2.0 (Intel Firmware Support Package) et le micrologiciel binaire du sous-système Intel ME, qui sont nécessaires pour initialiser et lancer le processeur et le chipset, sont intégrés dans CoreBoot.

Quoi de neuf dans CoreBoot 4.12?

Dans cette nouvelle version de CoreBoot 4.12, 190 développeurs ont participé et préparé 2692 changements dont les plus importants sont les suivants.

Dans Coreboot 4.12 Ajout de la prise en charge de 49 cartes mères, dont la plupart sont utilisés sur les appareils Chrome OS.

Alors que la prise en charge de 51 cartes mères a été supprimée, dont l'élimination est principalement liée à la fin du support pour les plaques obsolètes et travailler pour éliminer les doublons options de conseil similaires. De nombreuses cartes, qui étaient auparavant présentées comme des modèles séparés, sont combinées en ensembles (variante), dans lesquels un module couvre immédiatement toute la famille d'appareils.

Le code pour supporter les plateformes AMDFAM10, VIA VX900 et FSP1.0 (BROADWELL_DE, FSP_BAYTRAIL, RANGELEY), qui ne répondent pas aux nouvelles exigences, a été exclu de la base de code principal. Par exemple, dans FSP1.0, il n'est pas possible d'implémenter l'étape POSTCAR.

Tenant compte du nettoyage des doublons, malgré le fait que formellement le nombre de planches retirées dépasse le nombre de planches ajoutées, la liste des équipements compatibles s'est allongée. La nouvelle version a également apporté de nombreux changements liés à la prise en charge améliorée des appareils fournis avec le micrologiciel OEM, y compris ceux basés sur Coreboot.

En plus de continuer à nettoyer la base de code, notes de volume sur les licences dans les en-têtes de fichiers ont été remplacés par des identifiants SPDX courts. Les noms de tous les auteurs ayant participé au développement sont rassemblés dans le fichier AUTEURS. Les fichiers d'en-tête ont été révisés pour minimiser le code couvert lors de l'assemblage de chaque unité d'assemblage.

Le contrôleur de lecteur flash SMMSTORE est reconnu comme prêt pour une utilisation généralisée. Le contrôleur utilise le mode SMM (System Management Mode) pour écrire, lire et effacer des zones de la mémoire flash, et peut être utilisé dans les composants du système d'exploitation ou du micrologiciel pour organiser le stockage permanent des paramètres, sans avoir besoin de mettre en œuvre un contrôleur spécifique à chaque plate-forme.

Les outils de test unitaire ont été étendus, qui s'intègrent au nouveau système de construction et se reportent à l'utilisation du framework Cmocka. Un répertoire tests / séparé a été créé dans l'arborescence des sources pour les tests unitaires.

Les composants désormais requis pour les systèmes x86 incluent RELOCATABLE_RAMSTAGE, POSTCAR_STAGE et C_ENVIRONMENT_BOOTBLOCK. RELOCATABLE_RAMSTAGE qui permettent à ramstage d'être déplacé vers une autre zone de mémoire au moment de l'exécution qui ne chevauche pas le système d'exploitation ou les pilotes de charge utile (le déplacement est nécessaire car ramstage est mis en cache dans CBMEM pour un chargement plus rapide lors de la sortie du mode veille).

POSTCAR_STAGE utilisé pour passer de CAR (Cache-As-Ram) à l'exécution de code à partir de DRAM. C_ENVIRONNEMENT_BOOTBLOCK permet d'utiliser le bootblock compilé en utilisant GCC normal, au lieu d'un compilateur romcc spécialisé.

Obtenez CoreBoot

Enfin, pour ceux qui souhaitent pouvoir obtenir cette nouvelle version de CoreBoot ils peuvent le faire à partir de leur section de téléchargement, qui peut être trouvé sur le site officiel du projet.

En plus de cela, ils pourront trouver de la documentation et plus d'informations sur le projet.

Le lien est le suivant.


Le contenu de l'article adhère à nos principes de éthique éditoriale. Pour signaler une erreur, cliquez sur c'est par ici !.

Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.