| 2018-12-13 15:53:02 |
Paolo Pisati |
bug |
|
|
added bug |
| 2018-12-13 15:56:16 |
Paolo Pisati |
nominated for series |
|
Ubuntu Xenial |
|
| 2018-12-13 15:56:24 |
Paolo Pisati |
linux-raspi2 (Ubuntu): status |
New |
Invalid |
|
| 2018-12-14 15:19:31 |
Paolo Pisati |
description |
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":
...
[ 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 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.
Fix:
The original
Regression: |
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":
...
[ 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 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.
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).
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.
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. |
|
| 2018-12-14 16:01:00 |
Paolo Pisati |
description |
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":
...
[ 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 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.
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).
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.
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. |
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 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+) 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
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 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.
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 |
|
| 2019-01-10 10:53:53 |
Paolo Pisati |
description |
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 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+) 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
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 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.
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 |
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 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:
...
[ 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-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 the acttion 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
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 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.
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 |
|
| 2019-01-11 12:20:15 |
Paolo Pisati |
description |
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 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:
...
[ 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-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 the acttion 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
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 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.
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 |
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:
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).
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(), 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 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 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 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
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[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 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 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?
1: https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/rpi_SCH_3bplus_1p0_reduced.pdf
2: https://github.com/raspberrypi/linux |
|
| 2019-01-11 14:11:55 |
Paolo Pisati |
description |
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:
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).
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(), 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 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 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 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
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[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 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 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?
1: https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/rpi_SCH_3bplus_1p0_reduced.pdf
2: https://github.com/raspberrypi/linux |
Impact:
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:
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 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 tested by adding debug to drivers/leds/leds-gpio.c::gpio_leds_create() and drivers/leds/leds-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 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, 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 "opposite" and can be easily confirmed by looking at the board schematics[1]:
-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, current normally flows through the led, while when Q4 is biased, all current is sinked to GND via Q4 - the led by default on
Fix:
The fix is composed of 8 patches:
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
From the bottom:
-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 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 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 level
-patch 006 and 007 reduce the "regression surface": when patch 001 was 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 new driver
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 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, 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 |
|
| 2019-01-11 14:55:07 |
Stefan Bader |
bug task added |
|
linux-raspi2 (Ubuntu Xenial) |
|
| 2019-01-11 16:30:26 |
Kleber Sacilotto de Souza |
linux-raspi2 (Ubuntu Xenial): status |
New |
Fix Committed |
|
| 2019-02-04 09:09:42 |
Launchpad Janitor |
linux-raspi2 (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2019-02-04 09:09:42 |
Launchpad Janitor |
cve linked |
|
2000-1134 |
|
| 2019-02-04 09:09:42 |
Launchpad Janitor |
cve linked |
|
2007-3852 |
|
| 2019-02-04 09:09:42 |
Launchpad Janitor |
cve linked |
|
2008-0525 |
|
| 2019-02-04 09:09:42 |
Launchpad Janitor |
cve linked |
|
2009-0416 |
|
| 2019-02-04 09:09:42 |
Launchpad Janitor |
cve linked |
|
2011-4834 |
|
| 2019-02-04 09:09:42 |
Launchpad Janitor |
cve linked |
|
2015-1838 |
|
| 2019-02-04 09:09:42 |
Launchpad Janitor |
cve linked |
|
2015-7442 |
|
| 2019-02-04 09:09:42 |
Launchpad Janitor |
cve linked |
|
2016-7489 |
|
| 2019-02-04 09:09:42 |
Launchpad Janitor |
cve linked |
|
2017-5715 |
|
| 2019-02-04 09:09:42 |
Launchpad Janitor |
cve linked |
|
2018-19407 |
|
| 2019-02-04 09:09:42 |
Launchpad Janitor |
linux-raspi2 (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
