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

Objetivos

El D1 es un núcleo T-Head XuanTie C906: RV64IMAFDC + extensión vectorial del proveedor xtheadvector (pre-RVV 1.0, vlenb=16), MMU sv39, 32 KB de cachés I/D, PLIC thead,c900. Este núcleo tiene particularidades que el kernel mainline corrige mediante arch/riscv/errata/thead/errata.c: IDs de CPU devueltos como 0, ausencia de instrucciones CMO estándar (el kernel utiliza las operaciones del proveedor th.dcache.*), errata de PMU, modo de direccionamiento MAE y la vulnerabilidad especulativa GHOSTWRITE relacionada con xtheadvector. Este tutorial avanzado: observar todo esto desde el sistema, ajustar los OPP (408 MHz / 1008 MHz @ 0,9 V), vigilar el umbral térmico (85 °C pasivo, 100 °C crítico) y medir el impacto de las opciones de compilación en este núcleo atípico.

Hardware

• Lichee RV Dock con una imagen mainline reciente (las erratas de T-Head están en los kernels recientes; CONFIG_ERRATA_THEAD_*)
• Consola serie o SSH; stress-ng (o stress) para la carga; disipador o pequeño ventilador para las pruebas térmicas (512 MB DDR3 in-package, sin GPU)
• gcc riscv64 nativo en la placa para los micro-benchmarks

Código completo

# 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

Verificación esperada

dmesg muestra las líneas de erratas de T-Head aplicadas (CMO/PMU/MAE/GHOSTWRITE según el kernel) — prueba de que el kernel reconoce el C906 a pesar de sus IDs a 0. scaling_available_frequencies lista exactamente 408 MHz y 1008 MHz; bajo plena carga, la CPU mantiene 1008 MHz y luego baja cuando se alcanza el umbral pasivo de 85 °C (visible en el registro térmico). Un binario compilado con -march=...v estándar lanza una instrucción ilegal o ignora la parte vectorial: el C906 no habla RVV 1.0. La RAM se limita a ~460-500 MB utilizables (512 MB DDR3 in-package).

Errores frecuentes

• Creer que la CPU está muerta porque mvendorid/marchid valen 0: es la errata documentada del C9xx, no un defecto; el kernel se basa en el device tree (thead,c906).
• Compilar con -march=rv64gcv «para aprovechar la parte vectorial»: xtheadvector 0.7.1 ≠ RVV 1.0; utilizar una toolchain de T-Head o quedarse en escalar.
• Esperar una GPU/vídeo: no hay GPU 3D ni códec de hardware utilizable en mainline (CedarX sin licencia clara) — el HDMI 4Kp30 es solo salida de vídeo.
• Vigilar sin carga: el throttling a 85 °C solo se observa con stress-ng prolongado; sin una prueba bajo carga, el umbral nunca se valida.
• Comparar el rendimiento con placas ARM olvidando: 1 núcleo, 512 MB, 1 GHz — dimensionar los servicios en consecuencia (sin navegador, sin contenedores pesados).