Watchguard XTM 5 Series
-
This post is deleted! -
Has anyone got 2.4.3 update working on XTM 5 yet? For me 2.4.2 update works fine. But if i try updating from 2.4.1 to 2.4.3 the unit stops booting. Any ideas?
-
@747builder: Yes. Loading the compiled .aml file at boot works as long as you're running a BIOS with Speedstep unlocked and enabled.
@diesel678: Yes, running 2.4.3 here. Had no issues upgrading.
Edit: Typo
-
I measured my youngest (manufactured in 2015) XTM5 box power consumption with the Q9505S CPU in all power states with all cores loaded using mprime. This unit is also equipped with 80+ PSU made by FSP, as opposed to my other two units that have Seventeam PSUs. The idle power consumption on this box is only 37W.
But in my measurement I also discovered why Lanner / WatchGuard might have disabled Speedstep. Basically, it looks like the box power consumption savings are smaller than the extra processing time required by the CPU caused by reduced frequency, resulting in net power consumption increase rather than decrease! See the attachment.A good practical case study would be to measure steady state power consumption of a XTM5 box in actual installation with both BIOS configurations. Like a unit doing all its routing / firewalling / UTM duties under controlled traffic…
Edit: I had a momentary lapse of reason and the numbers in the attachment are obviously incorrect, since they assume that when the box is idle it consumes 0W as opposed to 37W. I will post corrected numbers later tonight, but there is a notable overall power saving, so implementing SpeedStep remains worthwhile.
![XTM5 Speedstep Power.jpg_thumb](/public/imported_attachments/1/XTM5 Speedstep Power.jpg_thumb)
![XTM5 Speedstep Power.jpg](/public/imported_attachments/1/XTM5 Speedstep Power.jpg) -
Ok, fresh off the press, here are the corrected power consumption numbers and net energy use for XTM5 with Q9505S in each available processor power state. Note that I was able to load the CPU more consistently by selecting a different mprime torture workload and I repeated each test several times to eliminate measurement variability. Also note that I reformatted the table to make it easier to understand. The numbers look very good and I will definitely keep Speedstep enabled in my deployed box. Under partial loads the energy savings are substantial!
Peter.
Edit: Cleaned-up the attached image for additional clarity.
![XTM5 Speedstep Energy Usage.jpg_thumb](/public/imported_attachments/1/XTM5 Speedstep Energy Usage.jpg_thumb)
![XTM5 Speedstep Energy Usage.jpg](/public/imported_attachments/1/XTM5 Speedstep Energy Usage.jpg) -
Nice! Guess I'll leave it enabled then. ;)
I'll do it anyway just to see how it affects stability, if at all.
Steve
-
I've read in a different thread that you do not need to flash the bios on an XTM 505 if you use a hard drive to boot pfsense. I can get the hard drive to boot on a different machine but on my XTM 505 it boots up shows me the bios and just plays a weird post jingle. When I get into bios everything is still view only. So I'm guessing I will have to flash it. Is there a particular bios I should flash with?
-
Yes, it should be possible to boot without flashing the BIOS. I may have already unlocked mine before I put an SSD in there. It certainly boots a CF card without any change.
Either the image I tweaked ages ago or t-rexky's image linked above should unlock the options and allow you to choose what to boot from.
There are details on flashing it earlier in this thread.
Be aware that flashing your BIOS is always inherently risky and that doing so with an image you downloaded from a forum even more so. ;) Your box may end up a brick etc etc
Steve
-
Yes, it should be possible to boot without flashing the BIOS. I may have already unlocked mine before I put an SSD in there. It certainly boots a CF card without any change.
Either the image I tweaked ages ago or t-rexky's image linked above should unlock the options and allow you to choose what to boot from.
There are details on flashing it earlier in this thread.
Be aware that flashing your BIOS is always inherently risky and that doing so with an image you downloaded from a forum even more so. ;) Your box may end up a brick etc etc
Steve
Got it, thank you. The only CF card I have at the moment is the 1GB that came with the Watchguard. When I used Win32DiskImager to image that card with your rom it still wont boot to the CF card. Is there a size limitation or am I goofing something up?
-
What do you mean by "When I used Win32DiskImager to image that card with your rom it still wont boot to the CF card."? You need a CF card with a bootable OS on it, BSD or Linux, a file with the BIOS image and installed 'flashrom' tools to actually do the reading and writing of the EPROM…
Also, the XTM5 boxes boot from SATA devices if there is no CF card installed without a need to flash the BIOS, so there is something else gone south with your attempts. So, unchanged factory BIOS with factory settings should successfully boot a SATA drive as long as you remove the CF card. All you need to do is unplug the CF card and plug-in the SATA drive, then power-up.
-
What do you mean by "When I used Win32DiskImager to image that card with your rom it still wont boot to the CF card."? You need a CF card with a bootable OS on it, BSD or Linux, a file with the BIOS image and installed 'flashrom' tools to actually do the reading and writing of the EPROM…
Also, the XTM5 boxes boot from SATA devices if there is no CF card installed without a need to flash the BIOS, so there is something else gone south with your attempts. So, unchanged factory BIOS with factory settings should successfully boot a SATA drive as long as you remove the CF card. All you need to do is unplug the CF card and plug-in the SATA drive, then power-up.
Ok, obviously I'm being a dummy about the BIOS then. Thanks for the info. I guess I still have some troubleshooting to do with the SSD then.. I can boot pfsense if I plug the SSD into another machine. But for whatever reason the Watchguard just sits there stuck at the different startup options.
-
Keep in mind that the XTM box BIOS defaults to IDE mode on SATA, not AHCI. If you installed pfSense on a machine in AHCI mode then perhaps it chokes on the XTM in IDE mode… I don't know enough about pfSense driver implementation to be able to talk intelligently about this. Hopefully someone else can chip in.
-
Keep in mind that the XTM box BIOS defaults to IDE mode on SATA, not AHCI. If you installed pfSense on a machine in AHCI mode then perhaps it chokes on the XTM in IDE mode… I don't know enough about pfSense driver implementation to be able to talk intelligently about this. Hopefully someone else can chip in.
I did notice the system was in AHCI mode when I was installing to the hard drive. I swapped it to IDE and then booted to a DVD of pfsense and then reinstalled to the drive but I'm getting the same results. I'll test creating the installation media in IDE as well.
-
If you’re wanting to unlock the bios I would remove the CF card and run straight from the ssd and get it working first. Then follow the instructions on page three of this forum. I believe I used putty and fetched it directly and then updated the bios that way.
Investigating the XTM8 box caused me to re-investigate the various bios editing tools available and I have now found that newer versions of amibcp are able to correctly edit the SuperIO tables without corrupting the bios in the process. So now we can have the bios correctly configure the SIO chip for gpio use and set the arm/disarm LED to red at boot, which seems like the way it should have been all along.
Flashing the bios is always a risk and I have bricked my own box doing it many times! However it was always due to a corrupt bios file rather than the flashing process itself and it is possible to recover from a bad flash (see earlier posts here). So the modified bios file is here. Flash at your own risk!
Modifications are:
Bios setup menus are unlocked and some aditional menus are unhidden.
LCD now reports 'pfSense V1.8' at boot time.
Speedstep is unlocked and enabled if you have a compatible CPU.
Arm/Disarm LED is now red from boot.Probably the safest way to get this file, least chance of corruption, is to fetch it straight to the box.
[2.1-BETA1][root@pfsense.localdomain]/tmp(10): fetch https://sites.google.com/site/pfsensefirebox/home/xtm5_83.rom xtm5_83.rom 100% of 1024 kB 1957 kBps
You can then also check its MD5 sum is correct:
[2.1-BETA1][root@pfsense.localdomain]/tmp(11): md5 xtm5_83.rom MD5 (xtm5_83.rom) = e75bc93ca2db547a3facb8d611f0d441
Then write it with flashrom from there:
[2.1-BETA1][root@pfsense.localdomain]/tmp(13): flashrom -w xtm5_83.rom flashrom v0.9.5.2-r1515 on FreeBSD 8.3-RELEASE-p8 (i386), built with libpci 3.1.9, GCC 4.2.1 20070719 [FreeBSD], little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found chipset "Intel ICH7/ICH7R". Enabling flash write... OK. Found ST flash chip "M25P80" (1024 kB, SPI) at physical address 0xfff00000. Flash image seems to be a legacy BIOS. Disabling coreboot-related checks. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... VERIFIED.
It may be necessary to reset the CMOS with the on board jumper to get access to the bios menus. My box has been unlocked for so long I can't remember if I had to and I have no easy way to test. ::)
Steve
-
I made some additional BIOS tweaks and I think I am now done. One thing I was still unable to get working is the password protection of the BIOS - no matter what I tried the unit always bypasses the password check when entering BIOS setup. It has been this way ever since I unlocked it. Here is the list of changes:
ACPI_AML version 0x03: Introduced independent BIOS minor version codes for ACPI_AML revisions BIOS branch x.x.An for E3400 CPU, where n is the ACPI_AML revision BIOS branch x.x.Bn for Q9505S CPU, where n is the ACPI_AML revision Changed 'Sign On Message' to include 'Unlocked v1.9.A3 / E3400 PT'. Changed 'Sign On Message' to include 'Unlocked v1.9.B3 / Q9505S PT'. XTM515-BIOS1.3-UNLOCKED1.9: Modified BIOS Strings from 'Fan confiruration' to 'Fan configuration' Modified DVMT BIOS String "This setting is only available for WinXp." to "This setting is only for WindowsXP." & introduced line breaks. Changed Failsafe and Optimal IDE mode to AHCI (00 -> 02) Changed Failsafe and Optimal 'Remote Access Term Type' to VT100 (00 -> 01) Changed Failsafe and Optimal 'Always CF Card Boot' to Disable Changed 'Sign On Message' to include 'Unlocked v1.9 PT'. XTM515-BIOS1.3-UNLOCKED1.8b: Corrected all ACPI_AML iasl Warnings based on "Internet wisdom" Corrected all applicable ACPI_AML iasl Remarks, 17 benign Remarks remain Introduced all eight P-states in ACPI_AML for E3400 CPU Corrected P-sate power consumption values based on XTM5 power measurements Changed 'Sign On Message' to include 'Unlocked v1.8b PT / E3400'. Changed 'Sign On Message' to include 'Unlocked v1.8b PT / Q9505S'. XTM515-BIOS1.3-UNLOCKED1.8a: Implemented P-state dependencies _PSD in ACPI_AML. Changed 'Sign On Message' to include 'Unlocked v1.8a PT / E3400'. Changed 'Sign On Message' to include 'Unlocked v1.8a PT / Q9505S'. XTM515-BIOS1.3-UNLOCKED1.8: Changed 'Sign On Message' to include 'Unlocked v1.8 PT / E3400'. Corrected ACPI version help string line breaks in "Enabled RSDP pointers to 64-bit [...]". XTM515-BIOS1.3-UNLOCKED1.7: Changed 'Sign On Message' to include 'Unlocked v1.7 PT / E3400'. Modified LCD boot string from "WG BIOS 1.3" to "Firewall UTM" in module 1B (Single Link Arch BIOS). XTM515-BIOS1.3-UNLOCKED1.6: Changed 'Sign On Message' to include 'Unlocked v1.6 E3400 PT'. Created two ROM branches, one for E3400 CPU and one for Q9505S CPU. XTM515-BIOS1.3-UNLOCKED1.5: Changed 'Sign On Message' to include 'Unlocked v1.5 PT'. Enabled 'PCIPnP' and 'Chipset' menus. Enabled 'CPU Configuration' submenu in 'Advanced' menu. Enabled 'ACPI Configuration' submenu in 'Advanced' menu. XTM515-BIOS1.3-UNLOCKED1.4: Updated platform 11 CPUID 1067a microcode to version a0b. XTM515-BIOS1.3-UNLOCKED1.3: Disabled 'Lan ByPass Control' submenu in 'Advanced' menu. Modified BIOS Strings from 'Port0 AHCI Speed limit to' to 'Port0 AHCI Speed limit' for Port0 to Port3. XTM515-BIOS1.3-UNLOCKED1.2: Changed 'Aways CF Card Boot' to 'Show' in 'Advanced' menu. XTM515-BIOS1.3-UNLOCKED1.1: Unlocked the BIOS by changing 'User Access Level' to 03 in 'Security' menu.
And those who are interested can download it from here:
https://www.dropbox.com/s/icnp3jloiw5rnyb/XTM515-BIOS-v1.9.zip?dl=0
As before, I included the factory and the modified ACPI tables in source format (.dsl) and compiled format (.aml).
DISCLAIMER: These work great for me, but please USE AT YOUR OWN RISK.
-
Did you add the code to set the ARM LED red? Don't think I can live without that now. ;)
Steve
-
Keep in mind that the XTM box BIOS defaults to IDE mode on SATA, not AHCI. If you installed pfSense on a machine in AHCI mode then perhaps it chokes on the XTM in IDE mode… I don't know enough about pfSense driver implementation to be able to talk intelligently about this. Hopefully someone else can chip in.
Figured out what my problem was… I was trying to boot on a GPT partition scheme.. I know what I'm doing, I swear!
-
Did you add the code to set the ARM LED red? Don't think I can live without that now. ;)
Steve
Unfortunately no, this is one of the features that I personally did not require. I presume it's fairly trivial to implement?
-
Yes just add the registers and values to the bootblock SIO table.
| Register | Value | Description |
| 07 | 08 | Logical device to 8, GPIO2 |
| 30 | 01 | Enable GPIO2 as GPIO |
| f0 | cf | Set bits 4 & 5 as output |
| f1 | 20 | Set bit 5 high, Red | -
Looks pretty straight forward, thanks for the info! I also looked up the data sheets to confirm I understand what this is changing.