rpi4b: ACT led verwendet standardmäßig heartbeat trigger

[reox]

Ein RPI4B mit Debian Bookworm drauf hat seit er das letzte mal den Strom verloren hat* eine eigenheit: die Grüne LED blinkt kontinuierlich 2x kurz und dann etwa 1s Pause. Das entspricht keinem der offiziell dokumentierten Muster: https://www.raspberrypi.com/documentati ... lash-codes
Außerdem kommt der Pi ganz normal hoch und es scheint auch alles zu funktionieren. Lediglich die Bluetooth Firmware wird nicht geladen, was offenbar ein aktueller bug ist, da bestimmte blobs in firmware-brcm80211 fehlen.
Ich hab / und /boot/firmware standardmäßig read-only gemounted, allerdings passiert das selbe auch wenn ich in /etc/fstab rw einstelle und neu starte.

Hat Debian noch irgendwelche anderen LED Blinkmuster eingebaut und will mir was sagen? Betrifft es vllt eh genau die Probleme die Firmware zu laden?


* Sehr wahrscheinlich sind ein paar Updates ohne reboot dazwischen gewesen... Daher kann ich nicht genau sagen seit wann das so ist. Aufgefallen ist es mir, nachdem ich einmal den Strom gezogen habe und nach dem booten die LED geblinkt hat.

[buhtz]

Wo hast du das Debian her? Ist das von rapsi.debian.net?
Welche Version (in Zahlen) ist das?

[reox]

Ja es ist ein "offizielles" debian image. Aber was ich da ursprünglich installiert habe kA... Das muss noch vorm bullseye freeze gewesen sein und ich hab es immer auf testing/sid gehabt.
aktuell ist es:

Code: Alles auswählen

# uname -a
Linux rpiap 5.15.0-1-arm64 #1 SMP Debian 5.15.3-1 (2021-11-18) aarch64 GNU/Linux
# cat /etc/debian_version
bookworm/sid

und falls das von belang ist, das hier ist der fehler beim laden der firmware:

Code: Alles auswählen

[   10.542348] brcmfmac mmc0:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.bin (-2)
[   10.562324] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[   10.562344] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.bin failed with error -2
[...]
[   11.757778] Bluetooth: hci0: BCM: chip id 107
[   11.762632] Bluetooth: hci0: BCM: features 0x2f
[   11.768838] Bluetooth: hci0: BCM4345C0
[   11.773417] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0000
[   11.782453] bluetooth hci0: firmware: failed to load brcm/BCM4345C0.hcd (-2)
[   11.790162] bluetooth hci0: firmware: failed to load brcm/BCM.hcd (-2)
[   11.797433] Bluetooth: hci0: BCM: firmware Patch file not found, tried:
[   11.804270] Bluetooth: hci0: BCM: 'brcm/BCM4345C0.hcd'
[   11.809505] Bluetooth: hci0: BCM: 'brcm/BCM.hcd'

Code: Alles auswählen

||/ Name               Version      Architektur  Beschreibung
+++-==================-============-============-==========================================================
ii  firmware-brcm80211 20210818-1   all          Binary firmware for Broadcom/Cypress 802.11 wireless cards
ii  raspi-firmware  1.20210805+ds-1 arm64        Raspberry Pi family GPU firmware and bootloaders

edit: ah moment! ich seh schon wo das herkommt:

Code: Alles auswählen

# cat /sys/class/leds/ACT/trigger
none kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock disk-activity disk-read disk-write ide-disk mtd nand-disk [heartbeat] cpu cpu0 cpu1 cpu2 cpu3 panic usb-gadget usb-host mmc1 mmc0 rc-feedback rfkill-any rfkill-none rfkill0 bluetooth-power hci0-power rfkill1 unimac-mdio--19:01:link unimac-mdio--19:01:1Gbps unimac-mdio--19:01:100Mbps unimac-mdio--19:01:10Mbps

die ACT led ist mit heartbeat getriggert. Ich hab jetzt auf none gesetzt und das blinken ist weg. Wieso ist das da eingestellt gewesen? Ich war das jedenfalls nicht (absichtlich) ^_^ Wie kann ich herausfinden, wo das initial gesetzt wird?

[reox]

Also offenbar ist irgendein Update gekommen, dass diesen trigger immer auf heartbeat setzt. Eine Vermutung war, dass udev daran beteiligt ist aber ich habe noch keine regel finden können die da greift.
mit aufgedrehtem debug log sehe ich das hier:

Code: Alles auswählen

# journalctl -u systemd-udevd -b -0 | grep ACT:
Nov 19 21:11:53 rpiap systemd-udevd[229]: ACT: Device is queued (SEQNUM=2310, ACTION=add)
Nov 19 21:11:53 rpiap systemd-udevd[229]: ACT: Device ready for processing (SEQNUM=2310, ACTION=add)
Nov 19 21:11:53 rpiap systemd-udevd[229]: ACT: sd-device-monitor: Passed 144 byte to netlink monitor
Nov 19 21:11:53 rpiap systemd-udevd[229]: ACT: Device is queued (SEQNUM=2311, ACTION=change)
Nov 19 21:11:53 rpiap systemd-udevd[229]: ACT: SEQNUM=2311 blocked by SEQNUM=2310
Nov 19 21:11:53 rpiap systemd-udevd[231]: ACT: Processing device (SEQNUM=2310, ACTION=add)
Nov 19 21:11:53 rpiap systemd-udevd[231]: ACT: /usr/lib/udev/rules.d/71-seat.rules:74 Importing properties from results of builtin command 'path_id'
Nov 19 21:11:53 rpiap systemd-udevd[231]: ACT: sd-device: Created db file '/run/udev/data/+leds:ACT' for '/devices/platform/leds/leds/ACT'
Nov 19 21:11:53 rpiap systemd-udevd[231]: ACT: Device processed (SEQNUM=2310, ACTION=add)
Nov 19 21:11:53 rpiap systemd-udevd[231]: ACT: sd-device-monitor: Passed 255 byte to netlink monitor
Nov 19 21:11:53 rpiap systemd-udevd[229]: ACT: Device ready for processing (SEQNUM=2311, ACTION=change)
Nov 19 21:11:53 rpiap systemd-udevd[229]: ACT: sd-device-monitor: Passed 225 byte to netlink monitor
Nov 19 21:11:53 rpiap systemd-udevd[231]: ACT: Processing device (SEQNUM=2311, ACTION=change)
Nov 19 21:11:53 rpiap systemd-udevd[231]: ACT: /usr/lib/udev/rules.d/71-seat.rules:74 Importing properties from results of builtin command 'path_id'
Nov 19 21:11:53 rpiap systemd-udevd[231]: ACT: sd-device: Created db file '/run/udev/data/+leds:ACT' for '/devices/platform/leds/leds/ACT'
Nov 19 21:11:53 rpiap systemd-udevd[231]: ACT: Device processed (SEQNUM=2311, ACTION=change)
Nov 19 21:11:53 rpiap systemd-udevd[231]: ACT: sd-device-monitor: Passed 336 byte to netlink monitor

(Ja das Datum ist falsch, der rpi behält sich das nicht über einen reboot...)
Aber so wirklich hat das nichts mit dem trigger zu tun...

Ich hab zum testen sysfsutils installiert und in /etc/sysfs.conf

Code: Alles auswählen

class/leds/ACT/trigger = none

eingetragen, aber das hat offenbar keinen effekt - denn der heartbeat kommt trotzdem. Offenbar wird es nach dem starten von sysfsutils gesetzt, denn ein systemctl restart sysfsutils deaktiviert den heartbeat.
Was kann das denn sein? Ich bin mittlerweile sehr ratlos...

[reox]

Ich hab einen anderen raspi4b hier liegen, der war vorher auf bullseye und ich hab ihn vor kurzem auf bookworm gezogen. Seit dem machen da jetzt sowohl PWR als auch ACT LED wieder irgendwas, was ich denen nicht gesagt habe.
Wieso verstehe ich nicht - aber es scheint sich irgendwas zwischen kernel 5.10 und 6.1 geändert zu haben...
Was ich noch weniger verstehe ist, dass ich das auch nicht mehr weg konfigurieren kann.
Unter /etc/default/raspi-firmware-custom folgendes eintragen:

Code: Alles auswählen

dtparam=pwr_led_trigger=default-on  # Wahlweise auch none - siehe https://github.com/raspberrypi/firmware/issues/1742#issuecomment-1225910618
dtparam=pwr_led_activelow=off
dtparam=act_led_trigger=none
dtparam=act_led_activelow=off

und update-initramfs ausführen, schreibt diese Info korrekt in /boot/firmware/config.txt aber nach einem reboot ist alles beim alten. Ich kann die LED zwar mittels /sys/class/leds/{PWR,ACT}/brightness ausschalten, aber das ist ja keine Lösung.
Was wurde da wie geändert, dass unter Bookworm das nicht mehr zum konfigurieren ist?!

edit: der workaround (oder jetzt auch offizieller lösungsweg?!) scheint zu sein es tatsächlich im sysfs zu lösen: https://n.ethz.ch/~dbernhard/disable-le ... ry-pi.html
Gut, das funktioniert natürlich aber was wurde geändert, dass die dtparam nicht mehr gehen? Dokumentiert ist das offenbar nicht.