Simone
01685016df
Confronto fra la classe gs::IntelSKLXSmbus dei binari Armoury Crate e il nostro driver: nessuna divergenza, stessa mappa registri, registro per registro, device PCI 0x2085 compreso. Il valore non è una correzione ma una seconda conferma indipendente su un'interfaccia che il datasheet Intel non documenta per la PCU function 5 — la prima era PawnIO.Modules. Più tre dati che nei nostri doc non c'erano. Fonte dichiarata come claim di terzi ma verificabile (raw/ e disasm/ nella cartella non-git su partizione Windows), con due spot-check su due riscontrati sul disassemblato primario. Nessuna modifica al codice necessaria.
160 lines
9.6 KiB
Markdown
160 lines
9.6 KiB
Markdown
# Cross-check col reverse engineering vendor ASUS (`aura-re`) — 2026-08-26
|
|
|
|
> **Esito: nessuna divergenza. Il binario ASUS usa la stessa mappa registri del driver,
|
|
> registro per registro.** Il valore di questo confronto non è una correzione: è la
|
|
> **seconda conferma indipendente** su un'interfaccia che il datasheet Intel non documenta
|
|
> per la PCU function 5 — la prima era PawnIO.Modules (`SmbusIntelSkylakeIMC.p`,
|
|
> `TODO.md` §Notes) — più tre dati che nei nostri doc non c'erano.
|
|
|
|
| | |
|
|
|---|---|
|
|
| **Fonte** | `/media/simone/OS/Users/Simone/Desktop/aura-re` — analisi statica dei binari Armoury Crate, prodotta il **2026-08-26** (cartella non-git, sulla partizione Windows) |
|
|
| **Grado di fiducia** | claim di terzi, ma **verificabile**: `raw/` ha i binari, `disasm/` il disassemblato completo |
|
|
| **Spot-check fatto** | 2 su 2 riscontrati sul disassemblato primario, non sul solo testo — vedi §4 |
|
|
| **Ricaduta sul codice** | **nessuna modifica necessaria** |
|
|
|
|
---
|
|
|
|
## 1. Confermato — mappa registri identica
|
|
|
|
Confronto fra `aura-re/03-smbus-backends.md` (classe `gs::IntelSKLXSmbus`) e
|
|
`i2c-imc-skylake.c`.
|
|
|
|
| Elemento | ASUS `gs::IntelSKLXSmbus` | Nostro driver | Esito |
|
|
|---|---|---|---|
|
|
| Device PCI | DID `0x2085` | `PCU_DEVICE 0x2085` (`:95`) | identico |
|
|
| Canale 0 — CMD / STAT / DATA | `0x9C` / `0xA8` / `0xB4` | `:110-112` | identico |
|
|
| Canale 1 — CMD / STAT / DATA | `0xA0` / `0xAC` / `0xB8` | `:113-115` | identico |
|
|
| CMD `[7:0]` | BA, offset nel device | `GENMASK(15,0)` low byte (`:132`) | identico |
|
|
| CMD `[14:8]` | SA, indirizzo 7 bit | `:130-131` | identico |
|
|
| CMD `[15]` | WRT, 1 = scrittura | `WRITE_OPERATION BIT(15)` (`:154`) | identico |
|
|
| CMD `[17]` | WORD, accesso 16 bit | `WORD_BIT BIT(17)` (`:138`) | identico |
|
|
| CMD `[19]` | TRIGGER | `GO_BIT BIT(19)` (`:136`) | identico |
|
|
| CMD `[20]` | TSOD poll *(loro: `[inferenza]`)* | `TSOD_ACTIVE_BIT BIT(20)` (`:137`) | concorde |
|
|
| STATUS, letto come **byte** | `[0]` BUSY `[1]` ERROR `[2]` read done `[3]` write done | `:164-167` | identico |
|
|
| DATA — scrittura byte | `[23:16]` | `raw << 16` con `raw` a 8 bit (`:571-572`) | identico |
|
|
| DATA — scrittura word | `[31:16]` | `swab16(*value) << 16` (`:571-572`) | identico |
|
|
| DATA — lettura | `[15:0]` | `raw & 0xffff` / `& 0xff` (`:599-600`) | identico |
|
|
|
|
> **Perché conta.** La cover letter dice che il datasheet Intel (rif. 614073 §3.1.8)
|
|
> descrive un'altra interfaccia, sulla channel function, e **non** copre la function 5.
|
|
> Il HAL ASUS pilota la function 5 esattamente con la nostra codifica: la mappa non è più
|
|
> solo "misurata sul mio hardware".
|
|
|
|
## 2. Differenze di condotta — nessuna è un difetto nostro
|
|
|
|
- **Bit 29** — ASUS **non lo scrive mai**: legge il CMD e lo maschera con
|
|
`and dword ptr [r8], 0xfffe0000`, cioè conserva tutti i bit ≥ 17 e ricostruisce solo
|
|
`[16:0]`. Il bit 29 sopravvive perché **lo ha già messo il firmware**. Noi lo scriviamo
|
|
esplicitamente (`COMMAND_PREFIX`, `:155`) e abbiamo misurato che azzerandolo la
|
|
transazione fallisce con ERROR. Le due osservazioni sono coerenti; è un secondo dato per
|
|
la domanda "cos'è il bit 29" se un reviewer la fa.
|
|
- **Gate TSOD** — ASUS si limita a **rifiutare** la transazione se `CMD bit20 == 1`
|
|
(funzione `0x14001D720`, chiamata una sola volta via `std::call_once`). Noi facciamo di
|
|
più: check di `SMBCNTL.TSOD_POLL_EN` a probe (`:783`) **e** azzeramento + ripristino del
|
|
bit 20 su tutti i canali per ogni transfer (`imc_prepare_xfer`, `:517-548`). Il nostro
|
|
è strettamente più cauto — niente da importare.
|
|
- **`PNTR_SEL` (bit 18)** — ASUS non lo usa affatto. La scoperta del 27/07 resta solo
|
|
nostra: nessuna conferma, ma nemmeno contraddizione.
|
|
- **Timeout** — ASUS: 1000 iterazioni con attesa di ~237 µs (`0xED`) ≈ 237 ms.
|
|
Noi: poll 10 µs, timeout 50 ms idle / 200 ms GO / 50 ms done. Nessuna azione.
|
|
|
|
## 3. Dati nuovi, che nei nostri doc non c'erano
|
|
|
|
- 🚨 **Tabella CPUID → Device ID del vendor** (`0x140001510`, tab. in
|
|
`03-smbus-backends.md`):
|
|
|
|
| CPUID `>>4` | Famiglia | DID cercato |
|
|
|---|---|---|
|
|
| `0x306F` | Haswell-E / EP | `0x2FA8` |
|
|
| `0x406F` | Broadwell-E / EP | `0x6FA8` |
|
|
| `0x5065` | Skylake-X / Cascade Lake-X | `0x2085` |
|
|
|
|
- **Il vendor conferma che i due layout non sono intercambiabili.** Il ramo
|
|
`gs::IntelImcSmbus` (Haswell/Broadwell) usa `SMBSTAT 0x180` / `SMBCMD 0x184` /
|
|
`SMBCNTL 0x188` con TRIGGER a `[31]`, PNTR_SEL a `[30]`, WORD a `[29]`, WRITE a `[27]` —
|
|
**identico a `i2c-imc` di Lutomirski**; il ramo SKL-X è la codifica compatta che usiamo
|
|
noi. È l'argomento tecnico del perché serve un driver nuovo e non un'estensione di
|
|
`i2c-imc` (fonte: `aura-re/08-domande-aperte.md`, §"`IntelImcSmbus` contro `i2c-imc`").
|
|
- **ENE a `0x27`: il percorso vendor è write-only**, e ora lo si legge nel codice ASUS,
|
|
non in un commento di OpenRGB. Sessione `0xE1=0x01` + `0xE4=0x09`, colori
|
|
`0xEC`/`0xED`/`0xEE`, commit `0xDD=0x64`, **50 µs di attesa attiva fra una scrittura e
|
|
l'altra**, `Sleep(1 ms)` attorno all'apertura/chiusura, chiusura `0xE1=0x02` poi `0x03`.
|
|
Corrobora **P2** (chiusa il 10/08) da una fonte indipendente.
|
|
- **Gli indirizzi RGB dei moduli vengono *assegnati*, non sono di fabbrica**
|
|
(`EneRGBSDK::Dram_AssignAddress`, base `0x48`; `GskillLogic::ChangeAddress`). Quindi
|
|
`0x27` è "l'indirizzo dopo l'inizializzazione", non un dato di targa — da tenere
|
|
presente in ogni futura misura sull'ENE.
|
|
|
|
## 4. Spot-check sul disassemblato primario
|
|
|
|
Due claim presi a campione e riscontrati sul `.asm`, non sul testo del doc:
|
|
|
|
```
|
|
disasm/AacKingstonDramHal_x64.asm:337
|
|
0x000140001550 b885200000 mov eax, 0x2085 # tabella CPUID->DID, voce SKL-X
|
|
|
|
disasm/AacKingstonDramHal_x64.asm:33438
|
|
0x00014001d29f 4181200000feff and dword ptr [r8], 0xfffe0000 # ReadByte: conserva
|
|
# i bit >=17 (29 e 20)
|
|
```
|
|
|
|
## 5. 🚨 Vincolo: questo materiale non va su LKML
|
|
|
|
Deriva dal disassemblato di binari ASUS proprietari. Le affermazioni della patch e della
|
|
cover letter restano fondate **sulle nostre misure su hardware**, che ci sono già e bastano.
|
|
Il cross-check serve internamente (e in `docs/submission/review-answers.md`, gitignored),
|
|
non come citazione nel thread upstream.
|
|
|
|
## 6. Ricadute fuori da questo progetto
|
|
|
|
- **furyrs** — Kingston FURY: RGB a `0x58` (DDR4, base `0x57`+1) e `0x60` (DDR5, base
|
|
`0x5F`+1); mode register `0x08`: `0x53` `'S'` = controllo software, `0x44` `'D'` =
|
|
default; detect = ReadWord `0x05`/`0x06`/`0x88`/`0x26` con 20 ms fra i passi. Detect
|
|
del modulo RGB via SPD: manufacturer `0x0198` in `SPD[0x140/0x141]`, flag RGB =
|
|
**`SPD[0x168] bit 4`** (pagina 1, SPA1 `0x37`). Fonte: `aura-re/04-dram-kingston.md`.
|
|
- **tuf-x299-aura** — i LED della mobo **non stanno sull'i801**: stanno sul controller
|
|
SMBus del Super I/O **Nuvoton** (`0x2E`/`0x2F`, LDN `0x0B`, base da `0x62`/`0x63`), con
|
|
controller **AURA82** a `0x9C` 8 bit = **`0x4E` 7 bit** e pacchetti da 65 byte con marker
|
|
`0xEC`. Spiegherebbe sia lo scan i801 muto sia OpenRGB a zero controller.
|
|
Fonte: `aura-re/05-mobo-aura.md`, `06-porting-linux.md`.
|
|
|
|
## 7. Cosa ho già letto nel disassemblato (per non rifarlo)
|
|
|
|
Analisi mia del 26/08 sulla vtable di `gs::IntelSKLXSmbus`
|
|
(`disasm/AacKingstonDramHal_x64.rtti.txt:17-30`, 13 slot, base `gs::Smbus` ne ha 11 con
|
|
7 `_purecall`):
|
|
|
|
| Slot | VA | Cosa fa davvero | Ricaduta sul driver |
|
|
|---|---|---|---|
|
|
| 1-4 | `0x14001D310` / `D240` / `D3E0` / `D4A0` | read/write byte e word | già nostri |
|
|
| 6 | `0x14001CD60` | **block read emulata**: ciclo che chiama lo slot 4 (`call [rax+0x20]` = ReadWord) e impila 2 byte per giro in uno `std::vector` | **niente block hardware** |
|
|
| 7 | `0x14001CEB0` | **block write emulata**: ciclo che chiama lo slot 3 (`call [rax+0x18]` = WriteWord), impacchettando 2 byte per giro | idem |
|
|
| 8 | `0x14001D560` | write "nuda": `CMD &= 0xfffc00ff` (azzera `[17:8]`, **conserva BA `[7:0]`, bit 18, 20, 29**), poi `SA` in `[14:8]`, `WRT` in `[15]`, `GO` in `[19]`; nessun dato messo in DATA; indirizzo = `arg1 + arg2` a 8 bit; chiude con `WaitDone(isWrite=1)`. È il **page-select SPD** (SPA0/SPA1) che serve a leggere gli offset > `0xFF` | equivalente al nostro Send Byte, ma **senza** usare `PNTR_SEL` |
|
|
| 12 | `0x14001D5D0` | `slot % 6` → indice in tabella a `0x14007F938`, passo 4 | mappa slot logico → indirizzo |
|
|
|
|
Costruttore (`0x14001A3C5`-`0x14001A496`): crea **esattamente due** istanze, con
|
|
`(status, cmd, data)` = `(0xA8, 0x9C, 0xB4)` e `(0xAC, 0xA0, 0xB8)`. 🚨 **Nessun altro
|
|
offset del config space della function 5 viene toccato** in questo percorso: niente
|
|
registro nascosto da aggiungere al driver.
|
|
|
|
**Conclusione: dal materiale letto finora non esce nessuna feature hardware che ci
|
|
manchi.** Le domande che potrebbero ancora cambiare il driver sono in `TODO.md` §V,
|
|
item `V3`.
|
|
|
|
## 8. 🚨 Un claim di `aura-re` è sbagliato — verificato sul primario
|
|
|
|
`aura-re/06-porting-linux.md` §"Percorso 1" dice che *«esiste già un'implementazione Linux
|
|
funzionante: OpenRGB ha un driver SMBus per il Super I/O Nuvoton»* e cita
|
|
`i2c_smbus/i2c_smbus_nuvoton_nct6775.cpp`. **Quel file non esiste.** Su
|
|
`hw/OpenRGB-src` a `master` `8c19428b` (2026-08-08) l'unico backend Nuvoton è
|
|
`i2c_smbus/MacOS/i2c_smbus_nct6775.cpp` — **solo macOS**, esattamente come dice già
|
|
`hw/tuf-x299-aura/TODO.md` **B2**. Su Linux la strada resta il modulo out-of-tree
|
|
`i2c-nct6775` (`openrgb-dkms`) che espone un adapter i2c, non un backend interno di
|
|
OpenRGB: meccanismo diverso, e in `tuf-x299-aura` è bloccato per decisione di Simone
|
|
finché `W27` è aperta.
|
|
|
|
Morale operativa: `aura-re` è forte dove disassembla (i claim con indirizzo VA reggono lo
|
|
spot-check), debole dove riassume l'ecosistema Linux. Prendere i primi, verificare i
|
|
secondi.
|