Ich bin nicht sicher, auf welcher Ebene ich ein Problem habe.
Das System ist ein LeopardBoard DM368, auf dem TIs eigener SDK-/LSP-/BusyBox-Kernel läuft. Der Linux-Kernel ist 2.6.x und verwendet daher das Treibermodell serial_core.c.
Standardmäßig ist im System ein UART aktiviert, UART0, der gemountet ist und /dev/ttyS0auch über die Bootargs verwendet/aufgerufen wird console=ttyS0,115200n8 earlyprintk.
Wir möchten UART1 wie folgt aktivieren /dev/ttyS1: Daher haben wir den Low-Level-Initialisierungscode der Platine durchlaufen, der Pinmux, Uhren usw. einrichtet.
Beim Booten meldet die Low-Level-Initialisierung (über die von mir hinzugefügten Printks), dass UART1 aktiviert wurde, und auch der Treibercode meldet Zufriedenheit:
[ 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
Der Port erscheint jedoch nicht in /dev/(als /dev/ttyS1) und es gibt Unstimmigkeiten bei seinem Status (Flusssteuerungsbits), die meiner Vermutung nach dazu führen können, dass er hängen bleibt bzw. nie überträgt:
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
Wenn ich versuche, es über die Befehlszeile zu konfigurieren oder zu ändern, erhalte ich eine Fehlermeldung:
>: stty -F /dev/ttyS1
stty: can't open '/dev/ttyS1': No such file or directory
Seltsamerweise funktioniert es perfekt, wenn ich die Bootargumente auf console=ttyS1,115200n8 earlyprintkden Port ändere, und ttyS0 wird immer noch korrekt initialisiert und funktioniert auch:
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
Das wäre zwar in Ordnung, aber unser Bootloader muss UART0 verwenden, daher wäre es gut, alle Konsolenkrams auf ttyS0 zu behalten und ttyS1 für unsere sekundäre Kommunikation zu haben.
Ich habe ein paar printk’s in serial_core.c eingefügt und es scheint, als würde uart_open() nie für ttyS1 aufgerufen. Ich nehme an, es ist etwas in der Linux-Init-/Startsequenz, das geändert werden muss?
Herausgegeben: weil ich mich selbst getäuscht hatte, indem ich eine tat, echo >/dev/ttyS1die eineDateigenannt /dev/ttyS1, was die Sache etwas vernebelte. Ich bin mir jetzt zu 99 % sicher, /dev/ttyS1dassniemalserstellt.
Antwort1
mknod /dev/ttyS1 c 4 65
(wenn /devschreibgeschützt ist, verwenden Sie jedes beschreibbare Verzeichnis, das ohne die Option gemountet ist nodev)
Wenn der Knoten ohne Fehler erstellt wird, können Sie überprüfen, ob Ihr Patch beim Lesen/Schreiben auf dem Knoten oder mit einem beliebigen Terminalemulator funktioniert.
Das Problem ist, dass der Knoten nicht erstellt wird?
Wenn Sie einige Auto-Magic dynamische dev fs wie devfsoder udevwahrscheinlich gibt es einigeAnmeldungProblem in der Mitte (aber ich denke nicht, da der Großteil des Codes derselbe ist, um ttyS0 aufzurufen, und ich schätze, das Hinzufügen eines seriellen Ports ist wie das Hinzufügen einer Konfigurationszeile in einem Array in einer Plattformdatei).
Wenn Sie kein solches Entwicklungs-Fundament verwenden, haben Sie wahrscheinlich MAKEDEVirgendwo in Ihrem Build-Baum eine Datei, in die Sie manuell eine Zeile für Ihr neues Gerät einfügen können, das statisch erstellt werden soll. Ich habe auch ein System gesehen, bei dem die Entwicklungsknoten von einem Init-Skript erstellt wurden.