** Description changed: Impact: User are reporting that the green led (the one next to the red power led) is not working on the RaspberryPi 3B+ board. - And after debugging the issue, this is what i found: + After debugging the issue, this is what i found: 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 ... 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). + initialize, but it's red power led that fails and the loop tears down + both of them but since the red (by default) is connected to Vcc, it + stays lit (see point 3 below for more info on the wiring) so we have the + impression that the one to fail is the green one. - This can easily proffed by adding debug to drivers/leds/leds- + This can easily tested by adding debug to drivers/leds/leds- gpio.c::gpio_leds_create() and drivers/leds/leds- - gpio.c::gpio_led_probe(), and commenting out the red pwr_led block in + gpio.c::gpio_led_probe(), or 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 green action led will work properly. 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 + instead only the Broadcom firmware can access its gpio, thus a new + mechanism (the exgpio driver) that uses 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 + led, this way it's possible to plumb 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]: + 3) the biasing of the two leds (power and action) is "opposite" 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. + -D5 (the action led) uses the transistor 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, + -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. + current is sinked to GND via Q4 - the led by default on Fix: The fix is composed of 8 patches: - 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 + 1f50a81 UBUNTU: [Config] GPIO_BCM_EXP=y + 53bc3cc UBUNTU: SAUCE: dts: rpi3: remove hpd-gpios overwrite + a1252a5 UBUNTU: SAUCE: dts: cm3: revert hpd-gpios to gpio + 0d136d8 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: + 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 + -patch 0001 and 002 contain the "gpio via firmware" exgpio 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). + cherry-picked cleanly from it (minus same mechanical 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 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 005 fixes the pwr led biasing level -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. + introduced in 4.9, the hdmi phy in the RaspberryPi3 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 since this bug deal only with leds + and noone has opened one against the hvmi video output, to reduce the + regression surface, i reverted these chunks in the new driver (using + these two SAUCE patches) and kept using the mechanism we used so far in + Xenial. - -patch 008 enable the driver in our Ubuntu raspi2 config. + -patch 008 enable the new driver - By apply these patches, the pwr led correctly initialize during boot, - and as a consequence the act led work too. + By apply these patches, the power led correctly initialize during boot, + and as a consequence the action 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. + and reboot - on a non-patched kernel, the power led (red) will be always-on, while the action led (green) will be off. 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? + led code, and only applies to the RaspberryPi3B+ board. 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
