Watchguard XTM 5 Series
-
@stephenw10 said in Watchguard XTM 5 Series:
FreeDOS will display at 9600bps by default.
But why are you booting FreeDOS? It's not required to run pfSense on there.Steve
I know, but I want to install something else on the box since my cpu will not support the newer versions. I am thinking about running a different fw distro on it with open vpn.
I need freedos to flash the bios so I can boot of the usb :-)
Thank you! -
You don't, you can flash the BIOS using flashrom directly from pfSense.
We have committed to supporting the 2.4.X branch for a year after 2.5 is released though. You have long while yet before that becomes an issue.
Steve
-
@stephenw10
I have changed to 9600bps and it still wiont show anything. I cant even see the bios or the boot up screen on 9600. Any other idea?
Thanks -
Do you see the BIOS setup at 115200? If not then you have a problem with the console cable or terminal setup. You should see some output there even with no boot media.
Steve
-
@stephenw10
Yes, i can see everything on 115200. Bios, Boot, PFSense installer and so on...
Only if I put a live cd on the cf, or freedos or anything else but pfsense i see no output after the boot screen is completed. My cable is good. -
Once it has booted up, unplug your console cable and plug it back in. That usually works for me for some reason.
-
@fffrank
Well That did not work. :) Anything else? -
What FreeDOS image are you using exactly?
Still unclear why it's a problem though.
@tibby said in Watchguard XTM 5 Series:
I need freedos to flash the bios so I can boot of the usb :-)
This is incorrect. So unless you want to actually run FreeDOS then just flash the BIOS from pfSense.
Steve
-
@dlucas46 said in Watchguard XTM 5 Series:
Hi all,
For those of you with Xeons that would like coretemp to report the correct temp, you can try this recompiled coretemp module.
I have set the TJMax value to 70c
Remove the png extension and upload to /boot/coretemp2.ko
Chmod 755 coretemp2.ko
In your /boot/loader.conf.local add the following:
coretemp2_load="YES"
Reboot.
You should now have a correct temperature reading. I did this several months ago and its been working fine.
If your CPU is in the same family as L5420 this should also work for you.
Is it possible to re-upload this file or is there another way I can get it?
Thank you!
-
@travishauch here you go: coretemp2.zip
Extract the file and upload to /boot/modules as described in previous post.
You do not need to rename the file this time. -
@dlucas46 said in Watchguard XTM 5 Series:
@travishauch here you go: coretemp2.zip
Extract the file and upload to /boot/modules as described in previous post.
You do not need to rename the file this time.Thank you so much! You are a life saver!!!!!!!!!!!!!!!!!!
-
Apologies for digging up an old thread.
Recently obtained a XTM510 and it at the moment is running pretty flawlessly with Debian, I've tried everything under the sun and kept coming back to Debian.
Is there any way to get this boxes "ARM" led rocking while under Debian? (probably the wrong place to ask) I have the bios that is way up there in this topic, is there any way I can modify it so that it doesn't say Pfsense1.8 on bootup as its not running that?
I have googled about for weeks to try and get the LED working on the front to no avail. By the seems, it looks like I'd need a windows OS on the box to mod the bios..?
Again, apologies if this is the wrong place, just would like some help, as this seems to be the only place with the most information on it.
-
The Arm/Disarm LED is connected to the SuperIO chip so there may well be an easier way to do it in Debian.
The modified BIOS sets up the GPIO pins correctly in order to set it to red at that point but the program checks for that and sets it if it has not been.
https://github.com/stephenw10/WGXepc/blob/7f688371751925586d047bc8a2b13bc03e92b64b/WGXepc.c#L1117So, enable GPIO2 as a GPIO, most of those pins are multifuction.
Set bits 4 and 5 as output.
Set the bits for red, green or off.Steve
-
@stephenw10 I have tried to compile that script to no avail, keeps telling me that there is files missing, I have googled about for those files, still with no avail. In regards to the bios, would I back it up, edit the bios backup on a different PC and then reflash it back to the box?
-
Yeah I've never tried to use it under Linux. But you should be able to use the data there to set the SuperIO chip some other way. It would not surprise me to find that Linux already has a utiltiy to do it.
Yes, editing the bios and reflashing it is what I did. That's always a risk!Steve
-
@stephenw10 I found SuperIO tool which dumps all of the superIO bits and bobs, no luck to controlling the IO as of yet, although I could just be looking for the wrong thing. If needs be, I can offer someone access to it if anyone wants to dink about on it to try and get the LED working.
Some positive though, I have gotten the system temp sensor to work with lm_sensors, with little to no fan speed with the stock fans and low speed adapters, its rock solid at 65C.
Ive slapped in the dump from the superIO tool below:
superiotool r6637 Found Winbond W83627THF/THG (id=0x82, rev=0x85) at 0x2e Register dump: idx 20 21 22 23 24 25 26 28 29 2a 2b 2c 2d 2e 2f val 82 85 ff fe c6 00 00 00 00 00 00 00 00 00 ff def 82 NA ff 00 MM 00 MM 00 00 00 MM MM MM 00 00 LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 f2 f4 f5 val 00 00 00 00 02 0e 00 ff 00 00 def 01 03 f0 06 02 0e 00 ff 00 00 LDN 0x01 (Parallel port) idx 30 60 61 70 74 f0 val 01 03 78 07 04 3c def 01 03 78 07 04 3f LDN 0x02 (COM1) idx 30 60 61 70 f0 val 01 03 f8 04 00 def 01 03 f8 04 00 LDN 0x03 (COM2) idx 30 60 61 70 f0 f1 val 01 02 f8 03 00 04 def 01 02 f8 03 00 00 LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 72 f0 val 01 00 60 00 64 01 0c 82 def 01 00 60 00 64 01 0c 80 LDN 0x07 (GPIO 1, GPIO 5, game port, MIDI port) idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 val 00 02 01 03 30 09 ff ff ff ff ff ff def 00 02 01 03 30 09 ff 00 00 ff 00 00 LDN 0x08 (GPIO 2) idx 30 f0 f1 f2 f3 f4 f5 f6 f7 val 01 cf 6c 00 00 ff 00 00 00 def 00 ff 00 00 00 RR 00 00 00 LDN 0x09 (GPIO 3, GPIO 4) idx 30 f0 f1 f2 f3 f4 f5 f6 val 00 ff ff ff 00 ff ff ff def 00 ff 00 00 00 ff 00 00 LDN 0x0a (ACPI) idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 f0 f1 f3 f4 f6 f7 f9 fe ff val 00 00 01 00 fb 00 30 00 00 00 00 8f 33 00 00 00 00 00 00 def 00 00 00 00 MM MM 00 00 00 00 00 00 00 00 00 00 00 RR RR LDN 0x0b (Hardware monitor) idx 30 60 61 70 val 01 0a 00 00 def 00 00 00 00 -
A (long) while back, I integrated the LED control code in a version of the lcdproc sdeclcd driver (the driver that applies to all these Watchguard/Lanner boxes). The intent was to capture all the hard discovery work generously shared by @stephenw10 before it became lost to the big bit bucket in the sky. lcdproc drivers can support a generic output function sent by a client, but it is up to the driver to interpret the number parameter as it sees fit. I meant for it to be portable FreeBSD and Linux code, but it has not been touched in a while. The code seemed a bit complex and not necessarily a great for for an LCD driver, so it was never submitted upstream. Have a look here:
-
@fmertz Beautiful, I already dinked with that driver to get the mappings correct, must've missed it. How would I control the LED with LCDProc? cant immediately see an option to do so.
-
Well, you would have to create a "client" to the LCDd server, and issue an "output" command, followed by an int. That value would be interpreted as:
/** * API: Updates LEDs as per "state". Here, "state" is supposed to contain the sequence the LEDs are * to be lit by. We need to support Red, Green and Off. Therefore, we need 2 bits to encode the * possible values. So, a 32 bit "state" can host a sequence of 16 separate illuminations. Each * group of 2 bits is examined in sequence, as a time slot, each time output is called, and the * hardware LEDs are updated accordingly. */Read through the beginning of this: LCDproc Developer's Guide
In short, after starting LCDd with the sdeclcd driver, create a new client:
telnet 127.0.0.1 13666Then try:
hello info output 2863311530 output 1431655765This was only tested on an older X-Core-e, so adjust your expectations...
-
Significantly more difficult on the XTM5 because they are not directly addressable GPIOs like they were on the X-E. You need to run a sequence against the SuperIO chip to access it's registers.
Steve
