FHEM Forum

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?!?

Hi,

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

Gruß Otto

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

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

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

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

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?

Zitat von: Matthias76 am 23 Februar 2020, 19:23:16
[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.

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

boot_delay=1 in der

/boot/config.txt

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 (https://www.kernel.org/doc/html/v4.10/admin-guide/serial-console.html)

ZitatTo 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:
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?

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.

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 ...

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.

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

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

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

Ich habe heute nochmal direkt mit Monitor am PI statt per SSH gearbeitet... gebootet.
Ja, dann sieht man es sogar.
Kurz nachdem er angeschaltet wurde steht dort
uboot (Taste drücken zum Stoppen des automatischen Bootens)
und dann kommen die Signale am ttyS0 so rüber, wie eine Tastatur, wo man ständig auf einer Taste haut.

Also entweder man kann es schon dort/vorher unterdrücken oder man müsste diese ganze Abfrage/Möglichkeit des "Abbruchs durch Taste" abstellen können.
Die Infos aus den Konfigdateien greifen wohl erst später. ^^

Naja, wenn du mit Monitor und Tastatur dran bist, kannst du vermutlich das Environment vom U-boot einstellen. Und dort die serielle Konsole abschalten. Dann könnte es gehen.
Wie es genau geht, musst du dir ergurgeln.

Viele Grüße,
Enrik

Moin,

Auszug /boot/firmware/README

Zitat* config.txt     - the first configuration file read by the boot process
* syscfg.txt     - the file in which system modified configuration will be placed, included by config.txt
* usercfg.txt    - the file in which user modified configuration should be placed, included by config.txt

cat /boot/firmware/config.txt ergibt am Ende:

enable_uart=1
cmdline=nobtcmd.txt

include syscfg.txt
include usercfg.txt

Weiter geschaut:
cat /boot/firmware/nobtcmd.txt
net.ifnames=0 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc
Nach allem was ich weiß: hier console=ttyAMA0,115200 streichen!

Hast Du das gemacht? Dieser Befehl erledigt das "mikrochirurgisch"
sudo sed -i 's/console=ttyAMA0,115200 //' /boot/firmware/nobtcmd.txt

Zusätzlich musst Du seriel-getty disablen, aber das hast Du sicher schon gemacht, sonst ist die UART im System nicht verwendbar ;)
sudo systemctl stop serial-getty@ttyAMA0.service
sudo systemctl disable serial-getty@ttyAMA0.service
sudo systemctl mask serial-getty@ttyAMA0.service

Gruß Otto

Ich würde btw. auch gleich setzen
enable_uart=0

Nein! Damit fehlt dann die UART im System. Er braucht diese ja!

Zitat# Please DO NOT modify this file; if you need to modify the boot config, the
# "usercfg.txt" file is the place to include user changes.

Die config.txt ist in Ruhe zu lassen!
Dort stehen defaults, die werden überschrieben durch
/boot/firmware/usercfg.txt - die ist leer
/boot/firmware/syscfg.txt - die lädt wiederum die nobtcfg.txt

Also wenn Änderungen dann nur in der  /boot/firmware/usercfg.txt

Aber da braucht man nichts ändern, wie schon gesagt die nobtcfg.txt ändern.

O.K. ... wobei ich persönlich zum debuggen es testen würde .. ;o)

Von der Sache her, alles wie vermutet :)
Ich habe jetzt eine serielle Anbindung an dem Pi (CP2102) und kann mich über die serielle Console einloggen und normal steuern :)
Schicke ich während des boot Vorganges (zeitlich etwa beim/kurz nach dem bunten Bildschirn) einen sinnlosen Block über die serielle Schnittstelle, lande ich im uboot  8)
"hit any key"
wenn ich dann dort boot eingebe, geht es normal weiter

Mal sehen wie ich das Uboot störungsfrei  aufsteigen lassen kann  ???
Edit:
Nächste Erkenntniss: Das Löschen in der /boot/firmware/nobtcmd.txt entzieht dem System die serielle Console, aber das Uboot hat sie noch  :-[
Edit2:
setenv bootdelay 0 im Uboot hilft nicht. Ich bin für Ideen sehr empfänglich :) Es ist für  mich ziemlich trüb da unten.

Zitat von: Otto123 am 26 Februar 2020, 12:44:08
Edit:
Nächste Erkenntniss: Das Löschen in der /boot/firmware/nobtcmd.txt entzieht dem System die serielle Console, aber das Uboot hat sie noch  :-[

Hätte ich nicht anders erwartet. Die Pi-Firmware passt ja erstmal nur den device tree für den Linux-Kernel an. Wenn das U-boot den nicht verwendet, ist die Schnittstelle noch da.
Es sollte aber möglich sein, im U-boot environment die Konsolen zu konfigurieren und auf 'video/keyboard only' zu stellen.
Gruß,
Enrik

Bingo!
Danke :)
also einmal im uboot (hit any key)
setenv stdin vidconsole,usbkbd
saveenv

Man kann sich das vorher mit pri anschauen, da steht relativ zum Schluss
stdin serial,usbkbd

Edit:
Ob das jetzt wirklich richtig war? Jetzt bleibt das Uboot finster, man kann zwar blind auf der Tastatur tippen. Ich habe gedacht ich knipse nur die serielle Eingabe aus?
Edit2
Sieht irgendwie doch alles gut aus. Die serielle Ausgabe gibt es noch, aber er reagiert nicht auf Eingaben.
Edit3:
Und wenn man stdin=vidconsole,usbkbd setzt bleibt das Uboot auch nicht mehr finster. Man kann dann nur noch mit dem keyboard den Bootvorgang mit Sichtkontakt unterbrechen. :)

Um nicht unbedingt ins Uboot steigen zu müssen, geht es auch in der Terminalzeile, allerdings muss mindestens einmal im uboot saveenv erfolgt sein:
sudo sed -i 's/stdin=serial,usbkbd/stdin=vidconsole,usbkbd/' /boot/firmware/uboot.env

Gruß Otto

Hey Otto

Das klingt nach einer Lösung.
Nur gibt es in meinem System keine Datei, die "uboot" oder "uboot.env" heißt.  :o
Nun, dann dachte ich, tippe ich es einfach ein,
aber die Tastatur geht bei mir zu dem Zeitpunkt noch nicht.
2...
1...
0...
boot...

Egal, wie oft ich und auf welche Taste ich drücke.

Auch wenn ich mit den seriellen Infos den Bootvorgang aussteigen lasse, habe ich noch keine Tastatur.
Komische Sache.

Wie geht das?
Das Image was er für den Pi3 64 bit herunterlädt ist exakt das gleiche wie das beim Pi4!?!

Zitatubuntu-18.04.4-preinstalled-server-arm64+raspi3

Was hast Du für ein Image geladen?
Edit: Ok Hab ich nicht gewusst: Die uboot.env Datei gibt es erst nach dem ersten saveenv im uboot  :-X

Aber eine Tastatur sollte schon gehen  :o was hast Du für eine Tastatur dran stecken?

Ansonsten, verbinde die serielle Schnittstelle von deinem cubietruck mit dem pi und bedien das uboot über eine serielle console von dort  ;D
Einmal saveenv reicht ja

Ich kann hier gerade nur entweder Cubie oder Pi4 in Betrieb nehmen (außerdem würde auch eine Stift/Buchsenleiste dann fehlen).
Als Tastatur habe ich ein übliches drahtloses Set (Tastatur / Maus-Kombi).
Ich probiere bei Gelegenheit noch eine einfachere Tastatur.

Kann ich nicht ein gültige uboot.dev woanders her bekommen? Was muss den sonst so drin stehen? Was steht in eurer?
Wobei ich irgendwo gelesen habe, man sollte vorsichtig damit sein, sonst bootet gar nichts mehr.
"uboot.dev" führt bei Google sowieso nur zu sehr wenig Funden.  ;-)

Zitat von: Matthias76 am 29 Februar 2020, 14:36:42
Als Tastatur habe ich ein übliches drahtloses Set (Tastatur / Maus-Kombi).
...
Kann ich nicht ein gültige uboot.dev woanders her bekommen?

Was ist üblich?  ::) Tastaturen die über Bluetooth angebunden sind (oder spezielle Treiber brauchen), werden zu diesem Zeitpunkt nicht funktionieren. Spezielle USB Sticks wie "Logitech unified" funktionieren.

Das mit der uboot.dev würde ich unbedingt lassen! Die ist mit Sicherheit Systemspezifisch.

Wenn das mit der Tastatur so ein Problem sein sollte  :-X kannst Du Dir entweder ein neues uboot kompilieren oder mit den uboot-tools die bestehende irgendwie "manipulieren". Habe mir das einen Abend lang angeschaut, da würde ich lieber eine einfache USB Tastatur bei ... bestellen :) und bis dahin was schönes machen.

Gruß Otto

Hi,

in Anbetracht der Tatsache, dass der Pi 4 vier zusätzliche serielle Ports hat, würde ich einfach auf einen anderen ausweichen, wenn die passenden Pins frei sind.

Viele Grüße,
Enrik