Journal Des DIMMs DDR RGB en SMBus vraiment PITA

Cher nal, à la base, mon histoire était simple : j'ai des barrettes de RAM RGB qui font plein de lumière, achetées uniquement parce qu'elles sont moins chères que les non-illuminées, et je voulais qu'elles s'éteignent. Je fais un tour dans le BIOS, je me dirige vers l'option idoine, qui parle de désactivation du RGB, je valide, et… j'en ai toujours plein les yeux. Quelques temps sur un moteur de recherche plus tard, je me rends compte que les barrettes de RAM RGB fonctionnent différemment des contrôleurs RGB intégrés aux cartes mères (qui sont ceux contrôlés dans le BIOS par l'option citée plus haut), et qu'il faut utiliser… un utilitaire Windows fourni par le fabricant des barrettes, et spécifique à chaque marque !

Et c'est là que commence le drame, pour moi : je fais quelque recherches sur comment faire sous Linux, et tombe assez rapidement sur OpenRGB, un logiciel libre (GPL) sympa. Sauf qu'il n'est pas disponible sur Debian dans les dépôts officiels (le développeur offre tout de même ses propres paquets). Et que ça a l'air assez orienté interface graphique, alors que moi je veux juste désactiver le RGB, pas changer mille options — bon OK, il y a une version en ligne de commande, mais après un coup d'œil au code… c'est un peu cra-cra. Et surtout, je veux comprendre le pourquoi du comment, parce que ça m'intéresse toujours de creuser comment on en arrive à avoir des monstres logiciels sous Windows pour pouvoir éteindre les LEDs, alors qu'un libriste semble arriver à faire mieux bénévolement…

Je commence donc par regarder les sources d'OpenRGB pour le « contrôleur » (c'est du C++, il a une architecture modulaire blahblah) de mon constructeur ici :

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Controllers/CrucialController/CrucialControllerDetect.cpp

Franchement, j'aime pas le style de code, il y des choses utilisées de manière tordue (l'I2C_SMBUS_WRITE, ligne 84), des commentaires qui n'ont pas de sens vu le flôt de contrôle (ligne 191) — on observe d'ailleurs que les messages de debug sont issus d'une personne différente de celui qui a écrit le code… —, l'histoire de remaping semble étrange, bref, je me décide à essayer de voir ce qu'il fait vraiment, en utilisant les outils que je connais.

Ici, donc, on voit que pour contrôler le RGB de ces barrettes, il faut passer par de l'I²C, un bus de données simple que je connais bien, et pour lequel l'utilisation du driver I²C présentant directement le bus à l'espace utilisateur i2c-dev est vachement pratique. Pour info, l'I²C il y en a dans les batteries de votre laptop, pour son chargeur (par le transfo, mais le contrôleur dans votre laptop), dans tous les périphériques PCI ou PCIe (c'est le bus de « contrôle »), dans l'identification de votre écran (EDID), pour contrôler les backlights et les RTC, etc. Bref, il est partout, et souvent dans sa version SMBus qu'on va utiliser ici. Pour interagir en « bas-niveau » depuis l'espace utilisateur par le driver sus-cité, on utilise les outils fournis par i2c-tools — je découvrirai plus tard que c'est exactement ce que faisais le développeur principal, Adam Honse, pour reverse-engineerer le matériel.

En bref, du point vue logiciel, l'I²C est un bus de données où un « maître » contrôle plusieurs périphériques « esclaves » (la terminologie a été changée l'année dernière dans la norme, mais je suis de la vieille école), addressés sur 8 bits, dont le moins significatif indique si on veut écrire où lire dans ce périphérique des valeurs de 8 bits, ce qui donne au final 7 bits pour addresser 128 périphériques, moins quelques adresses réservées. Le protocole SMBus est un sous-ensemble de ce protocole, où les périphériques obéissent à un ensemble de commandes de lecture/écriture qui adressent pour chaque périphérique une carte de registres (j'essaye de traduire « register map » ou « register file ») sur 8 bits également. On peut y écrire des registres de 8 ou 16 bits de large (''byte'' ou ''word''), en changeant éventuellement l'ordre pour les mots de 16 bits (variante ''swapped'' dans le noyau) parce que même si la norme dit que c'est big-endian, gérer l'endianness correctement est un running-gag dans le milieu informatique. La documentation du noyau sur SMBus résume tout ça assez bien.

Mettons les mains dans le cambouis, on installe donc ces outils et on charge le driver :

apt-get install i2c-tools
modprobe i2c-dev

Et en fait, avant même de commencer à utiliser les classiques i2cget/i2cset, je me rends compte que le paquet contient un outil nommé decode-dimms, qui attire tout de suite mon attention : je pourrai sûrement en tirer des informations intéressantes ! Je le lance, mais il m'indique de charger le module adéquat pour obtenir les informations contenues dans l'EEPROM du SPD (Serial Presence Detect) de la barrette. J'ai tenté eeprom, qui marche mais a des informations tronquées, pour lesquelles il faudrait utiliser ee1004 mais… celui-ci ne fonctionne pas. Bon, voyons tout de même ce qu'obtient le premier :

modprobe eeprom
decode-dimms

# decode-dimms version 4.3

Memory Serial Presence Detect Decoder
By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,
Jean Delvare, Trent Piepho and others
WARNING: /sys/bus/i2c/drivers/eeprom/0-0052/eeprom is smaller than expected
WARNING: Fewer data bytes available (256) than needed (384)
HINT: You should be using the ee1004 driver instead of the eeprom driver
WARNING: /sys/bus/i2c/drivers/eeprom/0-0053/eeprom is smaller than expected
WARNING: Fewer data bytes available (256) than needed (384)
HINT: You should be using the ee1004 driver instead of the eeprom driver


Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/0-0052
Guessing DIMM is in                              bank 3
Kernel driver used                               eeprom

---=== SPD EEPROM Information ===---
EEPROM CRC of bytes 0-125                        OK (0x7956)
# of bytes written to SDRAM EEPROM               384
Total number of bytes in EEPROM                  512
Fundamental Memory type                          DDR4 SDRAM
SPD Revision                                     1.1
Module Type                                      UDIMM
EEPROM CRC of bytes 128-253                      OK (0xC6AB)

---=== Memory Characteristics ===---
Maximum module speed                             2666 MT/s (PC4-21300)
Size                                             16384 MB
Banks x Rows x Columns x Bits                    16 x 16 x 10 x 64
SDRAM Device Width                               8 bits
Ranks                                            2
Rank Mix                                         Symmetrical
Primary Bus Width                                64 bits
AA-RCD-RP-RAS (cycles)                           19-19-19-43
Supported CAS Latencies                          20T, 19T, 18T, 17T, 16T, 15T, 14T, 13T, 12T, 10T

[…]

On voit que les périphérique I²C intéressant sont les 0x52 et 0x53 sur le bus 0 (le driver eeprom scanne le bus entre 0x50 et 0x57 selon ses sources). Maintenant qu'on connait le bus utilisé et les périphériques visés, on peut utiliser nos outils classiques. Listons les périphériques :

i2cdetect 0

WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         08 -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- 1a 1b -- -- -- -- 
20: -- -- -- -- -- -- -- 27 -- -- -- -- -- -- -- -- 
30: 30 -- -- -- 34 35 36 -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- 52 53 -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --  

En fait, si vous n'avez pas encore déchargé le module eeprom, vous verrez des « UU » à la place de 52 et 53, car ce driver a pris possession de ces périphériques et le noyau empêche de le perturber en refusant de lui envoyer des informations directement depuis l'espace utilisateur. Faites-le maintenant :

modprobe -r eeprom

On peut maintenant récupérer le contenu de l'EEPROM SPD avec l'outil i2cdump, et même utiliser decode-dimms dessus, comme précédemment (ici pour la première barrette seulement), mais uniquement les 256 premiers octets :

i2cdump 0 0x52 > dimm1-1.dump
decode-dimms -x dimm1-1.dump

Comme le contenu est tronqué, c'est là qu'on va commencer à creuser un peu plus profondément : pour une DIMM de DDR4, le driver ee1004 qu'on aurait dû normalement utiliser indique que celle-ci contient un mécanisme de sélection de page par le contrôleur de l'EEPROM afin d'obtenir les 256 octets suivants (cf. drivers/misc/eeprom/ee1004.c, en suivant la norme JEDEC éponyme). Pour cela, il faut écrire quelque-chose (peu importe le contenu) à l'adresse 0x37, qui n'est pas indiqué dans le scan ci-dessus car c'est un périphérique qui ne répond qu'aux écritures, pas aux lectures, et on pourra revenir à la première page en écrivant à 0x36. Comme ee1004 ne semble pas arriver à le faire dans notre cas, faisons-le « à la main » :

i2cset 0 0x37 0
i2cdump 0 0x52 > dimm1-2.dump
i2cset 0 0x36 0

Puis nous concaténons les deux pages, avec un peu d'aide de awk pour la renumérotation des lignes (ces dumps sont des représentations hexadécimales, pas du binaire brut), et redemandons à decode-dimms de nous l'interpréter :

(cat dimm1-1.dump && awk 'NR>1 { print "1" $0 }' dimm1-2.dump) > dimm1-full.dump
decode-dimms -x dimm1-full.dump

On obtient d'autres informations comme la date de fabrication et le numéro de série, et il n'y a plus de message d'erreur sur le manque de données.

Tout ça c'est intéressant mais retournons à notre histoire de RGB. En regardant le projet OpenRGB, on voit qu'il scanne la plage 0x50 à 0x57 comme le fait le module eeprom, et en plus il interroge un périphérique à l'adresse 0x27. Puis il y a l'histoire de « remapage » qui semble consister à séparer les barrettes afin de les faire apparaître comme des périphérique différents, mais ça n'est pas ce qui m'intéresse : je veux toutes les éteindre d'un coup. Le contrôleur est également vérifié par certaines propriétés, comme le fait de renvoyer des nombres incrémentaux entre 0xA0 et 0xB0 (c'est bien le cas ici), et de contenir les chaînes « Micron » à l'adresse 0x1025 ou 0x1030 (le miens est à 0x1030).

Mais quand vous regardez la manière d'interroger tout ça, c'est quand même étrange : la fonction CrucialRegisterRead écrit d'abord dans le registre 0x0 à l'adresse du contrôleur un mot de 16b (inversé), puis obtient la valeur en lisant le registre 0x81. On a donc une sorte d'indirection supplémentaire pour accéder à un espace d'adressage de 16 bits, où le périphérique expose un registre de 16b (inversé) pour l'adresse, en 0x0, et permet soit d'y écrire (regardez CrucialRegisterWrite) quand on écrit dans le registre 0x1 une valeur, soit d'y lire quand on lit le registre 0x81.

Bon, soit. Je regarde maintenant les fonctions qui vont agir sur le fonctionnement des LED proprement dites, en allant lire le code du contrôleur une fois instancié :

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Controllers/CrucialController/CrucialController.cpp

Je vois une fonction SendBrightness qui me semble tout à fait adaptée, et qui écrit en gros quelques valeurs magiques au bon endroit… Essayons de traduire ça en commandes i2cset. Attention ! j'utilise ici les version sans confirmation utilisateur, et utiliser ce code directement chez vous sans vérifier pourrait être dangereux, en écrivant là où il ne faut pas : à utiliser à vos risques et périls, même si à priori la région SPD des DIMM est protégée en écriture. Ça donne, en prenant soin d'avoir inversé les deux octets d'adresse à chaque fois :

BUS=0
DEV=0x27
WRITE="i2cset -y $BUS $DEV";
READ="i2cget -y $BUS $DEV";

brightness=0x0

# set brightness
$WRITE 0x0 0xEE82 w
$WRITE 0x1 0xFF b
$WRITE 0x0 0xEF82 w
$WRITE 0x1 $brightness b
$WRITE 0x0 0xF082 w
$WRITE 0x1 0x83

On lance et… ça marche ! En réalité, je n'ai pas réussi du premier coup car je n'avais d'abord pas inversé les octets de l'adresse, et que j'avais mal transcris les fonctions d'écriture, mais après quelques temps de réflexion je suis arrivé à ça. On peut faire de même pour les « effets », si on veut s'amuser ; forcément, j'ai voulu voir et ça fonctionne bien.

Et puis j'ai voulu comprendre encore un peu plus. Pourquoi cette indirection, qu'est-ce que sont ces adresses et valeurs ? Au début, j'ai pensé à un pont (bridge) I²C, vu que le contrôleur en 0x27 semble contrôler toutes les barettes en même temps et donc pourrait multiplexer les commandes vers chacune individuellement. Puis j'ai cherché des photos des barrettes de chez Crucial voir si on pouvait y récolter des informations sur le chip en question. J'ai vu sur l'une d'entre elles que certaines barrettes avaient un micro-contrôleur 6K5830 de chez ENE, un taïwanais donc il est difficile d'avoir des informations autrement qu'en chinois. Cependant, la datasheet que j'ai trouvée indique que c'est un « MCU (MiCrocontroller Unit) 8051 à mémoire flash avec 24 canaux pour commander des LED en PWM », ce qui correspond tout à fait au rôle de contrôle des LEDs d'une barrette de RAM !

Pour ceux qui ne connaissent pas, le 8051 est à l'origine un micro-contrôleur de chez Intel datant de 1980, qui a été cloné par plein de constructeurs dès qu'on doit mettre une petite dose de programmation dans n'importe quel périphérique simple, comme ici de l'allumage de LED. On le trouve peu souvent indépendemment, comme le sont au contraire les ATmegas par exemple, mais il est présent au sein de beaucoup d'autres périphériques comme cœur permettant d'ajouter de la souplesse de programmation.

Et donc, nous avons un micro-contrôleur programmable sur chaque barrette de RAM ?! Mais alors, cette histoire d'écriture indirecte, ça serait un mécanisme pour attaquer directement l'espace de 16 bits adressé par ce 8051 ? Essayons en regardant dans la datasheet de ce MCU la valeur d'un des registres qui a une valeur significative (car se retrouver avec 0x00 ou 0xff peut souvent être un hasard), par exemple le registre contrôlant l'adresse d'esclave du contrôleur sur le bus SMBus 0 (il a deux bus utilisable comme esclave, essayons le premier), qui est à 0xF002 :

$WRITE 0x0 0x02F0 w
$READ 0x81 b

Et nous obtenons 0x4f, soit une fois décalé à droite (n'oubliez pas que le LSB sert à indiquer si c'est une lecture ou écriture), donne 0x27, ce qui est bien son adresse ! En allant tester d'autres registres, on voit qu'on accède effectivement par ce mécanisme à tout l'espace d'adressage spécifique, et que les valeurs semblent correspondre à la datasheet, à quelques bits réservés près qui semble indiquer que mon modèle est peut-être légèrement différent de celui de ce manuel. On a même les instructions pour dumper la mémoire flash…

Mais alors à quoi correspond 0x82xx ? Normalement la XRAM, ici de 2 kB, va jusqu'à 0x800, si elle est mappée dès 0. Qu'est-ce qui est mappé à la suite ? On va tenter un truc bourrin : le registre DPTR est utilisé pour les accès indirects, que ça soit à la XRAM ou la PMEM. Comme on peut y accéder en tant que SFR par la plage 0xFFxx (cf. datasheet), on va échantillonner l'octet haut de DPTF (adresse 0xFF83) autant qu'on peut et essayer de voir un motif, sachant que ça mélange aussi bien des accès à la RAM qu'au programme. J'essai un rapide :

timeout 10 sh -c 'while true; $WRITE 0x0 0x83ff w ; $READ 0x81 b ; done ' > run_10s_DPTRH
sort < run_10s_DPTRH | uniq -c

Et j'obtiens (rappelez-vous, c'est l'octet supérieur) :

474 0x00
260 0x01
467 0x02
 30 0x03
  3 0x06
 24 0x50
  3 0x52
  3 0x60
 10 0x61
2102 0x80
 21 0x81
1502 0x82
282 0xf0
993 0xf1
 28 0xf2

On a donc des accès entre 0x00xx-0x06xx qui doivent être les accès à la XRAM, quelques rares accès entre 0x50xx-0x61xx, beaucoup entre 0x80xx-0x82xx (ceux qui nous intéressent), et pas mal aussi à 0xF0xx (registres de configuration divers), 0xF1xx (le watchdog) et 0xF2xx (les GPIO). En fait, en examinant un autre registre spécial, celui utilisé pour lire la flash (0xF808 et 0xF809, indiquant l'octet bas et haut de l'adresse lue/écrite), je vois qu'il vaut 0x6EFF, soit presque 28 kB, et que la flash pour cette puce est de 4 kB de flash ROM et 28 kB de flash pour le programme, que les accès jusqu'à 0x6Exx peuvent être des accès à la PMEM, en imaginant que la flash soit mappée ainsi (normalement de la flash n'est pas adressable par octet, il faut des opérations spéciales pour y accéder ; j'imagine qu'avec une archi ayant une mémoire de programme en lecture seule comme le 8051, mapper ça n'est pas trop compliqué). De plus, le registre de protection de flash (une autre idée qui m'est venue après) indique la plage 0x7000-0x7F80 à protéger ; j'imagine que c'est un bout du bootloader, donc les 4 kB de flash ROM mappées successivement à la flash programme. Du coup on arrive à 0x8000 (28 kB + 4 kB = 32 kB = 0x8000), mais toujours pas d'explication sur ce que c'est… Un alias de la XRAM, peut-être, vu qu'on reste dans les deux premiers kB ? (< 0x8800) Je n'ai pas de réponse aujourd'hui…

Bon, ça serait un truc à explorer mais je vais m'arrêter là pour l'instant. Je n'ai trouvé qu'une seule référence à ce genre de reverse-engineering, sur Twitter par un chercheur en sécu…

On aperçoit aussi dans la sortie de decode-dimms une indication sûr une sonde thermale « compatible TSE2004 ». Qu'est-ce donc, et y aurait-il déjà quelque-chose pour ça dans le noyau ? À la bourrin, je grep les sources :

git grep -i tse2004

On trouve le driver jc42, issu du sous-système de surveillance du matériel (hwmon) qui semble correspondre à ce capteur de température. On charge ce driver :

modprobe jc42

Rien dans dmesg, c'est pratique… Mais quand on lance un i2cdetect 0, on voit que les périphérique 0x1a et 0x1b ont été captés par un driver (UU remplace leur adresse), on suppose donc que ça a bien fonctionné. Sans avoir à lancer les outils en espace utilisateur de surveillance matérielle (qui doivent sûrement être très bien, mais je veux juste voir si ça marche), je farfouille dans /sys à la recherche d'un truc lié, sachant qu'il doit y avoir d'autres sondes hwmon disponibles qui rendent la distinction moins facile — i.e. /sys/class/hwmon en indique plus que deux… mais on voit que les deux derniers viennent d'être ajoutés ! J'étais parvenu à les trouver autrement, en allant dans /sys/class/i2c-dev/i2c-0/device/0-001a/ et en allant voir les données du drivers associé, dans hwmon/. Et donc on interroge la température actuelle des DIMM (adaptez les indices pour votre cas) :

cat /sys/class/hwmon/hwmon{4,5}/temp1_input
34500
35000

En millième de degré celsius, je suppose. Mais en fait, on peut aussi faire ça à la main, après avoir déchargé le driver :

modprobe -r jc42

En suivant jc42_read dans le driver jc42, qui va chercher le registre JC42_REG_TEMP qui est le 0x5, en lisant un mot inversé, puis le multiplie par 125/2, on peut y arriver :

i2cget -y 0 0x1a 0x5 w

Nous donne par exemple 0xfcc1, soit 0xc1fc*125/2 = 3103750, qui a donc un nombre de décimales étrange mais semble être la bonne valeur (ce second test a été effectué à un moment plus froid).

Voilà, je pense qu'on a déjà fait un bon tour de notre barrette de RAM et des différents périphérique auxilliaires qu'on trouve dessus… tout ça pour éteindre une lumière RGB !