# Building lacie-leds from Linux source using gcc



## iJaffa (Jan 28, 2020)

I'm trying to port lacie-leds the tool to FreeBSD to use in FreeNAS. I've got FreeBSD 11.3 running with gcc installed. When I initially ran "gcc lacie-leds.c -o lacie-leds", I was getting a fatal error "sys/io: no such file or directory" so I replaced


```
#include <sys/io.h>
```

with


```
#include <sys/ioctl.h>
```

but now I"m getting a warning for "implicit declaration of function 'outb'" and "implicit declaration of function 'inb'".

I'm still new to this and would really appreciate some assistance.


----------



## SirDice (Jan 28, 2020)

Those functions look specific to Linux. You probably need to rewrite the whole code and use gpio(3).


----------



## iJaffa (Jan 28, 2020)

That's very useful information, thank you.

I've not written in C before or done anything with gpio on FreeBSD. Could you point me to some resources which can help me get started?

Doing some more digging, it appears that the hardware I am trying to talk to is the F71882 Super I/O which led me to this page from OpenBSD, but I'm not sure how much relevance this has to the conversation.


----------



## SirDice (Jan 28, 2020)

Lets prevent an XY problem. What exactly are you trying to do? I mean where do you think you need this code for?


----------



## iJaffa (Jan 28, 2020)

I’ve got a LaCie 5Big NAS Pro which I’ve installed FreeNAS onto. All the hardware is detected by the kernel and runs flawlessly, except that the LED on the front is constantly blinking blue.

In normal operation, it should be a solid blue, and it goes red in the case of an error (i.e. drive failure).

The git I linked has a successful implementation for Linux, and I wanted to replicate that in FreeBSD which I would then assume would be easy enough to put into FreeNAS.


----------



## SirDice (Jan 28, 2020)

Does /dev/led/* exist?


----------



## iJaffa (Jan 28, 2020)

`/dev/led` contains em0 and em1 which would be the onboard NIC’s.

I was looking further at the man page for gpioctl but not sure that gpio on its own will work since `gpioctl -l` outputs `gpio_open: No such file or directory`, and according to this thread it might not be the right attempt with an Intel chip anyway.

I don’t necessarily need all the LED control functions, I just need to stop the front LED from blinking since the unit is out in the open and the blinking is going to drive people nuts, so I’m all ears for any other ideas.


----------



## pboehmer (Jan 28, 2020)

I know this is not the solution you're looking for, but electrical tape over the LEDs is probably the easiest solution.  If aesthetics is an issue, maybe using color matched (duct?) tape.


----------



## SirDice (Jan 28, 2020)

iJaffa said:


> /dev/led contains em0 and em1 which would be the onboard NIC’s.


Some storage drivers actually expose their LEDs that way:

```
dice@molly:~ % ll /dev/led/
total 0
crw-------  1 root  wheel  0x3b Dec 16 08:54 ahci0.0.fault
crw-------  1 root  wheel  0x3a Dec 16 08:54 ahci0.0.locate
crw-------  1 root  wheel  0x3d Dec 16 08:54 ahci0.1.fault
crw-------  1 root  wheel  0x3c Dec 16 08:54 ahci0.1.locate
crw-------  1 root  wheel  0x3f Dec 16 08:54 ahci0.2.fault
crw-------  1 root  wheel  0x3e Dec 16 08:54 ahci0.2.locate
crw-------  1 root  wheel  0x41 Dec 16 08:54 ahci0.3.fault
crw-------  1 root  wheel  0x40 Dec 16 08:54 ahci0.3.locate
crw-------  1 root  wheel  0x43 Dec 16 08:54 ahci0.4.fault
crw-------  1 root  wheel  0x42 Dec 16 08:54 ahci0.4.locate
crw-------  1 root  wheel  0x45 Dec 16 08:54 ahci0.5.fault
crw-------  1 root  wheel  0x44 Dec 16 08:54 ahci0.5.locate
crw-------  1 root  wheel  0x36 Dec 16 08:54 siisch0
crw-------  1 root  wheel  0x37 Dec 16 08:54 siisch1
```

So I was kind of hoping this was the case for you too.


----------



## iJaffa (Jan 29, 2020)

SirDice said:


> Some storage drivers actually expose their LEDs that way:



You would expect so, but LaCie is not known for doing things the standard way, and Seagate have made things even worse since they acquired LaCie.

Doing yet more digging, it would appear that the LED can be controlled through another project called led_ctrl which is part of the lacie-nas-tools. An excerpt from the readme states:


```
led_ctrl is a POSIX shell script which allow to configure LEDs (compatible
with the GNU/Linux sysfs LED API) via an understandable configuration file
```

and goes onto indicate that the script simply requires `make install` to be run from the source directory and then the `led_ctrl` can be run. I have run this successfully from the command line in my VirtualBox instance of FreeBSD, but rightfully getting the error `missing or empty syses LED directory: /sys/class/leds` since sysfs is not native to FreeBSD.

I can try using the sysfsutils ports (this seems to expose `/sys`), but unsure if the LaCie device will expose the LED's that way until I can give it a go later today (hopefully FreeNAS supports installation of ports, haven't tried yet).

*Update:* I am able to `make install` the code just fine in FreeNAS as well, but get the same `missing or empty syses LED directory: /sys/class/leds` error as in FreeBSD. There is already a /sys folder in the root of FreeNAS but it does not contain anything. Installing sysfsutils from ports fails with `checking for C compiler default output file name... configure: error: C compiler cannot create executables` so that's a no go. I am beginning to think this custom LaCie LED is simply is not meant to behave in the BSD world...


----------

