Watchguard XTM 5 Series

stephenw10

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 connection

It 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

2.0.1-dmesg.boot.txt

fmertz

@stephenw10:

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.

stephenw10

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

stephenw10

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.

fmertz

@stephenw10:


[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 D945GTP

I'll read the ICH7 spec to find out more. Next, we'll have to figure out the exact GPIO pin for Armed/Disarmed.

stephenw10

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

stephenw10

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

fmertz

@stephenw10:

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…

stephenw10

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

stephenw10

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

stephenw10

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

fmertz

@stephenw10:

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…

stephenw10

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

Brak

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.

stephenw10

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

Brak

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.

stephenw10

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

fmertz

@stephenw10:

I have been playing around with a Core2Duo E4500.

Wikipedia mentions that series has 64bit support.

http://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors#.22Allendale.22.2C_.22Conroe.22_.2865_nm.29

We need to put a 64 bit lcdproc/sdeclcd package on the radar…

stephenw10

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

Brak

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…