Présentation du dispositif

L’Ox64 est commercialisé à 8 $ et propose un processeur RISC‑V à trois cœurs distincts. Contrairement à de nombreux microcontrôleurs, il intègre un noyau Linux complet, mais il ne possède pas d’unité de gestion mémoire (MMU) et les interfaces Ethernet, Wi‑Fi et carte SD restent non fonctionnelles au moment de la rédaction.

Architecture matérielle et contraintes d’accès

Le tableau de broches expose les lignes GPIO14 et GPIO15 comme ports UART TX/RX. L’absence de programmation USB oblige à utiliser un adaptateur série (ex. CH340G) ou, comme l’auteur l’a fait, un RP2040 (Raspberry Pi Pico) configuré en pont série. Le schéma de connexion consiste à relier GPIO‑4 du RP2040 → GPIO‑15 de l’Ox64 et GPIO‑5 du RP2040 → GPIO‑14 de l’Ox64, avec les masses communes reliées.

Processus de flashage et adaptations logicielles

Le logiciel officiel Dev Cube échoue sous Ubuntu Wayland, affichant l’erreur suivante :

$ ./BLDevCube-ubuntu 
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so: undefined symbol: g_log_structured_standard
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.
(BLDevCube-ubuntu:54646): GLib-GIO-ERROR **: Settings schema 'org.gnome.settings-daemon.plugins.xsettings' does not contain a key named 'antialiasing'
Trace/breakpoint trap (core dumped)

Contournement : lancer la session Xorg ou désactiver Wayland. Le flashage via Dev Cube reste impossible, même avec le pont RP2040, ce qui conduit à l’utilisation de bflb-mcu-tool. Avant de l’exécuter, il faut modifier le fichier Python ~/.local/lib/python3.10/site-packages/bflb_mcu_tool/libs/bflb_interface_uart.py afin de supprimer la gestion des signaux DTR/RTS, incompatibles avec le pont série.

Le binaire de démarrage low_load_bl808_m0.bin, fourni dans le guide Linux du BL808, est alors flashé avec la commande :

$ bflb-mcu-tool --chipname=bl808 --port=/dev/ttyACM2 --baudrate=2000000 --firmware=out/low_load_bl808_m0.bin

Le terminal de l’Ox64 répond alors :

dynamic memory init success, heap size = 156 Kbyte
E907 start...
mtimer clk:1000000
psram clk init ok!

Ces messages confirment que le chargeur M0 s’est exécuté, que la RAM dynamique de 156 KB est opérationnelle et que les horloges du timer et du PSRAM sont correctement initialisées.

Analyse des perspectives et limites actuelles

Le succès du flashage montre que le soc BL808 peut être mis en service avec un outil open‑source, mais plusieurs obstacles subsistent : l’absence d’MMU empêche l’exécution de distributions Linux classiques, les pilotes réseau et stockage restent à développer, et le processus de mise à jour nécessite une chaîne d’outils non trivialement installable. La dépendance à un pont RP2040 ajoute une couche matérielle supplémentaire, augmentant le coût et la complexité pour les utilisateurs non‑experts. En l’état, l’Ox64 constitue une plateforme d’expérimentation RISC‑V à très bas prix, adaptée aux développeurs souhaitant explorer le bootloader BL808 et les premiers stades d’un système Linux minimal.