Dear all, I had read the post about the linux driver for the leds of the HP-EX hardware:

viewtopic.php?f=2&t=2335

since this does not work for the Acer Easystore H340 I decided to do a bit reversing for myself.

I dissected the wnas.sys driver from the H340 hardware and saw that It basically uses the ICH7 LPC GPIO bridge to control its GPIOs. Especially the following ones were used inside the driver:

0x06: Used to enable/disable the internal USB drive (the 256MB internal USB stick)
0x14: Info Led blue
0x18: Info Led red
0x19: Power Led
0x1B: Led for the USB front connector

I googled a bit and found someone who has already written a led driver controlling GPIOs from the LPC bridge for a Intel NAS. I grabbed his source and altered it to handle the above mentioned GPIOs. The source is attached.

In order to generate the driver extract the bz2 file into your home directory; cd into it and simply run "make". (Please be aware that you have to have the kernel headers and the basic compile environment available)

Afterwards, you should find a file called "leds-h340.ko". After doing a "sudo insmod leds-h340.ko" you should find the following directories under: /sys/class/leds
h340:InfoLedBlue
h340:InfoLedRed
h340:PowerLed
h340:USBDiskEnable
h340:USBLight

Example: **EDIT** fixed the command line
Now you can disable the blinking "i" with:
echo 0 > /sys/class/leds/h340:InfoLedBlue/brightness
echo 255 > /sys/class/leds/h340:InfoLedBlue/brightness

The following line will make the "i" red
echo 0 > /sys/class/leds/h340:InfoLedRed/brightness

-> This is the very first version and I wrote it mainly to control the "i" led to have a visual indication when something went wrong.
I did not find any reference to the HDD leds yet. If anybody knows, please tell

comments welcome

Very nice, thank you for sharing!

_________________
Alex Kuretz
Remote Notification: Monitoring and alerting for your Home Server via email, Twitter, text message, RSS, push notifications, and on your Mac desktop
Have you tried our Add-Ins?

I updated the driver and removed some major annoyances:
Version 0.2: this is a bugfix version
- BUGFIX: fix crash when module is unloaded and then loaded again
- BUGFIX: on unload of module remove sysfs entries
- BUGFIX: add support for GPIO pins 32..63 on ICH7 LPC
- BUGFIX: switch off blinking of I led per default after module is loaded

Can someone give me a hint in which *.dll or *.sys WHS driver the hdd leds are controlled? If I could only find out where these leds are switched on/off I could add this to the driver.
One idea could be to find the mysterious ANNIE.GHO test application which does some things with these leds.... Ideas are greatly appreciated


I ran forward and backward through the wnas.sys driver but could not find any information..

Well done! I'm glad my article helped.

I got a hint concerning the FAN control via lmsensors:

sudo apt-get install lm-sensors

Since the used smsc sch5127 super-io chip is not yet fully supported i did a

modprobe dme1737 force_id=0x7c

this tricks the lmsensors module to think there is a sch311x adapter. Afterwards I did call

sensors

and got this (unfortunately there is no way to get hold on the HDD leds yet...)

sch311x-isa-0870
Adapter: ISA adapter
in0: +1.79 V (min = +0.00 V, max = +3.32 V)
in1: +0.80 V (min = +0.00 V, max = +1.99 V)
in2: +3.32 V (min = +0.00 V, max = +4.38 V)
in3: +5.02 V (min = +0.00 V, max = +6.64 V)
in4: +15.79 V (min = +0.00 V, max = +15.94 V)
in5: +3.33 V (min = +0.00 V, max = +4.38 V)
in6: +3.25 V (min = +0.00 V, max = +4.38 V)
fan1: 766 RPM (min = 0 RPM) ALARM
fan2: 0 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM) ALARM
temp1: +60.2°C (low = -127.0°C, high = +127.0°C)
temp2: +61.4°C (low = -127.0°C, high = +127.0°C)
temp3: +38.1°C (low = -127.0°C, high = +127.0°C)
cpu0_vid: +2.050 V

Good work. I meant to do the reverse engineering on this but never got the time. I'd be interested in seeing how you progress on this. Keep up the excellent work!

I did some more digging and found out, that the 4 HDD leds are connected to the SMSC SCH5127 SuperIO Chip.

In total, there are 8 LEDs (4 blue, 4 red) where 6 are connected to GPIO bank 5 and two to GPIO Bank 1:

On GPIO Bank 5 there are the GPIOs 0,1,2,3,6,7 and on GPIO bank 1 GPIOs 1 and 4
Where the following GPIOs seem to belong together:

GPIO 1.1+1.4
GPIO 5.0+5.1
GPIO 5.2+5.3
GPIO 5.6+5.7

The GPIO inversion seems to be already configured in the BIOS or kept at default since the driver does not touch this bit. It only configures the pin function as GPIO PushPull Output.

ADDENDUM:
LED brightness is controlled via PWM3 of the HWM module.

HP MediaSmart server 485 also uses the SMSC SCH5127 chipset.

I got annoyed with the blinking health LED after I installed Ubuntu on my ex485. So I created a small Linux daemon that stops that, takes control of the LEDs, decreases the brightness, and monitors for disk changes using udev.

More information and source available from: http://bitbucket.org/adaptation/mediasmartserverd

I downloaded the source and it looks really good; but it would not run out of the box since the underlying hardware is slightly different (e.g. the H340 uses the ICH7 southbridge). I think this driver can be adapted to also fit to the h340; do you have a list which GPIO pin is mapped to which LED on the EX485?

Have a look near the bottom of the readme.txt file, and you can see my notes on the offsets I've discovered. Specifically io_port_status1_ offsets 0x04, 0x0c, 0x18, and 0x38.

I don't actually have a copy of the datasheet for the SCH5127. A lot of it has been disassembly and guess work. If you have a copy of the datasheet, or can point me at more information; I'd love to tidy up some of the variables/comments/etc.

Looks like there is hope yet for a driver for the H340. Keep it up guys.

Concerning the SCH5127 register offsets (I also only have a datasheet for the 311x series available; unfortunately, the sch5127 datasheet is nowhere available): Below is a short disassembly of the SCH5127GPIOWrite() function and a explanation how I got to the assumed pins and offsets from my post.

dil register contains GPIO-ID (e.g. 0x56, 0x57,0x11; can be seen when looking at the parameters given from the calling function HDDLedWrite() ; also, the LED configuration register offsets can be seen in the sch5127init() function; the only registers which seem to be initialized are the HDD led gpio's )

sil register contains the desired operation (CLEAR bit = 1; SET bit = 2)

in C it would look like the following:

#define GPIOPIN_SET 0x02UL
#define GPIOPIN_CLR 0x01UL
#define GPIOBNK_OFFSET 0x4AUL

SCH5127GPIOWrite(UINT32 gpioID, UINT32 gpioOp)
{
UINT8 *address;
address=RunTimeBaseAddr+GPIOBNK_OFFSET+(gpioID>>4UL);
switch (gpioOp)
{
case GPIOPIN_SET:
*address|=(1UL<<(gpioID&0x04UL));
break;
case GPIOPIN_CLR:
*address&=~(1UL<<(gpioID&0x04UL));
break;
}

}

->The assembly listing shows that at offset 0x4A is the base address of the GPIO registers.
-> The High nibble of the gpioID contains the GPIO bank and the low nibble contains the pin itself

.text:0000000000000150 public SCH5127GPIOWrite
.text:0000000000000150 SCH5127GPIOWrite proc near ; CODE XREF: HDDLEDWrite+63p
.text:0000000000000150 ; HDDLEDWrite+7Ap ...
.text:0000000000000150 mov cl, dil
.text:0000000000000153 mov edx, cs:_RunTimeBaseAddr
.text:0000000000000159 shr dil, 4 ; dil either 5 or 1 =GPIO Bank in DIL
.text:000000000000015D add edi, 4Ah ; 'J' ; edi either 0x4B or 0x4F
.text:000000000000015D ; Bank GPIO1 or GPIO5
.text:0000000000000160 and ecx, 0Fh ; ECX containing GPIO Pin
.text:0000000000000163 movzx edi, dil
.text:0000000000000167 add edx, edi ; edx=BaseAddr+Edi(=0x4A+5 or 1)
.text:0000000000000169 in al, dx ; Read Value from GPIOBNK to AL
.text:000000000000016A cmp sil, 1
.text:000000000000016E mov dil, al
.text:0000000000000171 jnz short local_sil_ne_1 ; esi=2 -> SET Bit
.text:0000000000000173 movzx ecx, cl ; esi =1 -> CLEAR Bit
.text:0000000000000176 mov eax, 0FFFFFFFEh
.text:000000000000017B rol eax, cl
.text:000000000000017D and eax, edi
.text:000000000000017F jmp short local_write_value ; clear all except al
.text:0000000000000181 ; ---------------------------------------------------------------------------
.text:0000000000000181
.text:0000000000000181 local_sil_ne_1: ; CODE XREF: SCH5127GPIOWrite+21j
.text:0000000000000181 cmp sil, 2 ; esi=2 -> SET Bit
.text:0000000000000185 mov eax, 1
.text:000000000000018A jnz short local_error
.text:000000000000018C movzx ecx, cl
.text:000000000000018F shl eax, cl
.text:0000000000000191 or eax, edi
.text:0000000000000193
.text:0000000000000193 local_write_value: ; CODE XREF: SCH5127GPIOWrite+2Fj
.text:0000000000000193 movzx eax, al ; clear all except al
.text:0000000000000196 out dx, al
.text:0000000000000197 xor eax, eax
.text:0000000000000199
.text:0000000000000199 local_error: ; CODE XREF: SCH5127GPIOWrite+3Aj
.text:0000000000000199 retn
.text:0000000000000199 SCH5127GPIOWrite endp

After having another look at your driver; I looked through the Intel IHR9 controller datasheet, and updated my code accordingly. LEDs are turned on/off with GPIO on the IHR9, where the GPIO base address is amongst the PCI LPC interface bridge registers. Brightness is controlled via a separate pair of I/O addresses; retrieved with LPC SIO I/O address 0x2e, although I noticed during my disassembly that there's a fall back to LPC SIO I/O 0x4e.

So on the ex485, hard drive bay LEDs are mapped:
Blue: 22, 21, 13, 57
Red: 4, 5, 38, 39
Where values < 32 are GP_LVL otherwise GP_LVL2

Annoying blinking blue LED is 28 on GPO_BLINK

Brightness is controlled via register? 0x32 which must control one of the SCH5127s PWM outputs.

-

Having a look at the IHR7 datasheet http://www.intel.com/assets/pdf/datasheet/307013.pdf

0x4A is part of the GPIO Base address amongst the LPC Interface Bridge registers (page 363). Which is a 32 bit register starting at 0x48 but the top 16 bits are zero. Where the GPIO offsets are described on page 463. Although your driver is already making use of this information. It was more in response to your latest post and my recent readings of the IHR data sheets...

-

IHR7 and IHR9 appear to be identical for the addresses that I'm abusing. So if you have a look at modifying the initPciLpc_() method to also expect the PCI device and vendor ID for the IHR7. It will detect it and should use the correct GPIO addresses. Whether it then finds the SCH5127 is an unknown. While the LED bit assignments are almost guaranteed to be wrong.

just to avoid confusion: there are two different components used to control the nas' leds:

some of the GPIOs are directly attached to the ICH7-LPC bridge (the ones already handled by the leds driver above). In case of the H340:

0x06: Used to enable/disable the internal USB drive (the 256MB internal USB stick)
0x14: Info Led blue
0x18: Info Led red
0x19: Power Led
0x1B: Led for the USB front connector

the remaining LEDs (the 4 HDD leds) are not connected to the LPC bridge but to the sch5127 super-IO chip, which is itself connected via ISA-Bus to the LPC bridge. The LEDs brightnes is also controlled by the SCH5127's PWM3 port.

here is a snippet from /proc/ioports:
0800-087f : pnp 00:01
0870-0871 : dme1737
0870-0871 : dme1737
0cf8-0cff : PCI conf1
1000-107f : 0000:00:1f.0
1000-107f : pnp 00:01

1180-11bf : 0000:00:1f.0
1180-11bf : pnp 00:01
1180-11bf : leds_h340


LPC-GPIO-Interface is (in my case) from 0x1180-0x11BF and the SCH5127 is mapped as isa bus pnp device from 0x800 to 0x87f (where the dme1737 sensors driver uses the ioports 0x870-0x871). The sch5127 can only do per-byte-IO; this is why all accesses to the SCH5127's ports are done via UINT8 pointer.

I can not understand why acer had to attach the hdd leds to the superio chip and not directly to the LPC bridge (since there were still enough gpios available)

In those cases I figure the PCB layout designer found it much easier to lay tracks to the GPIOs on one chip, instead of the other.

What I've been wondering is why the wnas.sys driver is not more generic. Version I have specifically looks for the IHR9 chipset, and all of the I/Os are hard coded. Complicating deployment, and means that you'd have to recompile a new driver for hardware changes.

I'd be interested if someone could give me a copy of the H340 driver to see what the differences are. I've attached the ex485's version to this post.