Snagboot: Recovery par DFU (Device Firmware Update)

1. Introduction

Lors de la fabrication de cartes électroniques "maison" conçues spécifiquement pour les besoins d'un projet, il est généralement nécessaire de procéder à une installation d'usine des différents logiciels (aussi appelée "flashage"). Cela consiste à installer une image (généralement une image Linux "maison" générée par Yocto ou Buildroot), des firmwares et un bootloader, ainsi que des données spécifiques à une unité (numéro de série, révision, adresses MAC).

Pour cela, l'équipe chargée de la production des cartes doit avoir à sa disposition le matériel nécessaire ainsi qu'une procédure précise décrivant les opérations de "flashage". Il faut donc un moyen de démarrer une carte électronique "neuve" qui n'a jamais été utilisée (en dehors d'éventuels tests électroniques pour la vérification des alimentations, etc.).

À la mise sous tension, les SoC (NXP, TI…) exécutent un ROM code capable de démarrer sur différents périphériques selon la configuration matérielle dite "bootmode", qui est sélectionnée directement sur certaines broches du SoC.

Pour les besoins de cet article, nous allons prendre comme exemple la carte SK-TDA4VM de Texas Instruments, disposant d'un SoC J721e alias TDA4VM, mais dépourvue d'eMMC. Nous utiliserons donc la carte SD comme support pour cet article.

Il va de soi qu'il serait possible de flasher directement la carte SD depuis Linux ; mais l'objectif ici est de reproduire, sur ce support, les étapes qu'il faudrait mener pour flasher une eMMC présente sur la carte électronique.

D'après le tableau suivant, ce SoC est capable de démarrer sur plus d'une dizaine de périphériques différents.

Sur la carte SK-TDA4VM, la sélection du bootmode est grandement facilitée par la présence de switchs permettant de choisir une méthode de boot parmi sept.

Supposons que nous souhaitions une connectique simple et rapide entre le PC de flashage et la carte électronique: le choix se porte naturellement sur l'interface USB Type-C.

(Note: DFP signifie "Downstream Facing Peripheral", venant de la terminologie USB Type-C.)

Sur le SoC J721e, le démarrage par USB supporte uniquement le boot par protocole DFU (Device Firmware Update):

Avec le switch SW1 positionné en position 010, nous pouvons brancher un câble USB-A/USB-C entre le PC de flashage et la carte.

Lors de la mise sous tension de la carte, nous devons maintenant détecter un nouveau périphérique sur le PC de flashage:

$ lsusb
Bus 003 Device 031: ID 0451:6163 Texas Instruments, Inc. J721E DFU

Pour l'instant, le SoC n'a utilisé que son ROM code et attend de recevoir les premiers échanges DFU pour recevoir un premier bootloader. Le ROM code a initialisé de son propre chef l'interface USB sélectionnée par le bootmode en mode USB device. Il ne s'agit pas du mode USB OTG, car il n'y a aucune négociation avec le PC hôte. Le ROM code suppose aussi que l'alimentation VBUS est présente sur le bus USB. Il est donc possible de connecter le SoC à un port USB d'un PC.

À partir de là, nous souhaitons parvenir à charger une image Linux embarqué sur un support de stockage persistant (eMMC, NOR, SSD, ou même carte SD) dans un temps raisonnable — de l'ordre de quelques minutes. Sur une carte plus complète, il serait aussi nécessaire de flasher d'autres mémoires flash, pouvant par exemple contenir un bitstream FPGA.

La carte SK-TDA4VM ne disposant pas de mémoire eMMC, nous allons donc expérimenter le flashage de l'image Linux embarqué sur la carte SD comme s'il s'agissait d'une eMMC.

2. Chargement par DFU

La documentation du SDK du SoC J721e décrit la méthode de chargement du bootloader en ligne de commande (étape par étape) avec l'outil dfu-util. Il est indispensable d'ajouter le lien série UART de la console de debug afin d'observer le log généré par le SoC et d'accéder au shell d'U-Boot une fois le bootloader complètement chargé.

Le démarrage complexe du SoC J721e nécessite le chargement de plusieurs firmwares et bootloaders, car il faut initialiser le "Security Enclave Boot Processor" au travers d'un protocole spécifique "TIFS/DMSC". Pour cela, un premier core ARM R5F est utilisé avant le démarrage du core ARM AArch64: https://docs.u-boot.org/en/latest/board/ti/j721e_evm.html#boot-flow

Le détail des fichiers utilisés est précisé dans la documentation U-Boot:

https://docs.u-boot.org/en/latest/board/ti/j721e_evm.html#image-formats

Note: le fichier binaire sysfw.itb est spécifique à certains modèles de SoC TI utilisant un flux de boot dit "Split binary" (J721e et AM65): https://docs.u-boot.org/en/latest/board/ti/k3.html#boot-flow-variations

Essayons:

$ dfu-util -l
dfu-util 0.11
Found DFU: [0451:6163] ver=0200, devnum=14, cfg=1, intf=0, path="3-3.2", alt=1, name="SocId", serial="01.00.00.00"
Found DFU: [0451:6163] ver=0200, devnum=14, cfg=1, intf=0, path="3-3.2", alt=0, name="bootloader", serial="01.00.00.00"

$ dfu-util -R -a bootloader -D tiboot3.bin
dfu-util 0.11
dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0451:6163
Device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
Device returned transfer size 512
Copying data from PC to DFU device
Download    [=========================] 100%       257093 bytes
Download done.
DFU state(6) = dfuMANIFEST-SYNC, status(0) = No error condition is present
DFU state(2) = dfuIDLE, status(0) = No error condition is present
Done!
dfu-util: can't detach
Resetting USB to switch back to Run-Time mode

Pour l'instant, il n'y a toujours rien sur la console.

Si nous parvenons toujours à détecter un device DFU 0451:6163, c'est que tout s'est bien passé:

$ dfu-util -l
dfu-util 0.11

Found DFU: [0451:6163] ver=7ea4, devnum=15, cfg=1, intf=0, path="3-3.2", alt=0, name="sysfw.itb", serial="UNKNOWN"

Si le device disparaît, cela signifie que le bootloader ne configure pas l'interface USB en mode "peripheral".

Notons que le nom de l'interface DFU est passé de "bootloader" à "sysfw.itb": cela signifie qu'il faut envoyer ce fichier. Lors de la rédaction de cet article, j'ai remarqué qu'il y avait certainement un délai à respecter pour exécuter le transfert suivant, sinon la commande échoue car le device n'est plus détecté.

$ dfu-util -R -a sysfw.itb -D sysfw.itb
dfu-util 0.11
dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0451:6163
Device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
Device returned transfer size 4096
Copying data from PC to DFU device
Download    [=========================] 100%       268978 bytes
Download done.
DFU state(7) = dfuMANIFEST, status(0) = No error condition is present
DFU state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to Run-Time mode

Cette fois-ci, il se passe des choses dans la console de debug:

U-Boot SPL 2026.04 (Apr 22 2026 - 23:07:15 +0200)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.8--v11.02.08 (Fancy Rat)')
Trying to boot from DFU

Le premier étage du bootloader SPL vient de démarrer.

Lorsque tout se passe bien, d'autres devices DFU sont détectés: "tispl.bin" et "u-boot.img".

$ dfu-util -l
dfu-util 0.11
 
Found DFU: [0451:6163] ver=7ea4, devnum=20, cfg=1, intf=0, path="3-3.2", alt=1, name="u-boot.img", serial="UNKNOWN"
Found DFU: [0451:6163] ver=7ea4, devnum=20, cfg=1, intf=0, path="3-3.2", alt=0, name="tispl.bin", serial="UNKNOWN"

Pour l'instant, il est trop tôt pour transférer le bootloader AArch64 "u-boot.img": il faut envoyer "tispl.bin" en premier.

$ dfu-util -R -a tispl.bin -D tispl.bin
dfu-util 0.11
 
dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0451:6163
Device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
Device returned transfer size 4096
Copying data from PC to DFU device
Download    [=========================] 100%      1294663 bytes
Download done.
DFU state(7) = dfuMANIFEST, status(0) = No error condition is present
DFU state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to Run-Time mode

Le chargement de ce nouveau binaire poursuit la procédure de boot de ce SoC.

La console de debug affiche maintenant beaucoup de logs, car la trust zone ARM est mise en place avec l'exécution d'ARM Trusted Firmware et d'OP-TEE ainsi qu'un firmware DM (Device Management), spécifique aux SoC TI, est ensuite démarré sur le core AArch64.

Trying to boot from DFU
################################################################DOWNLOAD ... OK
Ctrl+C to exit ...
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Loading Environment from nowhere... OK
init_env from device 18 not supported!
Starting ATF on ARM64 core...
 
NOTICE:  BL31: v2.13.0(release):v2.13.0-259-ge0c4d3903b-dirty
NOTICE:  BL31: Built : 07:01:36, Jul  1 2025
I/TC: 
I/TC: OP-TEE version: 4.7.0-47-ga9690ae39 (gcc version 12.3.1 20230626 (Arm GNU Toolchain 12.3.Rel1 (Build arm-12.35))) #1 Thu Aug  7 15:25:10 UTC 2025 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.8--v11.02.08 (Fancy Rat)')
I/TC: Activated SA2UL device
I/TC: Fixing SA2UL firewall owner for GP device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: EIP76D TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: HUK Initialized
I/TC: Primary CPU switching to normal world boot
 
U-Boot SPL 2026.04-00822-gb935eacb653e (Apr 22 2026 - 23:07:33 +0200)
Unable to shutdown MCU R5 core 1, -22
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.8--v11.02.08 (Fancy Rat)')
DM ABI: 3.0 (firmware ver 0x000b 'PSDK.11.02.00.07--v11.02.07' patch_ver: 7)
Trying to boot from DFU
cdns-usb3-peripheral usb@6000000: Couldn't get USB3 PHY:  -19
cdns-usb3-peripheral usb@6000000: Couldn't get USB3 PHY:  -19
No USB device found
udc_device_get_by_index failed
Error: -22
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

À ce stade, la procédure de démarrage manuel, déjà assez fastidieuse, se termine parfois par un échec. Il faut reprendre tout depuis le début.

Lorsque cela se passe bien, nous obtenons les logs du bootloader SPL sans erreur (on ignore les logs sur l'interface USB):

U-Boot SPL 2026.04-00822-gb935eacb653e (Apr 24 2026 - 22:29:53 +0200)
Unable to shutdown MCU R5 core 1, -22
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.8--v11.02.08 (Fancy Rat)')
DM ABI: 3.0 (firmware ver 0x000b 'PSDK.11.02.00.07--v11.02.07' patch_ver: 7)
Trying to boot from DFU
cdns-usb3-peripheral usb@6000000: Couldn't get USB3 PHY:  -19
cdns-usb3-peripheral usb@6000000: Couldn't get USB3 PHY:  -19
No USB device found
udc_device_get_by_index failed
Skipping authentication on GP device
Skipping authentication on GP device

Nous pouvons enfin envoyer le dernier binaire:

$ dfu-util -R -a uboot.img -D uboot.img

Et ainsi voir apparaître le démarrage du bootloader sur la console, avec une invite de commande:

U-Boot 2026.04-00822-gb935eacb653e (Apr 24 2026 - 22:29:53 +0200)
 
SoC:   J721E SR1.1 GP
Model: Texas Instruments J721E SK
Board: J721EX-SK rev A
DRAM:  2 GiB (total 4 GiB)
optee optee: OP-TEE: revision 4.7 (a9690ae39995af36)
I/TC: Reserved shared memory is enabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
Core:  141 devices, 38 uclasses, devicetree: separate
Flash: 0 Bytes
MMC:   mmc@4fb0000: 1
Loading Environment from nowhere... OK
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   am65_cpsw_nuss ethernet@46000000: K3 CPSW: nuss_ver: 0x6BA00101 cpsw_ver: 0x6BA80100 ale_ver: 0x00293904 Ports:1
eth0: ethernet@46000000port@1
Hit any key to stop autoboot: 0

En pratique, le chargement du bootloader "fonctionne" lorsque l'on réalise l'opération à la main, ce qui introduit naturellement un délai entre chaque commande. Mais cela devient plus délicat si l'on exécute ces mêmes étapes depuis un script: il faut respecter une certaine temporisation pour laisser aux firmwares et au bootloader le temps de démarrer, et même envoyer deux fois de suite la dernière étape pour démarrer complètement U-Boot.

La réalisation de ces étapes permet de vérifier que le bootloader chargé par DFU fonctionne correctement et permet de prendre la main sur la carte électronique. Il serait plus pratique de réaliser ces opérations en une seule commande.

3. Snagboot

Depuis 2023, l'outil Snagboot est régulièrement cité comme une solution générique pour flasher les différents SoC rencontrés sur les systèmes embarqués sous Linux.

Il est régulièrement évoqué lors de conférences comme Capitole du Libre 2023, OSSEU 2025 et, dernièrement, le FOSDEM 2026.

Snagboot est décrit comme étant :

“vendor-agnostic, open-source and developer-friendly recovery and reflashing tool".

Snagboot se décline en trois outils (snagrecover, snagflash et snagfactory).

Pour l'instant, nous allons découvrir snagrecover, car il automatise la séquence de "recovery" que nous venons de voir avec dfu-util.

Le principe est de démarrer la commande snagrecover en précisant le type de SoC utilisé et la liste des différents binaires à utiliser:

snagrecover -s tda4vm -f templates/j721e-evm.yaml

Le fichier j721e-evm.yaml contient la liste des différents fichiers à charger pour cette plateforme:

# templates/j721e-evm.yaml 
tiboot3:
  path: tiboot3.bin
sysfw:
  path: sysfw.itb
tispl:
  path: tispl.bin
u-boot:
  path: u-boot.img

Le support pour le SoC J721e (TDA4VM) a été ajouté en avril 2026 (https://github.com/bootlin/snagboot/pull/84) après la release v2.6.1, notre carte SK-TDA4VM nécessite donc (pour le moment) d'installer Snagboot depuis les sources.

La commande snagrecover permet de:

• détecter la présence du SoC sur l'interface USB (0451:6163)
• séquencer les échanges avec le SoC pour flasher les différents binaire

La commande ci-dessus produit le log suivant:

snagrecover -s tda4vm -f templates/j721e-evm.yaml

2026-04-20 10:07:47,352 [INFO] SoC model tda4vm is an alias for j721e
2026-04-20 10:07:47,367 [INFO] Starting recovery of j721e board

2026-04-20 10:07:47,369 [INFO] Installing firmware tiboot3
2026-04-20 10:07:47,369 [INFO] Searching for partition id...
2026-04-20 10:07:47,370 [INFO] Found DFU Functional descriptor: wTransferSize = 512
2026-04-20 10:07:47,370 [INFO] Downloading file...
2026-04-20 10:07:48,127 [INFO] Done manifesting firmware
2026-04-20 10:07:48,127 [INFO] Done
2026-04-20 10:07:48,127 [INFO] Done installing firmware tiboot3

2026-04-20 10:07:49,128 [INFO] Installing firmware sysfw
2026-04-20 10:07:49,128 [INFO] Searching for partition id...
2026-04-20 10:07:49,129 [INFO] Found DFU Functional descriptor: wTransferSize = 4096
2026-04-20 10:07:49,129 [INFO] Downloading file...
2026-04-20 10:07:50,472 [INFO] Done manifesting firmware
2026-04-20 10:07:50,473 [INFO] Done
2026-04-20 10:07:50,473 [INFO] Sending detach command...
2026-04-20 10:07:50,474 [INFO] Sending DFU_DETACH...
2026-04-20 10:07:50,475 [INFO] Done installing firmware sysfw

2026-04-20 10:07:51,477 [INFO] Installing firmware tispl
2026-04-20 10:07:51,477 [INFO] Searching for partition id...
2026-04-20 10:07:51,478 [INFO] Found DFU Functional descriptor: wTransferSize = 4096
2026-04-20 10:07:51,478 [INFO] Downloading file...
2026-04-20 10:07:53,368 [INFO] Done manifesting firmware
2026-04-20 10:07:53,368 [INFO] Done
2026-04-20 10:07:53,368 [INFO] Done installing firmware tispl

2026-04-20 10:07:53,371 [INFO] Installing firmware u-boot
2026-04-20 10:07:53,371 [INFO] Searching for partition id...
2026-04-20 10:07:53,372 [INFO] Found DFU Functional descriptor: wTransferSize = 4096
2026-04-20 10:07:53,372 [INFO] Downloading file...
2026-04-20 10:07:55,529 [INFO] Done manifesting firmware
2026-04-20 10:07:55,529 [INFO] Done
2026-04-20 10:07:55,529 [INFO] Sending detach command...
2026-04-20 10:07:55,531 [INFO] Sending DFU_DETACH...
2026-04-20 10:07:55,531 [INFO] Done installing firmware u-boot

2026-04-20 10:07:57,533 [INFO] Installing firmware u-boot
2026-04-20 10:07:57,533 [INFO] Searching for partition id...
2026-04-20 10:07:57,533 [INFO] Found DFU Functional descriptor: wTransferSize = 4096
2026-04-20 10:07:57,533 [INFO] Downloading file...
2026-04-20 10:07:59,804 [INFO] Done manifesting firmware
2026-04-20 10:07:59,804 [INFO] Done
2026-04-20 10:07:59,804 [INFO] Sending detach command...
2026-04-20 10:07:59,805 [INFO] Sending DFU_DETACH...
2026-04-20 10:07:59,805 [INFO] Done installing firmware u-boot

2026-04-20 10:07:59,805 [INFO] Done recovering j721e board

Nous constatons, grâce à l'horodatage, qu'il y a bien une temporisation (1 seconde) entre le chargement de chaque firmware, nous constatons également que snagrecover charge deux fois de suite le bootloader U-Boot: cela correspond effectivement au comportement précédemment observé avec dfu-util.

Nous retrouvons l'explication de ce comportment un peu inattendu dans les source des snagboot : https://github.com/bootlin/snagboot/blob/3740b6f7d0cb0a2ddea5ac096e196afcec3cf52c/src/snagrecover/recoveries/am6x.py#L43

# For newer versions of U-Boot, only SPL will run from the
# previous commands and the U-Boot firmware should be sent
# one more time.

L'opération de recovery est terminée: elle a duré plus d'une dizaine de secondes (12 s).

Comparé à un démarrage "classique" depuis une mémoire eMMC ou une carte SD dès la mise sous tension de la carte, ce moyen de démarrage est plus long, car les différentes étapes ne s'enchaînent pas automatiquement, ce qui introduit des délais entre chacune d'elles.

Snagrecover peut par exemple remplacer une carte SD en phase de développement, si le prototype ne dispose pas de connecteur SD (pour simplifier le routage du PCB ou faire des économies sur la BOM). Mais cette solution aura forcément un impact négatif dès qu'il faudra investiguer un problème sur le BSP (U-Boot/kernel), un cas qui demande de redémarrer souvent.

U-Boot est maintenant accessible depuis l'interface série en console (un utilisateur peut reprendre la main sur U-Boot via la console série). Mais si rien ne se passe, le bootloader va essayer d'exécuter la commande "bootcmd" au bout de quelques secondes et tenter de démarrer s'il trouve un disque déjà flashé. Or, s'il s'agit d'une nouvelle carte, aucune image ne sera disponible pour démarrer.

Pour la carte SK-TDA4VM, "bootcmd" exécute par défaut: run envboot; bootflow scan -lb, ce qui permet de booter normalement lorsqu'une image est trouvée.

Afin d'effectuer le flashage des mémoires présent sur la carte électronique, il est nécessaire de modifier la commande de boot par défaut, afin de donner accès aux périphériques de stockage à un outil de flashage, par l'intermédiaire du driver gadget USB présent dans U-Boot.

Le projet Snagboot propose l'outil Snagflash, destiné à réaliser les étapes de flashage.

4. Snagflash

Snagflash est l'outil dédié au flashage des périphériques de stockage. Pour fonctionner, il est nécessaire qu'un bootloader soit déjà chargé sur le SoC (généralement par snagrecover).

Pour flasher, Snagflash propose trois modes (protocoles) différents à choisir selon les besoins d'un projet. Nous allons essayer de les comparer.

Chaque mode: DFU, Fastboot ou UMS, doit être activé (manuellement ou automatiquement) pour faire fonctionner Snagflash ; il faut pour cela pouvoir adapter la configuration d'U-Boot.

4.1 Le mode DFU

Le mode DFU est particulièrement intéressant, car il permet d'exposer plusieurs périphériques de stockage en même temps. Mais cela implique au préalable d'avoir récupéré la taille de ces périphériques de stockage.

Afin de retrouver la taille de la carte SD, nous allons essayer de la lire jusqu'à la toute dernière adresse:

Depuis U-boot:

=> mmc dev 1
switch to partitions #0, OK
mmc1 is current device

=> mmcinfo  
Device: mmc@4fb0000
Manufacturer ID: ff
OEM: 5678
Name: MCARD
Bus Speed: 100000000
Mode: UHS SDR50 (100MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 29.1 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes

L'outil mmcinfo n'affiche pas la taille de la carte SD dans un format directement utilisable par la suite, mais il est possible de l'obtenir en essayant de lire un block a une addresse trés élevée en dehors de la carte SD:

=> mmc read ${loadaddr} 0x7fffffff 1
MMC read: dev # 1, block # 2147483647, count 1 ... MMC: block number 0x80000000 exceeds max(0x3a3d000)
0 blocks read: ERROR

Note: méthode issue de la documentation Toradex: https://developer.toradex.com/software/linux-resources/linux-features/how-to-erase-the-emmc-flash-memory-linux/

Il est également possible d'obtenir cette valeur depuis un système Linux:

root@sk-tda4vm:/sys/block/mmcblk1# cat size 
61067264 soit 0x3a3d000

Nous pouvons maintenant utiliser cette valeur comme taille afin d'accéder à notre carte SD par DFU au format "raw":

=> env set dfu_alt_info "mmc 1=emmc_raw raw 0 0x3a3d000"

=> dfu list
DFU alt settings list:
dev: eMMC alt: 0 name: emmc_raw layout: RAW_ADDR

=> dfu 0      
cdns-usb3-peripheral usb@6000000: DRD version v1 (ID: 0004024e, rev: 00000200)
cdns-usb3-peripheral usb@6000000: Initialized  ep0 support:  
…

Nous pouvons vérifier que la carte SD est bien détectée par le PC de flashage:

dfu-util -l
dfu-util 0.11

Found DFU: [0451:6163] ver=7ea4, devnum=55, cfg=1, intf=0, path="3-3.2", alt=0, name="emmc_raw", serial="0000000000000441"

La syntaxe à utiliser pour configurer le mode DFU dans U-Boot au moyen de la variable d'environnement "dfu_alt_info" est documentée ici:

https://docs.u-boot.org/en/v2026.04/usage/dfu.html#environment-variables

Voici une version plus complète, exposant la mémoire flash SPI NOR présente sur la carte SK-TDA4VM:

=> mtd list
jedec_spi_nor flash@0: non-uniform erase sector maps are not supported yet.
SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB
mtd: partition "ospi.phypattern" is out of reach -- disabled
List of MTD devices:
* nor0
  - device: flash@0
  - parent: spi@47040000
  - driver: jedec_spi_nor
  - path: /bus@100000/bus@28380000/bus@47000000/spi@47040000/flash@0
  - type: NOR flash
  - block size: 0x40000 bytes
  - min I/O: 0x10 bytes
  - 0x000000000000-0x000004000000 : "nor0"
          - 0x000000000000-0x000000080000 : "hbmc.tiboot3"
          - 0x000000080000-0x000000280000 : "hbmc.tispl"
          - 0x000000280000-0x000000680000 : "hbmc.u-boot"
          - 0x000000680000-0x0000006c0000 : "hbmc.env"
          - 0x0000006c0000-0x0000007c0000 : "hbmc.sysfw"
          - 0x000000800000-0x000004000000 : "hbmc.rootfs"

Cette fois-ci, la taille de la mémoire flash est affichée et directement utilisable pour configurer le mode DFU:

=> env set dfu_alt_info "mtd nor0=nor_raw raw 0x0 0x400000&mmc 1=emmc_raw raw 0 0x3a3d000"

=> dfu 0 list
DFU alt settings list:
dev: MTD alt: 0 name: nor_raw layout: RAW_ADDR
dev: eMMC alt: 1 name: emmc_raw layout: RAW_ADDR

Cette fois-ci, un deuxième device est accessible et prêt au flashage.

dfu-util -l
dfu-util 0.11

Found DFU: [0451:6163] ver=7ea4, devnum=56, cfg=1, intf=0, path="3-3.2", alt=1, name="emmc_raw", serial="0000000000000441"
Found DFU: [0451:6163] ver=7ea4, devnum=56, cfg=1, intf=0, path="3-3.2", alt=0, name="nor_raw", serial="0000000000000441"

Il est même possible d'exposer certaines zones mémoire en RAM pouvant servir à charger un kernel et son devicetree.

Tout d'abord, récupérons les adresses où sont chargés le kernel et le devicetree:

=> printenv
…
loadaddr=0x82000000
fdtaddr=0x88000000
…
loadfdt=load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/dtb/${fdtfile}
loadimage=load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/${bootfile}

Il faut s'assurer de laisser suffisamment d'espace en RAM pour stocker les binaires.

=> env set dfu_alt_info "mtd nor0=nor_raw raw 0x0 0x400000&mmc 1=emmc_raw raw 0 0x3a3d000&ram 0=kernel ram 0x82000000 0x4000000&ram 0=fdt ram 0x88000000 0x80000"

=> dfu 0 list
DFU alt settings list:
dev: MTD alt: 0 name: nor_raw layout: RAW_ADDR
dev: eMMC alt: 1 name: emmc_raw layout: RAW_ADDR
dev: RAM alt: 2 name: kernel layout: RAM_ADDR
dev: RAM alt: 3 name: fdt layout: RAM_ADDR

Sur le PC de flashage:

$ dfu-util -l
dfu-util 0.11

Found DFU: [0451:6163] ver=7ea4, devnum=58, cfg=1, intf=0, path="3-3.2", alt=3, name="fdt", serial="0000000000000441"
Found DFU: [0451:6163] ver=7ea4, devnum=58, cfg=1, intf=0, path="3-3.2", alt=2, name="kernel", serial="0000000000000441"
Found DFU: [0451:6163] ver=7ea4, devnum=58, cfg=1, intf=0, path="3-3.2", alt=1, name="emmc_raw", serial="0000000000000441"
Found DFU: [0451:6163] ver=7ea4, devnum=58, cfg=1, intf=0, path="3-3.2", alt=0, name="nor_raw", serial="0000000000000441"

Essayons maitentant de flasher une image.wic générée par Yocto de 1,6 Go. Cette image représente un projet déjà bien avancé.

Attention: en mode DFU, il faut utiliser l'image non compressée. Le protocole DFU n'a pas été conçu pour envoyer des fragments d'images générés par bmaptool.

$ snagflash -P dfu -p 0451:6163 --dfu-keep -D 1:image.wic

Le temps de flashage est très long: en effet, le mode DFU ne permet de transférer qu'à une vitesse d'environ 1 200 kb/s.

$ sudo usbtop --bus usbmon3
Bus ID 3 (Raw USB traffic, bus number 3)    To device    From device
  Device ID 113 :            1181.38 kb/s    36.73 kb/s

Il faut plus de 40 minutes pour effectuer le flashage complet de l'image Yocto sur la carte SD !

Bien que la carte SK-TDA4VM dispose d'interfaces USB 3.0 (super-speed), une première limitation vient du driver gadget USB, qui ne supporte que le high-speed (ce qui reste déjà suffisant pour le recovery). En plus de cette limitation, le protocole DFU réduit encore la bande passante à un peu plus d’1M/s.

Le mode DFU, limité par sa bande passante, est adapté aux petites mémoires ou pour donner accès à certains registres (STM32 OTP et PMIC via DFU virt).

4.2 UMS (USB Mass Storage)

Avec la même configuration USB, le mode UMS permet de flasher beaucoup plus vite la carte SD de la SK-TDA4VM. Ce mode permet d'exposer un seul périphérique de stockage (ici la MMC) et de l'utiliser comme une "clé USB".

Depuis U-Boot:

=> ums 0 mmc 1
UMS: LUN 0, dev mmc 1, hwpart 0, sector 0x0, count 0x3a3d000
cdns-usb3-peripheral usb@6000000: DRD version v1 (ID: 0004024e, rev: 00000200)

Côté port série de debug, U-Boot signale qu'il fonctionne toujours en affichant une petite animation (curseur rotatif).

Dès que ce mode s'active, le PC réagit comme si une clé USB était insérée (attention au montage automatique de partitions).

$ lsblk 
NAME       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda          8:0    1  29,1G  0 disk

Pour relancer le flashage d'image WIC:

sudo snagflash -P ums -s image.wic.xz -b /dev/sda

Dans le mode UMS, le support des images fragmentées (bmaptool) est disponible. Snagflash essaie de trouver un fichier .bmap (généré automatiquement avec Yocto). Pour Buildroot, il faut ajouter le paquet host-bmap-tool pour qu'un fichier sdcard.img.bmap soit généré en plus de l'image sdcard.img générée par genimage.

Dans le mode UMS, la vitesse de transmission monte à 7 Mb/s.

$ sudo usbtop --bus usbmon3
Bus ID 3 (Raw USB traffic, bus number 3)    To device    From device
  Device ID 113 :                        7097.97 kb/s     17.06 kb/s

En moins de 4 minutes, la même image est flashée sur la carte SD.

sudo snagflash -P ums -s image.wic.xz -b /dev/sda
2026-04-25 15:59:39,830 [INFO] Running snagflash using protocol ums
2026-04-25 15:59:39,830 [INFO] Waiting for /dev/sda...
2026-04-25 15:59:39,830 [INFO] Done
2026-04-25 15:59:39,831 [INFO] Reading image.wic.xz...
2026-04-25 15:59:39,831 [INFO] Copying image.wic.xz to /dev/sda...
2026-04-25 15:59:39,831 [INFO] Looking for image.wic.bmap...
2026-04-25 15:59:39,831 [INFO] Found bmap file image.wic.bmap
2026-04-25 15:59:39,832 [INFO] Opening image.wic.xz with on-the-fly decompression
2026-04-25 16:02:38,801 [INFO] Done

4.3 Fastboot

Le dernier mode, "Fastboot", semble réunir les avantages du mode DFU (multi-device) et du mode UMS (rapide).

Il permet d'accéder à différents périphériques tout en proposant un mode "interactif" avec la version "Extended Fastboot".

D'après un commit récent:

“Fastboot is more efficient than DFU and more featureful than UMS. It's also the only flashing backend supported by snagfactory.”

La commande en mode fastboot, équivalente aux commandes Snagflash précédentes en mode DFU ou UMS, est la suivante:

snagflash -P fastboot-uboot -p 0451:6163 -I flash.cmd

Nous utilisons l'extension fastboot-uboot pour flasher l'image wic de plusieurs Go directement sur la carte SD (écriture RAW). Le protocole fastboot-uboot est plus adapté au transfert de gros fichiers. L'identification du device USB est rappelée sur la ligne de commande (0451:6163). Les commandes de flashage interactif sont regroupées dans le fichier flash.cmd:

# flash.cmd
set fb-addr 0x82000000
set target mmc1
flash "image.wic.xz" 0

La variable fb-addr rappelle l'adresse en RAM où commence le buffer d'échange pour le téléchargement des binaires. On précise qu'on vise l'interface mmc1, celle de la carte SD de la SK-TDA4VM. La commande flash récupère le chemin vers le fichier wic (celui-ci pouvant être compressé) et précise l'offset où commencer le flashage.

Dans notre exemple, nous flashons toute l'image wic déjà partitionnée par Yocto directement sur la carte SD, d'où l'offset à 0.

Le mode fastboot-uboot peut toutefois poser problème avec les gros fichiers wic générés par Yocto.

Malgré le téléchargement du fichier wic par fragments grâce au fichier bmap, certains fragments restent toujours trop volumineux pour tenir dans la zone DDR configurée par U-Boot.

Bien que la SK-TDA4VM dispose de 4 Go de RAM, U-Boot ne configure que la première région de 2 Go. Sur ces 2 Go, certaines zones sont réservées à l'exécution d'U-Boot lui-même, ainsi qu'aux firmwares ATF et OP-TEE (spécificité de ce SoC).

Voici ce qui s'est passé lors de notre première tentative:

snagflash -P fastboot-uboot -p 0451:6163 -I flash.cmd
2026-04-24 23:36:08,388 [INFO] Running snagflash using protocol fastboot-uboot
2026-04-24 23:36:08,401 [INFO] []
2026-04-24 23:36:08,401 [INFO] Done
2026-04-24 23:36:08,401 [INFO] running commands from file flash.cmd
2026-04-24 23:36:08,401 [INFO] running command set fb-addr 0x82000000
setting 'fb-addr' to '0x82000000'
2026-04-24 23:36:08,401 [INFO] running command set target mmc1
setting 'target' to 'mmc1'
2026-04-24 23:36:08,401 [INFO] running command flash "image.wic.xz" 0
2026-04-24 23:36:08,401 [INFO] Running pre-flash checks...
2026-04-24 23:36:08,407 [INFO] fastboot OKAY
2026-04-24 23:36:08,432 [INFO] (bootloader) downloadsize value b'0x2f000000'
2026-04-24 23:36:08,432 [INFO] Flashing file image.wic.xz
2026-04-24 23:36:08,432 [INFO] Found a bmap file, listing sparse ranges...
2026-04-24 23:36:08,432 [INFO] Opening image.wic.xz with on-the-fly decompression
2026-04-24 23:36:18,136 [INFO] Opening image.wic.xz with on-the-fly decompression
2026-04-24 23:36:18,136 [INFO] Flashing sparse range 0/13
2026-04-24 23:36:18,136 [INFO] Flashing to MMC device...
2026-04-24 23:36:18,282 [INFO] fastboot OKAY
2026-04-24 23:36:18,294 [INFO] flashed 12288/12288 bytes
2026-04-24 23:36:18,294 [INFO] Flashing sparse range 1/13
2026-04-24 23:36:18,300 [INFO] Flashing to MMC device...
2026-04-24 23:36:19,154 [INFO] fastboot OKAY
2026-04-24 23:36:19,809 [INFO] flashed 21176320/21176320 bytes
2026-04-24 23:36:19,814 [INFO] Flashing sparse range 2/13
2026-04-24 23:36:19,982 [INFO] Flashing to MMC device...
2026-04-24 23:36:20,163 [INFO] fastboot OKAY
2026-04-24 23:36:20,392 [INFO] flashed 1200128/1200128 bytes
2026-04-24 23:36:20,392 [INFO] Flashing sparse range 3/13
2026-04-24 23:36:20,392 [INFO] Flashing to MMC device...
2026-04-24 23:36:20,535 [INFO] fastboot OKAY
2026-04-24 23:36:20,542 [INFO] flashed 8192/8192 bytes
2026-04-24 23:36:20,542 [INFO] Flashing sparse range 4/13
2026-04-24 23:36:20,543 [INFO] Flashing to MMC device...
2026-04-24 23:36:20,865 [INFO] fastboot OKAY
2026-04-24 23:36:21,773 [INFO] flashed 6037504/6037504 bytes
2026-04-24 23:36:21,773 [INFO] Flashing sparse range 5/13
2026-04-24 23:36:21,848 [INFO] Flashing to MMC device...
2026-04-24 23:36:24,000 [INFO] fastboot OKAY
2026-04-24 23:36:28,837 [INFO] flashed 67936256/67936256 bytes
2026-04-24 23:36:28,843 [INFO] Flashing sparse range 6/13
2026-04-24 23:36:28,844 [INFO] Flashing to MMC device...
2026-04-24 23:36:37,138 [INFO] fastboot OKAY
2026-04-24 23:36:48,274 [INFO] flashed 267296768/267296768 bytes
2026-04-24 23:36:48,301 [INFO] Flashing sparse range 7/13
2026-04-24 23:36:48,303 [INFO] Flashing to MMC device...
2026-04-24 23:36:56,382 [INFO] fastboot OKAY
2026-04-24 23:37:05,225 [INFO] flashed 267296768/267296768 bytes
2026-04-24 23:37:05,252 [INFO] Flashing sparse range 8/13
2026-04-24 23:37:05,255 [INFO] Flashing to MMC device...
2026-04-24 23:37:13,166 [INFO] fastboot OKAY
2026-04-24 23:37:21,990 [INFO] flashed 267296768/267296768 bytes
2026-04-24 23:37:22,007 [INFO] Flashing sparse range 9/13
2026-04-24 23:37:22,008 [INFO] Flashing to MMC device...
2026-04-24 23:37:30,263 [INFO] fastboot OKAY
2026-04-24 23:37:39,096 [INFO] flashed 267296768/267296768 bytes
2026-04-24 23:37:39,115 [INFO] Flashing sparse range 10/13
2026-04-24 23:37:39,116 [INFO] Flashing to MMC device...
Traceback (most recent call last)

Avec une image générée par Yocto de 1,6 Go (wic), Fastboot charge en mémoire RAM à partir de l'adresse 0x82000000 (SYS_LOAD_ADDR par défaut) et plante lorsqu'il transfère le fragment 10/13 (dans cet exemple), au moment où U-Boot essaie d'accéder à l'adresse 0x9e800000.

Nous obtenons un crash U-Boot, dont le log est récupéré depuis l'interface série:

"Synchronous Abort" handler, esr 0x96000046, far 0x9e800000
elr: 00000000808cf880 lr : 000000008087fe88 (reloc)
elr: 00000000fff52880 lr : 00000000fff02e88
x0 : 000000009e800000 x1 : 00000000fde82c40
x2 : 0000000000001000 x3 : 0000000000000000
x4 : 732f6e69622f2123 x5 : 0000000000000000
x6 : 0000000000000044 x7 : 00000000fde40570
x8 : 00000000fffffffe x9 : 00000000fde405f8
x10: 00000000fde40570 x11: 00000000ffffffe0
x12: 0000000000000068 x13: 000000000000000e
x14: 00000000fde400b6 x15: 0000000000000000
x16: 00000000ffefbbd8 x17: 0000000000000000
x18: 00000000fde62e00 x19: 0000000000001000
x20: 00000000fde82b80 x21: 00000000fffd3000
x22: 00000000fde7e360 x23: 00000000fffd3000
x24: 00000000fffb5803 x25: 00000000fde82b80
x26: 0000000000000000 x27: 0000000001000404
x28: 0000000000000000 x29: 00000000fde40570

Code: eb03005f 540001e1 d65f03c0 f8636824 (f8236804) 
Resetting CPU ...

resetting ...

En cherchant dans le code, on retrouve cette adresse utilisée pour OP-TEE:

config K3_OPTEE_LOAD_ADDR
    hex "Load address of OPTEE image"
    default 0x9e800000
    help
      The load address for the OPTEE image. This value defaults to 0x9e800000
      if not provided in the board defconfig file.

bdinfo nous confirme que cette adresse est effectivement réservée.

# bdinfo
 memory[0]      [0x80000000-0xffffffff], 0x80000000 bytes, flags: none
 memory[1]      [0x880000000-0x8ffffffff], 0x80000000 bytes, flags: none
 reserved.count = 0x4
 reserved[0]    [0x9e800000-0xa8ffffff], 0xa800000 bytes, flags: no-map
 reserved[1]    [0xaa000000-0xabbfffff], 0x1c00000 bytes, flags: no-map
 reserved[2]    [0xfce40b30-0xffffffff], 0x31bf4d0 bytes, flags: no-overwrite
 reserved[3]    [0x8ffff7000-0x8ffffffff], 0x9000 bytes, flags: no-notify, no-overwrite

Il faut donc réduire la taille du buffer utilisé par le mode Fastboot (fb-size).

Le calcul est le suivant: l'adresse loadaddr étant par défaut à 0x82000000 et l'adresse à ne pas dépasser étant 0x9e800000, cela signifie que fb-size doit être au maximum de 0x1c800000.

# flash.cmd
set fb-addr 0x82000000
# Reduce fastboot buffer size to not hit K3_OPTEE_LOAD_ADDR (0x9e800000)
set fb-size 0x1c800000
set target mmc1
flash "image.wic.xz" 0

Note: au lieu de modifier fb-size depuis le fichier flash.cmd, il est préférable d'ajuster la configuration U-Boot en utilisant la variable CONFIG_FASTBOOT_BUF_SIZE:

CONFIG_FASTBOOT_BUF_SIZE=0x1c800000

Cette modification a été proposée au projet U-Boot mais nécessite quelques ajustements:

https://lore.kernel.org/u-boot/20260426135715.1395250-1-romain.naour@smile.fr/

Avec une taille réduite du buffer Fastboot, le flashage va au-delà de l'étape 10/13, mais il échoue à nouveau:

ValueError: Truncated flash, only 112640 bytes were flashed instead of 114688 bytes

Cependant, l'image flashée est tout à fait fonctionnelle. Il s'agit d'une régression des premières versions Snagboot v2.6 et v2.6.1, qui vient d'être corrigée: https://github.com/bootlin/snagboot/pull/91. La prochaine release sera certainement entièrement fonctionnelle.

Le temps de flashage reste assez proche de celui obtenu en UMS, autour de 4 min, avec une vitesse de transmission par à-coups d'environ 39 439,36 kb/s (usbtop).

4.4 Flasher une eeprom I2C par Fastboot

Pour les besoins spécifiques d'une carte électronique, une mémoire eeprom I2C peut être utilisée pour stocker des paramètres propres à la carte:

• le modèle (nom) de la carte
• le numéro de série
• la date de fabrication
• la révision matérielle
• la configuration DDR
• les adresses MAC.

La SK-TDA4VM dispose d'une eeprom I2C AT24C512C sur l'interface I2C0 (wkup_i2c0). Cette eeprom contient déjà les informations spécifiques à cette carte ; nous allons expliquer comment la flasher. Attention à ne pas effacer cette eeprom sur une carte fonctionnelle.

À partir d'un binaire nommé "eeprom" respectant le format décrit dans le guide utilisateur (Table 4-11, Board ID Memory Header Information): https://www.ti.com/lit/ug/spruis4e/spruis4e.pdf, nous allons pouvoir le flasher à distance directement dans l'eeprom en utilisant plusieurs commandes Fastboot (-f).

Pour cela, le binaire "eeprom" est téléchargé en RAM (0x82000000) dans U-Boot via -f download:eeprom. Cette opération crée automatiquement une nouvelle variable U-Boot nommée "filesize", contenant la taille du fichier téléchargé (0xfe).

Une deuxième commande Fastboot va exécuter une commande U-Boot à distance pour s'assurer que le bus I2C 0, où se trouve l'eeprom, est bien actif.

La troisième et dernière commande Fastboot va procéder à la copie de la donnée destinée à l'eeprom depuis la RAM.

La commande snagflash est la suivante:

$ snagflash -P fastboot -p 0451:6163 -f download:eeprom -f ucmd:"i2c dev 0" -f ucmd:"eeprom write 0 0x50 0x82000000 0 ${filesize}
2026-05-04 10:47:27,309 [INFO] Running snagflash using protocol fastboot
2026-05-04 10:47:27,318 [INFO] ['download:eeprom', 'ucmd:i2c dev 0', 'ucmd:eeprom write 0 0x50 0x82000000 0 ']
2026-05-04 10:47:27,318 [INFO] Sending command download with args ['eeprom']
2026-05-04 10:47:27,324 [INFO] fastboot OKAY
2026-05-04 10:47:27,324 [INFO] Sending command ucmd with args ['i2c dev 0']
2026-05-04 10:47:27,378 [INFO] Sending command ucmd with args ['eeprom write 0 0x50 0x82000000 0 ']
2026-05-04 10:47:27,385 [INFO] Done

Le téléchargement et le flashage sont quasiment instantanés.

Note: il faut s'assurer que le driver U-Boot misc i2c eeprom soit activé dans la configuration U-Boot.

4.5 Flasher une mémoire NOR SPI

La carte SK-TDA4VM dispose d'une mémoire flash NOR SPI contenant de base une image complète d'un système Linux. Pour démarrer depuis cette mémoire non volatile, il faut modifier le bootmode du SoC afin de sélectionner le boot SPI.

Notre image étant stockée sur la carte SD, il est possible d'utiliser cette mémoire pour stocker un bitstream de FPGA (4 Mo). Il serait ainsi nécessaire de flasher ce composant en même temps que l'image Linux.

Fichier de configuration:

# nor-spi-flash.cmd
set fb-addr 0x82000000
set target nor0
set eraseblk-size 0x40000
flash fpga-bitstream.bin 0

Flashage depuis snagflash:

$ snagflash -P fastboot-uboot -p 0451:6163 -I nor-spi-flash.cmd
2026-05-04 10:52:24,003 [INFO] Running snagflash using protocol fastboot-uboot
2026-05-04 10:52:24,011 [INFO] []
2026-05-04 10:52:24,011 [INFO] Done
2026-05-04 10:52:24,011 [INFO] running commands from file nor-spi-flash.cmd
2026-05-04 10:52:24,011 [INFO] running command set fb-addr 0x82000000
setting 'fb-addr' to '0x82000000'
2026-05-04 10:52:24,011 [INFO] running command set target nor0
setting 'target' to 'nor0'
2026-05-04 10:52:24,011 [INFO] running command set eraseblk-size 0x40000
setting 'eraseblk-size' to '0x40000'
2026-05-04 10:52:24,011 [INFO] running command flash fpga-bitstream.bin 0
2026-05-04 10:52:24,011 [INFO] Running pre-flash checks...
2026-05-04 10:52:24,017 [INFO] fastboot OKAY
2026-05-04 10:52:24,027 [INFO] (bootloader) downloadsize value b'0x1c800000'
2026-05-04 10:52:24,027 [INFO] Flashing file fpga-bitstream.bin
2026-05-04 10:52:24,027 [INFO] Flashing to MTD device...
2026-05-04 10:52:30,695 [INFO] fastboot OKAY
2026-05-04 10:53:20,740 [INFO] flashed 4194304/4194304 bytes

En moins d'une minute, le bitstream du FPGA est flashé.

4.6 Ne rien flasher du tout (pourquoi pas)

Si les différentes méthodes de flashage proposées ci-dessus ne conviennent pas, sont trop longues, ou simplement impossibles du fait des limitations d'U-Boot, il est possible de passer la main à une image Linux initramfs adaptée.

En mode DFU ou Fastboot, il est tout à fait possible de charger un kernel, un devicetree et une image initramfs directement en mémoire RAM et de démarrer dessus.

Ce système Linux pourrait même s'appuyer sur le mécanisme de mise à jour déjà en place sur la cible (RAUC, SWUpdate ou Mender).

5. Conclusion

Au travers de cet article, nous avons pu démarrer pour la première fois une carte électronique et flasher ses différents logiciels et firmwares au moyen d'un câble USB et du logiciel de flashage Snagboot.

Cela suppose de pouvoir modifier la méthode de démarrage par défaut (le bootmode) de la carte. À minima, il faut que les broches de bootmode soient accessibles depuis des points de test afin d'activer le boot par USB (DFU).

Une fois le bootloader (U-Boot) chargé par Snagrecover, les opérations de flashage sont relativement faciles à mettre en œuvre (à condition de ne pas accéder à des zones réservées de la RAM). Le mode fastboot / fastboot-uboot est à privilégier par rapport aux modes DFU et UMS, car il permet de lancer des commandes U-Boot à distance grâce à son mode interactif. S'il faut flasher plusieurs cartes à la fois, le mode Fastboot doit être utilisé pour bénéficier du dernier outil: Snagfactory.

Contrairement au mode DFU, il ne semble pas possible de réaliser un "upload" ou un "dump" depuis la cible avec le mode Fastboot. Snagflash en mode Fastboot ne permet donc pas de récupérer un firmware ou une image déjà flashée.

Pour aller plus loin, il est envisageable de coupler le boot par USB/DFU (via Snagboot) à un outil d'intégration continue, afin de charger une image tout juste générée par une infrastructure CI/CD.

Attention: certains SoC comme les Sitara AM57 (famille OMAP) ne sont pas encore supportés par Snagrecover. Leur séquence de démarrage par USB/DFU diffère de celle du TDA4VM et des nouveaux SoC TI K3: elle nécessite l'exécution d'un binaire "usbboot-stand-alone", capable de scanner le port USB toutes les 250 ms à la recherche d'un message "ASIC ID" puis d'un "Boot message" (https://github.com/bootlin/snagboot/issues/86).

En complément du support pour le SoC J721e, j'ai aussi ajouté les tout derniers SoC TI à la longue liste de ceux déjà supportés: https://github.com/bootlin/snagboot/pull/88

6. Références

• https://www.ti.com/tool/SK-TDA4VM
• https://www.beagleboard.org/boards/beagleplay
• https://openbeagle.org/beagley-ai/beagley-ai/
• https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/11_02_00_04/exports//docs/linux/Foundational_Components/U-Boot/UG-DFU.html
• https://snagboot.readthedocs.io/
• https://bootlin.com/blog/snagboot-v2-6-released/
• https://fosdem.org/2026/schedule/event/7BBMJ3-snagboot_vendor-agnostic_open-source_and_developer-friendly_recovery_and_reflash/
• https://android.googlesource.com/platform/system/core/+/refs/heads/master/fastboot/README.md