ipq806x: rt4230w-rev6: fix status reporting via the LEDs #15440
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
target/ipq806x
robimarko
force-pushed
the
rt4230w-rev6-leds
branch
from
b1d911b
to
4beb6e0
Compare
There is a custom LED controller between the 3 SoC GPIO outputs and the red and blue LEDs of the device. It implements a strange mapping that includes fixed, flashing, and breathing modes. The current DTS configuration causes OpenWrt to flash the LEDs over the controller's own flashing, resulting in chaotic output in boot, failsafe, and upgrade modes. This change fixes the LEDs in the best way possible as long as each OpenWrt running state is limited to be signaled by a single led. Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com> Link: openwrt#15440 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Lanchon
added a commit
to Lanchon/openwrt
that referenced
this pull request
May 15, 2024
There is a custom LED controller between the 3 SoC GPIO outputs and the red and blue LEDs of the device. It implements a strange mapping that includes fixed, flashing, and breathing modes. The current DTS configuration causes OpenWrt to flash the LEDs over the controller's own flashing, resulting in chaotic output in boot, failsafe, and upgrade modes. This change fixes the LEDs in the best way possible as long as each OpenWrt running state is limited to be signaled by a single led. Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com> Link: openwrt#15440 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (cherry picked from commit 0868268)
|
thank you @Ansuel ! |
Vladdrako
pushed a commit
to Vladdrako/openwrt
that referenced
this pull request
May 18, 2024
There is a custom LED controller between the 3 SoC GPIO outputs and the red and blue LEDs of the device. It implements a strange mapping that includes fixed, flashing, and breathing modes. The current DTS configuration causes OpenWrt to flash the LEDs over the controller's own flashing, resulting in chaotic output in boot, failsafe, and upgrade modes. This change fixes the LEDs in the best way possible as long as each OpenWrt running state is limited to be signaled by a single led. Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com> Link: openwrt#15440 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
hauke
pushed a commit
to Lanchon/openwrt
that referenced
this pull request
May 23, 2024
There is a custom LED controller between the 3 SoC GPIO outputs and the red and blue LEDs of the device. It implements a strange mapping that includes fixed, flashing, and breathing modes. The current DTS configuration causes OpenWrt to flash the LEDs over the controller's own flashing, resulting in chaotic output in boot, failsafe, and upgrade modes. This change fixes the LEDs in the best way possible as long as each OpenWrt running state is limited to be signaled by a single led. Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com> Link: openwrt#15440 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (cherry picked from commit 0868268)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There is a custom LED controller between the 3 SoC GPIO outputs and the red and blue LEDs of the device. It implements a strange mapping that includes fixed, flashing, and breathing modes.
The current DTS configuration causes OpenWrt to flash the LEDs over the controller's own flashing, resulting in chaotic output in boot, failsafe, and upgrade modes.
This change fixes the LEDs in the best way possible as long as each OpenWrt running state is limited to be signaled by a single led.
FYI, i documented the modes provided by the led controller here:
https://openwrt.org/inbox/toh/askey/rt4230w_rev6#leds
videos
these videos show the bootloader, failsafe wait, and normal boot phases of openwrt boot.
old.mp4
new.mp4