🛠 Le C906 sous le capot : errata T-Head, OPP 408/1008 MHz, thermique et vector

Objectifs

Le D1 est un cœur T-Head XuanTie C906 : RV64IMAFDC + extension vectorielle vendor xtheadvector (pré-RVV 1.0, vlenb=16), MMU sv39, 32 Ko de caches I/D, PLIC thead,c900. Ce cœur a des spécificités que le noyau mainline corrige via arch/riscv/errata/thead/errata.c : ID de CPU renvoyés à 0, absence d'instructions CMO standard (le noyau utilise les ops vendor th.dcache.*), erratum PMU, mode d'adressage MAE, et la faille spectulative GHOSTWRITE liée à xtheadvector. Ce tutoriel avancé : observer tout ça depuis le système, régler les OPP (408 MHz / 1008 MHz @ 0,9 V), surveiller le seuil thermique (85 °C passif, 100 °C critique) et mesurer l'impact des choix de compilation sur ce cœur atypique.

Matériel

• Lichee RV Dock sous image mainline récente (les errata T-Head sont dans les noyaux récents ; CONFIG_ERRATA_THEAD_*)
• Console série ou SSH ; stress-ng (ou stress) pour la charge ; dissipateur ou petit ventilateur pour les tests thermiques (512 MB DDR3 in-package, pas de GPU)
• gcc riscv64 natif sur la carte pour les micro-benchmarks

Code complet

# 1) Identité CPU — le C906 ment sur ses registres d'identification :
dmesg | grep -iE 'errata|thead|c9'
cat /proc/cpuinfo            # uarch « thead,c906 » ; mvendorid/marchid à 0 (errata)

# 2) Fréquence : deux OPP seulement (408 MHz et 1008 MHz @ 0,9 V)
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
echo performance | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq   # ~1008000 kHz en pleine charge

# 3) Thermique : seuils mainline 85 °C (passif/throttle) et 100 °C (critique)
watch -n2 'cat /sys/class/thermal/thermal_zone*/temp'   # milli-°C
stress-ng --cpu 1 --timeout 300 &     # la fréquence doit baisser près de 85 °C

# 4) Vectoriel : le C906 expose xtheadvector (0.7.1), PAS rvv-1.0 :
#    un binaire compilé avec -march=rv64gcv (RVV standard) refusera la
#    partie vectorielle ; les toolchains T-Head (XTheadVector) ciblent le 0.7.1.
cat /proc/sys/abi/* 2>/dev/null | head -3
gcc -Q --help=target | grep -i march   # ce que le gcc natif accepte

# 5) Benchmark mono-cœur honnête (1 cœur, 512 MB : comparer vos flags)
gcc -O2 -march=rv64imafdc -o bench bench.c && ./bench
gcc -O3 -march=rv64gc -o bench2 bench.c && ./bench2   # éviter -march=rv64gcv ici

Vérification attendue

dmesg affiche les lignes d'errata T-Head appliqués (CMO/PMU/MAE/GHOSTWRITE selon le noyau) — preuve que le noyau reconnaît le C906 malgré ses IDs à 0. scaling_available_frequencies liste exactement 408 MHz et 1008 MHz ; en pleine charge le CPU tient 1008 MHz puis retombe quand le seuil passif de 85 °C est atteint (visible dans la log thermique). Un binaire -march=...v standard lève une instruction illégale ou ignore le vectoriel : le C906 ne parle pas RVV 1.0. La RAM plafonne à ~460-500 Mo utilisables (512 Mo DDR3 in-package).

Erreurs fréquentes

• Croire le CPU mort car mvendorid/marchid valent 0 : c'est l'errata documenté du C9xx, pas un défaut ; le noyau s'appuie sur le device tree (thead,c906).
• Compiler en -march=rv64gcv « pour profiter du vectoriel » : xtheadvector 0.7.1 ≠ RVV 1.0 ; utiliser une toolchain T-Head ou rester en scalaire.
• Attendre un GPU/vidéo : pas de GPU 3D ni de codec matériel utilisable en mainline (CedarX sans licence claire) — l'HDMI 4Kp30 est de l'affichage seul.
• Surveiller sans contrainte : le throttling à 85 °C ne se voit qu'avec stress-ng prolongé ; sans test en charge, le seuil n'est jamais validé.
• Comparer les perfs avec des cartes ARM en oubliant : 1 cœur, 512 Mo, 1 GHz — dimensionner les services en conséquence (pas de navigateur, pas de conteneurs lourds).