** Description changed: Impact: People are reporting that the green led (the one next to the red power led) is not working on the RaspberryPi 3B+ board. After debugging the issue, this is what i found: 1) in reality, it's not the green led that is not working, but is the - power led that "fails": + power led that fails to initialize: ... [ 2.299216] leds-gpio: probe of soc:leds failed with error -2 ... what happens is that, since all leds are initialized in a loop, if one of them fail to init properly, the loop tears down all the initialized leds in that loop - one can easily proof that by adding debug to drivers/leds/leds-gpio.c::gpio_leds_create() and drivers/leds/leds- gpio.c::gpio_led_probe(), or simply commenting out the pwr_led block in arch/arm/boot/dts/bcm2710-rpi-3-b-plus.dts - the board will boot up, the above leds-gpio error will disappear and act_led will work properly. - 2) the pwr_led in all rpi3 boards (rpi3 a/b classic or b+) are not + 2) the pwr_led in all rpi3 boards (rpi3 a/b classic or b+) is not available direcly by the OS, instead only the Bradcom firmware can manipulate its gpio, thus a new mechanism that used the bcm firmware as a middleman was developed - the exgpio driver: using a mailbox mechanism, messages are sent from the Linux kernel to the Broadcom - firmware to query the status of the led GPIO or set it, this was it's - possible for the linux led trigger to make it work. + firmware to query or set the status of the led GPIO, this way it's + possible to hook the Linux led trigger to it Fix: The fix is composed of 7 patches: 9194ee1 UBUNTU: [Config] GPIO_BCM_EXP=y 24bfd3c UBUNTU: SAUCE: dts: rpi3: remove hpd-gpios overwrite b9d10bb4 UBUNTU: SAUCE: dts: cm3: revert hpd-gpios to gpio b75dca4 UBUNTU: SAUCE: make it build on bcm2709 9989bb3 Revert "UBUNTU: SAUCE: dts: use the virtgpio driver" 20a6601 bcm2835-gpio-exp: Copy/paste error adding base twice 85f3449 bcm2835-gpio-exp: Driver for GPIO expander via mailbox service - Starting from the bottom, patch 0001 and 002 contain the "gpio via firmware" driver (and a fix for it) - those are the original patches tha are present in the Github's RaspberryPi repository, and they were cherry-picked cleanly from it (minus same changes in Kconfig and Makefile for the surrounding context). + Starting from the bottom, patch 0001 and 002 contain the "gpio via firmware" driver (and a fix for it) - those are the original patches that are present in the Github's RaspberryPi repository[*] rpi-4.9.y branch, and they were cherry-picked cleanly from it (minus same changes in Kconfig and Makefile surrounding context to make it apply). Patch 0003 reverts a change that tried to pilot pwr led gpio using the default virtgpio driver. Patch 004 fixes the arch name: in 4.9 the Raspberry arch was called "ARCH_BCM2835", while in Xenial 4.4 is "ARCH_BCM2709". - Patch 005 and 006 reduce the "regression surface": when patch 001 was introduced, the hdmi phy in the rpi3 and cm3 was moved to use this new code, but since our hdmi driver is significantly different from the one in the rpy-4.9 tree, and noe one has reported any problem with it, to reduce the regression potential, i reverted this change, and moved back these gpios to use the in-tree gpio driver (as it is now in Xenial), using two SAUCE patches. + Patch 005 and 006 reduce the "regression surface": when patch 001 was introduced, the hdmi phy in the rpi3 and cm3 was moved to use this new code, but since our hdmi driver is significantly different from the one in the rpy-4.9 tree, and no one has reported any problem with it, to reduce the regression potential, i reverted this change, and moved back these gpios to use the in-tree gpio driver (as it is now in Xenial), using two SAUCE patches. Finally, patch 007 enable the driver in our Ubuntu raspi2 config. By apply these patches, the pwr led correctly initialize during boot, and as a consequence the act led too. How to test: Add this to config.txt: dtparam=act_led_trigger=heartbeat dtparam=pwr_led_trigger=heartbeat and reboot - on a non-patched kernel, the power led (red) will be always-on, while the green led will be off. On a patched kernel, both leds will blink continuosly. - Regression: It's new code, so there's always regression potential in it, but by reducing the scope of the original patch, the impact is limited to the led code. + + XXX TBD: testing with older / newer firmware, testing on an unsupported + platform (rpi2), why the dafualt-on led trigger is not working? + + *: https://github.com/raspberrypi/linux
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1808366 Title: Led trigger not working on rpi3b+ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1808366/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs