Watchguard XTM 5 Series
-
Probably. :)
It looks like standard X86 hardware from the de-manufacturing instructions.
I think you're the first person with a spare one though, they are still fetching big money second hand.
It looks like it has a seperate VPN accelerator card of some sort, it probably isn't supported by FreeBSD so I'd remove that.
If you can document your progress that would be great! :)Steve
-
I have managed to acquire one of these boxes, an XTM 505, for a very reasonable cost. Unfortunately it was damaged in shipping which cracked the front panel but that does mean I have an excuse to void the warranty to repair/replace it. :)
These are really quite nice boxes. As with previous Watchguard offerings the 5 series models share the same hardware package and are only differentiated by the licensing which is not relevant for pfSense use.The box has:
A Celeron 440 CPU.
1GB of DDR2 ram in a single DIMM. There are two slots on the motherboard supporting up to 4GB (at least, the G41 chipset claims to support 8GB or DDR2).
It has an ICH7 82801GB southbridge.
1X Intel 10/100 NIC (built into the chipset)
6X Intel 82574L Gigabit NICs. ;D
2X front panel USB sockets
RJ-45 style serial console connectionIt has a VPN accelerator card connected via PCI-e, a Cavium Nitrox CN1605, which is not supported by FreeBSD at this time. It doesn't cause a problem though.
The connection to this card is the reverse of what you might expect but common in SBCs. The PCI-E slot is on the card and the edge connector is on the motherboard. Some adapter would be required to use this for a standard PCI-E card.It has two CPU fans and one system fan (plus one in the PSU) but thankfully unlike previous models they are software controllable and are set to thermal control (possibly via the Winbond W83627THG super I/O though the board also has a W83792G chip which could also do the job) in the BIOS by default. Resulting in a relatively quiet appliance.
Like previous models it has an LCD with front panel buttons. This is a Vitek Display VC202W-GGE-JC01. It is still connected via a parallel interface but is different to the earlier units. It also has the familiar Watchguard arm/disarm LED though my unit only ever shows green, possibly damaged.
Edit: Although different manufacturer and type it still complies with the original spec from the X-Core consequently the current driver in the lcdproc-dev package works just fine. ;D The keys are not correct but do work to some extent.
There are two SATA headers on the motherboard and the PSU has an unused SATA power connector. There is also space to mount a drive but additional hardware would be needed.
The unit draws ~30W at idle. It seems to run quite cool, 35°C in the BIOS, and the platform has much upgrade potential for alternative CPUs.
Like the X-e box it has some diagnostic LEDs on the board (near the PSU). There are 5 leads labled led3-7. LED3 indicates power to the board, even when the unit is 'off'. After successfully POSTing all 5 are lit. Unlike previos models it has a soft power switch, it's never totally de-powered. There is a microswitch on the motherboard which appears to be connected in parallel with the rear power switch.
Unlike other models the BIOS on the 5 series is easily accessible. Console redirect is enabled by default at 115200 8N1, press TAB to enter the bios setup (in colour!). This is great for CPU swaps etc however everything in the bios is set to read only (except the clock) so nothing can be adjusted. :( It's an AMI bios I'm unfamiliar with and the BIOS rom is non-removable so playing with this is high risk. ;)
The bios is stored on an ST M25P80 (pdf), an 8 pin serial flash device. It is readable with flashrom in FreeBSD.
The motherboard had a 'lan bypass' option and the menu for configuring it is still present in the bios however the necessary relays are missing from the PCB.
Unfortunately this means it cannot be set to boot from the USB sockets (would be a security risk I suppose ::)) so to install pfSense you need to replace the CF card. The Watchguard OS is stored on a 1GB Transcend card and I had no trouble booting a 4GB Transcend card though there is a significant delay before booting starts.
There are numerous other populated headers on the board almost all unlabled. However it may be possible to discover there use since this is a custom appliance built by Lanner. It very similar to the FW-7580 and indeed the motherboard is labelled MB-7580 W. The LCD has been moved for some reason and is now attached via a long cable. ???
Is running 2.0.1 like a champ! :)
See attached file dmesg.boot.
More to come…
Steve
Edit: Additional LCD info.
Edit: Correction -
Edit: Although different manufacturer and type it still complies with the original spec from the X-Core consequently the current driver in the lcdproc-dev package works just fine. ;D The keys are not correct but do work to some extent.
If you discover the mapping of key to port value, I'll be happy to update the driver code. Same if you can pass along the exact ICH pci device id (we already know the manufacturer to be Intel id 0x8086), as well as GPIO pins for the LEDs.
-
Working on it. :)
In fact all the keys work they are just incorrectly mapped to the expected function.
The arm/disarm led on my box is suspect (never shows red) so it might be tricky to get a definate mapping.
Fun and games!Steve
-
Ok so here's the pci device listing:
[2.0.1-RELEASE][root@pfSense.localdomain]/root(11): pciconf -lc hostb0@pci0:0:0:0: class=0x060000 card=0x2e308086 chip=0x2e308086 rev=0x03 hdr=0x00 cap 09[e0] = vendor (length 12) Intel cap 6 version 1 vgapci0@pci0:0:2:0: class=0x030000 card=0x2e328086 chip=0x2e328086 rev=0x03 hdr=0x00 cap 05[90] = MSI supports 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP pcib1@pci0:0:28:0: class=0x060400 card=0x27d08086 chip=0x27d08086 rev=0x01 hdr=0x01 cap 10[40] = PCI-Express 1 root port max data 128(128) link x1(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x27d08086 cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib2@pci0:0:28:1: class=0x060400 card=0x27d28086 chip=0x27d28086 rev=0x01 hdr=0x01 cap 10[40] = PCI-Express 1 root port max data 128(128) link x1(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x27d28086 cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib3@pci0:0:28:2: class=0x060400 card=0x27d48086 chip=0x27d48086 rev=0x01 hdr=0x01 cap 10[40] = PCI-Express 1 root port max data 128(128) link x1(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x27d48086 cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib4@pci0:0:28:3: class=0x060400 card=0x27d68086 chip=0x27d68086 rev=0x01 hdr=0x01 cap 10[40] = PCI-Express 1 root port max data 128(128) link x1(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x27d68086 cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib5@pci0:0:28:4: class=0x060400 card=0x27e08086 chip=0x27e08086 rev=0x01 hdr=0x01 cap 10[40] = PCI-Express 1 root port max data 128(128) link x1(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x27e08086 cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib6@pci0:0:28:5: class=0x060400 card=0x27e28086 chip=0x27e28086 rev=0x01 hdr=0x01 cap 10[40] = PCI-Express 1 root port max data 128(128) link x1(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x27e28086 cap 01[a0] = powerspec 2 supports D0 D3 current D0 uhci0@pci0:0:29:0: class=0x0c0300 card=0x27c88086 chip=0x27c88086 rev=0x01 hdr=0x00 uhci1@pci0:0:29:1: class=0x0c0300 card=0x27c98086 chip=0x27c98086 rev=0x01 hdr=0x00 uhci2@pci0:0:29:2: class=0x0c0300 card=0x27ca8086 chip=0x27ca8086 rev=0x01 hdr=0x00 uhci3@pci0:0:29:3: class=0x0c0300 card=0x27cb8086 chip=0x27cb8086 rev=0x01 hdr=0x00 ehci0@pci0:0:29:7: class=0x0c0320 card=0x27cc8086 chip=0x27cc8086 rev=0x01 hdr=0x00 cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 pcib7@pci0:0:30:0: class=0x060401 card=0x244e8086 chip=0x244e8086 rev=0xe1 hdr=0x01 cap 0d[50] = PCI Bridge card=0x244e8086 isab0@pci0:0:31:0: class=0x060100 card=0x27b88086 chip=0x27b88086 rev=0x01 hdr=0x00 cap 09[e0] = vendor (length 12) Intel cap 1 version 0 features: Quick Resume, 4 PCI-e x1 slots atapci0@pci0:0:31:1: class=0x01018a card=0x27df8086 chip=0x27df8086 rev=0x01 hdr=0x00 atapci1@pci0:0:31:2: class=0x01018f card=0x27c08086 chip=0x27c08086 rev=0x01 hdr=0x00 cap 01[70] = powerspec 2 supports D0 D3 current D0 none0@pci0:0:31:3: class=0x0c0500 card=0x27da8086 chip=0x27da8086 rev=0x01 hdr=0x00 em0@pci0:2:0:0: class=0x020000 card=0x00008086 chip=0x10d38086 rev=0x00 hdr=0x00 cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled em1@pci0:3:0:0: class=0x020000 card=0x00008086 chip=0x10d38086 rev=0x00 hdr=0x00 cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled em2@pci0:4:0:0: class=0x020000 card=0x00008086 chip=0x10d38086 rev=0x00 hdr=0x00 cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled em3@pci0:5:0:0: class=0x020000 card=0x00008086 chip=0x10d38086 rev=0x00 hdr=0x00 cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled em4@pci0:6:0:0: class=0x020000 card=0x00008086 chip=0x10d38086 rev=0x00 hdr=0x00 cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled em5@pci0:7:0:0: class=0x020000 card=0x00008086 chip=0x10d38086 rev=0x00 hdr=0x00 cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled fxp0@pci0:1:8:0: class=0x020000 card=0x27dc8086 chip=0x27dc8086 rev=0x01 hdr=0x00 cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0
I believe the ICH7 is the host: chip=0x2e308086 so device ID is 2e30.
-
[2.0.1-RELEASE][root@pfSense.localdomain]/root(11): pciconf -lc isab0@pci0:0:31:0: class=0x060100 card=0x27b88086 chip=0x27b88086 rev=0x01 hdr=0x00
The current code looks for the Low Pin Count device at bus 0, device 31, function 0. This is where GPIO lives. My read is that the device ID is 0x27b8, sub type 8086.
Linux file /usr/share/misc/pci.ids lists:
27b8 82801GB/GR (ICH7 Family) LPC Interface Bridge
8086 544e DeskTop Board D945GTPI'll read the ICH7 spec to find out more. Next, we'll have to figure out the exact GPIO pin for Armed/Disarmed.
-
I agree, that's the LPC device.
After extensive testing I am thinking that the arm/disarm led on the XTM 5 is not driven by GPIO pins on the ICH7.As other models the GPIO base address is stored in LPC pci config at offset 48H: [2.0.1-RELEASE][root@pfSense.localdomain]/root(14): pciconf -r pci0:0:31:0: 0x48 00000481 As before bit 1 is hard wired high so the GPIO base is 0x0480\. Same as the X-Peak and X-E. Experimental findings of ICH7 IO space; GPIO 0-31 0x483-0x480 Set pins as gpio or native fuctions. 1=gpio Default 1F3FF7FF 0001 1111 0011 1111 1111 0111 1111 1111 Found 1F15F7C1 0001 1111 0001 0101 1111 0111 1010 0001 0x0487-0x0484 Set gpios as input or output. 1=Input Default E0E8FFFF Found E0E87F83 bit 1 is input. Possible outputs are 1110 0000 1110 1000 0111 1111 1000 0011 (set as gpio & set as output) 1 1111 1 1 1 1 1 10 possible gpio bits! Far more than previously. 0x048f-0x048c GPIO Levels Default 02FE0000 0000 0010 1111 1110 0000 0000 0000 0000 Found E3EEFBBF 1110 0011 1110 1110 1111 1011 1011 1111 Set as an output GPIO and are low (led is off) 1 11 1 1 Test result x xxxx x x x x x 0x0487-0x0484 Enable blink. 1=Blink at 1Hz Default 00040000 0000 0000 0000 0100 Found 00040000 1 Results: No effect on arm/disarm led. :( We have a clue from Watchguard OS, gpio2 GPIO 32-63 0x4B3-0x4B0 Set pins as gpio or native fuctions. 1=gpio Default 000300FF 0000 0000 0000 0011 0000 0000 1111 1111 Found 000000CF 0000 0000 0000 0000 0000 0000 1100 1111 0x04B7-0x04B4 Set gpios as input or output. 1=Input Default 000000F0 0000 0000 0000 0000 0000 0000 1111 0000 Found E0E87F83 bit 1 is input. Possible outputs are 0000 0000 0000 0000 0000 0000 0011 0000 (set as gpio & set as output) 1100 1111 6 possible gpio bits. 0x04BB-0x04B8 GPIO Levels Default 00030003 0000 0000 0000 0011 0000 0000 0000 0011 Found 000000BB 0000 0000 0000 0000 0000 0000 1011 1011 Set as an output GPIO and are low 1 1 Test result xx xxxx None found :(
Or maybe the led is damaged on my box.
Next possibility is via the superIO chip but that is way harder to test. :(Steve
-
Or possibly it's driven from the LCD module in some way.
There is a clue in the boot message from the Watchguard OS:Parallel LCM Driver Version 0.0.2 is loaded plcm_drv: LPTx Address = 378 Logical Device GPIO2 disabled, no function, enabling now GPIO2(bit4) not configured for LED triggering, configuring now SST_ | <enable_flash_ich_dc_spi> WARNING: SPI Configuration Lockdown activated.</enable_flash_ich_dc_spi>
Hmm. Time to look at the display.
Steve
-
There is a clue in the boot message from the Watchguard OS:
GPIO2(bit4) not configured for LED triggering, configuring now
How about this GPIO 2 area? It is at gpiobase + 0x30. Section 10.10.6 in the spec. Bet you it is bit 4 does stuff…
-
If you mean GPIOs 32-63 on the ICH7 then I already tried that, see test results above. Nothing doing.
The fact that is refer to 'logical device gpio2' makes me think it could be the superio chip as that is how it is referred to in the datasheet. Also gpio2 bit 4 happens to be a dedicated gpio.
There is the other winbond chip which looks to be only accessible via i2c. That would be difficult.
Steve
-
Aha! ;D
Found it!
The arm/disarm led is controlled by bits 4 and 5 of logical device 8 (GPIO2) on the SuperIO chip.In order to use the led two things must first be set. The GPIO2 device must be enabled by setting CR30 on logical device 8 to 0x01. Then bits 4 and 5 must be set to output but setting CRF0 on logical device 8 to 0xCF. This ties in with the clue in the previous post.
The odd thing about this is that I would have expected these to be setup by the bios and set the LED as red from the outset. In fact my box never shows red at all if I boot the Watchguard OS.Then the led can be controlled via CRF1:
Control Register F1 Bit5 Bit4 Arm/Disarm LED 0x00 0 0 Off 0x10 0 1 Green 0x20 1 0 Red 0x30 1 1 Off
Accessing these control registers is a proper PITA! A great string of commands have to be sent. For example, setting CRF1 to 0x10 to set the led green:
[2.0.1-RELEASE][root@pfSense.localdomain]/conf(85): ./writeio 2e 87 Setting 2e to 87 [2.0.1-RELEASE][root@pfSense.localdomain]/conf(86): ./writeio 2e 87 Setting 2e to 87 [2.0.1-RELEASE][root@pfSense.localdomain]/conf(87): ./writeio 2e 7 Setting 2e to 7 [2.0.1-RELEASE][root@pfSense.localdomain]/conf(88): ./writeio 2f 8 Setting 2f to 8 [2.0.1-RELEASE][root@pfSense.localdomain]/conf(89): ./writeio 2e f1 Setting 2e to f1 [2.0.1-RELEASE][root@pfSense.localdomain]/conf(90): ./writeio 2f 10 Setting 2f to 10 [2.0.1-RELEASE][root@pfSense.localdomain]/conf(91): ./writeio 2e aa Setting 2e to aa
Fortunately you can use superiotool to read back what we have done:
[2.0.1-RELEASE][root@pfSense.localdomain]/conf(92): superiotool -d superiotool r 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 01 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 83 10 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 09 00 30 00 00 00 00 8f 32 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
Steve
-
Here are the keyboard mappings for the LCD:
Button Pressed 0x379 None 87 Up E7 None A7 Down C7 None 87 Left CF None 8F Right EF None AF
Unfortunately I think that's going to cause a conflict with the existing codes. :-\
Steve
-
Here are the keyboard mappings for the LCD:
Unfortunately I think that's going to cause a conflict with the existing codes. :-\Good find. After applying the mask, all these codes are in conflict with existing codes, and map differently. We need to find a (portable/easy) way to tell the boxes apart…
-
There seemed to be quite a lot of potential in this box for unlocking additional features in the bios, boot from USB various power saving tweaks etc. Also the arm/disarm led is not correctly set to red at boot. I suspect that Watchguard must have fixed this with bios update them selves but I have no proof of that.
You can easily read and write the bios flash chip from pfSense with the flashrom package:pkg_add -r ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/ports/i386/packages-8.1-release/Latest/flashrom.tbz
Initially I read the bios image to a file so I could look at it with various tools. This was all mostly new to me, I have played around with award bios mods before but not AMI. Much reading later I realised the bios is locked down because the 'user access level' is set to 2, 'limited', in which the only thing that can be modified by the normal user is the time and date.
As a first test I changed the access level to 3, full, using amibcp. Although I had read that newer AMI bioses could be corrupted by amibcp this did not seem to be the case for this one modification. I got brave and flashed back the modified image, success! I now had access to all the available settings.However many of the interesting settings are hidden in the standard bios so in order to enable USB boot I modified the bios image again to unhide most options. I chose to hide the LAN bypass menu since that relays are not included on the board. I reflashed the image, disaster! ??? It appears that, as reported on many other sites, amibcp does indeed often or almost always corrupt the bios. The first time I had just been lucky. Since the bios flash chip is soldered to the board there is no possibility for a 'hot flash' and I only have one of these anyway.
Looking on the positive side the board does have an SPI header next to bios chip for programming it and this seemed like an excellent opportunity to learn how to use it! ::)
Much reading later… I came across the website of this genius from the Czech republic. As well as providing a useful, and incredibly simple, circuit this man has provided code to the flashrom project to use it. Alternatively use his own code from DOS. Awesome job!
Now unfortunately you need a later version of flashrom than 8.1 provides but fortunately the most recent version from 8-stable installs and runs fine on an 8.1 box (for parallel port use anyway).Lanner helpfully provide the pinout of the SPI header but you can easily find it with a multimeter anyway. Interestingly the WP (write protect) pin is not connected which I thought was going to be a show stopper
but it's not needed. Also useful is that the motherboard, when plugged in but not powered up, provides the required 3.3V to power the chip pull the HOLD pin high. So some soldering and five minutes crossing my fingers later I'm back in business. :)
You don't want to be doing this but it's nice to know you can if you have to! :)Steve
-
How's the progress on these units? If you need help getting the LCD working, I have a hacky script that should work. And do you think any more will be hitting the second-hand market anytime soon? They seem okay on specs, but I guess Watchguard will EOL them anyways at some point.
-
The LCD is configured exactly the same as the previous models so existing drivers work fine.
The EOL on these is not going to be for a long time (sometime after 2016) so right now you just have to get lucky. ;)I have been playing around with a Core2Duo E4500. First of all it works in there no problems, it's detected by the bios and by pfSense. It's a nice upgrade from single core Celeron to Dual core C2D and it's not expensive. The platform should support many other processors. The peak power consumption goes up, 41W in the bios and around 47W while booting, but the idle consumption is identical at 30W so the fans remain slow unless it's pushed.
There is potential to actually reduce this by using Speedstep which is in the C2D but not the Celeron. However the required components are not all there. I think I'm about 90% of the way to making it work but something is eluding me.
So far I have:
Extracted and modified the DSDT table from the bios (including fixing a few errors on the way) to include code to pass the P-state information to the est(4) driver via ACPI.
Found and disabled the code that sets the EIST lock bit in the bios. This required extracting the relevant bios module and disassembling it.
Set the EIST enable bit. Both these are MSRs in the CPU.So far the est driver attaches to the 2 cpus at boot and provides the various frequency/voltage combinations to powerd. Everything appears to be working great except that the power consumtion remains steadily at 30W. I don't think it's actually changing anything. :-\
I'm learning a lot though! :)
Steve
-
Oh, so the SDECLCD firebox driver works pretty much out of the box with these units? That makes life pretty easy. It looked different in your pics, but I would assume Watchguard made them make it the same for ease of use.
-
Exactly. Only the the X-Core had an actual SDEC LCD all the other models have LCDs made by someone else but with custom part numbers. I assumed Watchguard didn't want to have to include code for many types of LCD in their OS.
Steve
-
I have been playing around with a Core2Duo E4500.
Wikipedia mentions that series has 64bit support.
We need to put a 64 bit lcdproc/sdeclcd package on the radar…
-
Indeed, though I'm running it 32bit. It would be interesting to see whether there's much advantage to running 64bit. There are plenty of reports that it makes almost no difference.
I haven't tried your new driver yet but thanks for doing it :). Still trying to make EIST function correctly. It doesn't help that the SuperIO is not compatible with mbmon so I can't read the core voltage directly.Steve
-
I'd love to get the lcdproc-dev and SDECLCD driver working on 64bit. Does that require a whole driver rewrite or a recompile? I'm not even sure if lcdproc-dev is amd64 capable…
-
I think I'm losing my mind over EIST. ::)
I have eventually come to the conclusion that EIST is in fact working with my modified bios and loading a custom DSDT.[2.0.1-RELEASE][root@pfSense.localdomain]/root(1): sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.temperature: 25.0C dev.cpu.0.cx_supported: C1/1 C2/96 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% last 5000us dev.cpu.0.freq: 1200 dev.cpu.0.freq_levels: 2200/65000 2000/55000 1800/50000 1600/45000 1400/40000 1200/30000 dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.temperature: 25.0C dev.cpu.1.cx_supported: C1/1 C2/96 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% last 5000us
If I read the MSRs directly from the CPU using cpucontrol I can see that the multiplier and VID are set as requested by the DSDT.
[2.0.1-RELEASE][root@pfSense.localdomain]/root(3): cpucontrol -m 198 /dev/cpuctl0 MSR 0x198: 0x0b280b28 0x0600061d
As well as that I can see the core voltage is reduced by reading the SuperIO chip registers directly.
At 1200 V-Core is at register 20\. idx 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f val 01 78 01 ff 04 37 00 01 78 01 50 01 3c 3c 01 05 01 ff 20 00 00 01 01 3c 43 00 ff ff 24 32 00 e3 64 c8 25 ba d0 80 00 26 1f ff f0 00 de 5f 9d b4 04 0a 54 7c 5a 08 26 28 a4 15 3d 20 12 00 00 03 9c 00 fe ff 00 00 af 2d 03 01 84 18 95 80 5c def RR ff RR ff 00 00 00 00 01 01 01 01 3c 3c 0a 0a RR ff 00 00 00 01 01 3c 43 RR ff ff RR RR NA NA NA NA NA NA NA RR RR NA NA NA NA NA NA NA NA NA NA NA NA NA RR RR RR RR NA NA NA NA NA RR RR 03 00 00 fe ff RR RR 5f NA 03 RR 44 18 15 80 5c At 2200 idx 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f val 01 78 01 ff 04 37 00 01 78 01 50 01 3c 3c 01 05 01 ff 20 00 00 01 01 3c 43 00 ff ff 24 32 00 e1 64 c8 26 ba d0 80 00 26 1f ff f0 00 de 5f 9d b4 04 0a 54 7c 5a 08 26 28 a4 15 3d 20 12 00 00 03 00 00 fe ff 00 00 af 2d 03 01 84 18 95 06 a3 def RR ff RR ff 00 00 00 00 01 01 01 01 3c 3c 0a 0a RR ff 00 00 00 01 01 3c 43 RR ff ff RR RR NA NA NA NA NA NA NA RR RR NA NA NA NA NA NA NA NA NA NA NA NA NA RR RR RR RR NA NA NA NA NA RR RR 03 00 00 fe ff RR RR 5f NA 03 RR 44 18 15 80 5c VID is 0x1D is 29 Voltage is VIDx12.5 + 825 = 1187.5 Vcore reading is 0x64 is 100: 100x4.8 + 690 = 1170 Seems pretty close!
However it is almost impossible to see any effect because the CPU supports C1/E state which is already as low power if not lower. In fact I believe that EIST will only operate in C0 anyway. It will probably reduce the total power consumption when the box is under a moderate load since it can only enter C1 when the CPU is idle for a time.
Unfortunately the minimum core voltage either for C1/E or the lowest EIST P-state is VID=1D (decimal 29) which is 1.19V. I'm not sure if that's just because my CPU is bad quality or that's a MB limitation. The full speed core voltage is 1.325V but the spec is down to 0.85V :-\ (or 0.962 depending where you look)
It doesn't seem to support SLFM (Dymnamic FSB) either, or at least I can't seem to trigger it, which would otherwise enable a lower core voltage.
You might think that reducing the CPU frequency would have a measurable effect on the power draw. :-
Disappointing in some ways since using EIST on the Core-E box reduced the power consumption and CPU temps quite a bit.I've been staring at register values in hex for so long now I'm starting to dream about it! ;)
If you want to know about EIST and such just read this:
http://www.projectosx.com/forum/index.php?showtopic=610
It has almost all the information I found on many other sites in one article. :)Steve
-
I'd love to get the lcdproc-dev and SDECLCD driver working on 64bit. Does that require a whole driver rewrite or a recompile? I'm not even sure if lcdproc-dev is amd64 capable…
amd64 is one of the supported architectures for lcdproc as a project, so I would not expect problems there. The sdec driver, though, has never been compiled, much less run, in that arch. If/when someone manages to run a 64bit OS on this box, I'll be happy to provide a binary for testing. Just need to download/install a 64bit FreeBSD virtual machine, and recompile.
-
I'd love to get the lcdproc-dev and SDECLCD driver working on 64bit. Does that require a whole driver rewrite or a recompile? I'm not even sure if lcdproc-dev is amd64 capable…
amd64 is one of the supported architectures for lcdproc as a project, so I would not expect problems there. The sdec driver, though, has never been compiled, much less run, in that arch. If/when someone manages to run a 64bit OS on this box, I'll be happy to provide a binary for testing. Just need to download/install a 64bit FreeBSD virtual machine, and recompile.
I have hardware from Watchguards OEM (Lanner calls it thier LCM) that uses the same screen and is 64bit. I'd be more than willing to try out any binaries you need tested. Only differences is that the screen on my units are 20x2 and not 16x2. I'm sure that really isn't an issue tho. Currently the 32bit SDECLCD works fine, except the screens don't seem to use the full 20x2, although the "Next|Prev" popups show in the extra characters so they work.
Let me know what you need done/tested. I assume what works for me will work perfectly on stephen's unit.
-
Let me know what you need done/tested.
If you have a 64bit version of FreeBSD running, make sure you have a 64bit version of the lcdproc package. The catch is that with a 32 bit compatibility layer, 32bit packages run fine on 64bit systems. You can find out with the file command on the LCDd executable: "file LCDd"
Once this is running, you can get the 64bit driver from here (rename it to sdeclcd.so):
https://github.com/downloads/fmertz/sdeclcd/sdeclcd64.so
This file is the sdeclcd driver code as accepted upstream, compiled under FreeBSD 8.3 AMD64. No LED, or XTM code in this just yet.
Keep us posted.
-
While re-reading this I realised I never posted the bios version in my box.
The original bios shows in the POST as:MB-7580 Ver.WC0 02/03/2010
When it boots it shows on the LCD:
WG BIOS V1.2
This version of the bios code does not set the arm/disarm LED to red during boot as it should. It requires some additional values to be added to the bootblock SIO table which I have not found a way to do (that doesn't corrupt the bios).
If you have a more recent version please let me know.
Steve
-
As requested here's the output of some commands. This is from 2.1Beta on my XTM5.
[2.1-BETA1][root@pfsense.localdomain]/root(2): sysctl hw hw.machine: i386 hw.model: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz hw.ncpu: 2 hw.byteorder: 1234 hw.physmem: 1016168448 hw.usermem: 911572992 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: i386 hw.realmem: 1037697024 hw.amr.force_sg32: 0 hw.an.an_cache_iponly: 1 hw.an.an_cache_mcastonly: 0 hw.an.an_cache_mode: dbm hw.an.an_dump: off hw.ata.setmax: 0 hw.ata.wc: 0 hw.ata.atapi_dma: 0 hw.ata.ata_dma_check_80pin: 1 hw.ata.ata_dma: 0 hw.ath.bstuck: 4 hw.ath.txbuf: 200 hw.ath.rxbuf: 40 hw.ath.anical: 100 hw.ath.resetcal: 1200 hw.ath.shortcal: 100 hw.ath.longcal: 30 hw.bce.rx_ticks: 18 hw.bce.rx_ticks_int: 18 hw.bce.rx_quick_cons_trip: 6 hw.bce.rx_quick_cons_trip_int: 6 hw.bce.tx_ticks: 80 hw.bce.tx_ticks_int: 80 hw.bce.tx_quick_cons_trip: 20 hw.bce.tx_quick_cons_trip_int: 20 hw.bce.loose_rx_mtu: 0 hw.bce.hdr_split: 1 hw.bce.tx_pages: 2 hw.bce.rx_pages: 2 hw.bce.msi_enable: 1 hw.bce.tso_enable: 1 hw.bce.verbose: 1 hw.bge.allow_asf: 0 hw.bt848.slow_msp_audio: -1 hw.bt848.format: -1 hw.bt848.reverse_mute: -1 hw.bt848.tuner: -1 hw.bt848.card: -1 hw.bwn.wme: 1 hw.bwn.usedma: 1 hw.bwn.hwpctl: 0 hw.bwn.bluetooth: 1 hw.bwn.bfp: 0 hw.cardbus.cis_debug: 0 hw.cardbus.debug: 0 hw.cxgb.nfilters: -1 hw.cxgb.use_16k_clusters: -1 hw.cxgb.force_fw_update: 0 hw.cxgb.multiq: 1 hw.cxgb.ofld_disable: 0 hw.cxgb.msi_allowed: 2 hw.cxgb.tx_reclaim_threshold: 32 hw.cxgb.tx_coalesce_enable_stop: 256 hw.cxgb.tx_coalesce_enable_start: 512 hw.cxgb.tx_coalesce_force: 0 hw.cxgb.txq_mr_size: 1024 hw.em.eee_setting: 0 hw.em.rx_process_limit: 100 hw.em.enable_msix: 1 hw.em.sbp: 0 hw.em.smart_pwr_down: 0 hw.em.txd: 1024 hw.em.rxd: 1024 hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.rx_int_delay: 0 hw.em.tx_int_delay: 66 hw.igb.rx_process_limit: 100 hw.igb.num_queues: 0 hw.igb.header_split: 0 hw.igb.max_interrupt_rate: 8000 hw.igb.enable_msix: 1 hw.igb.enable_aim: 1 hw.igb.txd: 1024 hw.igb.rxd: 1024 hw.firewire.hold_count: 0 hw.firewire.try_bmr: 1 hw.firewire.fwmem.speed: 2 hw.firewire.fwmem.eui64_lo: 0 hw.firewire.fwmem.eui64_hi: 0 hw.firewire.phydma_enable: 1 hw.firewire.nocyclemaster: 0 hw.firewire.fwe.rx_queue_len: 128 hw.firewire.fwe.tx_speed: 2 hw.firewire.fwe.stream_ch: 1 hw.firewire.sbp.tags: 0 hw.firewire.sbp.use_doorbell: 0 hw.firewire.sbp.scan_delay: 500 hw.firewire.sbp.login_delay: 1000 hw.firewire.sbp.exclusive_login: 1 hw.firewire.sbp.max_speed: -1 hw.firewire.sbp.auto_login: 1 hw.hifn.maxbatch: 1 hw.hifn.debug: 0 hw.malo.txbuf: 256 hw.malo.rxquota: 256 hw.malo.rxbuf: 256 hw.malo.txcoalesce: 8 hw.malo.pci.msi_disable: 0 hw.mfi.detect_jbod_change: 1 hw.mfi.max_cmds: 128 hw.mfi.event_class: 0 hw.mfi.event_locale: 65535 hw.mfi.msi: 1 hw.mwl.rxdmalow: 3 hw.mwl.rxquota: 640 hw.mwl.txcoalesce: 8 hw.mwl.txbuf: 256 hw.mwl.rxbuf: 640 hw.mwl.rxdesc: 256 hw.pccard.cis_debug: 0 hw.pccard.debug: 0 hw.cbb.debug: 0 hw.cbb.start_32_io: 4096 hw.cbb.start_16_io: 256 hw.cbb.start_memory: 2281701376 hw.pcic.pd6722_vsense: 1 hw.pcic.intr_mask: 57016 hw.pci.usb_early_takeover: 1 hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 hw.pci.do_power_resume: 1 hw.pci.do_power_nodriver: 0 hw.pci.enable_io_modes: 1 hw.pci.default_vgapci_unit: -1 hw.pci.host_mem_start: 2147483648 hw.pci.mcfg: 1 hw.pci.irq_override_mask: 57080 hw.safe.rngmaxalarm: 8 hw.safe.rngbufsize: 16 hw.safe.rnginterval: 1 hw.usb.no_shutdown_wait: 0 hw.usb.no_boot_wait: 0 hw.usb.debug: 0 hw.usb.usb_lang_mask: 255 hw.usb.usb_lang_id: 9 hw.usb.template: 0 hw.usb.power_timeout: 30 hw.usb.no_pf: 1 hw.usb.no_cs_fail: 0 hw.usb.uath.regdomain: 0 hw.usb.uath.countrycode: 0 hw.usb.urtw.preamble_mode: 2 hw.usb.ucom.cons_baud: 9600 hw.usb.ucom.cons_subunit: 0 hw.usb.ucom.cons_unit: -1 hw.wi.debug: 0 hw.wi.txerate: 0 hw.intr_storm_threshold: 1000 hw.pagesizes: 4096 0 hw.availpages: 248088 hw.bus.devctl_queue: 1000 hw.bus.devctl_disable: 0 hw.nve_pollinterval: 0 hw.busdma.total_bpages: 513 hw.busdma.zone0.total_bpages: 513 hw.busdma.zone0.free_bpages: 513 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 63 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 4096 hw.clockrate: 2194 hw.via_feature_xcrypt: 0 hw.via_feature_rng: 0 hw.instruction_sse: 1 hw.apic.enable_extint: 0 hw.mca.erratum383: 0 hw.mca.amd10h_L1TP: 1 hw.mca.enabled: 1 hw.mca.count: 0 hw.mca.interval: 3600 hw.mca.force_scan: 0 hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1
[2.1-BETA1][root@pfsense.localdomain]/root(11): flashrom -V flashrom v0.9.5.2-r1515 on FreeBSD 8.3-RELEASE-p6 (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... OS timer resolution is 4 usecs, 2194M loops per second, 10 myus = 14 us, 100 myus = 104 us, 1000 myus = 1006 us, 10000 myus = 10008 us, 16 myus = 20 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "To Be Filled By O.E.M." DMI string system-product-name: "To Be Filled By O.E.M." DMI string system-version: "To Be Filled By O.E.M." DMI string baseboard-manufacturer: "To be filled by O.E.M." DMI string baseboard-product-name: "To be filled by O.E.M." DMI string baseboard-version: "To be filled by O.E.M." DMI string chassis-type: "Desktop" Found chipset "Intel ICH7/ICH7R" with PCI ID 8086:27b8\. Enabling flash write... 0xfff80000/0xffb80000 FWH IDSEL: 0x0 0xfff00000/0xffb00000 FWH IDSEL: 0x0 0xffe80000/0xffa80000 FWH IDSEL: 0x1 0xffe00000/0xffa00000 FWH IDSEL: 0x1 0xffd80000/0xff980000 FWH IDSEL: 0x2 0xffd00000/0xff900000 FWH IDSEL: 0x2 0xffc80000/0xff880000 FWH IDSEL: 0x3 0xffc00000/0xff800000 FWH IDSEL: 0x3 0xff700000/0xff300000 FWH IDSEL: 0x4 0xff600000/0xff200000 FWH IDSEL: 0x5 0xff500000/0xff100000 FWH IDSEL: 0x6 0xff400000/0xff000000 FWH IDSEL: 0x7 0xfff80000/0xffb80000 FWH decode enabled 0xfff00000/0xffb00000 FWH decode enabled 0xffe80000/0xffa80000 FWH decode disabled 0xffe00000/0xffa00000 FWH decode disabled 0xffd80000/0xff980000 FWH decode disabled 0xffd00000/0xff900000 FWH decode disabled 0xffc80000/0xff880000 FWH decode disabled 0xffc00000/0xff800000 FWH decode disabled 0xff700000/0xff300000 FWH decode disabled 0xff600000/0xff200000 FWH decode disabled 0xff500000/0xff100000 FWH decode disabled 0xff400000/0xff000000 FWH decode disabled Maximum FWH chip size: 0x100000 bytes BIOS Lock Enable: disabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x0 Root Complex Register Block address = 0xfed1c000 GCS = 0x460: BIOS Interface Lock-Down: disabled, Boot BIOS Straps: 0x1 (SPI) Top Swap : not enabled SPIBAR = 0xfed1c000 + 0x3020 0x00: 0x0004 (SPIS) 0x02: 0x4140 (SPIC) 0x04: 0x00000000 (SPIA) 0x08: 0x1014ffff (SPID0) 0x0c: 0xffffffff (SPID0+4) 0x10: 0xffffffff (SPID1) 0x14: 0xffffffff (SPID1+4) 0x18: 0x00000000 (SPID2) 0x1c: 0x00000000 (SPID2+4) 0x20: 0x00000000 (SPID3) 0x24: 0x00000000 (SPID3+4) 0x28: 0x00000000 (SPID4) 0x2c: 0x00000000 (SPID4+4) 0x30: 0x00000000 (SPID5) 0x34: 0x00000000 (SPID5+4) 0x38: 0x00000000 (SPID6) 0x3c: 0x00000000 (SPID6+4) 0x40: 0x00000000 (SPID7) 0x44: 0x00000000 (SPID7+4) 0x50: 0x00000000 (BBAR) 0x54: 0x0006 (PREOP) 0x56: 0x543b (OPTYPE) 0x58: 0x05d80302 (OPMENU) 0x5c: 0x0006019f (OPMENU+4) 0x60: 0x00000000 (PBR0) 0x64: 0x00000000 (PBR1) 0x68: 0x00000000 (PBR2) Programming OPCODES... program_opcodes: preop=5006 optype=463b opmenu=05d80302c79f0190 done SPI Read Configuration: prefetching disabled, caching enabled, OK. The following protocols are supported: SPI. Probing for AMIC A25L05PT, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L05PU, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L10PT, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L10PU, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L20PT, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L20PU, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L40PT, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L40PU, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L80P, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L16PT, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L16PU, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L512, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L010, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L020, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L040, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L080, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L016, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25L032, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for AMIC A25LQ032, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT25DF021, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT25DF041A, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT25DF081, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT25DF081A, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT25DF161, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT25DF321, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT25DF321A, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT25DF641(A), 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT25DQ161, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT25F512B, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT25FS010, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT25FS040, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT26DF041, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT26DF081A, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT26DF161, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT26DF161A, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT26F004, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT45CS1282, 16896 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT45DB011D, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT45DB021D, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT45DB041D, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT45DB081D, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT45DB161D, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT45DB321C, 4224 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT45DB321D, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel AT45DB642D, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for EMST F25L008A, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B05, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B05T, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B10, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B10T, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B20, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B20T, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B40, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B40T, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B80, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B80T, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B16T, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B32T, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B64, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25B64T, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25F05, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25F10, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25F20, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25F40, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25F80, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25F16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25F32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25Q40, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25Q80(A), 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25Q16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25Q32(A/B), 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25Q64, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25Q128, 16384 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon EN25QH16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Macronix MX25L512, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Macronix MX25L1005, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Macronix MX25L2005, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Macronix MX25L4005, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Macronix MX25L8005, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Macronix MX25L1605, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Macronix MX25L1635D, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Macronix MX25L1635E, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Macronix MX25L3205, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Macronix MX25L3235D, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Macronix MX25L6405, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Macronix MX25L12805, 16384 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Numonyx M25PE10, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Numonyx M25PE20, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Numonyx M25PE40, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Numonyx M25PE80, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Numonyx M25PE16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for PMC Pm25LV010, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for PMC Pm25LV016B, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for PMC Pm25LV020, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for PMC Pm25LV040, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for PMC Pm25LV080B, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for PMC Pm25LV512, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Sanyo LF25FW203A, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Spansion S25FL004A, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Spansion S25FL008A, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Spansion S25FL016A, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Spansion S25FL032A, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Spansion S25FL064A, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for SST SST25LF040A, 512 kB: program_opcodes: preop=5006 optype=462b opmenu=05ab0302c79f0190 on-the-fly OPCODE (0xAB) re-programmed, op-pos=2 probe_spi_res2: id1 0x13, id2 0x13 Probing for SST SST25LF080A, 1024 kB: probe_spi_res2: id1 0x13, id2 0x13 Probing for SST SST25VF010, 128 kB: probe_spi_rems: id1 0xff, id2 0xff Probing for SST SST25VF016B, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for SST SST25VF032B, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for SST SST25VF064C, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for SST SST25VF040, 512 kB: probe_spi_rems: id1 0xff, id2 0xff Probing for SST SST25VF040B, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for SST SST25VF040B.REMS, 512 kB: probe_spi_rems: id1 0xff, id2 0xff Probing for SST SST25VF080B, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for ST M25P05-A, 64 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for ST M25P05, 64 kB: Ignoring RES in favour of RDID. Probing for ST M25P10-A, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for ST M25P10, 128 kB: Ignoring RES in favour of RDID. Probing for ST M25P20, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for ST M25P40, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for ST M25P40-old, 512 kB: Ignoring RES in favour of RDID. Probing for ST M25P80, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Chip status register is 00 Chip status register: Status Register Write Disable (SRWD) is not set Chip status register: Bit 6 is not set Chip status register: Bit 5 / Block Protect 3 (BP3) is not set Chip status register: Bit 4 / Block Protect 2 (BP2) is not set Chip status register: Bit 3 / Block Protect 1 (BP1) is not set Chip status register: Bit 2 / Block Protect 0 (BP0) is not set Chip status register: Write Enable Latch (WEL) is not set Chip status register: Write In Progress (WIP/BUSY) is not set Found ST flash chip "M25P80" (1024 kB, SPI) at physical address 0xfff00000. Probing for ST M25P16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for ST M25P32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for ST M25P64, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for ST M25P128, 16384 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for ST M25PX16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for ST M25PX32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for ST M25PX64, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Winbond W25Q80, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Winbond W25Q16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Winbond W25Q32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Winbond W25Q64, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Winbond W25Q128, 16384 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Winbond W25X10, 128 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Winbond W25X20, 256 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Winbond W25X40, 512 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Winbond W25X80, 1024 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Winbond W25X16, 2048 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Winbond W25X32, 4096 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Winbond W25X64, 8192 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Unknown SFDP-capable chip, 0 kB: program_opcodes: preop=5006 optype=462b opmenu=055a0302c79f0190 on-the-fly OPCODE (0x5A) re-programmed, op-pos=2 No SFDP signature found. Probing for AMIC unknown AMIC SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Atmel unknown Atmel SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Eon unknown Eon SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Macronix unknown Macronix SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for PMC unknown PMC SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for SST unknown SST SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for ST unknown ST SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Sanyo unknown Sanyo SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Generic unknown SPI chip (RDID), 0 kB: probe_spi_rdid_generic: id1 0x20, id2 0x2014 Probing for Generic unknown SPI chip (REMS), 0 kB: probe_spi_rems: id1 0xff, id2 0xff Found ST flash chip "M25P80" (1024 kB, SPI). No operations were specified. Restoring MMIO space at 0x2822f070 Restoring MMIO space at 0x2822f07c Restoring MMIO space at 0x2822f078 Restoring MMIO space at 0x2822f076 Restoring MMIO space at 0x2822f074 Restoring PCI config space for 00:1f:0 reg 0xdc
Steve
-
Hello all,
I'm a relative n00b to the forum but have been playing with PFSense for a little over a year. I was running a Firebox X700 with PFSense running perfectly mostly thanks to all the hard work of all you fine folks, StephenW in particular. I outgrew the X700 and decided it was time to step up my PFSense hardware. So after some good forum reading I decided an economical upgrade was the XTM 5 series and purchased an XTM 505 on eBay.
Install was pretty basic. I actually flashed 2 CF cards one with 2.0.3 i386 and one with 2.0.3 x64 so I can be a guinea pig with testing 64 bit drivers and code. Slid the card in the CF slot and it booted up relatively quickly. As StephenW mentions the default Firebox serial settings are 115200 8 n 1 which you'll need set if you want to get to the BIOS (although there isn't much point as it's mostly read only). After that PFSense defaults back to 9600 8 n 1 so you'll have to change your serial settings back to finish configuring PFSense. I had a strange issue with type not transferring properly where each time I typed at about every 5th-6th key I would press was incorrect. It wasn't so bad that I couldn't delete the incorrect characters and get the WAN and LAN ports configured and IP'd. Probably a fault DB9-RJ45 cable but it was a new leftover cable from a Cisco install. Only mention this to see if it's common with anyone else.
For now I'm running 32 bit as I am using it as my primary router/firewall at home. So after hooking it up and logging in I was able to get the LCD working by installing LCDProc Dev and using the following settings:
Com Port: Parallel Port 1 (/dev/lpt0)
Display Size: 2 rows 20 columns
Driver: Watchguard Firebox with SDEC (x86 only)
Refresh Frequency: 5 seconds
Rest is defaultAs mentioned earlier the keys work but the mapping is off. Any ideas on how to remedy this? Would it be a simple modification to /usr/local/etc/LCDD.conf ?
Once I get the keymapping working and StephenW complete the WGXepc update for the XTM 5 series this thing will be perfectly adapted to PFSense; aside from the incompatible Cavium Nitrox CN1605.
-
FMertz,
Looking at dmidecode, it appears StephenW's and my UUID: 00020003-0004-0005-0006-000700080009 match. Could this be used as a unique identifier?
Anyone else with an XTM 5 series care to comment/check on this?
-
Like I say I think fmertz already implemented all of this. See:
http://forum.pfsense.org/index.php/topic,44034.msg276249.html#msg276249Try that and see what happens.
Steve
Edit: Yep all looks to be there.
-
I finally got around to updating WGXepc to include the code for the XTM5. It turned out to be rather more difficult than I'd imagined.
Anyway get it here or here(Oops the topic was locked!).Whilst investigating the SuperIO chip I found it was controlling the fans so I added code for that too. By default the fans are connected to the system_fan output which is set to run in 'Thermal Cruise' mode. The target temperature register is set to 0x37, I've yet to work out what that translates to but it must be quite high since the fans always run slow. They ramp down to a minimum speed but that is conveniently controllable. I have included code to set that in WGXepc. :) Obviously be careful messing about with the cooling but it shouldn't be possible to cause any problems as the fans will just ramp up if it gets hot. Unfortunately there is a quirk with setting the minimum value to a speed that is greater than the current fan speed. The only way I could get this to take effect was to switch to manual mode and then back to Thermal Cruise which causes the fans to goto max and then ramp back down. Not the end of the world but slightly annoying (to me at least!). It may also be possible to set the target temperature. Th diagnostic LEDs are probably also connected via the SuperIO but I haven't thought of a good use for them yet. ;)
Steve
-
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
-
Bravo as always Stephen. I will definitely take a look at this when I get ready to swap out the processor as speedstep is a much needed feature. Till then I'll stick with your new release of WGXepc.
Any subtle differences in the hardware between the XTM5 and XTM8? My understanding is that the hardware was the same and the different versions referenced unlocked features by license for the Watchguard software. Curious.
Thanks!
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
-
The XTM5 and XTM8 are very different. Different box, different mother board.
To get Speedstep sort-of working I had to use a modified DSDT file. However even when I had it seemingly functioning I could see any effects on either power consumption or heat. I put it down to the board/CPU supporting higher C states which reduce power anyway.
Steve
-
Just ordered an XTM 505 off ebay and I'm excited to try out pfSense on it. Has anyone successfully booted from or attached a USB drive or HDD yet? Also, has anyone tried stephenw10's firmware update?
Thanks!
-
Hmm, interesting, it looks like I never tried it after unlocking the BIOS. It's definitely not possible to boot from USB without altering some bios settings and to do that you need to flash the unlocked version. That obviously carries some risk but I'm quite confident that image I linked to is not corrupt. I uploaded it, downloaded it again and re-flashed it to my box without issue. Just make sure the MD5 sum is correct.
Steve
-
From my experience with the XTM8 (810), you can't boot anything from the usb ports - I tried!
I imagine the XTM505 will be the same - bios locked down and restricted as to what can be used - ie mouse and keyboard is pretty much as far as the bios will get you - until you unlock it.
My XTM8 is currently out of action - deffo be careful flashing the bios ;)
Eamon
-
StephenW10,
A little late of a response but yea duh about the hardware differences… I was thinking XTM5 series: 515, 505 etc which are all the same hardware. I can't keep up with all the Watchguard models you are working on. :P
Also, after trying LCDProc-Dev (latest package) it seems the key mapping was not integrated into the latest dev package as my key mapping are still off. I'll post in the appropriate thread about this as well but wanted to reference it here, this being the official thread for XTM5 devices. Also, Stephen, could you enlighten me on the shellcmd you use to start/restart the LCDProc service? Thanks.
LCDProc-Dev Thread:http://forum.pfsense.org/index.php/topic,44034.msg349010.html#msg349010
iolaus,
With all due respect to StephenW10 and thanks for his hard work, there isn't much to gain from unlocking the bios.I would echo Eams warning in that you do not want to flash your bios unless you know 100% that you will benefit from the features. If you want to tinker, I would suggest only doing so if you are not really relying on the hardware and can afford to brick it. You will need to have a level of comfort/experience with modifying hardware/bios as you may need to create a serial jumper soldered to the board to unbrick it or reflash the serial flash device (at least this was my understanding from reading through StephenW10s posts. Please correct me if I'm wrong).
-
I will be using my XTM505 in my local network so I'll definitely have to be careful not to brick it. I had hoped to try out Snort but I'm wondering if I have to worry about the finite write capabilities of the CF card. If so, is it possible to install additional storage (SSD or larger USB Flash), perhaps as secondary storage, without unlocking the BIOS?
-
I had the same issue and question but the answer for me was much simpler/easier than having to install secondary storage. Instead I used the SHELLCMD package to mount an NFS Share at post boot and then setup logs to write to the share. A much more elegant solution, especially if you hope to use any other software (Splunk etc) to parse your log files.
Hope that helps.