search

stupidpupil / hp_n36-40-54l_health_led_drivers

Control the Health LED on HP Microservers N36/40/54L
34 stars 5 forks source link

Controlling the red LED #2

Open martinellimarco opened 5 years ago

martinellimarco commented 5 years ago

First of all, thank you for this driver. I own a N40L since 2014 and from time to time I google to see if anyone have come up with a solution to control the status led. I'll try this driver soon.

In the readme you say you don't know how to control the red led. I remembered that some years ago I accidentally turned my status led pink/magenta.

I don't know if the color was due to the blue+orange leds or the blue+red ones. If it was blue+orange what I'm writing is not useful and I'm sorry for wasting your time but if it was blue+red maybe this can be an hint for you on how to pilot that led.

At the time I've found others on the internet with the same problem. Eventually an user in this wiki discovered that disabling a particular feature in the sounthbridge turned the red led off. https://n40l.fandom.com/wiki/Activity_Light_Control_(HP_Symbol)

The relevant part of the comment is this:

I had it after configuring a lot in the Mod-BIOS. I finally found out what causes the switch to pink: it's the last option in chipset->southbridge->usb-settings->port-5-OHCI. It must be set to "disabled".

That solved the problem for me and the status led went blue again.

Maybe you already know all of this, but I hope this may be useful.

stupidpupil commented 5 years ago

Thanks for opening this issue, and the suggestion.

I think you might be right that the problem you reference is an issue with the orange LED being turned on inappropriately, but it's worth looking into. I think it might also be the issue fixed in the 2011.07.29 version of the firmware.

I do wonder if there simply isn't any way for the operating system to control the red LED (with the BIOS released by HP at least). The circumstances that the manual describes would cause it all seem to be fairly critical issues that prevent booting - and that I'm guessed are recognised by the BIOS/hardware themselves.

I note that I only found the orange and blue LEDs by poking semi-randomly at GPIO pins - which is an extremely stupid thing to do, and has a decent chance of breaking something permanently...

I get the impression that Windows Server 2011 SBS could change the colour of the health light - indeed, perhaps adding support for this created the purple/pink bug. But I don't know if it could ever control the red LED...

martinellimarco commented 5 years ago

I'm running the 2013 firmware (modded) so I don't think it's the same issue fixed in the 2011 version. Now that I think of it, I've seen the pink/purple/magenta color playing with hibernation. I'll try to reproduce it and see if it's the orange or the red led.

martinellimarco commented 5 years ago

I did some tests and I think that what I see is the red led. Enabling the option in Chipser -> SouthBridge Configuration -> SB USB Configuration -> OHCI HC (Bus 0 Dev 20 Fn 5) on 2013 modded firmware I see the led turn pink. If during POST i press the power button the blue led goes off immediatly and I see the red one still powered for a second before the machine turn off. If I disable the same option in the bios I see the blue led as usual and when I press the power button the blue led goes off but I don't see the red one.

I tested with hibernation too, but I was remembering incorrectly. It wasn't happening with hibernation but with "halt" instead of "shutdown". If you use halt then manually power off the machine the led stay on. Blue if you have the bios option disabled, pink if it's enabled.

I took a photo of the pink led, so you can judge if it's blue+red on your own. https://postimg.cc/SJ2vC54S

stupidpupil commented 5 years ago

Hmm. I note that "Bus 0 Dev 20 Fn 5" actually corresponds to the ACPI/SMBus controller on the SB800-series.

Perhaps it's worth looking again at some of the pins that controller uses.

martinellimarco commented 5 years ago

I'm probably getting off topic, but may I ask you where are you getting this information? I'm sincerely interested in understanding how to get this kind of informations. I'm not competent enough when it comes to x86, I've wrote few drivers for FreeRTOS on ARM in the past but the hardware of the board I was working on was simple and very well documented. I understand the theory behind the process, but I lack detailed knowledge on the architecture of "modern" x86 boards. Part of my interests for this project is the idea that piloting a led should be a good place to start to learn more about the low level mechanisms.

I googled for technical reference and I've found a few documents describing the SB800:

How do you know that it actually corresponds to the ACPI/SMBus?

I always felt like I miss some information source when it comes to hardware detail. Maybe I'm looking in the wrong place or there are archives I don't know about, or simply I'm missing some keywords.

Can you enlight me?

stupidpupil commented 5 years ago

I'm completely incompetent in this area, and wondering where I got my idea now...

Apologies, I might well have just misled you. Will see if I can work it out.

martinellimarco commented 5 years ago

There is no need to apologize, I was just curious about the process of gathering the informations. For example, I'm reading the source of gpio-sb8xx and it match what I read in https://www.amd.com/system/files/TechDocs/45483.pdf so now I understand better how a driver like this is made, but I'm puzzled about how you have found out that pin 188 and pin 187 are the GPIOs that are attached to the LEDs. Have you inspected the board, was it trial and error PWMing a signal on every pin until a led turned on, or is there a method I don't know about?

stupidpupil commented 5 years ago

IIRC I was probing on the SMBus ports, and probing for SMBus devices on port 4 didn't find anything but it did make the HP logo turn a slightly unstable pink.

I'm not sure that I actually worked it out at that point, however, and I did go through of period trial-and-error toggling GPIO pins in frustration.

martinellimarco commented 5 years ago

thank you

YNikiforov commented 3 years ago

Blue and orange signals to the HP LED travel together through the PCB directly towards the SB. Red is routed differently, it goes through a pair of small mosfets Q8 and Q10 near the connector J50. All three signals can be tracked up to some tiny PCB traces under the SB chip and that's it. Which pin of the SB controls the red LED is a mystery.

Activating the option OHCI HC (Bus 0 Dev 20 Fn 5) in BIOS turns the red light on after reboot. Also there appears a new USB 1.1 controller in the system with device ID 00:14.5.

lspci -k | grep -i usb -A2
...
00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
        Subsystem: Hewlett-Packard Company SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
        Kernel driver in use: ohci-pci
        Kernel modules: ohci_pci
...

This is in hex and hence corresponds to our Dev 20 Fn 5 in decimal numbers. Maybe it is a special USB port used for debugging or logs or emergency restore.

I tried disabling this device but no luck. Unbind using echo "0000:00:14.5" | sudo tee /sys/bus/pci/drivers/ohci-pci/unbind results in the line Kernel driver in use: ohci-pci to disappear, in the lspci list. But the controller is still present in the list and the red LED is still on. Controller could possibly be turned off via sysfs at /sys/bus/pci/drivers/ohci-pci/0000:00:14.5/power. But it accepts only on and auto input values like this sudo sh -c 'echo auto > control' and sudo sh -c 'echo on > control'. Tried off, suspend, suspended, disable, disabled. All these are rejected with I/O error message.

Maybe some reverse engineering under Windows could help. Or looking into the BIOS code that turns that shit on. If someone has a board that could be sacrificed, would be possible to unsolder everything on the way and track it further to the exact pin of the SB and maybe it would help. But still it is easier to plug something like Blink(1) device in one of the front USB connectors to have kinda full RGB color. Otherwise the options are:

AnterCreeper commented 2 years ago

YNikiforov According to the Document from HPE, the red led indicates critical error, such as No RAM, Bad CPU or South/North Bridge, Bad firmware, etc. So it is specially controlled.