[As Good As Solved!] Watchguard Firebox Arm/Disarm LED
-
Hmmm. Interesting.
Let me look through the code again…. -
it is a x500
I am working on including the LED support in the LCD driver. Can you start by answering this:
http://forum.pfsense.org/index.php/topic,44034.msg239376.html#msg239376
-
it is a x500
I am working on including the LED support in the LCD driver. Can you start by answering this:
http://forum.pfsense.org/index.php/topic,44034.msg239376.html#msg239376
Not sure what u want an answer too…
Do you want me to run this: lcdproc? if so what do you want me to look for? -
Nope. We need the output of this command:
pciconf -r pci0:31:0 0:256Run it at the console. We need it to develop the code that determines which model you have.
Steve
-
Nope. We need the output of this command:
pciconf -r pci0:31:0 0:256Run it at the console. We need it to develop the code that determines which model you have.
Steve
AHA, here is the result, hope it helps:
[2.0.1-RELEASE][root@Host.name]/root(1): pciconf -r pci0:31:0 0:256
24408086 0280000f 06010005 00800000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00004001 00000010 00000000 00000000
00000000 00000000 00004081 00000010
09060b0c 000000d0 0a058080 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00005475 00000000 00000000 00000000
00000200 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00004004 00000000 00000000
00002002 00001f02 00000004 00000000
c0000010 14050000 00112233 45670291
017c000f 00000000 00000f47 00000200
ffffffff
[2.0.1-RELEASE][root@root@Host.name]/root(2): -
Thanks for that! :)
Interesting looking at that and comparing it with Tix's from his X700, here.
They are almost identical but there is a difference.
Do you have any extra hardware in your box?
Hmm….Steve
-
Thanks for that! :)
Interesting looking at that and comparing it with Tix's from his X700, here.
They are almost identical but there is a difference.
Do you have any extra hardware in your box?
Hmm….Steve
Can not remember that i did see anything special in it when i had it open last time, compared to the first x500 i had that the LED prog did work on.
But i will crack it open again and have a look if needed… -
Aha!
The correct output should be:[2.0.1-RELEASE][root@pfsense.fire.box]/bin(20): WGXepc Found Firebox X-Peak WGXepc Version 0.3 17:2:2011 WGXepc can accept two arguments: -f (fan) will return the current fan speed or if followed by a number in hex, 00-FF, will set it. -l (led) will set the arm/disarm to the second argument: red, green, red_flash, green_flash, off Not all functions are supported by all modelsI suspect that you somehow have an old version of the program. Either that or it's been corrupted or your box isn't outputing some text! (unlikely).
Try downloading it again.Steve
Edit: In fact looking again you can see in the usage text is says 'WGXe' which is the first version of the program I wrote and only worked with the Xe box. You must have renamed it WGXepc without realising.
-
Aha!
The correct output should be:[2.0.1-RELEASE][root@pfsense.fire.box]/bin(20): WGXepc Found Firebox X-Peak WGXepc Version 0.3 17:2:2011 WGXepc can accept two arguments: -f (fan) will return the current fan speed or if followed by a number in hex, 00-FF, will set it. -l (led) will set the arm/disarm to the second argument: red, green, red_flash, green_flash, off Not all functions are supported by all modelsI suspect that you somehow have an old version of the program. Either that or it's been corrupted or your box isn't outputing some text! (unlikely).
Try downloading it again.Steve
Edit: In fact looking again you can see in the usage text is says 'WGXe' which is the first version of the program I wrote and only worked with the Xe box. You must have renamed it WGXepc without realising.
Well done spotting that one, i will get find the newest version and test it and let u know. But not sure how i managed to rename the old version…
-
Perhaps someone else has uploaded a renamed copy. :-\
Steve
-
I took the file that you attached on your reply #59 in this thread and now the output looks alot better.
I am not physical close to it now so can not check bet still output looks promising:[2.0.1-RELEASE][root@host.box]/usr/local/bin(11): ./WGXepc2
Found Firebox X-Core
WGXepc Version 0.3 17:2:2011
WGXepc can accept two arguments:
-f (fan) will return the current fan speed or if followed
by a number in hex, 00-FF, will set it.
-l (led) will set the arm/disarm to the second argument:
red, green, red_flash, green_flash, off
Not all functions are supported by all models
[2.0.1-RELEASE][root@host.box]/usr/local/bin(12): ./WGXepc2 -l green
Found Firebox X-Core
[2.0.1-RELEASE][root@host.box]]/usr/local/bin(13):;D
-
-
I took the file that you attached on your reply #59 in this thread and now the output looks alot better.
I am not physical close to it now so can not check bet still output looks promising:[2.0.1-RELEASE][root@host.box]/usr/local/bin(11): ./WGXepc2
Found Firebox X-Core
WGXepc Version 0.3 17:2:2011
WGXepc can accept two arguments:
-f (fan) will return the current fan speed or if followed
by a number in hex, 00-FF, will set it.
-l (led) will set the arm/disarm to the second argument:
red, green, red_flash, green_flash, off
Not all functions are supported by all models
[2.0.1-RELEASE][root@host.box]/usr/local/bin(12): ./WGXepc2 -l green
Found Firebox X-Core
[2.0.1-RELEASE][root@host.box]]/usr/local/bin(13):;D
This did work… for future reference..
Just my bubu renaming an old version, still do NOT know how that happened, but again thank U Steve for all your help..
-
I have managed to resurrect my X-Core box after bending the chassis straight(er) and sticking bits back on with tape.
Since it's now up and running I decided to further investigate the LED states since it is possible to set it to 'dark' in the bios.
So carrying on from where we left off I investigated the remaining possible GPIO states:Experimental findings of ICH2 IO space; 0x4080-0x4083 Set pins as gpio or native functions. 1=gpio Default 1a003180 0001 1010 0000 0000 0011 0001 1000 0000 Found 1a203180 0001 1010 0010 0000 0011 0001 1000 0000 0x4084-0x4087 Set gpios as input or output. 1=Input Default 0000ffff Found 0000ffff bit 1 is input. Possible outputs are 0000 0000 0000 0000 1111 1111 1111 1111 1 1 1 1 (set as gpio & set as output) 0x408c-0x408f GPIO Levels Default 1f1f0000 Found 09bf0000 0000 1001 1011 1111 Therefore we have 4 possible bits with 16 possible states LED state 1 1 1 1 Address: 408f 408e Value: 019f 0000 0001 1001 1111 Red fast flash * 01bf 0000 0001 1011 1111 Red fast flash * 039f 0000 0011 1001 1111 Red fast flash * 03bf 0000 0011 1011 1111 Red fast flash * 099f 0000 1001 1001 1111 Red Steady * 09bf 0000 1001 1011 1111 Red Steady * 0b9f 0000 1011 1001 1111 Red Steady * 0bbf 0000 1011 1011 1111 Red Steady * 119f 0001 0001 1001 1111 Green flash fast * 11bf 0001 0001 1011 1111 Green flash fast * 139f 0001 0011 1001 1111 Green flash fast * 13bf 0001 0011 1011 1111 Green flash fast * 199f 0001 1001 1001 1111 Green Steady * 19bf 0001 1001 1011 1111 Green Steady * 1b9f 0001 1011 1001 1111 Green Steady * 1bbf 0001 1011 1011 1111 Green Steady *It's clear from those results that some of the GPIO bits we had previously identified as being set to both GPIO mode and to output are not doing anything useful. Also I failed to find OFF.
With nothing to loose I entered some large sweeping numbers and found a different bit that plays a part but should not!
I am at a loss to explain why this is so but can report some new results. I imagine I have suffered a logic failure some where but I cannot see it.
Anyway:Actual observed relevant bits are in fact different. Therefore 3 bits giving 8 possible states. LED state 1 1 1 Address: 408f 408e Value: 013f 0000 0001 0011 1111 Off * 01bf 0000 0001 1011 1111 Red fast flash * 093f 0000 1001 0011 1111 Red slow flash * 09bf 0000 1001 1011 1111 Red steady * 113f 0001 0001 0011 1111 Off * 11bf 0001 0001 1011 1111 Green fast flash * 193f 0001 1001 0011 1111 Green slow flash * 19bf 0001 1001 1011 1111 Green steady *So we have all states. It's clear that, on the X-Core at least, there is some other bit of electronics between the GPIO pins and the LED. It makes me wonder about the other boxes, perhaps I stopped testing too soon. ::)
Whilst fmertz is working to include LED support in the LCD driver I have included this new data into the WGXepc program. Find it attached along with the source. As before remove the .png extension and set the permissions. Any feedback welcome. :)
Steve
-
Thanks for the hard work. At this point, in terms of integrating this LED code into the main LCD driver, I am facing this dilemma:
-
For ease of use from a client perspective, the driver needs to provide a unified set of capabilities so all Fireboxes export the same capabilities.
-
Some boxes support just LED on or off, some do blink, some fast blink.
-
If we want to support blink and fast blink, we need to provide a software implementation for boxes that do not have it in hardware.
-
In addition, what about blinking red and green together, like R-R-G-R-R-G, etc?
I guess I am leaning towards a basic software implementation for blinking using just the GPIO pins to turn the LEDs on or off, and give up on hardware blinking.
Thoughts welcome.
-
-
I agree, now we have red, green and off for all the boxes it would be best to do anything else in software.
I think for most people simply having the LED go green at boot time will be sufficient. Anything else can be done with a separate lcdproc client that only controls the led.Another completely different idea would be to follow JimP's suggestion and have a separate FreeBSD led driver. This allows for all sorts of interesting possibilities, you can send data to /dev/led directly and have it flash a message in morse code for example. :) It's how the LEDs on the ALIX box are handled.
Steve
-
Anything else can be done with a separate lcdproc client that only controls the led.
separate FreeBSD led driver.
Maybe we can talk mdima into adding calls to output() in the existing php client. That client captures a range of things as it is.
Going down the driver path throws portability out the window. The code becomes FreeBSD only, and a completely separate implementation would be required for Linux. I have done neither, but, in the end, the purpose is to learn.
-
I hadn't considered portability.
Looking at the geode led driver they use the oem_bios function to indentify the different models. I guess this might be FreeBSD only.Steve
-
Just realised I posted the most recent version of this in the X700 thread and forgot to include it here.
Same as previous versions but includes an option to switch the LCD backlight if you aren't running LCDproc with the firebox driver.
Find it attached with the source.[2.0.1-RELEASE][root@pfsense.fire.box]/conf(8): ./WGXepc Found Firebox X-Peak WGXepc Version 0.5 13:2:2012 stephenw10 WGXepc can accept two arguments: -f (fan) will return the current fan speed or if followed by a number in hex, 00-FF, will set it. -l (led) will set the arm/disarm led state to the second argument: red, green, red_flash, green_flash, red_flash_fast, green_flash_fast, off -b (backlight) will set the lcd backlight to the second argument: on or off. Do not use with LCD driver. Not all functions are supported by all modelsSteve
-
More good work. What is anyone using for a fan speed setting? I have upgraded to the SL7EG CPU, run powerd and still have the original fans in my X750E.
Thanks!
Mike
