*gelöst* HM-MOD-RPI-PCB nach Umstieg auf Bookworm nur noch init/disconnected

[efyzz]

Moin,

ich steige nun endlich mal von Jessie auf Bookworm um. Nach FHEM-Installation und -Restore läuft das meiste schon ganz gut. Nur das HM-MOD-RPI-PCB will nicht, es wechselt ständig zwischen init und disconnected.

Ich habe entsprechend der Anleitung dies in die config.txt eingetragen:

Code Auswählen Erweitern

enable_uart=1
dtoverlay=miniuart-bt
core_freq=250
Und natürlich dies ausgeführt:

Code Auswählen Erweitern

systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service
ls -l /dev/ttyAMA0 liefert:

Code Auswählen Erweitern

crw-rw---- 1 root dialout 204, 64 Nov 19 22:32 /dev/ttyAMA0
ls -l /dev/serial* liefert:

Code Auswählen Erweitern

lrwxrwxrwx 1 root root  7 Nov 19 21:56 /dev/serial0 -> ttyAMA0

/dev/serial:
total 0
drwxr-xr-x 2 root root  80 Nov 19 21:56 by-id
drwxr-xr-x 2 root root 100 Nov 19 21:56 by-path
Das schaut zunächst mal so aus, als würde BT nicht funktionieren (/dev/serial1 -> ttyS0 fehlt), richtig? Ist zwar schon mal merkwürdig, wäre mir aber egal.

Was ich nicht verstehe ist:

Code Auswählen Erweitern

attr initialUsbCheck disable 1Das liefert bei mir nur:

Code Auswählen Erweitern

Please define initialUsbCheck firstAllerdings auf dem alten Jessie-System genauso. Also ist es scheinbar normal, dass man dieses Device nicht standardmäßig hat?!


Ein Hinweis noch: Ich benutze die GPIOs des Raspis in FHEM, habe jedoch kein WiringPi oder sowas installiert. Das sollte ja kein Problem sein oder?

Danke euch für Tipps!

[Otto123]

Moin,

Das liefert bei mir nur:
Code Auswählen Erweitern

Code Auswählen Erweitern

Please define initialUsbCheck firstAllerdings auf dem alten Jessie-System genauso.

Dann hast Du das gerät in deiner Installation mal gelöscht. Das ist auch ok. Der Vorschlag im Wiki ist minimal invasiv

Zum Betrieb unter Bookworm kann ich noch nichts sagen, das muss ich mir anschauen. Eventuell wurde da was geändert.

Gruß Otto

[TomLee]

Zum Betrieb unter Bookworm kann ich noch nichts sagen, das muss ich mir anschauen. Eventuell wurde da was geändert.

Ich hab das letzte Woche genau nach der Anleitung auf einem Pi4B, wo ich nur die fhem.cfg des "alten" System übernommen habe, gemacht. Hat auf Anhieb geklappt. Ich glaube ein reboot des Raspi war nötig wegen dem wechseln des Status, mein ich.

Aufgeschrieben hab ich mir:

Code Auswählen Erweitern

systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service

config="/boot/config.txt"
bash -c "cat <<EOF >> $config
enable_uart=1
dtoverlay=miniuart-bt
core_freq=250
EOF"
und alles war tutti
(bei s2m mag der playsound-setter nicht mehr, das beschäftigt mich)

[juemuc]

Hallo zusammen,

aktuell ist bei bookworm die Datei config.txt und cmdline.txt nach /boot/firmware/ umgezogen! Ich habe heute nach dieser Anleitung piVCCU neu installiert. Hierbei musste nur der Pfad für die oben genannten Dateien angepasst werden.

Viele Grüße
Jürgen

PS.: Die Deaktivierung von BT erfolgt aktuell über "dtoverlay=disable-bt". Die beiden Punkte müsste Alex aus meiner Sicht noch in seiner Doku korrigieren.

[efyzz]

Moin,

danke für eure Hinweise!

Nach stundenlangem Googeln habe ich es gefunden. Es ist tatsächlich ein Bug in Bookworm:
https://github.com/RPi-Distro/raspberrypi-sys-mods/issues/84

Mit apt-get upgrade war es jedoch nicht erledigt, ich musste die 99-com.rules manuell editieren, wie unten in dem Thread gezeigt.

Jetzt funktioniert es 

[RalfRog]

Hallo
Danke für die Info.Bereite gerade bookworm auf einem PI3 vor - soll produktiv auf einen Pi2+

Welchen Pi nutzt du denn und hattest die Probleme. Der Beitrag bezieht sich ja auf Pi4 & 5.

Gruß Ralf

[juemuc]

Hallo Ralf,

ich nutze einen PI3B. Bei mir waren die von efyzz beschriebenen Änderunen nicht notwendig. Ich nutze aber auch kein bluetooth.

Viele Grüße
Jürgen

[isy]

Lese hier mal mit, da ich die nä. Zeit mein Testsystem Pi4b mit Bookworm neu aufsetzen möchte und hier auch der HM-MOD-RPI-PCB wieder laufen muss.
BT Onboard muss aus, ich nutze einen externen, abgesetzten Adapter.

[Otto123]

Eigenartig, dass es jetzt hier so unterschiedliche Aussagen und Erfahrungen gibt. Mangels Pi4 oder Pi5 habe ich an meinem P3+ getestet.

aktuell ist bei bookworm die Datei config.txt und cmdline.txt nach /boot/firmware/ umgezogen!

Das ist richtig, aber es gibt für beide Dateien links, man kann arbeiten wie bisher.
Von der cmdline.txt sollte man mMn sowieso die Finger lassen, das funktioniert auch so:

Code Auswählen Erweitern

# seriell-getty Dienst für ttyAMA0 dauerhaft deaktivieren
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.serviceNach einem upgrade funktioniert bei mir das Vorgehen von hier wie gehabt. Allerdings gibt es zwei Anmerkungen:

• ich hatte den Zustand, dass ich den Pi vom Strom trennen musste, ein reboot hat nicht gereicht. Irgendwas hat das HMUART Modul beim ersten Start nicht vertragen.
• Die Ansicht von ls -l /dev/serial* ist jetzt anders: der Link zu ttyS0 (BT Schnittstelle) taucht nicht mehr auf. 

Das Ergebnis ist jetzt:

• lrwxrwxrwx 1 root root  7 25. Nov 14:00 /dev/serial1 -> ttyAMA0 # wenn man disable-bt Overlay verwendet hat.
• lrwxrwxrwx 1 root root  7 25. Nov 13:55 /dev/serial0 -> ttyAMA0 # wenn man miniuart-bt Overlay verwendet hat.

[RalfRog]

aktuell ist bei bookworm die Datei config.txt und cmdline.txt nach /boot/firmware/ umgezogen!

Das ist richtig, aber es gibt für beide Dateien links, man kann arbeiten wie bisher.

Genau war an sich auch mein Gedanke (war juemuc vielleicht nicht aufgefallen).
 
Für einen Wechsel der Plattform (Pi2,Pi3,Pi4,Pi5) ist in jedem Fall ein wenig Feintuning (z.B. serielle IFs) nötig. Aber gut zu hören, dass es am Pi3 (und vermutlich Pi2) wie bisher funktioniert.

Es hat sich mit bookworm im Detail aber mehr verändert - der Inhalt der ersten (Boot)-Partition ist komplett nach "/boot/firmware" umgezogen.
Die neue Dateiverteilung/funktion ist mir noch nicht ganz klar 

• wie bisher in Partition1 (/boot/firmware) "kernel_xy.img" und neu zusätzlich "initramfs_xy"
• im Verzeichnis "/boot" dann ebenfalls neu noch "vmlinuz-6.1.0-rpi4-rpi-v_xy" und "initrd.img-6.1.0-rpi4-rpi-v_xy"
• die Verzeichnisse in "/lib/modules/" heissen auch nicht mehr wie Kernelversion sonder analog zu vmlinuz/initrd in "/boot"

[efyzz]

Welchen Pi nutzt du denn und hattest die Probleme. Der Beitrag bezieht sich ja auf Pi4 & 5.

Interessant, dass es bei euch problemlos läuft. 

Ich habe ebenfalls einen Pi 3B. Und der genannte Beitrag bezieht sich nicht nur auf Pi 4 und 5, sondern insbesondere darauf, dass es gerade mit den "alten" Pis nicht mehr kompatibel war. Daher wird die gezeigte Änderung für den Pi 3 benötigt.

So jedenfalls bei mir ... 
Ich benutze Bookworm Lite 64. Ihr auch?

Kann natürlich auch sein, dass es jetzt in den Quellen mit drin ist. Als ich das im Github entdeckt habe, stand es ja schon auf "merged", aber wie gesagt war die Änderung bei mir noch nicht drin.

[Otto123]

Ich benutze Bookworm Lite 64.

Ja klar, aktuell 2023-10-10-raspios-bookworm-arm64-lite.img.xz

dass es jetzt in den Quellen mit drin

Ich konnte das mit dem Link zum Github  nicht wieder erkennen und auf die Schnelle verstehen.

• Es hat nach dem setup (vorher apt upgrade) nicht funktioniert,
• ich habe die udev rule von einem bullseye Pi geholt, es hat nicht funktioniert,
• ich habe den Pi aus-/eingeschaltet, es hat funktioniert und
• dann habe ich die udev rule zurück getauscht und es funktioniert immer noch.

Ich hoffe, ich habe keinen Fehler gemacht. Vielleicht wiederhole ich das noch mal.

Edit: Ich habe mir noch mal die /etc/udev/rules.d/99-com.rules angeschaut, die wird beim upgrade nicht verändert.

Edit: Ich habe nur diesen Schritt und diesen Schritt durchgeführt und nach einem Neustart kann ich

Code Auswählen Erweitern

defmod HMUART1 HMUARTLGW /dev/ttyAMA0 machen und es funktioniert sofort. Es muss bei meinem Versuch gestern etwas beim stecken des Moduls passiert sein. Ich glaube ich hatte den Pi nicht ausgeschaltet. 

[efyzz]

Nabend,

nur mal als abschließende Info: Ich habe die Tage ein apt upgrade durchgeführt und nun ist die Änderung in 99-com.rules standardmäßig enthalten.

[juemuc]

Dann bitte auf "gelöst" setzen.

Viele Grüße
Jürgen

[efyzz]

Ähm, wie macht man das?
Ich kann das Thema schließen, aber das meinst du sicherlich nicht.

[Otto123]

ersten Beitrag den Betreff editieren 

[webdandy]

Hallo,
könnte mir hier vielleicht jemand auf die Sprünge helfen.
Ich bekomme bei einer frischen Bookworm Installation auch ständig einen disconnect.

Folgendes habe ich schon getan:

Code Auswählen Erweitern

enable_uart=1
dtoverlay=miniuart-bt
core_freq=250

Code Auswählen Erweitern

systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service

Code Auswählen Erweitern

ls -l /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 64  1. Feb 10:16 /dev/ttyAMA0
ls -l /dev/serial*
lrwxrwxrwx 1 root root 7  1. Feb 09:57 /dev/serial0 -> ttyAMA0
Habe ich etwas vergessen?

Ich erhalte immer noch:

Code Auswählen Erweitern

024.02.01 10:11:07 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2024.02.01 10:11:10 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2024.02.01 10:11:13 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2024.02.01 10:11:16 1: HMUARTLGW myHmUART did not respond after all, reopening
2024.02.01 10:11:16 3: myHmUART device closed

Danke & Grüße
Fabian

[Otto123]

Hallo Fabian,

welche Generation Pi?
Der 5er muss offenbar anders vorbereitet werden.

Gruß Otto

[webdandy]

Hallo Fabian,

welche Generation Pi?
Der 5er muss offenbar anders vorbereitet werden.

Gruß Otto

Hallo Otto,
sorry zu erwähnen, ich benutze einen 4er.
Grüße
Fabian

[Otto123]

Beim 4er fällt mir die Lüftersteuerung ein: in raspi-config abschalten
Oder Modul stromlos machen, also auschalten und lange warten, bzw. Modul abziehen und eine Weile warten. Insbesondere auch wenn initialUsbcheck vorher zugeschlagen hatte.

[webdandy]

Lüftersteuerung habe ich gerade deaktiviert und stromlos hatte ich den Pi auch schon.
Leider keine Verbesserung:

Code Auswählen Erweitern

2024.02.01 11:43:18 3: Setting myHmUART serial parameters to 115200,8,N,1
2024.02.01 11:43:18 1: /dev/ttyAMA0 reappeared (myHmUART)
2024.02.01 11:43:22 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2024.02.01 11:43:25 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2024.02.01 11:43:28 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2024.02.01 11:43:31 1: HMUARTLGW myHmUART did not respond after all, reopening
2024.02.01 11:43:31 3: myHmUART device closed
2024.02.01 11:43:31 3: Setting myHmUART serial parameters to 115200,8,N,1
2024.02.01 11:43:31 1: /dev/ttyAMA0 reappeared (myHmUART)

Was hatte es mit 99-com.rules zu tun bei den vorherigen Posts?

[webdandy]

Um alles auszuschließen, habe ich ein neues HM-MOD-RPI-PCB aufgesteckt und siehe da, jetzt funktioniert es plötzlich.
War wohl blöderweise das Modul kaputt gegangen...
Jetzt bleibt es "opened" und alls ist schicki.

Danke Otto für Deine Tips.

Grüße
Fabian

[Otto123]

Klingt merkwürdig, aber naja nicht ganz ausgeschlossen. Versuch das nochmal, nachdem das Modul eine Weile rum gelegen hat sozusagen bevor es in den Eimer wandert.

[4eversr]

Ich bin heute mit meinem FHEM von einem Raspberry Pi 2 mit "Buster" auf einen Raspberry Pi 4 mit "Bookworm" umgestiegen.
Es hat alles reibungslos geklappt, mein komplettes FHEM läuft nun einwandfrei mit dem HM-MOD-RPI-PCB auf Bookworm. War mit Backup und ZIP-restore ein Kinderspiel.

Das einzig Ärgerliche/Merwürdige:
Die Monitorausgabe über HDMI an meinen Eizo Monitor funktioniert exakt seit dem Zeitpunkt nicht mehr, wo ich das hier in die /boot/firmware/config.txt zusätzlich eingetragen habe:

enable_uart=1
dtoverlay=miniuart-bt
core_freq=250

Danach dieses Verhalten:
Ich schließe mein, übrigens originales/zertifiziertes, Raspberry-Pi4 Netzteil an, ich sehe den kompletten Bootvorgang noch auf dem HDMI Bildschirm, und dann wenn der Bootvorgang gefühlt bei 90% wäre wird mein Bildschirm schwarz und bleibt es für immer. - Über SSH erreiche ich den Raspberry Pi einwandfrei und auch FHEM funktioniert danach klaglos. Bildschirm bleibt schwarz. Das Verhalten trat direkt nach dem Eintragen und Reboot auf (FHEM war zu diesem Zeitpunkt noch gar nicht installiert, kein CUL/USB-Device angesteckt, es war eine ganz frische Bookworm Installation, die mit apt-get update & upgrade zuvor auf den letzten Stand gebracht wurde)

Super seltsames Verhalten. Habe auch mal testweise ein hdmi_safe=1 in der Config getestet, das Verhalten bleibt. (Übrigens: Bookworm in 64bit als "Lite" ohne Desktopumgebung)


EDIT:
Hat sich hier fürs Form erledigt, denn es scheint nichts mit FHEM / den Settings direkt zu tun zu haben.
ICh lass das hier trotzdem mal drin, falls jemand ähnliche Probleme hat: Scheint ein Bookworm/Linux-Kernel Problem in Zusammenhang mit manchen (Eizo)-Monitoren zu sein. Habe jetzt mal statt meines Eizo Monitores ein 0815-Chinapanel angeschlossen, das wird beim Booten auch kurz schwarz, fängt sich dann aber wieder. - Der Eizo wird Schwarz, fängt sich aber nicht mehr. - Ich vermute durch das apt-get update & upgrade habe ich mir irgendein Bookworm Update reingezogen, was plötzlich zu diesem Verhalten führt, meine ersten Starts mit Bookworm & Eizo-Monitor verliefen alle reibungslos, so dass ich das Problem wohl fälschlich mit den Änderungen in der config.txt in Verbindung brachte.

[Jens_B]

Auch wenn es nicht mit FHEM zu tun hat, versuche ich mich mal an einer Lösung für das Eizo Problem:
Ich könnte mir vorstellen, das die Vertikalfrequenz nicht passt. Welche Frequenzen kann der Eizo denn?
Hast Du mal probiert in der Config.txt den HDMI Mode festzulegen? Bei meine 1. Gehversuchen mit einem PI 1 damals mußte ich das an einem älteren Samsung Monitor auch machen, sonst gabs kein Bild.





Ist nur so eine Idee.