どのレベルで問題が発生しているかわかりません。
システムは、TI独自のSDK/LSP/BusyBoxカーネルを実行するLeopardBoardDM368であり、コアLinuxカーネルは2.6.xであるため、serial_core.cドライバーモデルを使用します。
デフォルトでは、システムには1つのUART有効、UART0、/dev/ttyS0
としてマウントされ、bootargsconsole=ttyS0,115200n8 earlyprintk
を介して使用/呼び出されます。
UART1を/dev/ttyS1
として有効にしたいので、pinmux、クロックなどを設定する低レベルのボード初期化コードを実行しました。
起動時に、低レベルのinitは(私が追加したprintkを介して)UART1が有効になっていることを報告し、ドライバーコードも幸福を報告します。
[ 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/
に(/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
奇妙なことに、bootargsをconsole=ttyS1,115200n8 earlyprintk
に変更すると、ポートは完全に機能し、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を用意しておくと便利です。
いくつかのprintkをserial_core.cに挿入しましたが、uart_open()がttyS1に対して呼び出されていないようですが、Linuxのinit/startupシーケンスで変更が必要なものだと思いますか?
編集済み:echo >/dev/ttyS1
というファイルを作成した/dev/ttyS1
を実行して自分をだましていたため、多少曇っていました。私は今、/dev/ttyS1
が決して作成されていないことを99%確信しています。
mknod /dev/ttyS1 c 4 65
(/dev
は読み取り専用で、オプションnodev
なしでマウントされた書き込み可能なディレクトリを使用します)
ノードがエラーなしで作成された場合は、パッチがノードへの読み取り/書き込みまたはターミナルエミュレータで機能しているかどうかを確認できます。
問題は、ノードが作成されていないことです。
devfs
やudev
のような自動魔法の動的開発を使用している場合は、おそらく途中でいくつかの登録問題があります(しかし、私はほとんどの場合ほどではないと思いますコードはttyS0を起動するのと同じであり、シリアルポートを追加することは、プラットフォームファイルの配列に構成行を追加することに似ていると思います)。
このようなdevfsを使用していない場合は、ビルドツリーのどこかにMAKEDEV
ファイルがあり、静的に作成する新しいデバイスの行を手動で追加できます。開発ノードがinitスクリプトによって作成されたシステムも見ました。