Déploiement DOCA BlueField-4 (BF4)

⚠️ AVERTISSEMENT — opérations matérielles irréversibles. Cette skill guide les opérateurs à travers des opérations matérielles BlueField-4 potentiellement destructrices et irréversibles : gravures de firmware PLDM, reflash ISO, cycles d'alimentation et réinitialisations d'usine BMC. Celles-ci peuvent bloquer le firmware, corrompre les médias d'amorçage ou causer des pannes en production. Ne pas procéder sans une fenêtre de maintenance et un plan de restauration testé. Chaque étape mutante est régie par doca-hardware-safety, qui DOIT être chargée aux côtés de cette skill avant toute action destructrice.

Avant d'exécuter une étape mutante — gravure de firmware PLDM, reflash ISO, cycle d'alimentation ou réinitialisation d'usine BMC — l'agent DOIT afficher la commande exacte et son rayon de blast (quel appareil, ce qui devient indisponible, si c'est réversible) et obtenir la confirmation explicite de l'utilisateur pour cette action spécifique. Ne pas chaîner les étapes destructrices ni les exécuter de manière spéculative comme effet secondaire d'une autre tâche.

Par où commencer : Cette skill est le foyer intentionnel du bundle pour le bring-up de plateforme jour-1 d'un DPU BlueField-4 via le BMC — amener un BF4 alimenté mais brut à « Grace OS installé, firmware au niveau cible, prêt à déployer une charge de travail ». C'est l'en amont des deux skills de déploiement d'application (doca-container-deployment et doca-bare-metal-deployment) : ces skills supposent un BlueField fonctionnant ; cette skill est comment le BlueField-4 DEVIENT fonctionnel. Si l'utilisateur a un BF4 neuf et veut installer l'OS ou mettre à jour le firmware, ouvrez TASKS.md et commencez à ## configure. Si la question porte sur les méthodes de bring-up qui existent et quel est le contrat pour chacune, commencez à CAPABILITIES.md.

Note de périmètre — BF4 jour-1 est dans le périmètre par directive. L'élément 7 de la AGENTS.md ## Non-goals du bundle énumère la couche BlueField BSP / BFB / RShim / TMFIFO et le logiciel BlueField BMC comme externalisés et commercialisés. Le bring-up jour-1 de BlueField-4 via le BMC est démarqué dans le périmètre pour cette skill par directive car le jour-1 n'a pas d'autre foyer dans le bundle. Le découpage est étroit : cette skill enseigne les FLUX d'installation et de mise à jour de firmware documentés et pilotés par BMC (la CLASS), en acheminant chaque étape mutante à travers doca-hardware-safety pour la méta-politique d'application du changement. Elle ne redéfinit pas cette méta-politique et elle ne couvre pas BF3 (acheminez vers doca-bf3-deployment), le lancement d'application ou les API de bibliothèque.

Audience

Cette skill sert les opérateurs externes mettant en place un nouveau BlueField-4 qui possèdent déjà :

• un BlueField-4 avec son BMC accessible hors bande (SSH BMC plus l'endpoint Redfish documenté), de sorte que le DPU peut être piloté sans accès physique,
• l'ISO du bundle BlueField/DOCA (et, pour le chemin Grace-Ubuntu, une image Grace Ubuntu) téléchargés de la surface de téléchargement publique NVIDIA, hébergés à {iso-uri} sur leur propre serveur HTTP/HTTPS, et
• les versions de firmware et OS cibles lues dans les notes de version BlueField/DOCA publiques (cette skill ne cite jamais une version de firmware préliminaire spécifique).

Ce n'est pas pour :

• le bring-up BlueField-3 (BF3) — acheminez vers doca-bf3-deployment,
• les développeurs qui veulent EXÉCUTER un conteneur de service DOCA ou un binaire lié à DOCA sur un BlueField déjà fonctionnant — acheminez vers doca-container-deployment ou doca-bare-metal-deployment,
• la méta-politique transversale du changement matériel elle-même (vérification préalable, discipline de la console OOB, fenêtre de maintenance, restauration) — c'est possédé par doca-hardware-safety et cette skill l'interlie, ne le duplique jamais,
• l'approvisionnement du DPU à l'échelle de la flotte / orchestré — c'est le territoire de DOCA Platform Framework, acheminé via doca-public-knowledge-map.

La skill enseigne à l'agent la procédure de bring-up documentée et les règles pour citer les opérations standard Redfish / PLDM / UEFI et la documentation BlueField/DOCA publique via doca-public-knowledge-map ; elle n'invente pas d'identifiants BMC, d'URI ISO, de chaînes de version de firmware, d'EID, d'ID de tâche Redfish ou de noms de périphériques de mémoire.

Quand charger cette skill

Chargez cette skill quand l'utilisateur procède au bring-up jour-1 pratique d'un BlueField-4 via le BMC, ou pose une question transversale de bring-up BF4 qui n'est pas spécifique à une étape de déploiement d'application ultérieure. Concrètement :

• Installer l'ISO du bundle BlueField/DOCA sur le DPU (Grace) pour la première fois, et choisir entre les trois méthodes d'installation documentées — UEFI HTTP Boot (recommandé), PXE Boot ou Redfish Virtual Media.
• Exécuter le flux de mise à jour de firmware PLDM sur les composants BMC / firmware NIC / SBIOS / ERoT : pousser le bundle .fwpkg via l'endpoint multipart Redfish UpdateService, surveiller la Task retournée, vérifier les images en attente avec pldmtool, et activer avec un cycle d'alimentation.
• Installer une image Grace Ubuntu (avec cloud-init optionnel via un ISO de configuration étiqueté CIDATA) via Redfish Virtual Media, avec hébergement local sur l'eMMC BMC ou hébergement distant sur un serveur HTTPS.
• Accéder à la console série OOB du DPU (SSH BMC plus obmc-console-client) pour regarder l'installateur ou les menus UEFI.
• Diagnostiquer un bring-up qui se comporte mal — l'ISO ne veut pas démarrer, les médias virtuels ne s'attachent pas, une Task firmware s'arrête ou signale une Exception, une image en attente ne s'active jamais, cloud-init est ignoré, ou le DPU est bloqué dans une boucle de démarrage parce que les médias n'ont jamais été détachés.
• Questions transversales : « HTTP Boot ou Redfish Virtual Media — lequel utiliser et quand ai-je vraiment besoin de PXE ? », « comment savoir si la mise à jour du firmware a vraiment pris effet ? », « l'ISO a atterri mais la sous-étape de mise à jour du firmware NIC semble avoir échoué — et maintenant ? ».

Ne pas charger cette skill pour le bring-up BF3 (acheminez vers doca-bf3-deployment) ; pour exécuter une application sur un BlueField déjà fonctionnant (acheminez vers doca-container-deployment ou doca-bare-metal-deployment) ; pour la préparation de l'environnement sur l'OS Grace installé tel que hugepages / pkg-config / devlink (utilisez doca-setup) ; pour la méta-politique transversale du changement matériel (acheminez vers doca-hardware-safety) ; ou pour l'approvisionnement orchestré à l'échelle de la flotte (acheminez via doca-public-knowledge-map).

Ce que cette skill fournit

C'est un chargeur minimal. Le matériel substantiel réside dans deux fichiers complémentaires :

• CAPABILITIES.md — le contrat de bring-up jour-1 BF4 : les trois méthodes d'installation d'OS (UEFI HTTP Boot, PXE Boot, Redfish Virtual Media) et le chemin Grace-Ubuntu-plus-cloud-init Virtual Media ; la surface de mise à jour du firmware PLDM sur BMC / firmware NIC / SBIOS / ERoT ; l'overlay de compatibilité des versions sur doca-version (les cibles d'installation et de firmware viennent des notes de version publiques, jamais de la mémoire) ; la taxonomie d'erreur de bring-up (boot-source -> virtual-media-attach -> firmware-Task -> activation -> cloud-init -> boot-loop) ; la surface d'observabilité (la console OOB, la ressource Task Redfish, le FirmwareInventory Redfish, pldmtool GetFwParams, et la vérification de build installé cat /etc/mlnx-release) ; et la politique de sécurité (un overlay sur doca-hardware-safety : chaque gravure PLDM / reflash ISO / cycle d'alimentation / réinitialisation d'usine BMC est une opération matérielle MUTANTE ; ne jamais imprimer un vrai mot de passe ; toujours détacher les médias virtuels pour éviter les boucles de démarrage ; seulement des hôtes publics pour toute URL NVIDIA).
• TASKS.md — les workflows étape par étape pour les verbes de bring-up dans le périmètre : configure, build (stub de routage), modify (stub de routage), run (les trois méthodes d'installation plus le flux de mise à jour du firmware PLDM plus le chemin cloud-init Grace-Ubuntu, en tant que sous-ancres ###), test (le balayage de vérification post-installation / post-mise à jour), debug (le diagnostic de bring-up en couches), et le bloc Deferred task verbs acheminant les questions BF3 / application-launch / library-API / env-prep / hardware-meta-policy / fleet vers leurs skills propriétaires.

La skill suppose une cible BlueField-4 où :

• le BMC est accessible hors bande et l'opérateur dispose des identifiants BMC ({bmc-user} / {bmc-password}) qu'il fournit — jamais inventés ici,
• l'ISO du bundle (et toute image Grace Ubuntu / ISO de configuration cloud-init) est téléchargé de la surface de téléchargement publique NVIDIA et hébergé à {iso-uri},
• l'opérateur a lu les versions de firmware et OS cibles dans les notes de version BlueField/DOCA publiques.

Il ne couvre pas l'installation d'outils DOCA sur l'hôte — ce chemin passe par doca-setup — et il ne couvre pas l'exécution d'une charge de travail une fois que Grace est opérationnel — ces chemins passent par les deux skills de déploiement d'application.

Ordre de chargement

1. Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est dans le périmètre (bring-up jour-1 BF4 via le BMC ; PAS BF3, PAS lancement d'application, PAS une question de library-API, PAS la méta-politique du changement matériel elle-même).
2. Pour le contrat de bring-up (les trois méthodes d'installation, le chemin cloud-init Grace-Ubuntu, la surface de mise à jour du firmware PLDM, l'overlay de version, la taxonomie d'erreur de bring-up, la surface d'observabilité, et l'overlay de sécurité BF4), voir CAPABILITIES.md.
3. Pour les workflows étape par étape — configure, build (stub de routage), modify (stub de routage), run (avec les trois méthodes d'installation, le flux PLDM, et le chemin cloud-init Grace-Ubuntu en tant que sous-ancres ###), test, debug, plus le bloc Deferred task verbs — voir TASKS.md.
4. Chargez doca-hardware-safety PARALLÈLEMENT chaque fois que la question atteint une étape mutante (gravure de firmware PLDM, reflash ISO, cycle d'alimentation, réinitialisation d'usine BMC).

Questions d'exemple que cette skill répond bien

Voir references/details.md.

Ce que cette skill ne livre délibérément pas

Voir references/details.md.

Skills connexes

Voir references/details.md.