어느 수준에서 문제가 있는지 잘 모르겠습니다.
시스템은 TI의 자체 SDK/LSP/BusyBox 커널을 실행하는 LeopardBoard DM368이며, 핵심 Linux 커널은 2.6.x이므로 serial_core.c 드라이버 모델을 사용합니다.
기본적으로 시스템에는 하나의 UART가 활성화되어 있으며 UART0이 마운트되어 /dev/ttyS0bootargs를 통해 사용/호출됩니다 console=ttyS0,115200n8 earlyprintk.
우리는 UART1을 로 활성화하고 싶기 /dev/ttyS1때문에 핀먹스, 클럭 등을 설정하는 하위 수준 보드 초기화 코드를 살펴보았습니다.
부팅 시 낮은 수준의 init는 UART1이 활성화되었음을 보고하고(내가 추가한 printk를 통해) 드라이버 코드도 행복을 보고합니다.
[ 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
그러나 포트는 /dev/(as /dev/ttyS1)에 나타나지 않으며 상태(흐름 제어 비트)에 불일치가 있어 포트가 중단되거나 전송되지 않는 것으로 의심됩니다.
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
명령줄에서 구성하거나 수정하려고 하면 오류가 발생합니다.
>: stty -F /dev/ttyS1
stty: can't open '/dev/ttyS1': No such file or directory
console=ttyS1,115200n8 earlyprintk이상하게도 bootargs를 포트가 완벽하게 작동하도록 변경하면 ttyS0도 여전히 올바르게 초기화되어 작동합니다.
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
이제 괜찮습니다. 하지만 우리의 부트로더는 UART0을 사용해야 하므로 모든 콘솔 항목을 ttyS0에 유지하고 ttyS1을 보조 통신용으로 사용하는 것이 좋을 것입니다.
serial_core.c에 몇 개의 printk를 삽입했는데 uart_open()이 ttyS1에 대해 호출되지 않는 것 같습니다. 수정이 필요한 Linux init/startup 시퀀스에 있는 것으로 가정합니다.
편집됨echo >/dev/ttyS1: 내가 만든 일을 해서 내 자신을 속였기 때문입니다.파일라는 /dev/ttyS1문제가 다소 흐려졌습니다. 나는 이제 99% 확신 /dev/ttyS1한다.절대만들어진.
답변1
mknod /dev/ttyS1 c 4 65
( /dev읽기 전용인 경우 옵션 없이 마운트된 쓰기 가능한 디렉토리를 사용하십시오 nodev)
노드가 오류 없이 생성되면 패치가 노드 또는 터미널 에뮬레이터에 대한 읽기/쓰기가 작동하는지 확인할 수 있습니다.
문제는 노드가 생성되지 않는다는 것입니다.
당신이 같은 자동 마법의 동적 개발 fs를 사용하고 있다면 devfs아마 udev그런 것들이 있을 겁니다.등록중간에 문제가 있습니다(그러나 대부분의 코드가 ttyS0을 불러오는 것과 동일하지 않으며 직렬 포트를 추가하는 것은 일부 플랫폼 파일의 배열에 구성 행을 추가하는 것과 같다고 생각합니다).
그런 식으로 dev fs를 사용하지 않는다면 아마도 MAKEDEV빌드 트리 어딘가에 정적으로 생성될 새 장치에 대한 줄을 수동으로 추가할 수 있는 파일이 있을 것입니다. 또한 init 스크립트에 의해 개발 노드가 생성된 시스템도 본 적이 있습니다.