Error de compilación tipos en conflicto

Hola lenainjaune,

No sé de qué historial de un hilo anterior hablas :-)

Dicho esto, creo que tu problema está relacionado con el hecho de que no tienes un sistema Linux con un núcleo y los headers correspondientes, compatibles con el módulo que intentas compilar.

En general, en los errores de compilación, la primera advertencia o error es la más relevante.

Una búsqueda en elixir.bootlin.com muestra que, en el núcleo de Linux, es el encabezado dma-buf-map.h el que define struct dma_buf_map (ver mi edit a continuación*).

La salida de tu make muestra que tienes un kernel 5.10.0-20-amd64.

En esta versión del kernel, dma-buf-map.h no existe y struct dma_buf_map no está definida en ningún lugar.

https://elixir.bootlin.com/linux/v5.10.194/source/include/linux/dma-buf-map.h

Este encabezado parece existir y definir struct dma_buf_map a partir del kernel 5.11.

https://elixir.bootlin.com/linux/v5.11/source/include/linux/dma-buf-map.h#L115

Creo que necesitas una versión más actualizada del kernel y de sus headers para compilar este módulo.

---

* Edit: después de una búsqueda más detallada, parece que las versiones 5.11 a 5.17 del núcleo Linux contienen dma-buf-map.h

struct dma_buf_map no está definida en las versiones 5.18 y 5.19 del núcleo, ni en las versiones 6 del núcleo, que es la última versión principal en desarrollo.

Hola,

En teoría, deberías instalar tus encabezados de núcleo y lo necesario para compilar de la siguiente manera:

sudo apt update sudo apt install build-essential make linux-headers-amd64

Respecto al comentario de [Dal], esta estructura parece seguir existiendo en los encabezados del núcleo actual (6.4.0-3) en Debian testing:

/usr/src/linux-headers-6.4.0-3-common/include/linux/dma-buf.h

struct dma_buf { /** * @size: * * Tamaño del buffer; invariante durante la vida del buffer. */ size_t size; /** * @file: * * Puntero de archivo utilizado para compartir buffers y para refcontar. * Ver dma_buf_get() y dma_buf_put(). */ struct file *file; /** * @attachments: * * Lista de dma_buf_attachment que denota todos los dispositivos adjuntos, * protegido por &dma_resv lock @resv. */ struct list_head attachments; /** @ops: dma_buf_ops asociado con este objeto buffer. */ const struct dma_buf_ops *ops; /** * @vmapping_counter: * * Usado internamente para refcnt los vmaps devueltos por dma_buf_vmap(). * Protegido por @lock. */ unsigned vmapping_counter; /** * @vmap_ptr: * El puntero vmap actual si @vmapping_counter > 0. Protegido por @lock. */ struct iosys_map vmap_ptr; /** * @exp_name: * * Nombre del exportador; útil para depuración. Ver el * IOCTL DMA_BUF_SET_NAME. */ const char *exp_name; /** * @name: * * Nombre proporcionado por el espacio de usuarios; útil para contabilidad y depuración, * protegido por dma_resv_lock() en @resv y @name_lock para acceso de lectura. */ const char *name; /** @name_lock: Spinlock para proteger el acceso al nombre para acceso de lectura. */ spinlock_t name_lock; /** * @owner: * * Puntero al módulo exportador; utilizado para refcontar cuando el exportador es un * módulo del núcleo. */ struct module *owner; /** @list_node: nodo para la contabilidad y depuración de dma_buf. */ struct list_head list_node; /** @priv: datos privados específicos del exportador para este objeto buffer. */ void *priv; /** * @resv: * * Objeto de reserva vinculado a este dma-buf. * * REGLAS DE SINCRONIZACIÓN IMPLÍCITAS: * * Los controladores que admitan la sincronización implícita del acceso al buffer, como * por ejemplo, expuesto en `Soporte de sondeo de cerca implícita`_ deben seguir las * reglas a continuación. * * - Los controladores deben agregar una cerca de lectura a través de dma_resv_add_fence() con el * flag DMA_RESV_USAGE_READ para cualquier cosa que la API del espacio de usuarios considere un * acceso de lectura. Esto depende en gran medida de la API y del sistema de ventanas. * * - De manera similar, los controladores deben agregar una cerca de escritura a través de * dma_resv_add_fence() con el flag DMA_RESV_USAGE_WRITE para cualquier cosa que la API del espacio * de usuarios considere un acceso de escritura. * * - Los controladores pueden simplemente agregar siempre una cerca de escritura, ya que eso solo * causa una sincronización innecesaria, pero no problemas de corrección. * * - Algunos controladores solo exponen una API de espacio de usuarios sincrónica sin * canalización entre controladores. Estos no establecen cercas para su acceso. Un ejemplo aquí * es v4l. * * - El controlador debe usar dma_resv_usage_rw() al recuperar cercas como * dependencia para la sincronización implícita. * * REGLAS DE IMPORTADOR DINÁMICO: * * Los importadores dinámicos, ver dma_buf_attachment_is_dynamic(), tienen * restricciones adicionales sobre cómo configuran las cercas: * * - Los importadores dinámicos deben obedecer las cercas de escritura y esperar a que se * señalicen antes de permitir el acceso al almacenamiento subyacente del buffer * a través del dispositivo. * * - Los importadores dinámicos deben establecer cercas para cualquier acceso que no * puedan deshabilitar inmediatamente desde su &dma_buf_attach_ops.move_notify * callback. * * IMPORTANTE: * * Todos los controladores y funciones relacionadas con la gestión de memoria deben obedecer las * reglas de struct dma_resv, específicamente las reglas para actualizar y * obedecer las cercas. Ver enum dma_resv_usage para descripciones adicionales. */ struct dma_resv *resv; /** @poll: para soporte de sondeo del espacio de usuarios */ wait_queue_head_t poll; /** @cb_in: para soporte de sondeo del espacio de usuarios */ /** @cb_out: para soporte de sondeo del espacio de usuarios */ struct dma_buf_poll_cb_t { struct dma_fence_cb cb; wait_queue_head_t *poll; __poll_t active; } cb_in, cb_out; #ifdef CONFIG_DMABUF_SYSFS_STATS /** * @sysfs_entry: * * Para exponer información sobre este buffer en sysfs. Ver también * `Estadísticas DMA-BUF`_ para el uapi que esto habilita. */ struct dma_buf_sysfs_entry { struct kobject kobj; struct dma_buf *dmabuf; } *sysfs_entry; #endif }; 

Suponiendo que esta estructura sea la esperada por tu controlador, hay dos soluciones posibles:

1) Migrar a una Debian más reciente

Ten cuidado, no es una operación trivial, así que asegúrate de hacer copias de seguridad de los documentos que consideres importantes antes de empezar.

Si estás listo para migrar, corrige /etc/apt/sources.list, por ejemplo, de la siguiente manera para ir a Debian testing (= trixie, actualmente):

deb http://ftp.fr.debian.org/debian/ testing main contrib non-free-firmware deb http://security.debian.org testing-security main contrib non-free-firmware deb http://ftp.fr.debian.org/debian/ testing-updates main contrib non-free-firmware

... luego ejecuta:

sudo apt update sudo apt upgrade

De todos modos... tendrás que hacerlo tarde o temprano :-)

2) Instalar únicamente un núcleo más reciente

Si la migración te da miedo, puedes descargar los paquetes manualmente en packages.debian.org y luego instalarlos con dpkg -i.

• linux-image-amd-64
• linux-headers-amd64

wget http://ftp.fr.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-amd64_6.4.11-1_amd64.deb wget http://ftp.fr.debian.org/debian/pool/main/l/linux-signed-amd64/linux-headers-amd64_6.4.11-1_amd64.deb sudo dpkg -i linux-*-amd64.deb

(¡esperando que todas las dependencias ya estén instaladas!)

3) Solución intermedia: /etc/apt/preferences

La dificultad con la solución (2) es que a veces, recuperar las dependencias es particularmente laborioso (no debería suceder en tu caso). La idea es entonces referenciar en /etc/apt/sources.list los repositorios actuales y además los repositorios auxiliares (por ejemplo, los de Debian testing). Por lo tanto, sería copiar y pegar las líneas de las que hablé en la solución (1) al final del contenido actual de tu archivo.

Para indicarle a APT que priorice los paquetes proporcionados por Debian testing bajo ciertas condiciones, definimos un archivo en /etc/apt/preferences.d/ con un nombre arbitrario que sea un mínimo significativo (en tu caso, podría ser /etc/apt/preferences.d/ms9120 ya que es el nombre del módulo que estás intentando compilar).

Buena suerte

Hola,

Estoy de acuerdo con tus comentarios / respuestas / conclusiones [Dal] y lenainjaune. Solo un punto:

Entonces, si entiendo bien, no puedo adaptar el código para que funcione con mi núcleo actual.

Sí, pero hay que entender cómo reemplazar la estructura faltante dma_buf_map por su reemplazo. Esto requiere tener conocimientos en programación de núcleo, entender por qué esta estructura ha desaparecido y cómo proceder con un núcleo más reciente.

Si creo en este intercambio, aparentemente es porque la estructura ha sido renombrada a iosys_map (así como todas las funciones con prefijo dma_buf_map_* ven su prefijo corregido en consecuencia). Si es así, bastaría con corregir el código de tu controlador para probar la versión del núcleo y abstraer estos símbolos.

Ha pasado tiempo desde que hice programación en núcleo, pero inspirándote en esta discusión, podrías corregir cada ocurrencia de:

#include <linux/dma-buf-map.h>

en:

#ifdef __linux__ # if LINUX_VERSION_CODE < KERNEL_VERSION(6, 0, 0) # include <linux/dma-buf-map.h> # else # include <linux/iosys-map.h> # define dma_buf_map iosys_map # define DMA_BUF_MAP_INIT_VADDR IOSYS_MAP_INIT_VADDR # define dma_buf_map_set_vaddr iosys_map_set_vaddr # define dma_buf_map_set_vaddr_iomem iosys_map_set_vaddr_iomem # define dma_buf_map_is_equal iosys_map_is_equal # define dma_buf_map_is_null iosys_map_is_null # define dma_buf_map_is_set iosys_map_is_set # define dma_buf_map_clear iosys_map_clear # define dma_buf_map_memcpy_to iosys_map_memcpy_to # define dma_buf_map_incr iosys_map_incr # endif #endif

Para algo más limpio, podrías trasladar esta sección de código a un encabezado en la carpeta del módulo que intentas compilar (llamémoslo my-dfa-buf-map.h) y así, reemplazar:

#include <linux/dma-buf-map.h>

por:

#include "my-dma-buf-map.h"

Todo esto parte del principio de que solo es una cuestión de renombramiento...

Buena suerte

Si encuentras la tarea de editar los archivos del proyecto para aplicar los cambios propuestos por mamiemando en #10 tediosa o no estás seguro de ti mismo, puedes usar find y sed para hacer los cambios de manera permanente aplicando las modificaciones al lanzar esta línea.

Esto da como resultado lo siguiente en una sola línea, con GNU sed y find de tu sistema Linux:

find . -type f -not -path "./.git" -name "*.*" -exec sed -i 's/dma-buf-map.h/iosys-map.h/g; s/dma_buf_map/iosys_map/g; s/DMA_BUF_MAP_INIT_VADDR/IOSYS_MAP_INIT_VADDR/g; s/dma_buf_map_set_vaddr/iosys_map_set_vaddr/g; s/dma_buf_map_set_vaddr_iomem/iosys_map_set_vaddr_iomem/g; s/dma_buf_map_is_equal/iosys_map_is_equal/g; s/dma_buf_map_is_null/iosys_map_is_null/g; s/dma_buf_map_is_set/iosys_map_is_set/g; s/dma_buf_map_clear/iosys_map_clear/g; s/dma_buf_map_memcpy_to/iosys_map_memcpy_to/g; s/dma_buf_map_incr/iosys_map_incr/g; ' {} \; 

El resultado es teóricamente un código que debería compilar en un sistema reciente que tenga un núcleo y los encabezados del núcleo que soporten la nueva API iosys-map.h (a partir de v5.18), si los cambios semánticos están correctamente identificados y los cambios se limitan a eso.

El código así modificado no compilaría en un sistema que utilice la antigua API dma-buf-map.h, en cambio (a diferencia de la solución de mamiemando que propone directivas de compilación que distinguen las versiones del núcleo).

Hola

He creado un comando de varias líneas principalmente para aplicar los parches que propones sin tener que editar manualmente los archivos (conservo el formato para futuros proyectos y trataré de afinar para encontrar una versión menos complicada y, espero, con mejor legibilidad :D). Si tienes soluciones de escritura o comandos más prácticos, estoy toda oídos.

Como dije en #10, la solución más clara/simple sería poner los #define que propongo en un encabezado y asegurarse de que esos #define se apliquen a todos los archivos implicados en tu módulo.

Propuse "my-dma-buf-map.h" (nombre arbitrario). En el caso particular de tu módulo, dado que el archivo ms912x.h está incluido en todas partes, solo tienes que agregar al principio de "ms912x.h" la directiva :

#include "my-dma-buf-map.h"

Ten en cuenta que también podrías simplemente poner el contenido de "my-dma-buf-map.h" directamente en "ms912x.h". Si planeas proponer tus cambios en una solicitud de extracción de GitHub, esto sería sin duda lo mejor, ya que realmente no hay razón para separar estas consideraciones del "ms912x.h". El único interés en mantener la separación es separar todas nuestras correcciones del código existente en lugar de desmenuzar el código a diestra y siniestra.

Te propongo la trayectoria que casi logró instalar teniendo en cuenta las propuestas de mamiemando y [Dal], que dan aproximadamente el mismo resultado, pero no estoy lo suficientemente capacitado para determinar las diferencias.

Las dos soluciones son equivalentes, pero diferentes en su realización. Para recordar, cuando se compila un programa, en realidad hay varias etapas :

1. la precompilación (que solo resuelve las instrucciones precedidas de un #) : son solo tareas "simples" (#include = copiar y pegar ; #define = renombrar, etc.)
2. la compilación : cada archivo .c precompilado se convierte en un .o
3. el enlace : los .o se reúnen para formar el binario final (por ejemplo, un ejecutable, o una biblioteca (.so o .a), o un módulo (.ko)).

Volvamos a las dos soluciones que te propusimos :

• En #10, propongo con #define dejar que el precompilador haga el renombrado ;
• En #17, [Dal] propone hacer el trabajo del precompilador corrigiendo las fuentes con sed (así que estamos todavía antes de la precompilación ya que ni siquiera hemos llamado a gcc en esta etapa) ;
• En ambos casos, una vez pasada la etapa de precompilación, llegamos al mismo código fuente, y por eso desde el punto de vista de la compilación.

Hablemos brevemente de las ventajas / desventajas de las dos soluciones.

• La desventaja de #17 es que hay que hacer o no la manipulación según la versión del núcleo, mientras que en #10 dejamos que el compilador verifique la versión del núcleo y, en función de eso, determine si el renombrado es necesario o no. De hecho, es la oportunidad de hacer el

  "#include <drm/drm_edid.h>"

  ... únicamente si el núcleo se encuentra en una versión que proporciona este cabezera (te dejo mirar).

• La desventaja de #10 es que hay que agregar el archivo adicional e incluirlo en todas partes, lo que puede ser tedioso si el módulo implica un gran número de archivos. Pero en este caso, no es un gran problema, solo necesitas incluir "my-dma-buf-map.h" en "ms912x.h".

sept. 09 01:00:53 vm-bookworm kernel: ms912x: la verificación del módulo ha fallado: firma y/o clave requerida faltante - contaminando el núcleo

Por lo que veo aquí, parece que no has firmado tu módulo. No sé si esto es lo que desencadena los errores que siguen, pero es posible.

Este error es legítimo si utilizas un arranque seguro. De hecho, Linux se niega a cargar un módulo (.ko) si no ha sido firmado por una clave autorizada en el BIOS.

Concretamente, esto obliga a crear un par de claves, registrarlo en el BIOS (enroll), y usarlo para firmar el módulo (sign), y luego reiniciar. He detallado todo el procedimiento en este tutorial (ver sección "Creación del par de claves" y "Firma del módulo").

El problema de la firma de un módulo se plantea para cualquier módulo que puedas compilar, incluidos aquellos que compilarías a través de paquetes APT *-dkms. Para hacer que todo esto sea menos laborioso, las versiones recientes de Debian parecen generar un par de claves (que deben ser enroladas), pero aún no está muy claro. En fin, si es necesario, puedes volver al párrafo anterior.

Buena suerte

Hola lenainjaune,

La carga del módulo falla, y por el motivo de que los símbolos utilizados durante el intento de carga del módulo drm_gem_shmem_dumb_create y drm_gem_shmem_prime_import_sg_table son desconocidos o no son accesibles.

Estos símbolos están bien exportados por el núcleo de Linux 6.1, con directivas EXPORT_SYMBOL_GPL() que son macros que hacen que los símbolos sean inmediatamente accesibles para cualquier módulo que indique una licencia compatible con GPL.

https://elixir.bootlin.com/linux/v6.1/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L771

https://elixir.bootlin.com/linux/v6.1/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L771

(a partir de las versiones 5.2 del núcleo)

Supongo que estás intentando cargar el módulo en un núcleo 6.1.

Por su parte, el módulo incluye una macro MODULE_LICENSE("GPL"); en ms912x_drv.c

Una hipótesis para tu problema podría ser que la carga falla porque tu módulo intenta acceder a una parte del núcleo que no está cargada, y que sería un(os) módulo(s) constituyendo una dependencia para tu tipo de hardware.

¿Puedes hacer un /usr/sbin/modinfo ./ms912x.ko para ver qué dice, en particular en la sección "depends:"?

@[Dal] EstadoColaborador

No sé de qué historial de un hilo anterior hablas :-)

No, obviamente, ya que solo existió hasta que hice clic tontamente en un enlace durante su previsualización :D, lo que abrió el enlace en la misma pestaña y, por tanto, me hizo perder todo el contenido del post que estaba redactando (para aquellos a los que les pase, existe una solución que consiste en guardar los datos en la memoria volátil para el proceso del navegador - posible pista aquí en Linux y requiere el paquete gdb; además, también existen addons como este para Firefox que conservan los datos del formulario).

Dicho esto, creo que tu problema está relacionado con el hecho de que no dispones de un sistema Linux con un núcleo, y los encabezados correspondientes, compatibles con el módulo que intentas compilar.

Estoy cada vez más convencido. El núcleo 5.10.0-20-amd64 en Debian 11 da como primer error error: conflicting types para dma_buf_map según tu análisis porque no es manejado por el núcleo y ahora acabo de intentar la compilación en Debian 12 con el kernel 6.1.0-10-amd64 (sí, tengo máquinas virtuales listas para las pruebas, no hay necesidad de migrar un sistema ;-) ) :

root@vm-bookworm:~/ms912x-main# make make CHECK="/usr/bin/sparse" -C /lib/modules/6.1.0-10-amd64/build M=/root/ms912x-main modules make[1] : entrando en el directorio « /usr/src/linux-headers-6.1.0-10-amd64 » CC [M] /root/ms912x-main/ms912x_registers.o In file included from /root/ms912x-main/ms912x_registers.c:4: /root/ms912x-main/ms912x.h:113:47: warning: ‘struct dma_buf_map’ declared inside parameter list will not be visible outside of this definition or declaration 113 | const struct dma_buf_map *map, | ^~~~~~~~~~~ CC [M] /root/ms912x-main/ms912x_connector.o In file included from /root/ms912x-main/ms912x_connector.c:7: /root/ms912x-main/ms912x.h:113:47: warning: ‘struct dma_buf_map’ declared inside parameter list will not be visible outside of this definition or declaration 113 | const struct dma_buf_map *map, | ^~~~~~~~~~~ /root/ms912x-main/ms912x_connector.c: En la función ‘ms912x_read_edid’: /root/ms912x-main/ms912x_connector.c:12:30: error: ‘EDID_LENGTH’ undeclared (first use in this function) 12 | int offset = block * EDID_LENGTH; | ^~~~~~~~~~~ /root/ms912x-main/ms912x_connector.c:12:30: nota: cada identificador no declarado se informa solo una vez por cada función en la que aparece /root/ms912x-main/ms912x_connector.c: En la función ‘ms912x_connector_get_modes’: /root/ms912x-main/ms912x_connector.c:26:16: error: implicit declaration of function ‘drm_do_get_edid’ [-Werror=implicit-function-declaration] 26 | edid = drm_do_get_edid(connector, ms912x_read_edid, ms912x); | ^~~~~~~~~~~~~~~ /root/ms912x-main/ms912x_connector.c:26:14: warning: assignment to ‘struct edid *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 26 | edid = drm_do_get_edid(connector, ms912x_read_edid, ms912x); | ^ /root/ms912x-main/ms912x_connector.c:28:15: error: implicit declaration of function ‘drm_add_edid_modes’ [-Werror=implicit-function-declaration] 28 | ret = drm_add_edid_modes(connector, edid); | ^~~~~~~~~~~~~~~~~~ cc1: algunos warnings se tratan como errores make[2]: *** [/usr/src/linux-headers-6.1.0-10-common/scripts/Makefile.build:255 : /root/ms912x-main/ms912x_connector.o] Error 1 make[1]: *** [/usr/src/linux-headers-6.1.0-10-common/Makefile:2037 : /root/ms912x-main] Error 2 make[1] : saliendo del directorio « /usr/src/linux-headers-6.1.0-10-amd64 » make: *** [Makefile:15 : modules] Error 2 

y noto que el primer error es error: ‘EDID_LENGTH’ undeclared diferente de la de Debian 11 y la advertencia anterior es warning: ‘struct dma_buf_map’ declared inside parameter list will not be visible outside of this definition or declaration

> eso indica claramente que el cambio de núcleo ha resuelto el problema mencionado en mi primer post, ¡pero que todo no está resuelto aún!

Además, en la sección de preguntas del proyecto ms912x, después de la compilación, alguien tiene este error insmod: ERROR: could not insert module ms912x.ko: Unknown symbol in module
from dmseg: y pregunta la versión del núcleo a utilizar para compilar el programa con éxito, pero como he dicho, hay poca actividad en el proyecto y claramente falta información. No diría que está abandonado, sino probablemente en pausa.

Vamos avanzando...

Una búsqueda en elixir.bootlin.com muestra que, en el núcleo de Linux, es el encabezado dma-buf-map.h el que define struct dma_buf_map (ver mi edición a continuación *).

No conocía la herramienta elixir.bootlin.com, así que fui a dar una vuelta y probé de esta manera en qué núcleos se utilizaba EDID_LENGTH y según lo que entiendo parece haber sido siempre soportado (me parece lógico dado que EDID es, si no recuerdo mal, un protocolo usado para que las pantallas puedan identificarse ante un sistema utilizando el cable de video como medio de transmisión, así que incluso para el VGA) pero aquí no entiendo por qué no incluiría el encabezado edid.h directamente o indirectamente a través de otro encabezado, pero no sé cómo determinar eso...

Además, según lo que dice la persona en las preguntas del proyecto, se podría reemplazar dma_buf_map por iosys_map y como no entendía por qué hice una búsqueda y encontré esto y haciendo las correlaciones con tu herramienta, concluyo lo siguiente:

dma_buf_map (v5.11-rc1 -> v5.18-rc3)

iosys_map (v5.18-rc1 -> v6.5.1 actualmente)

¡Esta herramienta es genial! :D

Además, en la sección de preguntas del proyecto, también hay alguien que pregunta por la posibilidad de poder compilar con el núcleo v6+ (que debería dar un resultado análogo al mío - ver arriba).

> por deducción: dado que en el código se utiliza dma_buf_map, debería probar todos los núcleos entre v5.11-rc1 y v5.18-rc3.

Parecería confirmar lo que afirmas...

Entonces, ¿la idea es probarlos uno por uno?

Si no me equivoco, hay 308 núcleos candidatos donde existe dma_buf_map...

¿No habría forma de reducir y centrar esta lista porque, bueno, tengo otras cosas que hacer además de probar 300 núcleos? :(

¿Necesitas este módulo para qué exactamente?

No quería abordar el tema, porque creo que puede ser polémico. He adquirido un adaptador USB/VGA barato para poder conectar fácilmente una pantalla VGA adicional por USB. He logrado hacerlo funcionar en Windows 10 en una VM con los controladores proporcionados en el soporte (hoy en día ya no puedo, no entiendo por qué y no voy a perder tiempo en un sistema propietario); tenía la esperanza de poder hacer lo mismo en Linux.

root@vm-bookworm:~/ms912x-main# lsusb | grep -i vga Bus 001 Device 003: ID 534d:6021 MacroSilicon VGA Display Adapter

Por aquí y por allá leo que no se puede hacer eso en Linux, que nadie desarrolla un controlador, que hay que gastar dinero en equipos o cambiar de solución de hardware... hasta que encontré esto que parece responder perfectamente a mis necesidades ya que, como se indica en la primera frase controlador del núcleo de Linux para adaptador USB a VGA/HDMI de MacroSilicon. VID/PID es 534d:6021. El dispositivo es USB2.0

¡Vaya! ¡Parece que es justo lo que necesito! :D

Entonces, el primer paso es lograr compilar, el segundo será cargar y el tercero entender por qué... la visualización no funciona por sí sola :D (ya tengo experiencia en Linux) y puede que un día funcione, pero en todo caso habré aprendido un montón de cosas para lograrlo.

Eso es todo... :D

@mamiemando EstadoModerador

1) Migrar a una Debian más reciente

2) Instalar solo un núcleo más reciente

No es necesario, por ahora estoy probando en VM

De todos modos... tarde o temprano tendrás que hacerlo :-)

O... tal vez no ;D! Estoy bromeando medio en serio, pero mientras no logre encontrar el método adecuado para migrar las aplicaciones, la configuración, seguiré en Debian 11. Hay que decir que tengo muchas cosas que migrar y que, bueno, el argumento de "como no funciona, hay que pasar a la versión n+1" sí, en teoría, pero en la práctica, ¡no tanto! Para que conste, antes de instalar Debian 11 en mi PC personal estaba en Ubuntu 12.04 LTS y en general funcionaba muy bien y pude vivir con ello, hasta que hace 2 años creo, las exigencias del software me obligaron a cambiar de sistema!

wget http://ftp.fr.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-amd64_6.4.11-1_amd64.deb
wget http://ftp.fr.debian.org/debian/pool/main/l/linux-signed-amd64/linux-headers-amd64_6.4.11-1_amd64.deb
sudo dpkg -i linux-*-amd64.deb

(esperando que todas las dependencias ya estén instaladas!)

Pequeño error :

sudo dpkg -i linux-*-amd64.deb

->

sudo dpkg -i linux-*amd64.deb

sin guion a la izquierda de amd64.deb, de lo contrario dpkg no instalará!

2) Instalar solo un núcleo más reciente

3) Solución intermedia: /etc/apt/preferences

Sí, como le dije a [Dal], intentaré centrarme en las versiones de los núcleos candidatos.

@[Dal] EstadoColaborador

Podrías crear una máquina virtual con un Ubuntu 22.04 LTS para probar.

He instalado la VM de Ubuntu esta mañana y probaré la instalación del núcleo esta noche cuando regrese.

Entonces, si entiendo bien, no puedo adaptar el código para que funcione con mi núcleo actual o tendría que adaptar las partes de un núcleo operativo a otro núcleo, pero para eso tendrían que estar todas las dependencias instaladas y no en conflicto. Me parece un gran lío de antemano, casi imposible :( (no creo que algo pueda ser realmente IMposible :D) ...

Tengo una inspiración que conecta varias ideas y tecnologías ...

Así a groso modo: pruebo en Ubuntu el núcleo operativo y veo si la compilación tiene éxito, al final si la pantalla es detectada y funciona, luego intento instalar este núcleo operativo en el Debian "que es apropiado" y ver si funciona también, si encuentro la asociación funcional, tal vez podría considerar pasar por un contenedor (entre otras cosas, si el paso de este dispositivo USB3 en passthrough es posible) para al final tener un núcleo operativo autónomo (de lo que he comprendido los contenedores son más reactivos y ahorradores que las VMs, en uso de recursos de espacio de almacenamiento, CPU, RAM) para luego poder ser instalado (en teoría) en cualquier distribución.

Esta dirección me entusiasma mucho porque resolvería muchos de mis otros proyectos :D

Por seguir ...

Nota: si te preguntas por qué busco a toda costa instalarlo en una distribución Debian en lugar de Ubuntu (su bebé, vamos ;) ), respondería (sin crear polémica) que estoy extremadamente decepcionado con la dirección comercial que ha tomado Canonical/Ubuntu en los últimos años y que boicoteo esta distribución (aunque en el pasado alababa sus virtudes).

Así, a grandes rasgos: ... estoy intentando instalar este núcleo operativo en el Debian "que está bien" y ver si funciona también,

También logré compilar el módulo en una VM Debian 11 después de haber compilado el núcleo v5.15.0-43 siguiendo este tutorial adaptado para la v5.15.0-43 y tras 3-4 horas de compilación (creo que voy a estudiar en serio la paralelización y añadir CPUs a la VM, porque es realmente largo ;)), constate que puedo cargar el módulo sin errores PERO que la pantalla no es detectada ni en GUI ni en CLI. Pero bueno, todavía no estoy seguro de que el problema no sea sólo por la virtualización (vControlador USB2 o 3, servidor de visualización X/Wayland, etc.). Voy a probar en una PC física a ver.

=> así que es "casi" un éxito!

@[Dal] EstadoColaborador

Los contenedores normalmente comparten el mismo núcleo que el host, así que no creo que puedas utilizar este proceso.

Ups, tienes razón :( ! Estaba tan emocionado que hice atajos. Aparentemente, los contenedores no llevan su propio núcleo (a verificar si esto es absolutamente imposible). Así que volvemos a la virtualización... y para disfrutar de una pantalla externa no me parece el medio más práctico (habrá que ver!).

Como mamiemando encontró el post original de los mantenedores del núcleo que establece cambios en la API:

https://lore.kernel.org/lkml/aa1312fc-197b-c1ab-6a18-369d49c1e8f8@xs4all.nl/t/

Sí, también lo mencioné en mis primeros posts, porque necesitaba investigar por qué la persona había sustituido dma_buf_map por iosys_map en el código del módulo con el núcleo v5.19.0. Sin embargo, para ser sincero, no tenía idea de cómo podría servirme y cómo utilizarlo. Así que voy a intentar la propuesta de mamiemando

=> por deducción: dado que en el código se utiliza dma_buf_map, debería probar todos los núcleos entre v5.11-rc1 y v5.18-rc3.

Recibí una respuesta en la sección de preguntas del proyecto ms912x. Aparentemente sería posible compilar con todos los núcleos entre v5.11 y v5.17.

Además, según este colaborador, el servidor X no sería lo mejor para permitir la gestión de una pantalla adicional con este módulo (una vez más, obtengo la información a cuenta gotas) y sería mejor utilizar Wayland según lo que entiendo.

En mi caso, Ubuntu utiliza Wayland y Debian utiliza X11, ¡eso es sin duda el problema de fondo!

El inconveniente es que mi entorno de escritorio preferido/asignado es XFCE4 y que solo lo gestionaría Wayland a partir de XFCE4 v4.18 y más bien a partir de v4.20 (en Debian 11, XFCE4 está en v4.16 y no se puede hacer una actualización de versión), además no he logrado que lightdm utilice xwayland (he sobrevolado un poco el tema).

Creo que he encontrado la parte sumergida del iceberg ...

Por lo que entiendo, para que funcione, hay que despedir XFCE4/lightdm ...

Tengo que seguir investigando ...

Por lo que entiendo, para que funcione, hay que salir de XFCE4/lightdm ...

Para quienes estén interesados, la instalación en Debian 11 con un núcleo soportado (probado con un núcleo v5.15.43 compilado) y el trío Gnome/GDM/xWayland se realizó sin grandes sorpresas y la pantalla se detecta, sin embargo, en mi entorno virtual (Qemu/KVM) hay un bug porque, una vez detectada, el ratón se comporta de manera extraña.

@[Dal] EstadoColaborador

Cuando el compilador envía este tipo de advertencia:

"In file included from /root/ms912x-main/ms912x_registers.c:4:
/root/ms912x-main/ms912x.h:113:19: warning: ‘struct dma_buf_map’ declared inside parameter list will not be visible outside of this definition or declaration"

donde te advierte que piensa que estás declarando una struct dentro de los parámetros de una función, significa en realidad que el código compilado no comprende la definición de la struct que debería estar en otro lugar (normalmente, en un encabezado).

OK, guardaré esta información porque el mensaje es confuso!

Ahora, el hecho de que el módulo funcione bien, con tal o cual gestor de escritorio o servicio gráfico, puede estar relacionado con las limitaciones del propio módulo, o incluso con problemas inherentes al núcleo de Linux utilizado que pueden haberse resuelto en versiones más recientes. Estas cuestiones están un poco alejadas del tema de la programación en C.

Sí, completamente, continuaré mis investigaciones en otro lugar y me concentraré en la compilación del módulo ...

Entonces podrías contribuir con el código del módulo modificado y hacer felices a algunos otros internautas que tengan el mismo hardware que tú :-).

Si encuentras la tarea de editar los archivos del proyecto para aplicar los cambios propuestos por mamiemando en #10 desalentadora o no estás seguro de ti mismo, puedes usar find y sed para hacer los cambios directamente aplicando las modificaciones ejecutando esta línea.

Propuesta #10 de mamiemando :

root@vm-bookworm:~# diff ~/ms912x-main/ms912x.h ~/ms912x-main_origin/ms912x.h 8,26d7 < #include <linux/version.h> < #ifdef __linux__ < # if LINUX_VERSION_CODE < KERNEL_VERSION(6, 0, 0) < # include <linux/dma-buf-map.h> < # else < # include <linux/iosys-map.h> < # define dma_buf_map iosys_map < # define DMA_BUF_MAP_INIT_VADDR IOSYS_MAP_INIT_VADDR < # define dma_buf_map_set_vaddr iosys_map_set_vaddr < # define dma_buf_map_set_vaddr_iomem iosys_map_set_vaddr_iomem < # define dma_buf_map_is_equal iosys_map_is_equal < # define dma_buf_map_is_null iosys_map_is_null < # define dma_buf_map_is_set iosys_map_is_set < # define dma_buf_map_clear iosys_map_clear < # define dma_buf_map_memcpy_to iosys_map_memcpy_to < # define dma_buf_map_incr iosys_map_incr < # endif < #endif < 137c118 < #endif --- > #endif \ No newline at end of file 

Nota: LINUX_CODE_VERSION implica #include <linux/version.h> de lo contrario no estará definido y se obtendrá un error igualmente confuso error: missing binary operator before token "("

root@vm-bookworm:~# uname -r 6.1.0-10-amd64 root@vm-bookworm:~# make ... /root/ms912x-main/ms912x_connector.c:12:30: error: ‘EDID_LENGTH’ undeclared (first use in this function) 12 | int offset = block * EDID_LENGTH; ...

=> se obtiene el mismo error que #6

La propuesta de [Dal] #17 da el mismo resultado

Así que busqué acerca del error EDID_LENGTH y encontré esto y al pasar rápidamente sobre el intercambio encontré esto que propone añadir el encabezado #include <drm/drm_edid.h>; probé agregarlo al ms912.h y esta vez obtuve esto:

root@vm-bookworm:~/ms912x-main# make make CHECK="/usr/bin/sparse" -C /lib/modules/6.1.0-10-amd64/build M=/root/ms912x-main modules make[1] : entering directory « /usr/src/linux-headers-6.1.0-10-amd64 » CC [M] /root/ms912x-main/ms912x_registers.o CC [M] /root/ms912x-main/ms912x_connector.o CC [M] /root/ms912x-main/ms912x_transfer.o CC [M] /root/ms912x-main/ms912x_drv.o LD [M] /root/ms912x-main/ms912x.o MODPOST /root/ms912x-main/Module.symvers CC [M] /root/ms912x-main/ms912x.mod.o LD [M] /root/ms912x-main/ms912x.ko BTF [M] /root/ms912x-main/ms912x.ko /bin/sh: 1: ./tools/bpf/resolve_btfids/resolve_btfids: not found make[2]: *** [/usr/src/linux-headers-6.1.0-10-common/scripts/Makefile.modfinal:63 : /root/ms912x-main/ms912x.ko] Error 127 make[2]: *** Deleting « /root/ms912x-main/ms912x.ko » make[1]: *** [/usr/src/linux-headers-6.1.0-10-common/Makefile:1954 : modules] Error 2 make[1] : leaving directory « /usr/src/linux-headers-6.1.0-10-amd64 » make: *** [Makefile:15 : modules] Error 2 

Bueno, no sé a dónde voy, tendré que revisar esto con calma.

@mamiemando EstadoModerador
 

después de compilar el núcleo v5.15.0-43

• A priori no tienes razón para compilar el núcleo tú mismo, es todo el interés del tándem ofrecido por los paquetes linux-image-amd64 y linux-headers-amd64. Despliega un núcleo compilado y los headers necesarios para compilar un módulo compatible con este núcleo.

Sí, estoy de acuerdo, excepto que desde ciertas distribuciones (por ejemplo, la mía actual, Debian 11) no tengo realmente opción (recordatorio: ma_buf_map v5.11-rc1 -> v5.18-rc3 y iosys_map v5.18-rc1 -> v6.5.1 actualmente).

root@vm-bullseye-xfce:~# apt-cache search linux-image | grep headers linux-headers-5.10.0-20-amd64 - Archivos de encabezado para Linux 5.10.0-20-amd64 linux-headers-5.10.0-20-cloud-amd64 - Archivos de encabezado para Linux 5.10.0-20-cloud-amd64 linux-headers-5.10.0-20-rt-amd64 - Archivos de encabezado para Linux 5.10.0-20-rt-amd64 linux-headers-5.10.0-22-amd64 - Archivos de encabezado para Linux 5.10.0-22-amd64 linux-headers-5.10.0-22-cloud-amd64 - Archivos de encabezado para Linux 5.10.0-22-cloud-amd64 linux-headers-5.10.0-22-rt-amd64 - Archivos de encabezado para Linux 5.10.0-22-rt-amd64 linux-headers-5.10.0-25-amd64 - Archivos de encabezado para Linux 5.10.0-25-amd64 linux-headers-5.10.0-25-cloud-amd64 - Archivos de encabezado para Linux 5.10.0-25-cloud-amd64 linux-headers-5.10.0-25-rt-amd64 - Archivos de encabezado para Linux 5.10.0-25-rt-amd64 

Hola,

Nota: LINUX_CODE_VERSION implica #include <linux/version.h> si no, no se definirá y tendremos un error también confuso error: missing binary operator before token "("

Efectivamente.

 /bin/sh: 1: ./tools/bpf/resolve_btfids/resolve_btfids: no encontrado

Extraño este error. El paquete libbpf-tools parece que no proporciona este ejecutable. Mira por si acaso esta discusión.

no tengo realmente otra opción (recordatorio: ma_buf_map v5.11-rc1 -> v5.18-rc3 y iosys_map v5.18-rc1 -> v6.5.1 actualmente)

El propósito de los #define que mencioné es precisamente eliminar esta restricción reemplazando los símbolos obsoletos por los símbolos actuales.

Buena suerte

Hola lenainjaune,

"resolve_btfids" es una herramienta utilizada durante la compilación del núcleo y aparentemente de módulos.

Está presente en Linux v6.1.0 que estás utilizando:

https://elixir.bootlin.com/linux/v6.1/source/tools/bpf/resolve_btfids

pero no he visto paquetes de Debian que lo provean (ni en fuente ni en binario).

Con el código del núcleo correspondiente a Linux v6.1.0, podrías compilar este binario.

https://github.com/torvalds/linux/tree/v6.1

El código y el Makefile se encuentran por lo tanto en tools/bpf/resolve_btfids

Luego, puedes copiar el binario en el directorio de construcción del módulo en el lugar esperado, como se propone aquí:

https://aur.archlinux.org/packages/linux-git-headers?O=10#comment-836241

mkdir -p /lib/modules/$(uname -r)/build/tools/bpf/resolve_btfids/ cp /tmp/mybuilddir/linux-git/linux-git/src/linux/tools/bpf/resolve_btfids/resolve_btfids /lib/modules/$(uname -r)/build/tools/bpf/resolve_btfids/ 

(reemplazando el primer argumento de cp por la ubicación de tu binario)

Noticias ...

Instalar el módulo ms912x en Debian 12 con el núcleo predeterminado (v6.1.0-10)

@[Dal] EstadoColaborador

Saliendo de la generación de BTF para /root/ms912x-main/ms912x.ko debido a la falta de vmlinux

...

"resolve_btfids" es una herramienta utilizada durante la compilación del núcleo y aparentemente de los módulos. [...] Con el código del núcleo correspondiente a Linux v6.1.0, podrías compilar este binario.

Siguí tus recomendaciones (requiere el paquete libelf-dev) pero no fue suficiente para eliminar la advertencia, fue necesario seguir este procedimiento (probé la solución 1 con éxito) y después la advertencia desapareció. Además, esta advertencia no es a priori bloqueante, así que podemos ignorarla (ver más abajo).

Al final, el módulo se compiló con éxito PERO al momento de cargarlo, tuve un error "Símbolo desconocido en el módulo" que aún no he logrado resolver y por lo tanto el módulo no se carga (ver los detalles abajo).

@mamiemando EstadoModerador

Creé un comando de múltiples líneas principalmente para aplicar los parches que propones sin necesidad de editar manualmente los archivos (mantengo el lienzo para futuros proyectos y trataré de afinarlo para encontrar una versión menos complicada y con una mejor legibilidad :D). Si tienes soluciones de escritura o comandos más prácticos, estoy toda oídos.

---

Les propongo el camino que casi funcionó para instalar teniendo en cuenta las propuestas de mamiemando y [Dal], que dan aproximadamente el mismo resultado pero no estoy lo suficientemente capacitado para determinar las diferencias.

Preparaciones y recuperación del código fuente

root@vm-bookworm:~# apt update root@vm-bookworm:~# apt install -y build-essential gcc make cmake gettext git g++ intltool dbus-user-session vim sshfs root@vm-bookworm:~# wget https://github.com/rhgndf/ms912x/archive/refs/heads/main.zip root@vm-bookworm:~# unzip main.zip Archive: main.zip 86aac85d4347af8893c74cb8b7023187fc2e2f8b creando: ms912x-main/ inflando: ms912x-main/.clang-format inflando: ms912x-main/.gitignore inflando: ms912x-main/Makefile inflando: ms912x-main/README.md creando: ms912x-main/capturas/ inflando: ms912x-main/capturas/resoluciones inflando: ms912x-main/insmod.sh inflando: ms912x-main/ms912x.h inflando: ms912x-main/ms912x_connector.c inflando: ms912x-main/ms912x_drv.c inflando: ms912x-main/ms912x_registers.c inflando: ms912x-main/ms912x_transfer.c inflando: ms912x-main/registers root@vm-bookworm:~# cp -a ms912x-main ms912x-main_origen root@vm-bookworm:~# cd ms912x-main

Los headers del núcleo

root@vm-bookworm:~/ms912x-main# make make CHECK="/usr/bin/sparse" -C /lib/modules/6.1.0-10-amd64/build M=/root/ms912x-main modules make[1]: *** /lib/modules/6.1.0-10-amd64/build : No hay tal archivo o directorio. Parada. make: *** [Makefile:15 : modules] Error 2 # => headers del kernel ausentes # solución : https://devicetests.com/fixing-ubuntu-error-no-such-file-or-directory root@vm-bookworm:~# dpkg -l | grep $( uname -r ) ii linux-image-6.1.0-10-amd64 6.1.38-1 amd64 Linux 6.1 para PCs de 64 bits (firmado) root@vm-bookworm:~# apt install -y linux-headers-$( uname -r ) root@vm-bookworm:~# dpkg -l | grep $( uname -r ) ii linux-headers-6.1.0-10-amd64 6.1.38-1 amd64 Archivos de encabezado para Linux 6.1.0-10-amd64 ii linux-image-6.1.0-10-amd64 6.1.38-1 amd64 Linux 6.1 para PCs de 64 bits (firmado)

Encabezado faltante para dma_buf_map

root@vm-bookworm:~/ms912x-main# make make CHECK="/usr/bin/sparse" -C /lib/modules/6.1.0-10-amd64/build M=/root/ms912x-main modules make[1] : entramos en el directorio « /usr/src/linux-headers-6.1.0-10-amd64 » CC [M] /root/ms912x-main/ms912x_registers.o En el archivo incluido de /root/ms912x-main/ms912x_registers.c:4: /root/ms912x-main/ms912x.h:113:47: advertencia: ‘struct dma_buf_map’ declarado dentro de la lista de parámetros no será visible fuera de esta definición o declaración 113 | const struct dma_buf_map *map, | ^~~~~~~~~~~ CC [M] /root/ms912x-main/ms912x_connector.o En el archivo incluido de /root/ms912x-main/ms912x_connector.c:7: /root/ms912x-main/ms912x.h:113:47: advertencia: ‘struct dma_buf_map’ declarado dentro de la lista de parámetros no será visible fuera de esta definición o declaración 113 | const struct dma_buf_map *map, | ^~~~~~~~~~~ /root/ms912x-main/ms912x_connector.c: En la función ‘ms912x_read_edid’: /root/ms912x-main/ms912x_connector.c:12:30: error: ‘EDID_LENGTH’ no declarado (primer uso en esta función) 12 | int offset = block * EDID_LENGTH; | ^~~~~~~~~~~ /root/ms912x-main/ms912x_connector.c:12:30: nota: cada identificador no declarado se informa solo una vez por cada función en la que aparece /root/ms912x-main/ms912x_connector.c: En la función ‘ms912x_connector_get_modes’: /root/ms912x-main/ms912x_connector.c:26:16: error: declaración implícita de la función ‘drm_do_get_edid’ [-Werror=implicación-declaración-de-función] 26 | edid = drm_do_get_edid(connector, ms912x_read_edid, ms912x); | ^~~~~~~~~~~~~~~ /root/ms912x-main/ms912x_connector.c:26:14: advertencia: asignación a ‘struct edid *’ de ‘int’ hace un puntero de entero sin un tipo de conversión [-Wint-conversion] 26 | edid = drm_do_get_edid(connector, ms912x_read_edid, ms912x); | ^ /root/ms912x-main/ms912x_connector.c:28:15: error: declaración implícita de la función ‘drm_add_edid_modes’ [-Werror=implicación-declaración-de-función] 28 | ret = drm_add_edid_modes(connector, edid); | ^~~~~~~~~~~~~~~~~~ cc1: algunas advertencias se tratan como errores make[2]: *** [/usr/src/linux-headers-6.1.0-10-common/scripts/Makefile.build:255 : /root/ms912x-main/ms912x_connector.o] Error 1 make[1]: *** [/usr/src/linux-headers-6.1.0-10-common/Makefile:2037 : /root/ms912x-main] Error 2 make[1] : salimos del directorio « /usr/src/linux-headers-6.1.0-10-amd64 » make: *** [Makefile:15 : modules] Error 2 root@vm-bookworm:~/ms912x-main# make clean make -C /lib/modules/6.1.0-10-amd64/build M=/root/ms912x-main clean make[1] : entramos en el directorio « /usr/src/linux-headers-6.1.0-10-amd64 » make[1] : salimos del directorio « /usr/src/linux-headers-6.1.0-10-amd64 » rm -f /root/ms912x-main/Module.symvers /root/ms912x-main/*.ur-safe

Soporte para el encabezado dma_buf_map

Solución de mamiemando

Encabezado selectivo según versión de núcleo (ver #10)

Objetivo del comando de múltiples líneas: reproducibilidad y evitar errores

Nota: \n = salto de línea (newline)

Notas sobre la redacción de un comando de múltiples líneas complicado:

• ... | ... | ... : múltiples comandos encadenados
• ( ... \n ... ) > temp : salida de múltiples comandos en un archivo
• echo "..." > /dev/null : mi comentario de bricolaje :D !
• ... \\n ... : comando de múltiples líneas (\ estricto al final antes de \n)
• cat <<'EOF' \n ... \n ... \n EOF : heredoc (simplifica la escritura)
   ATENCIÓN : EOF debe ser estrictamente el único texto en la línea
• \ final estrictamente obligatorio en líneas FUERA de heredoc

Notas sobre los comandos:

• tac | ... | tac : permite gestionar por última coincidencia
• tac -b : resuelve la gestión extraña de la última línea
    (evita tener que agregar manualmente una línea al final de la
    entrada de comando)
• awk ...  { ... next } : evita que ocurra una coincidencia siguiente
• awk ... '...'\n'...' : múltiples líneas (SIN espacios alrededor del \n)
• ; final de línea obligatorio entre los bloques de comandos encadenados
• if [[ $( ! grep ... ) ]] ; then ... \n fi : evita una inserción
    adicional si ya está en su lugar

Nota: para entender la organización del comando, descarga el archivo ms912x.h desde su archivo ZIP

root@vm-bookworm:~/ms912x-main# \ src=ms912x.h ; \ ( echo "inicio precedido por \n -> última #include <linux/" > /dev/null ; \ echo ; \ cat $src | tac -b \ | awk '/^#include <linux\/.+>/ { print ; r = 1 ; next } r' \ | tac ; \ \ echo "inserción \n y encabezado para *VERSIÓN* necesaria" > /dev/null ; \ if [[ ! $( grep "#include <linux/version.h>" $src ) ]] ; then \ cat <<'EOF' #include <linux/version.h> EOF fi \ echo "otros #include -> última #define DRIVER_*" > /dev/null ; \ cat $src | tac -b \ | awk \ ' /^#define DRIVER_/ { print ; r = 1 ; next } '\ ' /^#include <linux\/.+>/ { exit } '\ ' r' \ | tac ; \ \ echo "adición de la gestión por versión de núcleo" > /dev/null ; \ if [[ ! $( grep "include <linux/dma-buf-map.h>" $src \ ) ]] ; then cat <<'EOF' #ifdef __linux__ # if LINUX_VERSION_CODE < KERNEL_VERSION(6, 0, 0) # include <linux/dma-buf-map.h> # else # include <linux/iosys-map.h> # define dma_buf_map iosys_map # define DMA_BUF_MAP_INIT_VADDR IOSYS_MAP_INIT_VADDR # define dma_buf_map_set_vaddr iosys_map_set_vaddr # define dma_buf_map_set_vaddr_iomem iosys_map_set_vaddr_iomem # define dma_buf_map_is_equal iosys_map_is_equal # define dma_buf_map_is_null iosys_map_is_null # define dma_buf_map_is_set iosys_map_is_set # define dma_buf_map_clear iosys_map_clear # define dma_buf_map_memcpy_to iosys_map_memcpy_to # define dma_buf_map_incr iosys_map_incr # endif #endif EOF fi \ echo "... resto intocado" > /dev/null ; \ cat $src | tac -b \ | awk '/^#define DRIVER_/ { exit } 1' \ | tac \ ) > temp

Verificación somera de que el comando anterior da el resultado correcto y reemplazar el contenido de ms912x.h por el de temp

root@vm-bookworm:~/ms912x-main# diff ms912x.h temp 7a8,9 > #include <linux/version.h> > 21a24,42 > #ifdef __linux__ > # if LINUX_VERSION_CODE < KERNEL_VERSION(6, 0, 0) > # include <linux/dma-buf-map.h> > # else > # include <linux/iosys-map.h> ... > # define dma_buf_map_incr iosys_map_incr > # endif > #endif > > 118c139,140 < #endif \ Sin final de línea al final del archivo --- > #endif > root@vm-bookworm:~/ms912x-main# mv temp ms912x.h

Solución de [Dal]

Ver #17

root@vm-bookworm:~/ms912x-main# find . -type f -not -path "./.git" -name "*.*" -exec sed -i 's/dma-buf-map.h/iosys-map.h/g; s/dma_buf_map/iosys_map/g; s/DMA_BUF_MAP_INIT_VADDR/IOSYS_MAP_INIT_VADDR/g; s/dma_buf_map_set_vaddr/iosys_map_set_vaddr/g; s/dma_buf_map_set_vaddr_iomem/iosys_map_set_vaddr_iomem/g; s/dma_buf_map_is_equal/iosys_map_is_equal/g; s/dma_buf_map_is_null/iosys_map_is_null/g; s/dma_buf_map_is_set/iosys_map_is_set/g; s/dma_buf_map_clear/iosys_map_clear/g; s/dma_buf_map_memcpy_to/iosys_map_memcpy_to/g; s/dma_buf_map_incr/iosys_map_incr/g; ' {} \; root@vm-bookworm:~/ms912x-main# diff -qr ~/ms912x-main ~/ms912x-main_origen/ Los archivos /root/ms912x-main/ms912x.h y /root/ms912x-main_origen/ms912x.h son diferentes Los archivos /root/ms912x-main/ms912x_transfer.c y /root/ms912x-main_origen/ms912x_transfer.c son diferentes root@vm-bookworm:~/ms912x-main# diff ~/ms912x-main/ms912x.h ~/ms912x-main_origen/ms912x.h 113c113 < const struct iosys_map *map, --- > const struct dma_buf_map *map, root@vm-bookworm:~/ms912x-main# diff ~/ms912x-main/ms912x_transfer.c ~/ms912x-main_origen/ms912x_transfer.c 160c160 < const struct iosys_map *map, --- > const struct dma_buf_map *map,

Encabezado faltante para el manejo de EDID

Nota: para el detalle del comando de múltiples líneas ver las notas arriba en la solución de mamiemando

root@vm-bookworm:~/ms912x-main# make ... /root/ms912x-main/ms912x_connector.c:12:30: error: ‘EDID_LENGTH’ no declarado (primer uso en esta función) 12 | int offset = block * EDID_LENGTH; | ^~~~~~~~~~~ root@vm-bookworm:~/ms912x-main# make clean root@vm-bookworm:~/ms912x-main# \ src=ms912x.h ; \ ( echo "inicio precedido por \n -> última #include" > /dev/null ; \ echo ; \ cat $src | tac -b \ | awk '/^#include.+/ { print ; r = 1 ; next } r' \ | tac ; \ \ echo "inserción \n y encabezado para EDID" > /dev/null ; \ if [[ ! $( grep "#include <drm/drm_edid.h>" $src ) ]] ; then cat <<'EOF' #include <drm/drm_edid.h> EOF fi \ echo "... resto intocado" > /dev/null ; \ cat $src | tac -b \ | awk '/^#include <drm\/.+>/ { exit } 1' \ | tac \ ) > temp root@vm-bookworm:~/ms912x-main# grep drm/drm_edid.h temp #include <drm/drm_edid.h> root@vm-bookworm:~/ms912x-main# mv temp ms912x.h root@vm-bookworm:~/ms912x-main# make ... Saliendo de la generación de BTF para /root/ms912x-main/ms912x.ko debido a la falta de vmlinux make[1] : salimos del directorio « /usr/src/linux-headers-6.1.0-10-amd64 »

El problema de la falta de vmlinux

Aconsejado por [Dal], seguí sus instrucciones desde #20

Advertencia: no sé si esta parte es necesaria ya que el mensaje del compilador es una advertencia y NO un error. Además, después de pruebas, su ausencia no impide generar el módulo compilado. Sin embargo, he notado que los archivos resultantes son diferentes dependiendo de si se maneja vmlinux o no. Así que aviso a los expertos ...

root@vm-bookworm:~/ms912x-main# cd root@vm-bookworm:~# wget https://github.com/torvalds/linux/archive/refs/tags/v6.1.zip root@vm-bookworm:~# unzip v6.1.zip root@vm-bookworm:~# cd linux-6.1/tools/bpf/resolve_btfids/ root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# make MKDIR /root/linux-6.1/tools/bpf/resolve_btfids/libbpf/ GEN /root/linux-6.1/tools/bpf/resolve_btfids/libbpf/bpf_helper_defs.h MKDIR /root/linux-6.1/tools/bpf/resolve_btfids/libbpf/staticobjs/ CC /root/linux-6.1/tools/bpf/resolve_btfids/libbpf/staticobjs/libbpf.o libbpf.c:46:10: error fatal: libelf.h: No hay tal archivo o directorio 46 | #include <libelf.h> | ^~~~~~~~~~ # => encabezado libelf.h faltante # solución : https://github.com/buserror/simavr/issues/170 root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# apt install -y libelf-dev root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# make # => OK archivo resolve_btfids compilado con éxito ! # # Continuación y final del #20 # root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# ls -dl /lib/modules/$(uname -r)/build/tools/bpf ls: no se puede acceder a '/lib/modules/6.1.0-10-amd64/build/tools/bpf': No hay tal archivo o directorio root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# mkdir -p /lib/modules/$(uname -r)/build/tools/bpf/resolve_btfids/ root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# cp resolve_btfids /lib/modules/$(uname -r)/build/tools/bpf/resolve_btfids/ # # Regresando a la compilación del módulo # root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# cd ~/ms912x-main root@vm-bookworm:~/ms912x-main# make clean root@vm-bookworm:~/ms912x-main# make ... Saliendo de la generación de BTF para /root/ms912x-main/ms912x.ko debido a la falta de vmlinux make[1] : salimos del directorio « /usr/src/linux-headers-6.1.0-10-amd64 » # => igual : mismo error ! # solución : https://devicetests.com/fixing-skipping-btf-generation-error-ubuntu-kernel-module-build root@vm-bookworm:~/ms912x-main# apt install -y dwarves root@vm-bookworm:~/ms912x-main# ls -ld /sys/kernel/btf drwxr-xr-x 2 root root 0 13 sep. 17:58 /sys/kernel/btf root@vm-bookworm:~/ms912x-main# ls -ld /usr/lib/modules/$(uname -r)/build lrwxrwxrwx 1 root root 37 14 jul. 05:46 /usr/lib/modules/6.1.0-10-amd64/build -> /usr/src/linux-headers-6.1.0-10-amd64 root@vm-bookworm:~/ms912x-main# cp -a /sys/kernel/btf/vmlinux /usr/lib/modules/6.1.0-10-amd64/build/ root@vm-bookworm:~/ms912x-main# make clean root@vm-bookworm:~/ms912x-main# make make CHECK="/usr/bin/sparse" -C /lib/modules/6.1.0-10-amd64/build M=/root/ms912x-main modules make[1] : entramos en el directorio « /usr/src/linux-headers-6.1.0-10-amd64 » CC [M] /root/ms912x-main/ms912x_registers.o CC [M] /root/ms912x-main/ms912x_connector.o CC [M] /root/ms912x-main/ms912x_transfer.o CC [M] /root/ms912x-main/ms912x_drv.o LD [M] /root/ms912x-main/ms912x.o MODPOST /root/ms912x-main/Module.symvers CC [M] /root/ms912x-main/ms912x.mod.o LD [M] /root/ms912x-main/ms912x.ko BTF [M] /root/ms912x-main/ms912x.ko make[1] : salimos del directorio « /usr/src/linux-headers-6.1.0-10-amd64 » # => OK sin advertencia de vmlinux

Cargar el módulo

root@vm-bookworm:~/ms912x-main# insmod /root/ms912x-main/ms912x.ko insmod: ERROR: No se pudo

Si estás considerando proponer tus modificaciones en un pull request de GitHub, sin duda sería lo mejor, ya que no hay realmente razón para llevar esas consideraciones fuera de "ms912x.h". El único interés en mantener la separación es para diferenciar todas nuestras correcciones del código existente en lugar de desmantelar el código aquí y allá.

Volveré sobre este punto que me interesa mucho ... ;)

Ambas soluciones son equivalentes, pero diferentes en su implementación.

Mi pregunta se centraba en el hecho de que los 2 binarios resultantes no sean idénticos (diff) utilizando el mismo kernel, cuando en mi lógica deberían serlo.

Concretamente, esto obliga a crear un par de claves, registrarlo en el BIOS (enroll), y usarlo para firmar el módulo (sign), y luego reiniciar. He detallado todo el procedimiento en este tutorial (ver sección "Creación del par de claves" y "Firma del módulo").

Tenía dudas sobre el tipo de BIOS que estaba utilizando (fuente) en cualquier caso en virtual da:

root@vm-bookworm:~# \ [ -d /sys/firmware/efi ] && echo BIOS UEFI || echo BIOS Legacy BIOS Legacy

De manera general, arranco mis sistemas (físicos y virtuales) en BIOS legacy y NO en BIOS EFI o MOK, que creo que es para EFI.

Como aún no he encontrado cómo firmar el módulo, intenté sortear desactivando la verificación de firmas para ver si el módulo se cargaría al final, pero en mi caso no funcionó (aunque aquí

A seguir ...

Tengo preguntas sobre todas sus respuestas. (Woody Allen)
¡Los conocimientos y las ideas pertenecen a todos (noosfera)!

Hola,

Mi pregunta se refería al hecho de que los 2 binarios resultantes no sean idénticos (diff) utilizando el mismo kernel, cuando en mi lógica deberían serlo.

No lo sé. Para hacer la comparación, deberías observar el resultado del preprocesador (lo que llamé más arriba la precompilación) con gcc -E para solo ejecutar el preprocesador. Así solo tendrás código fuente para comparar.

De manera general, inicio mis sistemas (físicos y virtuales) en BIOS legacy y NO en BIOS EFI, o MOK parece ser para EFI.

Efectivamente, en BIOS legacy, no tienes que preocuparte por firmar tu módulo. El arranque seguro es una funcionalidad propia de UEFI. Cuando está activado y el núcleo de Linux ha sido compilado "normalmente", el arranque seguro obliga a firmar los módulos compilados por uno mismo, de lo contrario, el núcleo de Linux rechaza (en general) cargarlos.

Como aún no he encontrado cómo firmar el módulo, quise eludir desactivando la verificación de firmas para ver si el módulo se cargaría al final, pero en mi caso no funcionó (sin embargo, aquí parece haber funcionado).

Para empezar, dado que estás en BIOS legacy, normalmente no tienes que preocuparte por firmar tu módulo.

En caso contrario, la firma de un módulo se detalla en el tutorial sobre el controlador nvidia que ya te indiqué (la sección "el módulo no está firmado"). Lo que se cuenta allí no es exclusivo de nvidia, sino de cualquier módulo compilado a mano o por DKMS. Una vez que se crea la clave, el script propuesto se encarga de firmar todos los módulos afectados, que podrán ser cargados una vez que hayas inscrito la clave.

En los enlaces que propones, que nunca he probado, se menciona la opción CONFIG_MODULE_SIG. Según lo que se explica aquí, es una opción de compilación del núcleo (así que no tiene nada que ver con el módulo que estás compilando).

• Por defecto, esta variable vale "y" y el núcleo generado rechazará si el arranque seguro está activado cargar un módulo DKMS o compilado a mano no firmado. Es típicamente la elección que se hace en un núcleo estándar (como el desplegado por linux-image-amd64, así que la elección ya se ha hecho).
• Cambiarlo a "n" permite no tener que firmar los módulos compilados a mano o mediante DKMS, pero hace que tu núcleo sea más vulnerable. En resumen, es una "solución" no muy elegante y no muy limpia. Es mejor crear tu clave y firmar tus módulos de manera adecuada.

Buena suerte