Passer au contenu

DCENT_OS pour Avalon (Canaan)

Chaque propriétaire d’Antminer peut choisir parmi cinq micrologiciels tiers. Un propriétaire d’Avalon ne peut en choisir aucun : Braiins OS+, VNish, LuxOS, ePIC et Hiveon publient chacun une liste des modèles pris en charge, et pas un seul n’inclut de matériel Canaan Vérifié 2026-08-21. DCENT_OS est le projet de micrologiciel entièrement ouvert, sous GPL-3.0, construit pour mettre fin à cela — au grand jour, chaque jalon étant publié comme preuve datée, avec la même échelle d’honnêteté qui a mené DCENT_OS de zéro jusqu’à des parts de pool acceptées sur du matériel Antminer et de classe Bitaxe.

Pourquoi un micrologiciel ouvert pour Avalon est important

Canaan mérite d’abord d’être reconnu : l’entreprise ouvre le code de son micrologiciel plus que tout autre grand fabricant d’ASIC — environ deux douzaines de dépôts publics, dont l’arbre complet du micrologiciel de minage domestique Avalon_Nano3s et sa lignée cgminer Vérifié — GitHub public. C’est précisément cette ouverture qui fait de la gamme Avalon la cible de micrologiciel personnalisé la plus accessible du minage, et pourquoi une scène communautaire se forme déjà autour des mineurs domestiques à base de K230 — jailbreaks, builds tiers, guides d’overclocking. Ce qui manque encore à cette scène, c’est un système d’exploitation entièrement ouvert, sous GPL-3.0, construit pour toute la gamme. C’est la lacune que DCENT_OS comble Pris en charge — aucun autre projet de micrologiciel sous GPL-3.0 ciblant Canaan n’a été trouvé au 2026-08-21.

L’argument de la souveraineté est le même que celui qui guide tout ce que nous construisons : un mineur dont vous ne pouvez ni lire, ni reconstruire, ni remplacer le micrologiciel est une machine que vous exploitez selon les conditions d’autrui. DCENT_OS traite Avalon comme une plateforme cible de premier plan — le dépôt public s’engage ouvertement sur cette structure plutôt que de la cacher — et cette page mesure la distance entre l’engagement et la preuve sans jamais confondre les deux.

Ce qui est prouvé aujourd’hui

Chaque ligne ci-dessous correspond à quelque chose qui s’est réellement produit, étiqueté selon la force de sa preuve. Rien de plus faible que l’étiquette n’apparaît dans la ligne.

DCENT_OS sur Avalon — le registre de preuves, 2026-08-21
Jalon Preuve Ce que cela signifie — et ce que cela ne signifie pas
Premier démarrage de l’espace utilisateur DCENT sur un vrai Nano 3 Expérimental — matériel réel, 2026-08-21 Un vrai Avalon Nano 3 sur notre banc a démarré un système de fichiers racine reconstruit localement sous la propre chaîne de démarrage d’usine de Canaan (SPL, U-Boot, Linux 5.10.4 sur le Kendryte K230), a exposé un accès SSH par clé uniquement, et a coexisté proprement avec le logiciel d’origine. Le btcminer de Canaan possédait toujours le hachage tout du long. DCENT_OS tourne sur la machine ; DCENT_OS ne mine pas encore la machine.
Chaîne de flashage K230 Vérifié — banc Notre outillage analyse, vérifie et assemble les images système .kdimg de Canaan et dialogue de bout en bout avec le protocole de flashage USB du K230, avec un contrôle de capacité et un mode simulation (dry-run), en intégrant le chargeur officiel de Canaan sous licence MIT. Prouvé face à de vraies images sur l’établi. C’est une capacité d’ingénierie que nous détenons — pas un téléchargement, et pas une procédure proposée aux lecteurs.
Premières images système DCENT assemblées Vérifié — banc Des images .kdimg complètes de premier démarrage pour le Nano 3 et le Nano 3S, construites à partir du SDK public Kendryte K230 et de Buildroot avec notre démon Rust intégré, chaque somme de contrôle étant vérifiée par notre propre analyseur. Construites et vérifiées sur l’établi ; délibérément non publiées.
Squelette de pilote A3197S en salle blanche Vérifié — banc ; échoue en mode fermé par conception Le pilote GPL-3.0 qui permettra à DCENT_OS de dialoguer avec les puces de hachage A3197S (Nano 3S ; le silicium de l’Avalon Q appartient à la même famille) est esquissé en salle blanche. Son constructeur de production échoue en mode fermé : tant que de véritables octets de bus capturés n’existent pas, il ne peut même pas être instancié. C’est une caractéristique d’honnêteté — ce projet ne prétend pas parler un protocole qu’il n’a pas capturé.
Primitives du protocole de contrôle testées côté hôte Vérifié — banc Le codec de contrôle mm_pkg de Canaan (l’ABI de message de 268 octets que parle le démon du Nano 3), l’empaquetage AUP et les opérations ascset sont implémentés et passent les tests côté hôte.

Ce qui ne l’est pas encore

Aucune prise en charge du minage. Sur la seule machine où l’espace utilisateur de DCENT_OS s’est exécuté, le btcminer d’origine de Canaan gère toujours les hashboards. Selon les propres termes du dépôt public : « Aucune preuve de part acceptée n’existe encore pour DCENT_OS sur du matériel Avalon. » Vérifié — dépôt public

Aucune image publique. Les images qui existent sont des artéfacts d’établi. Rien n’est téléchargeable, et le dépôt le dit clairement : « Ne considérez pas ce répertoire comme un micrologiciel installable. »

Aucune route d’installation. Il n’existe aucune procédure DCENT_OS pour installer quoi que ce soit sur un Nano 3, un Nano 3S ou un Avalon Q, et aucune ne sera publiée avant que la preuve n’existe.

Lorsque l’un de ces points changera, il changera d’abord dans le dépôt public, puis sur cette page, avec la même échelle de preuve que celle utilisée par les plateformes Antminer et ESP : téléversé ≠ miné, connecté ≠ en train de miner, partiel ≠ prouvé. Un jalon mérite son étiquette, ou il ne l’obtient pas.

Pourquoi il n’y a pas encore d’image publique

Réponse honnête, pas une esquive : une barrière de licence et une barrière de discipline.

Le cœur de minage en temps réel de Canaan pour la gamme Avalon actuelle est sous licence BUSL-1.1 — à source ouverte pour l’étude, mais non libre de redistribution Vérifié — texte de licence public. Une image publique de DCENT_OS qui l’embarquerait violerait cette licence, alors nous n’en publierons pas. Il reste deux issues honnêtes, et nous empruntons la première tout en gardant la seconde ouverte :

  • Le pilote en salle blanche — remplacer entièrement le cœur de minage sous licence par notre pilote A3197S sous GPL-3.0, construit à partir d’octets capturés sur du matériel que nous possédons. C’est la voie par défaut, et c’est pourquoi le squelette du pilote échoue en mode fermé tant que ces captures n’existent pas : la salle blanche signifie capturer, puis implémenter — jamais deviner, jamais copier.
  • Un accord de redistribution avec Canaan — une entreprise qui ouvre déjà davantage son code que n’importe lequel de ses concurrents. Cette porte n’est pas fermée.

Tant que l’une de ces deux issues n’aboutit pas, le travail sur Avalon reste interne au laboratoire. C’est ce que signifie « en développement » sur cette page — pas un euphémisme, une limite.

État par modèle — Nano 3, Nano 3S, Avalon Q

État de DCENT_OS par modèle Avalon, 2026-08-21 — aucune ligne n’est une offre d’installation
Modèle Matériel DCENT_OS aujourd’hui Le prochain jalon
Avalon Nano 3 4 TH/s · 140 W · Kendryte K230D Vérifié En développement — le plus avancé. Premier démarrage de l’espace utilisateur DCENT sur une vraie unité (2026-08-21) : notre système de fichiers racine reconstruit a démarré sous la chaîne de démarrage d’usine avec un accès SSH par clé uniquement, la pile d’origine intacte. Le btcminer de Canaan possède toujours le hachage. Expérimental Une preuve de démarrage du démon DCENT qui ne touche pas à la prise en charge du hachage — valider la coexistence avant toute autre chose.
Avalon Nano 3S 6 TH/s · 140 W · 12× A3197S · K230D Vérifié En développement. Une image de premier démarrage construite sur l’établi existe, et le squelette du pilote A3197S en salle blanche cible précisément les puces de cette machine. Vérifié — banc Des octets de bus A3197S capturés depuis du matériel de banc — le pilote à échec fermé ne peut être construit sans eux, à dessein.
Avalon Q ~90 TH/s · 1 674 W · classe A3197S / A322x (référence exacte non confirmée) · K230 Pris en charge En développement. Le Q partage le même travail de plateforme K230 que la gamme domestique — une génération de SoC, un support de démarrage, un format d’image — de sorte que les progrès de la gamme domestique sont des progrès pour le Q. Pris en charge Une unité de banc pour valider la carte de partitions, puis le même travail de pilote en salle blanche que pour le Nano 3S.
Avalon Mini 3 ~37 TH/s · K230 Pris en charge En développement — même voie de la famille K230 que la gamme Nano. Un micrologiciel communautaire gratuit existe déjà pour ce modèle chez un autre projet ; nous le créditons plutôt que de rivaliser par le silence. Suit la mise en route des Nano 3/3S.

Une limite mérite d’être précisée : les Avalon industriels plus anciens, de génération K210, exécutent FreeRTOS sans Linux en dessous ; un système DCENT_OS ne s’y « installera » donc jamais — la gestion de flotte et la supervision sont le plafond honnête pour ces machines Vérifié.

Suivre le travail — ou l’accélérer

Chaque jalon ci-dessus a été consigné comme un enregistrement daté, et les prochains le seront aussi. Si vous voulez que les propriétaires d’Avalon disposent de ce que les propriétaires d’Antminer ont déjà :

  • Surveillez le dépôt. Le code source de DCENT_OS est sous GPL-3.0 de bout en bout ; le répertoire Avalon est l’endroit où l’état change en premier.
  • Contribuez du matériel ou des captures. Le goulot d’étranglement n’est pas le code — ce sont les octets capturés. Du matériel de banc et des captures de protocole provenant de machines que vous possédez font avancer cette feuille de route plus que tout le reste ; CONTRIBUTING.md explique comment.
  • Faites tourner le matériel. Nous stockons et réparons les machines que ce travail cible — l’Avalon Nano 3 est disponible dans notre atelier de Montréal, et chaque unité sur le terrain est une raison de plus de terminer.

Faire tourner le micrologiciel d’origine en attendant est le bon choix — gardez-le à jour avec notre guide de mise à jour du micrologiciel Avalon.