Não tenho certeza em que nível estou tendo problemas.
O sistema é um LeopardBoard DM368 executando o próprio kernel SDK / LSP / BusyBox da TI, o kernel Linux principal é 2.6.x, portanto, usando o modelo de driver serial_core.c.
Por padrão, o sistema tem um UART habilitado, UART0, montado como /dev/ttyS0o qual também é usado/invocado por meio do bootargs console=ttyS0,115200n8 earlyprintk.
Queremos habilitar o UART1 como /dev/ttyS1, então passamos pelo código de inicialização da placa de baixo nível que configura o pinmux, relógios, etc.
Na inicialização, o init de baixo nível informa (por meio do printk que adicionei) que ativou o UART1, e o código do driver também relata felicidade:
[ 0.547812] serial8250.0: ttyS0 at MMIO 0x1c20000 (irq = 40) is a 16550A
[ 0.569849] serial8250.0: ttyS1 at MMIO 0x1d06000 (irq = 41) is a 16550A
No entanto, a porta não aparece em /dev/(como /dev/ttyS1) e há discrepâncias com seu status (bits de controle de fluxo) que suspeito que possam estar causando o travamento/nunca transmissão:
cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A mmio:0x01C20000 irq:40 tx:97998 rx:0 CTS|DSR
1: uart:16550A mmio:0x01D06000 irq:41 tx:0 rx:0 DSR
Se eu tentar configurá-lo ou modificá-lo na linha de comando, recebo um erro:
>: stty -F /dev/ttyS1
stty: can't open '/dev/ttyS1': No such file or directory
Estranhamente, se eu mudar os bootargs para console=ttyS1,115200n8 earlyprintka porta funciona perfeitamente, e ttyS0 ainda é inicializado corretamente e funciona também:
cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A mmio:0x01C20000 irq:40 tx:0 rx:0 CTS|DSR
1: uart:16550A mmio:0x01D06000 irq:41 tx:11563 rx:0 RTS|DTR|DSR
Agora, isso seria bom, mas nosso bootloader deve usar UART0, então seria bom manter todo o material do console em ttyS0 e ter ttyS1 para nossas comunicações secundárias.
Inseri alguns printk em serial_core.c e parece que uart_open() nunca está sendo chamado para ttyS1, presumo que seja algo na sequência de inicialização/inicialização do Linux que precisa ser modificado.
Editado: porque eu me enganei fazendo um echo >/dev/ttyS1que criou umarquivochamado /dev/ttyS1, o que turvou um pouco as coisas. Agora tenho 99% de certeza /dev/ttyS1que énuncacriada.
Responder1
mknod /dev/ttyS1 c 4 65
(se /devfor somente leitura, use qualquer diretório gravável montado sem a opção nodev)
Se o nó for criado sem erros você pode verificar se o seu patch está funcionando lendo/gravando no nó ou com qualquer emulador de terminal.
O problema é que o nó não foi criado?
Se você estiver usando algum dev fs dinâmico automático como devfsou udevprovavelmente há algumcadastroproblema no meio (mas acho que não, já que a maior parte do código é o mesmo para trazer o ttyS0 e acho que adicionar uma porta serial é como adicionar uma linha de configuração em um array em algum arquivo de plataforma).
Se você não estiver usando dev fs assim, provavelmente você tem um MAKEDEVarquivo em algum lugar da sua árvore de construção onde adicionar manualmente uma linha para que seu novo dispositivo seja criado estaticamente. Também vi um sistema onde os nós de desenvolvimento foram criados por um script de inicialização.