Die Sache mit ttyS0 serial0 ttyAMA0 UART und serial console

[Matthias76]

Hallo zusammen
Ich hatte beim Cubietruck mit meiner wilden Installation eines angepassten Ubuntu 14 auf Nand/SSD aufgegeben, meinen uart ganz automatisch nutzbar zu machen.
Beim booten war da immer die serielle Console drauf und das Modul in FHEM weg.

Jetzt wo ich nochmal neu durchstarte, habe ich es wohl wieder ein bisschen neuer oder anders, als die Massen.
Nun, es ist ein Raspberry Pi 4 mit 4GB Ram und 64GB SD-Card.
Darauf ist nun das offizielle Ubuntu 18.04.4 LTS für 64bit, also ARM64.

Auch hier hatte ich genau die gleichen Probleme.
Vor allem waren 100% aller Treffer falsch - also für das System.

Immer wieder Hinweise auf
/boot/cmdline.txt
/boot/config.txt
/etc/inittab
/etc/default/grub
/boot/grub/menu.lst
raspi-gpio
raspi-config

ALLE diese Dinge gab es nicht bei meinem Cubie und gibt es auch jetzt nicht beim RP4/U18.

Als Hilfe für alle, die auch mal in diese Fallen rennen könnten, hier das, wo ich es irgendwann nach langen Suchen gefunden hatte:
/boot/firmware/btcfg.txt
/boot/firmware/nobtcfg.txt
/boot/firmware/btcmd.txt
/boot/firmware/nobtcmd.txt
/boot/firmware/usercfg.txt

Dies sind sozusagen die boot.config und die cmdline.txt für den Fall dass Bluetooth (BT) an oder aus ist bzw. ob an/aus in der usercfg.txt.

Hier habe ich bestimmt, dass weder die serielle Console noch Bluetooth an sein soll und das uart=enabled ist.
Dadurch kann ich nun meine drei Pinne (GND, TX, RX) für das Empfangen des BMV-Polls (Batteriewächter von Victron) verwenden kann.
Das funktioniert auch soweit!

Aber eine Sache von damals ist auch jetzt geblieben. Vielleicht hat dazu jemand mal eine Idee:
Ein Reboot ist so nicht möglich: Ist die Verbindung gesteckt, fährt nach einem Neustart oder frischen Start das System nicht hoch!
Ich muss sie abziehen, dann hochfahren, dann dranstecken.

Ich dachte vorher noch, es kollidiere mit der seriellen Konsole, aber durch das Abschalten?!?

[Otto123]

Hi,

sind wirklich bloß die drei GPIO Pins beschaltet? Kein anderes Pin ist kontaktiert? Also nur Pin 6 / 8 / 10

Gruß Otto

[Matthias76]

Ja, dieses BMV wirft nur ununterbrochen in Endlosschleife seine Infos raus, ungefragt, ohne "Unterhaltung" und diese müssen nur abgefangen werden.

[enrikb]

Vermutlich stoppen die Zeichen auf der seriellen Schnittstelle deinen Bootloader während des Bootvorgangs.

Welche(r) Bootloader wird/werden denn in diesem Setup verwendet?

[Matthias76]

Wenn ich das mal wüsste, wie es Ubuntu macht.
Ich hatte die RP4/64-Bit-Installation hier her:
https://ubuntu.com/download/raspberry-pi

Es gibt in /boot einen Ordner "grub", aber der hat keinen Inhalt.
So sieht der sonstige Inhalt aus:
total 96464
-rw------- 1 root root  4038238 Jan 17 11:40 System.map-5.3.0-1017-raspi2
-rw------- 1 root root  4038777 Feb  4 19:51 System.map-5.3.0-1018-raspi2
-rw-r--r-- 1 root root   217231 Jan 17 11:40 config-5.3.0-1017-raspi2
-rw-r--r-- 1 root root   217209 Feb  4 19:51 config-5.3.0-1018-raspi2
lrwxrwxrwx 1 root root       44 Feb 23 07:03 dtb -> dtbs/5.3.0-1018-raspi2/./bcm2711-rpi-4-b.dtb
lrwxrwxrwx 1 root root       44 Feb 22 15:13 dtb-5.3.0-1017-raspi2 -> dtbs/5.3.0-1017-raspi2/./bcm2711-rpi-4-b.dtb
lrwxrwxrwx 1 root root       44 Feb 23 07:03 dtb-5.3.0-1018-raspi2 -> dtbs/5.3.0-1018-raspi2/./bcm2711-rpi-4-b.dtb
drwxr-xr-x 4 root root     4096 Feb 23 07:02 dtbs
drwxr-xr-x 4 root root     4096 Jan  1  1970 firmware
drwxr-xr-x 2 root root     4096 Feb  3 19:37 grub
lrwxrwxrwx 1 root root       28 Feb 23 07:02 initrd.img -> initrd.img-5.3.0-1018-raspi2
-rw-r--r-- 1 root root 21811418 Feb 22 15:13 initrd.img-5.3.0-1017-raspi2
-rw-r--r-- 1 root root 21835464 Feb 23 07:02 initrd.img-5.3.0-1018-raspi2
lrwxrwxrwx 1 root root       28 Feb  3 19:34 initrd.img.old -> initrd.img-5.3.0-1017-raspi2
lrwxrwxrwx 1 root root       25 Feb 23 07:02 vmlinuz -> vmlinuz-5.3.0-1018-raspi2
-rw------- 1 root root 25926144 Jan 17 11:40 vmlinuz-5.3.0-1017-raspi2
-rw------- 1 root root 25911808 Feb  4 19:51 vmlinuz-5.3.0-1018-raspi2
lrwxrwxrwx 1 root root       25 Feb  3 19:34 vmlinuz.old -> vmlinuz-5.3.0-1017-raspi2

Das Vorhandensein von dtb/uboot-Dateien interpretiere ich als "ist der Raspberry-Bootloader im Original Build von Ubuntu drin".

[pi4]
kernel=uboot_rpi_4.bin
max_framebuffers=2

[Otto123]

Andere Idee zum Test, Du spielst einfach mal eine SD Card mit Raspian und schaust ob sich das neu starten lässt ohne Probleme? Nur um zu sehen, das es kein "Hardware Problem" ist?

[enrikb]

[pi4]
kernel=uboot_rpi_4.bin
max_framebuffers=2

Wenn das ein mehr oder weniger Standard-Uboot ist, wird das an der seriellen Schnittstelle lauschen während des Bootvorgangs. Wenn dann ein Zeichen von der angeschlossenen Perihperie kommt, steht das Uboot in seiner 'shell'.

Du musst also herausfinden, wie du in diesem Setup dem Uboot das Lauschen an der seriellen Schnittstelle abgewöhnst.

Die Einstellungen aus config.txt (oder Äquivalent) sind ja erst für den Linux-Kernel.

Ich kenne mich aber mit Pi4 booten nicht aus, daher werde ich wohl nicht weiter helfen können.

[P.A.Trick]

Ich hatte auch Probleme mit meinem PI4 beim booten. Versuch mal

Code Auswählen Erweitern

boot_delay=1 in der

Code Auswählen Erweitern

/boot/config.txt

[Wernieman]

Ich würde an Deiner stelle anstatt Ubuntu ein "default" Distri für den Pi verwenden, also Debian oder Raspian. Es ist komnisch, was das Ubuntu Image dort macht.

Laut Kerneldokumentation:
https://www.kernel.org/doc/html/v4.10/admin-guide/serial-console.html

To use a serial port as console you need to compile the support into your kernel - by default it is not compiled in.

Hast Du in der Boot-Zeile für den Kernel folgendes drin:

Code Auswählen Erweitern

console=

Kenne mich jetzt aber auch nicht gut mit dem Boot-verhalten vom Pi (oder sonstigen ARM-Kleinst-Rechnern) aus ...

Edit:
Habe jetzt nochmals den therad durchgelesen und mir ist aktuell nicht klar:
Bootet Dein Rechner nicht oder startet FHEM nicht?

[Matthias76]

Ich denke, "enrikb" hat das Problem richtig erfasst und bewertet.
Von Debian wollte ich eigentlich weg, Raspian hat noch kein Arm64, oder?
Ne, eigentlich wollte ich SuSE, hätte ich auch auf Cubie fahren können, aber damit kommt FHEM schlecht zurecht.
Alleine schon wegen traditionellen YaST würde ich gerne "back 2 the roots", schade.

Nun, Ubuntu ist sicher eine optimale Wahl. Jetzt noch 18.04 LTS, bald schon 20.04 LTS.
Naja, dass jede Distro anders umschreibt (neue Links, neue Dateien, neue Orte, ständig neu das Rad erfinden) ist eine Sache, aber dass es in der gleichen quasi stetig bei jedem größeren Update passiert, eigentlich ein NoGo.
Auch da waren einst SuSE und RedHat deutlich beständiger und verlässlicher.

Aber sei es drum.
Ich hatte ja die passenden Stellen gefunden und nur das Problem übrig,
dass ich für einen Reboot (egal ob absichtlich oder nicht) die Verbindung vom UART / ttyS0 abziehen muss, da sonst der Bootprozess gar nicht beginnt.
Wenn ich danach den Stecker dran stecke, läuft alles super weiter und mein "COM1" funktioniert.

Es wäre halt nur schön, wenn auch ein (Re)-Boot [mit bestehender Verbindung] möglich wäre.
Dieses Problen hatte ich aber auch schon mit dem ausgehölten Debian/Ubuntu/Irgendwas auf dem Cubietruck.

[Wernieman]

Wie sich die Meinungen unterscheiden ... ich bin froh, nicht mehr mit yast arbeiten zu müssen ;o)

Wenn Du ein Vergleichbares Problem bei Cubi sowie Pi4 hast .... mal eine andere Frage:
Wenn Du ein Nagelneues nacktes System nimmst, tritt das problem auch auf? Würde aktuell an eine Useranpassung tippen ...

[enrikb]

Falls man beim pi4 den seriellen Port auch auf andere Pins legen kann und deine Hardware das ebenfalls unterstützt, würde ich noch versuchen, die Hardware an diese anderen Pins anzuschließen und dann erst im laufenden Linux (falls das geht) den seriellen Port auf diese Pins legen. Unmittelbar bevor die Hardware das erste mal verwendet wird. Evtl. reicht es auch, die Pin-Rekonfiguration in config.txt zu machen, aber nur wenn das U-boot das noch nicht auswertet.

Und natürlich sicherstellen, dass dieser Port keine Kernel-Konsole ist (dann könnte ein BREAK den Kernel immer noch stoppen) und auch kein getty auf dem Port läuft.

[Matthias76]

Ich weiß nicht, ob ich was "umlegen" kann.
Die GPIO-Stiftleiste ist ja genormt, hart verdrahtet, was wo liegt.
Beim einfachen UART ist immer nur von den verwendeten Pins die Rede.
So tief stecke ich nicht drin.

@Wernieman: Das ist der Witz an der Sache: Der Cuebie ist nun schon etwas veranzt, aber der Pi4 ist ganz neu - Samstag bekommen und direkt eingerichtet, ganz bewusst mit Ubuntu18LTS / ARM64.
Der sollte perfekt werden.

Da sind erstmal nur strikt nach Anleitungen die Dinge für FHEM und meine Hausautomation drauf.
Das Groß läuft auch schon und so hat er den Cubie bereits abgelöst.

Neuer, frischer und aufgräumter kann man kaum starten. :-D

[Otto123]

Hallo Matthias,

ich probier das die nächsten Tage mal, hab zwar keinen Pi4 aber das 64bit Ubuntu gibt es ja auch für den Pi3.

Ich hab noch keinen richtigen Plan, aber mal schauen was ich mit der UART anstellen kann

Gruß Otto

[Wernieman]

Habe aktuell keinen freien Pi .. meiner ist ausgeliehen .. (oder in Benutzung)