È possibile ottenere le informazioni per un albero dei dispositivi usando / sys di un kernel in esecuzione?


20

Comunemente per i sistemi arm, gli alberi dei dispositivi forniscono informazioni hardware al kernel (Linux). Questi alberi dei dispositivi esistono come file dts (sorgente dell'albero dei dispositivi) che vengono compilati e caricati nel kernel. Il problema è che non ho accesso a tale dtsfile, nemmeno a un dtbfile.

Ho accesso a /syse /procsulla macchina e volevo chiedere se ciò mi avrebbe permesso di "indovinare i valori corretti" da utilizzare in un dts?

Anche la potenziale risposta potrebbe evidenziare ulteriormente l'aspetto se la risposta a questa domanda dipende anche dal fatto che l'interfaccia dell'albero dei dispositivi sia stata utilizzata in primo luogo (ovvero è dtbstata creata e fornita al kernel) invece di qualche altro hacking "semplicemente deviamo dalla vaniglia e patch il kernel in modo da risolvere il problema di informazioni sul dispositivo solo per il nostro kernel "-soluzione?


Hai accesso all'immagine di avvio? È possibile estrarre l'albero dei dispositivi da lì. Posso aiutare.
phk,

Risposte:


27

/proc/device-tree o /sys/firmware/devicetree/base

Penso che entrambi siano alias, /sys/firmware/devicetree/baseprobabilmente è la scelta migliore dopo l'addomesticamento di /proc.

È quindi possibile accedere alle proprietà di dts dai file:

 hexdump /sys/firmware/devicetree/base/apb-pclk/clock-frequency

Il formato di output per gli interi è binario, quindi hexdumpè necessario.

dtc -I fs

Ottieni un albero dei dispositivi completo dal filesystem:

sudo apt-get install device-tree-compiler
dtc -I fs -O dts /sys/firmware/devicetree/base

invia il dts a stdout.

Vedi anche: Come elencare l'albero dei dispositivi del kernel | Scambio di stack Unix e Linux

dtc in Buildroot

Buildroot ha una BR2_PACKAGE_DTC=yconfigurazione da inserire dtcnel filesystem di root.

QEMU -machine dumpdtb

Se stai eseguendo Linux all'interno di QEMU, QEMU genera automaticamente i DTB se non lo dai esplicitamente -dtb, e quindi è anche in grado di scaricarlo direttamente con:

qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine dumpdtb=dtb.dtb

come menzionato in: https://lists.gnu.org/archive/html/qemu-discuss/2017-02/msg00051.html

Testato con questa configurazione QEMU + Buildroot sul kernel Linux v4.19 arm64.


4

Non sono sicuro di averti capito correttamente.

Se sei su un sistema che si è avviato usando un dtb, l'albero dei tuoi dispositivi dovrebbe essere accessibile all'interno di debugfs.

Puoi anche provare gli strumenti dtc di Pantelis Antoniou, che includono fdtdump e fdtget che stampano dts da un blob.

Se non si dispone affatto di un albero dei dispositivi e non si è avviato l'avvio da un dtb, è necessario passare da soli il codice macchina e aggiungere tutti gli attributi e i nodi specifici del dispositivo al proprio dts. Non esiste un albero di dispositivi "sintetici" generato per tale avvio. Un punto di partenza sarebbe una macchina o un genitore simile e quindi lavorare in modo sistema per sistema.


Grazie per chiarire. C'è una possibilità che la dtbpotrebbe essere accessibile attraverso attraverso le debugfs ancora che sarebbe contare su CONFIG_DEBUG_FSin .confige anche se impostato ancora sul capriccio che in realtà usato una dtbper cominciare, faccio a leggere questo diritto? Quindi, con un po 'di "sfortuna", non hanno fatto nessuno dei due e hanno usato una sorta di patch del kernel diretto instabile dell'interfaccia dell'albero dei dispositivi, giusto? Quindi questo significherebbe che l'ultima risorsa sarà il codice macchina, dato che violano GPLv2 e chiudono il kernel, giusto?
umanità e

Sì e sì per i primi due. Infine, IANAL, ma l'arco della macchina / ??? / mach - ??? / board - ???. C conterrebbe i dispositivi speciali presenti per una macchina nei kernel più vecchi. Questo dovrebbe essere coperto da GPL e deve essere disponibile a pagamento. I driver dei singoli dispositivi potrebbero essere a sorgente chiuso, nessuna violazione lì.
Dal
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.