You are here

LEDs on LHG XL 2

4 posts / 0 new
Last post
LEDs on LHG XL 2

Are the LEDs expected to work right on the RBLHG-2nD-XL at this time? I just set mine up with a nightly build less than 2 weeks ago, and I only get the power and 3rd and 4th rssi LEDs lit (solid). I even played around with /etc/config/system (replicating the configuration hypothesized in /etc/board.json) until I got rssileds to run. I can see the brightness values being updated in /sys/class/leds/rb:green:rssi*, but the actual LEDs don't change. This is with an active mesh connection to another node.

When I plug in the ethernet port, the lan and user leds start flashing (in different patterns).

I'm guessing that OpenWRT is mapping the wrong GPIOs; I see that the original support file was deleted:;a=blob;f=target/linux/ath79/dts/ar9344_mikrotik_routerboard-lhg-5nd.dts;h=e49eb9ab9d8ffa9c02bcf567155068354f9a0660;hb=7a496e4b4b02cfec2a862a8fd8908d64025c9027

Looks like now it's:;a=blob;f=target/linux/ath79/dts/qca9533_mikrotik_routerboard-lhg-2nd.dts;h=1866b7dd3b031dbcaf7aac564ea9e99b2f93750d;hb=7f2052ef22c04e2ee4b51ef1862b81bd5ae26f11
...which just includes:;a=blob;f=target/linux/ath...
...and looks pretty wrong.

Anybody else run into this before I try to dive in deeper and make some sense of it?


Alright, I did some probing, both by manually toggling the entries in /sys/class/leds, and then by probing the GPIOs ( By the way, be careful with the GPIOs, I managed to trigger a firstboot reset.

Some of the LEDs are controlled by mismatched nodes. I haven't tracked down the underlying GPIOs for those yet, but this should be traceable through the device tree definitions when the kernel is built.

Physical LED Control
PWR gpio17, active high
USR rb:green:eth
ETH controlled by ethernet hardware directly; no gpio
RSSI0 rb:blue:power
RSSI1 gpio9, active low
RSSI2 rb:green:rssi1
RSSI3 rb:green:rssi0
RSSI4 gpio16, active low

I was also able to control the LEDs via gpiochip494 (ath9k-phy0), but not reliably, and I definitely triggered a few resets in there.

I also have some ideas for linkled (like using USR instead).

OpenWRT upstream
As I review the current OpenWRT upstream implementation ( against my experiment and my best effort mapping the LEDs as defined in AREDN firmware back to GPIOs in the source, I think OpenWRT upstream is likely correct, although I question whether GPIO 16 really needs to be avoided.
I should also note that, since these LEDs are all on GPIOs, that they're all binary, so the brightness control (e.g. rssileds) does nothing.
K6AH's picture
Please submit an issue...
Hi Brett.  You can submit an Issue in GitHub or join the development team cheeky

Check your email.

Andre, K6AH

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer