¿Es posible obtener la información para un árbol de dispositivos usando / sys de un kernel en ejecución?


20

Comúnmente para sistemas de brazo, los árboles de dispositivos suministran información de hardware al núcleo (Linux). Estos árboles de dispositivos existen como archivos dts (fuente del árbol de dispositivos) que se compilan y cargan en el núcleo. El problema es que no tengo acceso a dicho dtsarchivo, ni siquiera a un dtbarchivo.

Tengo acceso a /sys, y /procen la máquina y que quería preguntar si eso me permitiría "adivinar los valores correctos" para ser utilizados en una EDE?

Además, la respuesta potencial podría resaltar adicionalmente el aspecto si la respuesta a esta pregunta también depende de si la interfaz del árbol de dispositivos se utilizó en primer lugar (es decir, dtbse creó y se proporcionó al núcleo) en lugar de algo más de piratería "simplemente nos desviamos de la vainilla y parchear el kernel para resolver el problema de información del dispositivo solo para nuestro kernel "-solution?


¿Tienes acceso a la imagen de arranque? Puede extraer el árbol de dispositivos desde allí. Puedo ayudar.
phk

Respuestas:


27

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

Creo que ambos son alias, /sys/firmware/devicetree/baseprobablemente sea la mejor opción después de la domesticación /proc.

Luego puede acceder a las propiedades dts desde los archivos:

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

El formato de salida para enteros es binario, por lo que hexdumpes necesario.

dtc -I fs

Obtenga un árbol de dispositivos completo del sistema de archivos:

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

saca los dts a stdout.

Consulte también: Cómo enumerar el Árbol de dispositivos del núcleo | Intercambio de pila de Unix y Linux

dtc en Buildroot

Buildroot tiene una BR2_PACKAGE_DTC=yconfiguración para poner dtcdentro del sistema de archivos raíz.

QEMU -machine dumpdtb

Si está ejecutando Linux dentro de QEMU, QEMU genera automáticamente los DTB si no los proporciona explícitamente -dtb, por lo que también puede volcarlos directamente con:

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

como se menciona en: https://lists.gnu.org/archive/html/qemu-discuss/2017-02/msg00051.html

Probado con esta configuración QEMU + Buildroot en el kernel de Linux v4.19 arm64.


4

No estoy seguro si te entiendo correctamente.

Si está en un sistema que se inició con un dtb, su árbol de dispositivos debería ser accesible desde debugfs.

También puede probar las herramientas dtc de Pantelis Antoniou, que incluyen fdtdump y fdtget que imprimen dts desde un blob.

Si no tiene un árbol de dispositivos en absoluto y no inició el arranque desde un dtb, deberá revisar el código de la máquina usted mismo y agregar todos los atributos y nodos específicos del dispositivo a sus dts. No existe un árbol de dispositivos "sintéticos" generado para tal arranque. Un punto de partida sería una máquina o padre similar y luego trabajar a su manera sistema por sistema.


Gracias por aclarar. Existe la posibilidad de que el dtbpodría ser accesible a través de a través de los debugfs sin embargo, que se basaría en CONFIG_DEBUG_FSen .confige incluso si se ha ajustado todavía en el mero capricho que en realidad utilizaron una dtbpara empezar, puedo leer este derecho? Así que con algo de "mala suerte" no hicieron nada y usaron algún tipo de parcheo directo del kernel en lugar de la interfaz del árbol de dispositivos, ¿verdad? Entonces esto significaría que el último recurso sería el código de la máquina, dado que violan GPLv2 y cierran la fuente del núcleo, ¿verdad?
humanityANDpeace

Sí y sí para los dos primeros. Por último, IANAL, pero la máquina arch / ??? / mach - ??? / board - ???. C contendría los dispositivos especiales presentes para una máquina en núcleos más antiguos. Esto debe estar cubierto por GPL y debe estar disponible por una tarifa. Los controladores de dispositivos individuales pueden ser de código cerrado, no hay violación allí.
FRob
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.