Olá todos,

Estou portabili 2.6.30rc2 kernel do Linux a partir de uma arquitetura ARM, / arch / arm / mach-DaVinci, para um novo dispositivo, chamado Jacinto2.

Eu estou usando a porta serial ttyS0 console como padrão. O bootloader é U-Boot e estou usando busybox montada como um ramdisk no interno SDRAM. Tenho o kernel para o ponto onde vai arrancar para o reservatório, no entanto, neste ponto, uma experiência estranha erro.

O kernel exibe o '/ #' casca pronta, mas a casca não pode tomar teclado. Não vai reagir a qualquer tecla, mas pode exibir texto.

No entanto, a série interromper funções corretamente, e se eu usar printk do buffer de impressão em série (em função uart_insert_char in / include / linux / serial_core.h), ele exibe os caracteres eu digito.

I'm pretty certeza meu busybox fs funciona bem, porque quando eu passar init \u003d / bin / ls (redireciona para busybox.ls), eu posso ver o meu fs adequadamente, e que passa de um simples programa Olá Mundo (init \u003d / Olá) realizações texto como eu esperava.

Sinto-me como certa a tty_buffer não está passando os personagens para o reservatório. Eu já determinou que os personagens estão sendo armazenados no "tty_buffer" struct. Como continuo escrevendo, o buffer enche com estes chars (Na tty_insert_flip_char função em / include / linux / tty_flip.h), mas nunca esvazia.

Sou enganado, ou esta deverá ser limpa como o chars são descarregadas para o usuário espaço? Além disso, alguém sabe como passar o seu tty tampão ao usuário programas espaciais, como a casca?

Alguém viu isso antes ou tiver sugestões para tentar?

Obrigado,
Joe


--------- Log --------------------
...
RAMDisk: gzip imagem encontrada no bloco 0
EXT2-fs warning: montagem Unchecked fs, é recomendado executar o e2fsck
VFS: Mounted root (ext2 filesystem) no dispositivo 1:0.
Libertar memória init: 144k
uart_open (0) denominado
ttyS0 - usando backup temporizador
*** Tentando init processos: </ bin / sh>
*** Run_init_process (/ bin / sh)
/ #
--------------------------------
Neste ponto, o meu printk's / serial IRQ's irá funcionar, mas o reservatório não reagir à entrada de teclado

Não tenho nenhuma experiência com arco. No entanto, fizemos um recompilar kernel Linux a utilizar um telecomando ttyS0 como a consola. tldp.org tem várias docsets para diferentes arquiteturas para a criação de consolas série. Isto é genérico para todos os kernels:

Remote Serial Console HOWTO

Então, como se fora, o TTY e série foram camadas finas.
O verdadeiro problema que estou tendo é com o schedule_delayed_work chamada.

A função tty_flip_buffer_push em drivers / char / tty_buffer.c chamadas flush_to_ldisc, que impele os dados ao usuário espaço, se o tty-> low_latency sinalizador está definido. Caso contrário, ele irá empurrar para o programador com schedule_delayed_work. O problema aqui é que este trabalho está atrasado nunca revisitado. Assim, a minha personagem de entrada nunca foi enviada ao usuário através do espaço, porque o programador nunca chamou o processo de fazê-lo novamente.

Por enquanto, tenho que dura para sempre codificada chamada flush_to_ldisc vez do schedule_delayed_work, mas esta não é uma correção, esta é uma solução. Alguém tem alguma sugestão de que esta seria chamada de programação não se comportar correctamente?

Existem listas que lhe dará muito mais orientados um feedback do que esta.

irc.freenode.net tem # u-boot e tem irc.oftc.net # kernelnewbies. Há também uma mailing-list para o ARM kernel.

Você pode ter muito melhor sorte recebendo feedback orientado a partir delas.

Gostaria de olhar em seu arquivo. Config. Se esta é uma plataforma suportada, eu aposto, há um pequeno problema configuração.

Graças mgessner, vou tentar o irc listas fora.