Unless I missed something it looks like OPNsense does not include default support for onboard LEDs on PC Engines APU* boards.
It looks like there is a kernel module available for them called apuled. According to the FreeBSD issue it supports APU1, APU2 and APU3.
Would be great if this could be shipped/included in the default configuration for serial builds so one can enable it. On ALIX boards/pfsense a popular package was BlinkLED, which would probably easy to re-implement once I have the LEDs available.
Thanks for the awesome work!
Hi @ktk,
The led driver nodes should be there for your APU already...
# ls /dev/led/led*
And it is easy to operate via shell script:
https://www.freebsd.org/cgi/man.cgi?query=led&sektion=4
Cheers,
Franco
@fichtner oh great didn't realize that thanks! Will update the posts in the forum accordingly. Also I will try to see if I can port BlinkLED! Will report here as well for reference.
Best way of integrating would be to rewrite the management parts in the MVC framework. That would automatically provide an API for future use... :)
https://docs.opnsense.org/development/examples/helloworld.html
@fichtner tnx will check that out!
@fichtner just checked on 17.7, I only see:
ls /dev/led/*
/dev/led/igb0 /dev/led/igb1 /dev/led/igb2
I don't think the drivers disappeared, but seeing igb* maybe the new APU leds are not found... I have to check on Monday on an old APU1 to see if they are available there, ok?
@fichtner sure thanks!
please ping me when I'm slacking off :)
Also having an APU1 board so I can check for /dev/led as well
there is no led on APU1d4 (release: OPNsense 17.7.12-amd64, FreeBSD 11.0-RELEASE-p17):
root@opn:~ # ls /dev/*
/dev/acpi /dev/ctty /dev/da0s1 /dev/geom.ctl /dev/mem /dev/random /dev/ttyu0.init /dev/ufssuspend /dev/ugen6.2
/dev/apm /dev/cuau0 /dev/da0s1a /dev/hpet0 /dev/midistat /dev/sndstat /dev/ttyu0.lock /dev/ugen0.1 /dev/urandom
/dev/apmctl /dev/cuau0.init /dev/da0s1b /dev/io /dev/netmap /dev/speaker /dev/ttyu1 /dev/ugen1.1 /dev/usbctl
/dev/audit /dev/cuau0.lock /dev/devctl /dev/kbd0 /dev/nfslock /dev/stderr /dev/ttyu1.init /dev/ugen2.1 /dev/xpt0
/dev/auditpipe /dev/cuau1 /dev/devctl2 /dev/kbdmux0 /dev/null /dev/stdin /dev/ttyu1.lock /dev/ugen3.1 /dev/zero
/dev/bpf /dev/cuau1.init /dev/devstat /dev/klog /dev/pass0 /dev/stdout /dev/tun1 /dev/ugen4.1
/dev/bpf0 /dev/cuau1.lock /dev/fido /dev/kmem /dev/pci /dev/sysmouse /dev/tun2 /dev/ugen5.1
/dev/console /dev/da0 /dev/full /dev/mdctl /dev/pf /dev/ttyu0 /dev/tun3 /dev/ugen6.1
/dev/fd:
0 1 2
/dev/pts:
0
/dev/reroot:
reroot
/dev/usb:
0.1.0 0.1.1 1.1.0 1.1.1 2.1.0 2.1.1 3.1.0 3.1.1 4.1.0 4.1.1 5.1.0 5.1.1 6.1.0 6.1.1 6.2.0 6.2.1 6.2.2
Same issue here... so that is really an issue with all APUs.... I'll take a look at the apuled integration.
Here's what worked for me on the APU.2C2 via the serial port:
After login, go to the shell (8), then:
root@OPNsense:~ # ls /dev/led
igb0 igb1 igb2
root@OPNsense:~ # echo f3 > /dev/led/igb0
blinks the LED for igb0. To turn it off:
echo 0 > /dev/led/igb0
@seamusdemora interesting, on what version are you?
Hi all, we have support for PC Engine APU leds and hidden front button control.
One patch to src, one additional port and one patch into core.
Configurable blinking schemes and ability to bind shell script to button action (we use it for reset config to factory defaults).
Alex can describe in details.
Patch to src:
It's a Larry's Baird driver for onboard LEDs and button, module name - apuled.ko
I got it here
Upon loading the driver creates four devices. Three led devices:
/dev/led/led1
/dev/led/led2
/dev/led/led3
One for the mode switch:
/dev/modesw
Additional port:
It's a very simple daemon which can light or quench LEDs. Also, it tracks onboard button state and can invoke action script when button pressed. LEDs can be light up by configurable schemes which can be switched.
Patch into core:
We created syshook for 'boot' runlevel which run above daemon when rc starts, before mounting filesystems rw. After rc runs, LEDs blinking according 'startup' scheme until rc finishes. Once OPNsense boot completed, blink scheme swithced to 'running'. When reboot initiated, scheme switches to 'running' again. When button pressed, blink scheme switched to scheme 'press'.
You can see how it really works on this video
And in addition about daemon:
If apuled.ko module doesn't loaded or if OPNsense running not on APU device, daemon exits immediately, so placing it in syshook doesn't make useless processes.
@ktk: I was on 18.1 when I checked this; I've since upgraded to 18.7. Have not checked to see if it still works. I'm afraid I'm completely unclear what's going on with @alexpro's comment. I seem to recall I found this in an OpenBSD man page...
@seamusdemora I mean three green LEDs and small button on front of APU. You tried blink orange LED on RJ45 conneсtor.
Ah! So sorry... my APU faces me connector-forward... I forget that there are actually LEDs on the other side :P
If our solution is suitable for opnsense mainstream, we can make pull-requests.
@evbevz video looks great to me. Not sure about how to proceed to get this into mainstream. @fichtner you might comment on that?
Errr... src.git support and publishing a plugin I guess. We've removed the original LED implementation in core because it wasn't essential, only tailored for APU/WRAP? and wasn't flexible either.
@alexpro & @evbevz would that be possible to create for you? Would be great, I think APU is pretty popular among OPNsense users.
@ktk , no problem, if @fichtner allows pull-request to kernel and core.
Is there a chance this LED support will arrive into 18.7, instead of 19.1?
interested too ;)
Imported kernel module via https://github.com/opnsense/src/commit/8ba72fd13491a6a0150c9a2235bb93da2d3bd1e6 for inclusion in OPNsense 19.1. Considering a backport to 18.7 when it works as expected...
Sorry for my dumb question: do I need to switch to "beta" release channel, to be able to try this feature?
@soder10, no, those pull-requests doesn't merged yet.
It’s a bit complicated to test. Needs new 19.1.b kernel, LED daemon and core patches all at once. All in due time...
On 20. Oct 2018, at 16:10, evbevz notifications@github.com wrote:
@soder10, no, those pull-requests doesn't merged yet.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
Ok, I am waiting patiently for 19.1 then :)
Just please make sure APU2/3 model number is not hardcoded, as APU4 and 5 are also available (at least APU4 is for sure using the exact same board as APU2/3, only difference is the +1 more NIC, so the 3x LED and 1 SWITCH should be the same)
@soder10 APU model number does not hardcoded. All will work fine I think, if apuled.ko loaded, and hardware description contains "APU", and all devices are present.
@soder10 APU model number does not hardcoded. All will work fine I think, if apuled.ko loaded, and hardware description contains "APU", and all devices are present.
Ok, if you are sure its not hardcoded in the kernel module or in any of the connected frameworks, then it should be fine.
I'm still on 18.x, did the support for the LEDs make it into 19.1?
The driver did, yes.
Excellent, thanks! Will check it out and see if I can contribute a plugin.
On my APU4C4 I can see the following LED devices running OPNsense 19.1:
/dev/led/igb0
/dev/led/igb1
/dev/led/igb2
/dev/led/igb3
These LEDs are the green link/activity LEDs of the 4 onboard LAN interfaces at the rear.
The APU has 3 additional status LEDs at the front.
Using 'kldload apuled' yields in the following additional devices:
/dev/led/led1
/dev/led/led2
/dev/led/led3
Nice, thanks!
Important note: you need to load the kernel driver named "apuled" after every reboot, as its not automatically loaded. Hand editing /boot/loader.conf is not the way it should be done, as that file is overwritten every single time a GUI-driven config change is saved.
Is there a way to add this "Load APU LED" into the System \ Settings \ Misc section, or do we need to add this under Settings \ TUNABLE : apuled_load = "YES" ?
why not create a ticket for the plugin? if you already use the plugin? it's in development mode...
@fichtner Oh well, I wasnt really aware that the plugin is in progress :)
Just wanted to give some warning to any random users, that the device driver load via manual is an ephemeral solution unless comitted via a permanent solution.
Is the (front) LED functionality still in the current version of OPNsense?
I have installed the latest OPNsense (20.1.3) on my apu2e4 and the apuled kernel module is loaded, but there are NO /dev/led/led* devices. Any idea what could be wrong?
@kosli There is a problem with this LED module driver since APU firmware 4.10.x -> check the description and possible workaround here:
https://pcengines.github.io/
and
https://github.com/pcengines/coreboot/issues/329
apuled driver doesn't work in FreeBSD. Check the GPIOs document for workaround.
https://github.com/pcengines/apu2-documentation/blob/master/docs/gpios.md
@soder10 thank you very much! I didn't expect that it was a bios upgrade (that I did only after installing OPNsense for the first time on that board) that made problems. I have added the loadef.conf.local setting and now the LEDs work fine. (Haven't tried downgrading the bios).
Most helpful comment
Same issue here... so that is really an issue with all APUs.... I'll take a look at the apuled integration.