** Description changed: Impact: - People are reporting that the green led (the one next to the red power + User 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: + And after debugging the issue, this is what i found: - 1) in reality, it's not the action / green led that is not working, but - is the power / red led that fails to initialize, and its failure cascade - on the other one: + 1) during boot, all leds are initialized in a function loop, and if one + of them fails to setup, the loop tears down all initialized instances: ... [ 2.299216] leds-gpio: probe of soc:leds failed with error -2 ... - 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- + in this particular case, it's not the green action led that fails to + initialize, but it's red power led that fails, the loop tears down all + two leds but since the red (by default) is connected to Vcc, it stays + lit (see point 3 below for more info on the wiring). + + This can easily proffed 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 + gpio.c::gpio_led_probe(), and commenting out the red 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 the acttion led will work + above leds-gpio error will disappear and the green action led will work properly. - 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 or set the status of the led GPIO, this way it's - possible to hook the Linux led trigger to it + 2) the pwr_led in the rpi3 b+ is not available direcly to the OS, + instead only the Bradcom firmware can access its gpio, thus a new + mechanism (the exgpio driver) that used the bcm firmware as a middleman + was developed: using a mailbox mechanism, messages are sent from the + Linux kernel to the Broadcom firmware to query or set the status of the + led GPIO, this way it's possible to hook the Linux led subsystem to this + gpio + + 3) the biasing of the two leds (power and action) is the opposite - this + is due to the way leds are wired on the board and can be easily + confirmed by looking at the board schematics[1]: + + D5 (the action led) uses Q5 in a switch configuration - when Q5 is not + biased, it acts as an open switch and no current goes through the led - + so by default the led is off. + + D6 (the power led) uses Q4 in a sink configuration - when Q4 is off, + current normally flows through the led, while when Q4 is biased, all + current is sinked to GND via Q4 - thus the led is by default on. Fix: - The fix is composed of 7 patches: + The fix is composed of 8 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 + 8458a1d UBUNTU: [Config] GPIO_BCM_EXP=y + 63d2976 UBUNTU: SAUCE: dts: rpi3: remove hpd-gpios overwrite + 8c7aebc UBUNTU: SAUCE: dts: cm3: revert hpd-gpios to gpio + 0b5e355 UBUNTU: SAUCE: make pwr_led GPIO_ACTIVE_LOW + e2d3ba2 UBUNTU: SAUCE: make it build on bcm2709 + 245fc18 Revert "UBUNTU: SAUCE: dts: use the virtgpio driver" + be25728 bcm2835-gpio-exp: Copy/paste error adding base twice + 4ccdf22 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 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 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. + 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[2] 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 where the driver originated, the + Raspberry arch was called "ARCH_BCM2835", while in Xenial 4.4 is + "ARCH_BCM2709". + + -patch 005 fixes the pwr led biasing + + -patch 006 and 007 reduce the "regression surface": when patch 001 was + introduced in 4.9, the hdmi phy in the rpi3 and cm3 was moved to use the + new driver, 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. + + -patch 008 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. + and as a consequence the act led work 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. + On a patched kernel, both leds will blink intermittently. 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 + 1: https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/rpi_SCH_3bplus_1p0_reduced.pdf + 2: 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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
