serielle Schnittstelle, consolenausgabe vermeiden

[gznw]

Hallo! Ich habe auf zwei Systemen die serielle Schnittstelle von der Platine nach außen geführt.
Das eine ist eine NSLU2 (Linux version 2.4.22-xfs) und das andere ist eine eTRAYz (Linux version 2.6.24.4).
An diese serielle Schnittstelle möchte ich gerne jeweils einen Mikrocontroller setzen (ATmega), der dann z.B. Sensordaten erfasst, oder Aktoren ansteuert. für diesen Fall ist es nicht so günstig, dass z.B. während des Bootens sämtlihce Ausgaben auf dieser seriellen Schnittstelle ausgegeben werden. zuvor habe ich immer einen USB-seriell-Adapter verwendet, der jedoch nicht 100%ig zuverlässig läuft.
daher ist nun meine Frage, wie ich diese Datenausgabe unterbinden kann. Diese daten werden sowieso gar nicht benötigt, denn diese Schnittstellen sind gar nicht dafür gedacht gewesen nach außen geführt zu werden. Ich möchte nur eine bidirektionale Verbindung hierüber mit dem Mikrocontroller realisieren.
Habt ihr eine Idee?? Vielen Dank!

gznw

P.S.: besonders störend ist auf der etrayz, dass man sich auch bei der seriellen Schnittstelle mit passwort einloggen muss. Das vereinfacht das Ganze nicht unbedingt.

[ThorstenHirsch]

Schau dir mal die /etc/inittab an, da könnte das stehen.

[gznw]

Hi!
Also auf der nslu steht da nur:

slog:unknown:/sbin/syslogd -n
klog:unknown:/sbin/klogd -n


Auf der etrayz

id:3:initdefault:
sz::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0
l3:3:wait:/etc/rc.d/rc 3
l6:6:wait:/etc/rc.d/rc 6

ca:12345:ctrlaltdel:/sbin/shutdown -r now
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"
pr::powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"

s0::respawn:/sbin/agetty 115200 ttyS0 xterm
s1::respawn:/usr/sbin/udpglue
s2::respawn:/usr/sbin/nfsglue



die Zeile
s0::respawn:/sbin/agetty 115200 ttyS0 xterm

sieht so aus, als wenn die damit was zu tun haben könnte, aber wie soll ich die abändern? Und warum ist auf der nslu sowas nicht?
hmm...

[zyrusthc]

Schmeiss die Zeile einfach raus.
Aber ich vermisse da so etwas :

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6


Achja und schau dir auch mal die Bootloader Konfiguration an, dort konfiguriert man auch die Ausgabe auf ttyS"bla" beim booten.


Greeez Oli

[derguteweka]

Moin,

Aenderungen der inittab greifen erst, wenn init laeuft, also nach dem booten des Kernels. Man kann sich da auch aussperren - ein Plan B sollte also existieren.

Ich zitier' mal aus der Hilfe bei "make menuconfig" des Kernels:

CONFIG_SERIAL_8250_CONSOLE:
If you say Y here, it will be possible to use a serial port as the
system console (the system console is the device which receives all
kernel messages and warnings and which allows logins in single user
mode). This could be useful if some terminal or printer is connected
to that serial port.

Even if you say Y here, the currently visible virtual console
(/dev/tty0) will still be used as the system console by default, but
you can alter that using a kernel command line option such as
"console=ttyS1".

Wenn man das abschaltet und es geht mal was beim booten schief, ist man halt ein bisschen angeschmiert, weil man nicht weiss, was.
Gruss
WK

[gznw]

Also ich habe die Zeile gestern schon einmal auskommentiert, und neu gebootet... danach konnte ich über diese Schnittstelle jedoch gar nichts mehr machen.. also auch keine Befehle ausführen :-( seltsam..
Vom Prinzip her müsste diese Schnittstelle auch nicht als "Notfallzugang" nutzbar sein, denn eigentlich wäre diese Schnittstelle gar nicht dem normalen User zugänglich.. Ich weiß aber, wenn es mal ein Problem gibt, dann werde ich mich an diese Äußerung hier erinnern :-)
Oder kann man diese Ausgabe auf die andere Schnittstelle umleiten, auf die ich per ssh zugreife? - die wird sicher erst verfügbar sein, wenn das System vollständig gebootet hat, richtig? Für den Notfall muss ich halt einen Filter in das Programm des µControllers einbauen, der nur Zeilen durchlässt, die mit einer bestimmten Zeichenfolge beginnen, aber beim Booten schießen ja schlagartig so viele Zeilen raus und da es da keine Flusskontrolle gibt, könnte das da evtl. ein kleines Problem geben. Und richtig zufriden wäre ich mit der Lösung nicht...
Kann ich irgendwie heruasfinden, ob es vielleicht noch eine weitere serielle Schnittstelle gibt, die auf der Platine verborgen ist?

@zyrusthc: diese Zeilen sind ja bei keinem meiner beiden Systeme enthalten.. die Bootloaderconfig guck ich mir gleich mal an...

Danke schonmal für Eure Hilfe!!!

[zyrusthc]

Also ganz ehrlich wenn du die Serielle Console benötigst bzw. beibehalten willst dann ist das sinnvollste den IC, ne eigene Schnittstelle zu verpassen , sprich nen anderen Anschluss am Sysboard und fals nicht vorhanden einen nachkaufen, als pci karte oder halt per usb2serial.
http://www.ebay.de/itm/USB-RS232-RS-232-Seriell-Converter-Adapter-Kabel-COM-9p-/200621708656?pt=DE_Technik_Computerzubeh%C3%B6r_Ka bel_Adapter&hash=item2eb5fc5570
oder
http://www.ebay.de/itm/USB-RS232-TTL-Konverter-Adapter-PRO-/130603232560?pt=DE_Technik_Computerzubeh%C3%B6r_Ka bel_Adapter&hash=item1e688f2d30

Greeez Oli

[gznw]

Also ich habe bisher nur die console per ssh verwendet! Die soll weiterhin verfügbar sein. Zusätzlich habe ich jetzt die auf der Platine ungenutzte serielle Schnittstelle nach außen geführt und möchte die so nutzen, wie ich es zuvor mit dem USB2serial - converter gemacht habe. Die NSLU2, sowie die eTRAYz sind kleine Systeme, die keinen PCI-Slot besitzen. Der Weg über USB2serial-converter ist bisher recht unschön geworden, da
1. nur USB1-converter lauffähig sind
2. nur 2 USB-Ports verfügbar sind (USB-Hub müsste wiederum USB1 sein)
3. ständig unvorhersehbare Probleme mit diesen Convertern auftreten.. z.B. nach einem Neustart muss man häufig den converter einmal abziehen und wieder einstecken.
4. der direkte Befehl
echo "zeichenkette" > /dev/ttyUSB0 funktioniert nicht, nur wenn man die serielle Schnittstelle zuvor mit
/opt/bin/screen picocom.... offen hält. Ich habe wirklich sehr viel mit diesen Dingern abgeärgert und deshalb möchte ich diese "versteckte" serielle Schnittstelle dafür nutzten, da sie bei allen meinen Tests super funktioniert hat, nur eben die Tatsachen, dass das System alle Meldungen hier ausgbibt und man sich bei der eTRAYz auch noch anmelden muss, müsste beseitigt werden. Dann wäre ich glücklich.

//EDIT: Hier hab ich nochmal rausgesucht was das für ein Krampf damals vor 3 Jahren war mit den Adaptern auf den beiden Systemen... Die anfängliche Euphorie hat sich mit der Zeit etwas gelegt, als sich die kleinen Macken gezeigt haben...
http://nslu2-info.de/nslu2/unslung/7420-serielle-kommunikation-porteinstellungen/?128f36b9




soo, ich habe mir dann nochmal sie /etc/rc.sysinit angeguckt und dort steht sind viele Sachen zu sehen, die an /dev/console (also in dem Fall diese Schnittstelle) gesendet werden..
/bin/date > /dev/console
...

die serielle Schnittstelle wird doch sicher nicht /dev/console heißen, sondern /dev/console verweist auf diese Schnittstelle(es ist /dev/ttyS0), oder irre ich mich da? Könnte man diesen Verweis löschen?

[derguteweka]

Moin,

Mal was zu den netten Vorschlaegen an der inittab rumzuschrauben und "Zeilen rauszuschmeissen":
Ich weiss ja nicht, ob ihrs wisst, aber das ist kein PC, um den's da geht. Deswegen hat der nicht unbedingt PCI Slots um irgendwelche Karten reinzuhaengen. Weiterhin kanns durchaus auch sein, dass man sich den bei solchen Aktionen arg zerschiesst.
Auch koennte init mit einiger Wahrscheinlichkeit kein sysvinit sein, sondern das init aus busybox. Das verhaelt sich anders bzgl. inittab usw.

@gznw : Bist du zuversichtlich, dass du das Dingens immer wiederbeleben kannst, wenn du mal irgendwas an den Initscripten bzw. dem Kernel gedreht hast, was sich als "suboptimal" fuers Bootverhalten heraustellen sollte?
Sprich: Kannst du irgendwie mit dem Bootloader des Dingens das wieder irgendwie reparieren? Das sollte unbedingt sichergestellt sein.

Ansonsten: wenn dich die Kernelmeldungen beim booten stoeren, bringt das rumpfuschen in der inittab nix - wenn die drankommt, ist es schon zu spaet. Dagegen hilft nur einen Kernel bauen, der die von mir vorhin zitierte Option ausgeschaltet hat. Und dann kanns sein, dass du immernoch Zeugs vom bootloader siehst.


Also ich habe die Zeile gestern schon einmal auskommentiert, und neu gebootet... danach konnte ich über diese Schnittstelle jedoch gar nichts mehr machen.. also auch keine Befehle ausführen :-( seltsam..
Seltsam? nur wenn du nicht weisst, was du tust.
Wenn du irgendwas "privates" mit der Seriellen machen willst, dann darf doch da keine shell dranhaengen - dann musst du dafuer sorgen, dass sich "deine" Software dann um den seriellen Port kuemmert. Also darfst du dich nicht beschweren, wenn du keine "Befehle ausfuehren" kannst.

Am sinnvollsten und sichersten waere es imho, wenn du das Protokoll zu deinem Microcontroller so aufbaust, dass der "merkt", dass das Kernelblubber ist, und keine Kommandos fuer ihn.
Das klappt z.b. einigermassen mit einer PPP-Verbindung ueber die serielle Schnittstelle, wo auch Kernelmessages rauskommen. Da bricht dann nur die Datenrate etwas zusammen, weil TCP das dann ausbuegeln muss.

Gruss
WK

[Iluminat23]

wie derguteweka schon geschreiben hat, wir die serielle console vom kernel befüttert. der kernel interesiert sich nicht für kram den man dem init sagt. normal müsste man dem kernel beim booten mitgeben auf welches seriellen schnittstellen er sein blah blah los werden soll. gib uns doch mal die cmdline des laufenden kernel.

cat /proc/cmdline
vermutlich musst du die commandline anpassen um das akteulle verhalten abzustellen.

gruß iluminat23

[gznw]

Hi!
also auf dem einen System bekomme ich hierauf folgende Antwort:

console=ttyS0,115200 root=/dev/md0 ro raid=noautodetect md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda2,/dev/sdb2 mac_adr=0x00,0x1c,0x85,0x20,0x07,0xbd mem=128M poweroutage=yes


was wäre denn die sinnvollste Abänderung und wo müsste ich die abspeichern? ttyS1 statt ttyS0? ttyS1 gibt es jedoch nicht, soweit ich weiß.. oder ganz löschen? oder ieber Finger davon weg?

[zyrusthc]

Wenn den usbserial dran hast und mal "console=ttyS1" ausprobierst wird nichts auf diesem ausgespuckt?

Greeez Oli

[Iluminat23]

Hi!
also auf dem einen System bekomme ich hierauf folgende Antwort:

console=ttyS0,115200 root=/dev/md0 ro raid=noautodetect md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda2,/dev/sdb2 mac_adr=0x00,0x1c,0x85,0x20,0x07,0xbd mem=128M poweroutage=yes


was wäre denn die sinnvollste Abänderung und wo müsste ich die abspeichern? ttyS1 statt ttyS0? ttyS1 gibt es jedoch nicht, soweit ich weiß.. oder ganz löschen? oder ieber Finger davon weg?

wenn du willst, dass über die serielle KEINE kernel meldungen mehr kommen, musst du "console=ttyS0,115200" aus der commandline entfernen. /dev/console verwendet der kernel als ausgabe schnittstelle wenn dies nicht gesetzt ist wird er eben keine ausgaben machen. über dmesg lassen sich die bootmeldungen nach dem das system gebootet ist aber weiterhin einsehen.

wie und ob du die cmdline modifizieren kannst hängt von dem installierten system ab.

Gruß
iluminat23

[gznw]

ok, nun muss ich nur noch heruasfinden wo diese Einstellungen vorgenommen werden.
@ zyrusthc: das habe ich so noch nicht probiert, aber ich brauche diese Meldungen auch überhaupt nicht. Sie waren mir vorher auch nicht zugänglich.

[Iluminat23]

der boot loader übergibt die cmdline dem kernel wenn er diesen startet. auf dem desktop ist dies meist grub oder lilo. auf embedded geräten mit arm wird oft der uboot eingesetzt. in deinem fall musst du raus bekommen was für ein bootloader in deinen geräten eingesetzt wird und wie du dort die boot optionen ändern kannst.

gruß
iluminat23