Hola a todos,

Estoy portar el kernel de linux 2.6.30rc2 de una arquitectura ARM, / arco / brazo / Mach-DaVinci, a un nuevo dispositivo, llamado Jacinto2.

Estoy utilizando el puerto serie ttyS0 como la consola por defecto. El gestor de arranque es de U-Boot y estoy usando busybox montado como un disco RAM interna SDRAM. Tengo el núcleo hasta el punto en que arrancará en el depósito, sin embargo en este punto mi experiencia de un extraño error.

El núcleo de la muestra '/ #' intérprete de comandos, pero el depósito no puede tener entrada de teclado. No va a reaccionar a cualquier tecla, pero puede mostrar texto.

Sin embargo, la serie de interrupción funciona correctamente, y si uso la printk para imprimir la amortiguación de serie (en función de uart_insert_char / include / linux / serial_core.h), imprime los caracteres de tipo I.

Estoy bastante seguro de mi busybox fs funciona bien, porque cuando pasa el init \u003d / bin / ls (redirige a busybox.ls), puedo ver a mi fs correctamente, y pasar un simple programa de hola mundo (init \u003d / hola) productos Espero que como texto.

Me siento de alguna manera la tty_buffer no es pasar los caracteres de la concha. He decidido que los personajes se están almacenando en la "tty_buffer" struct. Como sigo escribiendo, el buffer se llena de estos caracteres (en función de la tty_insert_flip_char / include / linux / tty_flip.h), pero nunca vacía.

¿Estoy equivocado, o en caso de que se liquidan como son los caracteres enrojecida espacio para el usuario? Además, ¿alguien sabe cómo pasa el tty su búfer en el espacio de usuario de programas como el depósito?

¿Alguien ha visto esto antes o tiene sugerencias para probar?

Gracias,
Joe


Registrarse --------- --------------------
...
Un disco ram: gzip imagen encontrada en bloque 0
EXT2-fs advertencia: fs sin montaje, se recomienda correr e2fsck
VFS: Montada raíz (sistema de ficheros ext2) en el dispositivo 1:0.
Liberación de inicio de memoria: 144K
uart_open (0) llama
ttyS0 - copia de seguridad mediante temporizador
*** Tratar los procesos de inicio: </ bin / sh>
*** Run_init_process (/ bin / sh)
/ #
--------------------------------
en este punto, mi printk del / de la serie de IRQ trabajará, pero el depósito no reacciona a la entrada de teclado

No tengo ninguna experiencia con arco. Sin embargo, hemos hecho una recompilación del kernel Linux para usar un mando a distancia ttyS0 como la consola. tldp.org tiene varios docsets para diferentes arquitecturas para la creación de las consolas de serie. Esto es genérico para todos los kernels de linux:

Consola remota de serie HOWTO

Así que, como resulta, la serie de capas de TTY y se multa.
El problema es que estoy teniendo con el schedule_delayed_work llamada.

La función de los conductores tty_flip_buffer_push / char / tty_buffer.c pide flush_to_ldisc, que empuja a los datos que el espacio de usuario, si la tty-> low_latency pabellón esté definido. De lo contrario, pulse en la agenda con schedule_delayed_work. El problema aquí es que este retraso en el trabajo nunca es renovado. Por lo tanto, mi personaje de entrada nunca fue enviada a través de espacio de usuario debido a que el programador nunca el proceso para hacerlo de nuevo.

Por el momento, tengo duro codificado a llamar flush_to_ldisc en lugar de la schedule_delayed_work, pero esto no es una solución, se trata de una solución. ¿Alguien tiene alguna sugerencia en cuanto a por qué la programación de esta convocatoria no se comportan correctamente?

Hay listas de correo que le dará mucha información con unos objetivos mejor definidos que este.

ha irc.freenode.net # U-Boot y ha irc.oftc.net # kernelnewbies. Existe también la lista de correo para el núcleo ARM.

Usted puede tener mucho mejor suerte obtener información específica de los mismos.

Quiero mirar en el archivo. Config. Si se trata de una plataforma soportada, apuesto hay un pequeño problema de configuración.

Gracias mgessner, voy a probar el irc listas a cabo.