Aller au contenu

Mettre à jour le firmware

La console met ses quatre puces à jour elle-même — RP1, RP2, RP3 et l'ESP32 — depuis la carte micro-SD et le Wi-Fi, sans PC et sans sortir la carte. Cette page dit comment ça marche, comment on publie une version, et ce qu'il faut faire une fois sur une carte qui n'a jamais eu de partitions.

Ce que voit l'utilisateur

Au démarrage du tableau de bord, Wi-Fi connecté, la console lit le manifeste publié (/api/firmware) et compare son build au plus petit build que ses puces annoncent. S'il est plus grand, une ligne apparaît au menu : V… DISPONIBLE : MISE A JOUR. Dans l'écran MISE A JOUR :

  • les quatre builds installés (ce que chaque puce dit faire tourner : sa bannière de boot, le hello de l'ESP), la version en ligne, celle de la carte ;
  • TELECHARGER : les images vont dans papydeck/firmware/ (<puce>-<build>.bin), chacune vérifiée par son sha256 ; le manifest.json est écrit en dernier — une carte qui a un manifeste est une carte complète ;
  • INSTALLER, après confirmation : ESP32, RP2, RP3, puis RP1, qui redémarre. Deux minutes environ. Chaque étape s'affiche ; une puce déjà au bon build est sautée, ce qui permet de reprendre après une coupure.

Rien n'est automatique au-delà de la vérification : télécharger et installer sont des choix.

Pourquoi ça ne peut pas briquer

Les trois RP2350 ont des partitions A/B et le try before you buy du bootrom (RP2350, datasheet §5.1.17) : la nouvelle image est écrite dans la partition qui ne tourne pas, relue et hachée, puis le bootrom la démarre une seule fois. Elle doit alors s'« acheter » (rom_explicit_buy) après ses autotests — pour RP1 : RP2 et RP3 ont démarré, la vidéo tourne, l'ESP répond, la carte est lisible ; pour RP2/RP3 : c'est RP1 qui juge (bannière à l'essai, puis VSYNC ou console) et qui ordonne l'achat. Tout reset avant l'achat — coupure, plantage, watchdog, 45 s sans autotests — ramène l'ancienne image, sans qu'aucun état persistant ait bougé. L'ESP32 a l'équivalent : deux slots OTA, et son bootloader ne garde la nouvelle image que si elle se déclare valide (à la première commande de RP1).

Le retour arrière a été provoqué au banc : une image qui ne s'achète pas revient sur l'ancienne en 45 s ; une puce qui ne donne pas sa bannière est remise sur son ancienne image par RP1.

Publier une version

Depuis papyDeck_FW, arbre propre :

export IDF_PYTHON_ENV_PATH=$HOME/.espressif/python_env/idf5.3_py3.13_env
source ~/esp/esp-idf/export.sh
python3 scripts/fw-publish.py            # --no-upload pour assembler seulement

Le script construit les variantes TBYB des trois RP2350 (build-tbyb, -DPAPYDECK_TBYB=ON : le bit qui rend l'image « à essayer ») et l'ESP, copie les images sous dist/fw/<puce>-<build>.bin, calcule les sha256, écrit le manifeste et l'envoie au serveur, qui le sert sous GET /api/firmware. Les images d'abord, le manifeste en dernier.

Le manifeste est plat, moins d'un kilo-octet :

{ "format": 1, "version": "v0.5.0-3-gabc1234", "build": 412, "board": "rev8",
  "rp1": { "file": "rp1-412.bin", "sha256": "…", "size": 440176 },
  "rp2": { "file": "rp2-412.bin", "sha256": "…", "size": 31596 },
  "rp3": { "file": "rp3-412.bin", "sha256": "…", "size": 33584 },
  "esp": { "file": "esp-412.bin", "sha256": "…", "size": 1356224 },
  "notes": "", "signature": "" }

build est git rev-list --count HEAD : l'entier monotone que la console compare, et la version d'image que le bootrom compare entre A et B. version est git describe, pour les yeux. signature est réservé (Ed25519 à venir) : aujourd'hui l'intégrité tient au sha256 et au HTTPS, dont l'ESP vérifie le certificat.

Une fois par carte : les tables de partitions

Une carte neuve, ou d'avant début septembre 2026, n'a pas de partitions. La migration se fait au PC, une fois ; ensuite plus jamais. Voir papyDeck_FW/README.md et CONTRIBUTING.md pour les commandes exactes (RP1 par picotool : la table puis le programme à 0x10002000 ; RP2 et RP3 par leur sonde, RP1 mis en BOOTSEL avant ; l'ESP par scripts/esp-flash.py, qui pose la table OTA).

Deux pièges qui ont coûté une soirée : picotool load -p 0 <uf2> ne reloge pas l'image dans la partition, il l'écrit à 0x10000000 sur la table ; et une image qui embarque la table est bootée comme la table, hors du choix A/B.

Le banc

Sans passer par le serveur : scripts/usb-file.py <image> papydeck/firmware/x.bin dépose un fichier sur la carte par l'USB (Ctrl-Y), et sur la console de RP1 Ctrl-P fw:<puce>:<chemin>:<sha256>:<build> joue une étape (esp prend un chemin HTTP). Ctrl-L dit part=A|B et tbyb= pour RP1, b<build> pA|pB [essai] pour les pairs.