[As Good As Solved!] Watchguard Firebox Arm/Disarm LED
-
Ok, well that implies we are looking in completely the wrong place!
You should be able to see the chip number in dmesg.[2.0-BETA5][root@pfSense.localdomain]/root(6): dmesg|grep ICH uhci0: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-a="">port 0xeb00-0xeb1f irq 23 at device 29.0 on pci0 usbus0: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-a="">on uhci0 uhci1: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-b="">port 0xed00-0xed1f irq 19 at device 29.1 on pci0 usbus1: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-b="">on uhci1 uhci2: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-c="">port 0xe800-0xe81f irq 18 at device 29.2 on pci0 usbus2: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-c="">on uhci2 uhci3: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-d="">port 0xe900-0xe91f irq 16 at device 29.3 on pci0 usbus3: <intel 82801fb="" fr="" fw="" frw="" (ich6)="" usb="" controller="" usb-d="">on uhci3 ehci0: <intel 82801fb="" (ich6)="" usb="" 2.0="" controller="">mem 0xd05c0000-0xd05c03ff irq 23 at device 29.7 on pci0 usbus4: <intel 82801fb="" (ich6)="" usb="" 2.0="" controller="">on ehci0 atapci0: <intel ich6="" udma100="" controller="">port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.1 on pci0</intel></intel></intel></intel></intel></intel></intel></intel></intel></intel></intel>
If isn't an ich device you might try grepping for Intel or something!
Steve
-
Allright, I ran dmesg on firebox1 (previously x500) and got the following:
[2.0-BETA5][admin@firebox1.domain]/root(1): dmesg|grep ICHatapci0: <intel ich2="" udma100="" controller="">port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.1 on pci0 atapci0: <intel ich2="" udma100="" controller="">port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.1 on pci0</intel></intel>
Then I grepped for Intel, which got me the following:
[2.0-BETA5][admin@firebox1.domain]/root(2): dmesg | grep Intel CPU: Intel(R) Celeron(TM) CPU 1200MHz (1202.73-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b4 Family = 6 Model = b Stepping = 4 pcib0: <intel 82815="" (i815="" gmch)="" host="" to="" hub="" bridge="">pcibus 0 on motherboard atapci0: <intel ich2="" udma100="" controller="">port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.1 on pci0 CPU: Intel(R) Celeron(TM) CPU 1200MHz (1202.73-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b4 Family = 6 Model = b Stepping = 4 pcib0: <intel 82815="" (i815="" gmch)="" host="" to="" hub="" bridge="">pcibus 0 on motherboard atapci0: <intel ich2="" udma100="" controller="">port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.1 on pci0</intel></intel></intel></intel>
And I still don't see what we were looking for so I ran dmesg without grep, which resulted in a rather odd output as you can see here:
[2.0-BETA5][admin@firebox1.virtualflo.com]/root(3): dmesg re2: link state changed to DOWN re3: link state changed to DOWN re4: link state changed to DOWN re5: link state changed to DOWN pid 6206 (nice), uid 0: exited on signal 11 (core dumped) pid 6446 (pfctl), uid 0: exited on signal 11 (core dumped) pflog0: promiscuous mode disabled Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. Uptime: 13h38m4s Rebooting... Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-RELEASE-p2 #1: Tue Feb 8 17:40:15 EST 2011 sullrich@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_wrap.8.i386 i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(TM) CPU 1200MHz (1202.73-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b4 Family = 6 Model = b Stepping = 4 Features=0x383f9ff <fpu,vme,de,pse,tsc,msr,pae,mce,cx8,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse>real memory = 268435456 (256 MB) avail memory = 243433472 (232 MB) wlan: mac acl policy registered ipw_bss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/. ipw_bss: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf. module_register_init: MOD_LOAD (ipw_bss_fw, 0xc0700bd0, 0) error 1 ipw_ibss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/. ipw_ibss: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf. module_register_init: MOD_LOAD (ipw_ibss_fw, 0xc0700c70, 0) error 1 wpi: You need to read the LICENSE file in /usr/share/doc/legal/intel_wpi/. wpi: If you agree with the license, set legal.intel_wpi.license_ack=1 in /boot/loader.conf. module_register_init: MOD_LOAD (wpi_fw, 0xc0873920, 0) error 1 ipw_monitor: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/. ipw_monitor: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf. module_register_init: MOD_LOAD (ipw_monitor_fw, 0xc0700d10, 0) error 1 ACPI Error: A valid RSDP was not found (20100331/tbxfroot-309) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. cryptosoft0: <software crypto=""> on motherboard padlock0: No ACE support. pcib0: <intel 82815="" (i815="" gmch)="" host="" to="" hub="" bridge=""> pcibus 0 on motherboard pir0: <pci 11="" interrupt="" routing="" table:="" entries=""> on motherboard $PIR: Using invalid BIOS IRQ 9 from 2.13.INTA for link 0x63 pci0: <pci bus=""> on pcib0 pcib1: <pcibios pci-pci="" bridge=""> at device 30.0 on pci0 pci2: <pci bus=""> on pcib1 safe0 mem 0xefbfe000-0xefbfffff irq 3 at device 6.0 on pci2 safe0: [ITHREAD] safe0: SafeNet SafeXcel-1141 rng des/3des aes md5 sha1 null re0: <realtek 10="" 8139c+="" 100basetx=""> port 0xd500-0xd5ff mem 0xefefa000-0xefefa1ff irq 10 at device 9.0 on pci2 re0: Chip rev. 0x74800000 re0: MAC rev. 0x00000000 miibus0: <mii bus=""> on re0 rlphy0: <realtek internal="" media="" interface=""> PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: [FILTER] re1: <realtek 10="" 8139c+="" 100basetx=""> port 0xd600-0xd6ff mem 0xefefb000-0xefefb1ff irq 5 at device 10.0 on pci2 re1: Chip rev. 0x74800000 re1: MAC rev. 0x00000000 miibus1: <mii bus=""> on re1 rlphy1: <realtek internal="" media="" interface=""> PHY 0 on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re1: [FILTER] re2: <realtek 10="" 8139c+="" 100basetx=""> port 0xd900-0xd9ff mem 0xefefc000-0xefefc1ff irq 11 at device 11.0 on pci2 re2: Chip rev. 0x74800000 re2: MAC rev. 0x00000000 miibus2: <mii bus=""> on re2 rlphy2: <realtek internal="" media="" interface=""> PHY 0 on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re2: [FILTER] re3: <realtek 10="" 8139c+="" 100basetx=""> port 0xda00-0xdaff mem 0xefefd000-0xefefd1ff irq 12 at device 12.0 on pci2 re3: Chip rev. 0x74800000 re3: MAC rev. 0x00000000 miibus3: <mii bus=""> on re3 rlphy3: <realtek internal="" media="" interface=""> PHY 0 on miibus3 rlphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re3: [FILTER] re4: <realtek 10="" 8139c+="" 100basetx=""> port 0xdd00-0xddff mem 0xefefe000-0xefefe1ff irq 9 at device 13.0 on pci2 re4: Chip rev. 0x74800000 re4: MAC rev. 0x00000000 miibus4: <mii bus=""> on re4 rlphy4: <realtek internal="" media="" interface=""> PHY 0 on miibus4 rlphy4: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re4: [FILTER] re5: <realtek 10="" 8139c+="" 100basetx=""> port 0xde00-0xdeff mem 0xefeff000-0xefeff1ff irq 6 at device 14.0 on pci2 re5: Chip rev. 0x74800000 re5: MAC rev. 0x00000000 miibus5: <mii bus=""> on re5 rlphy5: <realtek internal="" media="" interface=""> PHY 0 on miibus5 rlphy5: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re5: [FILTER] isab0: <pci-isa bridge=""> at device 31.0 on pci0 isa0: <isa bus=""> on isab0 atapci0: <intel ich2="" udma100="" controller=""> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.1 on pci0 ata0: <ata 0="" channel=""> on atapci0 ata0: [ITHREAD] ata1: <ata 1="" channel=""> on atapci0 ata1: [ITHREAD] cpu0 on motherboard unknown: <pnp0c01> can't assign resources (memory) atrtc0: <at realtime="" clock=""> at port 0x70-0x71 irq 8 pnpid PNP0b00 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 pnpid PNP0501 on isa0 uart0: [FILTER] uart0: console (9600,n,8,1) ppc0: <ecp parallel="" printer="" port=""> at port 0x378-0x37f,0x778-0x77a irq 7 drq 3 pnpid PNP0401 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppc0: [ITHREAD] ppbus0: <parallel port="" bus=""> on ppc0 ppi0: <parallel i="" o=""> on ppbus0 orm0: <isa option="" rom=""> at iomem 0xe0000-0xe0fff pnpid ORM0000 on isa0 unknown: <pnp0c01> can't assign resources (memory) RTC BIOS diagnostic error 20 <config_unit>Timecounter "TSC" frequency 1202731522 Hz quality 800 Timecounters tick every 10.000 msec IPsec: Initialized Security Association Processing. ata1: DMA limited to UDMA33, controller found non-ATA66 cable ad2: 5729MB <toshiba mk6014map="" n2.10="" a=""> at ata1-master UDMA33 GEOM: ad2s1: geometry does not match label (255h,63s != 15h,63s). Trying to mount root from ufs:/dev/ad2s1a pflog0: promiscuous mode enabled ovpns1: link state changed to UP re1: link state changed to UP pid 7510 (rrdtool), uid 0: exited on signal 11 (core dumped) re2: link state changed to DOWN re3: link state changed to DOWN re4: link state changed to DOWN re5: link state changed to DOWN pflog0: promiscuous mode disabled Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. Uptime: 1d3h28m51s Rebooting... Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-RELEASE-p2 #1: Wed Feb 9 15:55:23 EST 2011 sullrich@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_wrap.8.i386 i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(TM) CPU 1200MHz (1202.73-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b4 Family = 6 Model = b Stepping = 4 Features=0x383f9ff <fpu,vme,de,pse,tsc,msr,pae,mce,cx8,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse>real memory = 268435456 (256 MB) avail memory = 243433472 (232 MB) wlan: mac acl policy registered ipw_bss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/. ipw_bss: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf. module_register_init: MOD_LOAD (ipw_bss_fw, 0xc0700be0, 0) error 1 ipw_ibss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/. ipw_ibss: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf. module_register_init: MOD_LOAD (ipw_ibss_fw, 0xc0700c80, 0) error 1 wpi: You need to read the LICENSE file in /usr/share/doc/legal/intel_wpi/. wpi: If you agree with the license, set legal.intel_wpi.license_ack=1 in /boot/loader.conf. module_register_init: MOD_LOAD (wpi_fw, 0xc0873930, 0) error 1 ipw_monitor: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/. ipw_monitor: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf. module_register_init: MOD_LOAD (ipw_monitor_fw, 0xc0700d20, 0) error 1 ACPI Error: A valid RSDP was not found (20100331/tbxfroot-309) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. cryptosoft0: <software crypto=""> on motherboard padlock0: No ACE support. pcib0: <intel 82815="" (i815="" gmch)="" host="" to="" hub="" bridge=""> pcibus 0 on motherboard pir0: <pci 11="" interrupt="" routing="" table:="" entries=""> on motherboard $PIR: Using invalid BIOS IRQ 9 from 2.13.INTA for link 0x63 pci0: <pci bus=""> on pcib0 pcib1: <pcibios pci-pci="" bridge=""> at device 30.0 on pci0 pci2: <pci bus=""> on pcib1 safe0 mem 0xefbfe000-0xefbfffff irq 3 at device 6.0 on pci2 safe0: [ITHREAD] safe0: SafeNet SafeXcel-1141 rng des/3des aes md5 sha1 null re0: <realtek 10="" 8139c+="" 100basetx=""> port 0xd500-0xd5ff mem 0xefefa000-0xefefa1ff irq 10 at device 9.0 on pci2 re0: Chip rev. 0x74800000 re0: MAC rev. 0x00000000 miibus0: <mii bus=""> on re0 rlphy0: <realtek internal="" media="" interface=""> PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: [FILTER] re1: <realtek 10="" 8139c+="" 100basetx=""> port 0xd600-0xd6ff mem 0xefefb000-0xefefb1ff irq 5 at device 10.0 on pci2 re1: Chip rev. 0x74800000 re1: MAC rev. 0x00000000 miibus1: <mii bus=""> on re1 rlphy1: <realtek internal="" media="" interface=""> PHY 0 on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re1: [FILTER] re2: <realtek 10="" 8139c+="" 100basetx=""> port 0xd900-0xd9ff mem 0xefefc000-0xefefc1ff irq 11 at device 11.0 on pci2 re2: Chip rev. 0x74800000 re2: MAC rev. 0x00000000 miibus2: <mii bus=""> on re2 rlphy2: <realtek internal="" media="" interface=""> PHY 0 on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re2: [FILTER] re3: <realtek 10="" 8139c+="" 100basetx=""> port 0xda00-0xdaff mem 0xefefd000-0xefefd1ff irq 12 at device 12.0 on pci2 re3: Chip rev. 0x74800000 re3: MAC rev. 0x00000000 miibus3: <mii bus=""> on re3 rlphy3: <realtek internal="" media="" interface=""> PHY 0 on miibus3 rlphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re3: [FILTER] re4: <realtek 10="" 8139c+="" 100basetx=""> port 0xdd00-0xddff mem 0xefefe000-0xefefe1ff irq 9 at device 13.0 on pci2 re4: Chip rev. 0x74800000 re4: MAC rev. 0x00000000 miibus4: <mii bus=""> on re4 rlphy4: <realtek internal="" media="" interface=""> PHY 0 on miibus4 rlphy4: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re4: [FILTER] re5: <realtek 10="" 8139c+="" 100basetx=""> port 0xde00-0xdeff mem 0xefeff000-0xefeff1ff irq 6 at device 14.0 on pci2 re5: Chip rev. 0x74800000 re5: MAC rev. 0x00000000 miibus5: <mii bus=""> on re5 rlphy5: <realtek internal="" media="" interface=""> PHY 0 on miibus5 rlphy5: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re5: [FILTER] isab0: <pci-isa bridge=""> at device 31.0 on pci0 isa0: <isa bus=""> on isab0 atapci0: <intel ich2="" udma100="" controller=""> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.1 on pci0 ata0: <ata 0="" channel=""> on atapci0 ata0: [ITHREAD] ata1: <ata 1="" channel=""> on atapci0 ata1: [ITHREAD] cpu0 on motherboard unknown: <pnp0c01> can't assign resources (memory) atrtc0: <at realtime="" clock=""> at port 0x70-0x71 irq 8 pnpid PNP0b00 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 pnpid PNP0501 on isa0 uart0: [FILTER] uart0: console (9600,n,8,1) ppc0: <ecp parallel="" printer="" port=""> at port 0x378-0x37f,0x778-0x77a irq 7 drq 3 pnpid PNP0401 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppc0: [ITHREAD] ppbus0: <parallel port="" bus=""> on ppc0 ppi0: <parallel i="" o=""> on ppbus0 orm0: <isa option="" rom=""> at iomem 0xe0000-0xe0fff pnpid ORM0000 on isa0 unknown: <pnp0c01> can't assign resources (memory) RTC BIOS diagnostic error 20 <config_unit>Timecounter "TSC" frequency 1202731472 Hz quality 800 Timecounters tick every 10.000 msec IPsec: Initialized Security Association Processing. ata1: DMA limited to UDMA33, controller found non-ATA66 cable ad2: 5729MB <toshiba mk6014map="" n2.10="" a=""> at ata1-master UDMA33 GEOM: ad2s1: geometry does not match label (255h,63s != 15h,63s). Trying to mount root from ufs:/dev/ad2s1a pflog0: promiscuous mode enabled ovpns1: link state changed to UP re1: link state changed to UP re2: link state changed to DOWN re3: link state changed to DOWN re4: link state changed to DOWN re5: link state changed to DOWN</toshiba></config_unit></pnp0c01></isa></parallel></parallel></ecp></at></pnp0c01></ata></ata></intel></isa></pci-isa></realtek></mii></realtek></realtek></mii></realtek></realtek></mii></realtek></realtek></mii></realtek></realtek></mii></realtek></realtek></mii></realtek></pci></pcibios></pci></pci></intel></software></fpu,vme,de,pse,tsc,msr,pae,mce,cx8,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse></toshiba></config_unit></pnp0c01></isa></parallel></parallel></ecp></at></pnp0c01></ata></ata></intel></isa></pci-isa></realtek></mii></realtek></realtek></mii></realtek></realtek></mii></realtek></realtek></mii></realtek></realtek></mii></realtek></realtek></mii></realtek></pci></pcibios></pci></pci></intel></software></fpu,vme,de,pse,tsc,msr,pae,mce,cx8,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse>
I don't quite understand why dmesg would be filled with parts of the boot log and why it would even state uptime.
The output of dmesg on my macs looks a lot different, though they are of course running darwin.This probably doesn't help at all, does it?
-
Agreed, strange output.
I certainly does help. It looks like you've got ICH2 so that's a different datasheet for starters.
If you do a:pciconf -lb
You should see the PCI device and vendor IDs to confirm the chip.
Look for chip=0x24408086 or chip=0x244C8086. That's the LPC-PCI brigbe used to configure the GPIOs.
That command should give you the base pci address and from that you can read the gpio base address and then test the gpios. However on my box it doesn't! :(Steve
-
Luckily, pciconf -lb does work here.
0x244C8086 shows up as:
isab0@pci0:0:31:0: class=0x060100 card=0x00000000 chip=0x24408086 rev=0x05 hdr=0x00 atapci0@pci0:0:31:1: class=0x010180 card=0x24408086 chip=0x244b8086 rev=0x05 hdr=0x00 bar [20] = type I/O Port, range 32, base 0xff00, size 16, enabled
0x244C8086 isn't in the output.
The full output is as follows:
hostb0@pci0:0:0:0: class=0x060000 card=0x11308086 chip=0x11308086 rev=0x04 hdr=0x00 pcib1@pci0:0:30:0: class=0x060400 card=0x00000000 chip=0x244e8086 rev=0x05 hdr=0x01 isab0@pci0:0:31:0: class=0x060100 card=0x00000000 chip=0x24408086 rev=0x05 hdr=0x00 atapci0@pci0:0:31:1: class=0x010180 card=0x24408086 chip=0x244b8086 rev=0x05 hdr=0x00 bar [20] = type I/O Port, range 32, base 0xff00, size 16, enabled safe0@pci0:2:6:0: class=0xff0000 card=0x00010001 chip=0x114116ae rev=0x01 hdr=0x00 bar [10] = type Prefetchable Memory, range 32, base 0xefbfe000, size 8192, enabled re0@pci0:2:9:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00 bar [10] = type I/O Port, range 32, base 0xd500, size 256, enabled bar [14] = type Memory, range 32, base 0xefefa000, size 512, enabled re1@pci0:2:10:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00 bar [10] = type I/O Port, range 32, base 0xd600, size 256, enabled bar [14] = type Memory, range 32, base 0xefefb000, size 512, enabled re2@pci0:2:11:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00 bar [10] = type I/O Port, range 32, base 0xd900, size 256, enabled bar [14] = type Memory, range 32, base 0xefefc000, size 512, enabled re3@pci0:2:12:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00 bar [10] = type I/O Port, range 32, base 0xda00, size 256, enabled bar [14] = type Memory, range 32, base 0xefefd000, size 512, enabled re4@pci0:2:13:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00 bar [10] = type I/O Port, range 32, base 0xdd00, size 256, enabled bar [14] = type Memory, range 32, base 0xefefe000, size 512, enabled re5@pci0:2:14:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00 bar [10] = type I/O Port, range 32, base 0xde00, size 256, enabled bar [14] = type Memory, range 32, base 0xefeff000, size 512, enabled
However, I don't know how to interpret 0xff00 as the base.
Running ./readio gives me the following:[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(5): ./readio 0xff00 Reading ff00 :0
-
2440 is the ICH2 chip,82801BA, 244C is ICH2-M, 82801BAM. You have the former.
Unfortunately your output is like mine. The base address we need is that of the isab0 device, not listed.
Still this is all interesting stuff! :DSteve
-
And there I was thinking it did work for me!
So, is there another way of finding out what the base address for lsab0 is?
And I agree that this is all very interesting, though it does go slightly over my head.
Still, it must be said that you are good at explaining what I need to to and what to expect! -
I have to say I'm learning as I go here.
There must be another way since it's an integral part of the os. I have a feeling it's probably passed to the os by the bios. Certainly the bios code sets up the chipset initially so if it moved the gpiobase thats where it would be stored.
Intel provide a helpful application note for doing just this. Here.
They explain how it's all setup and how the registers relate to one another. They even provide example code for finding the gpiobase and the LPC base and it's written for FreeBSD. Unfortunately it's only sample functions and not something that could be compiled. :(
I don't really want to start messing about trying to write a program to do this. I sure there's FreeBSD package that can do this already I just don't know what it is.Steve
-
Edit: Don't do this! Perhaps it makes interesting reading for someone. See my post a few below here after Wallabybob pointed out my failure to understand pciconf. ::)
Here's something that seems to work, if you're feeling brave! :P I spent ages trying to compile a very simple program but gave up after more compile errors than I could count. Anyway the basic functionality is included in the pciutils package. First install the package:
/etc/rc.conf_mount_rw pkg_add -r pciutils /etc/rc.conf_mount_ro rehash
This is a port of the Linux lspci utility with some extra bits.
Fire it up and see what you have:[2.0-BETA5][root@pfSense.localdomain]/root(34): lspci 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 04) 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04) 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 04) 00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 4 (rev 04) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 04) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 04) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4) 00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 04) 01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19) 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19) 03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19) 04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19) 05:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) 05:01.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) 05:02.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) 05:03.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) 05:04.0 Network and computing encryption device: Cavium Networks Nitrox XL N1 Lite
This is my Xe box. You can see the ICH LPC bridge listed has PCI address 00:1f.0 (obviously change this to your address).
So now we can get lspci to spit out the configuration data. This function comes with a danger warning but works fine here:[2.0-BETA5][root@pfSense.localdomain]/root(35): lspci -s 00:1f.0 -xxx 00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04) 00: 86 80 41 26 07 01 00 02 04 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 41 26 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 01 04 00 00 80 00 00 00 81 04 00 00 10 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 0b 0c 05 0a d0 00 00 00 0b 80 80 09 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 10 00 0f 34 81 00 00 00 91 02 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 20 02 00 00 00 00 00 00 00 00 00 00 00 03 00 00 b0: 00 00 00 00 00 00 00 00 55 55 55 55 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 33 22 11 00 67 45 00 00 c0 c0 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 01 c0 d1 fe 00 00 00 00 80 0f 04 00 00 00 00 00
So now we have the important part of the configuration table. Looking at the datasheet for the ICH6 the GPIO base address is stored in registers 0x48-0x4b. You have to read it in reverse: 00 00 04 81. i.e 0x481 Except that reading the datasheet more closely we see that "bit 0 is hardwired to 1 to indicate I/O space" for some reason. ::) So the actual address is 0x480. Which we know to be true.
This procedure should work fine for you except that in the ICH2 the gpio base address is at 0x58-5B instead.
Steve
-
The FreeBSD utility pciconf can also be used to get this information. There is a man page at http://www.freebsd.org/cgi/man.cgi?query=pciconf&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html
-
The FreeBSD utility pciconf can also be used to get this information.
Doh! :-[
It was like three in the morning by the time I wrote that.The same result can be had with:
[code]
[2.0-BETA5][root@pfSense.localdomain]/root(10): pciconf -r pci0:0:31:0: 0x48
00000481On the X-core box with the ICH2 you need to look at 0x58 but the LPC device is in the same place so:
pciconf -r pci0:0:31:0: 0x58
Steve
-
On the X-core box with the ICH2 you need to look at 0x58 but the LPC device is in the same place so:
pciconf -r pci0:0:31:0: 0x58
Steve
Progress! That is to say, the command gives me a response on my firebox.
The response is as follows:[2.0-BETA5][admin@firebox1.domain]/root(1): pciconf -r pci0:0:31:0: 0x58 00004081
I'm not sure what this means though!
What is the next step? -
Aha! That's disappointingly similar to 480, open to confusion but it looks as though the GPIObase address is 0x4080.
The next setp is to re-try the instructions from here but using 0x4080 in place of 0x480.
Hopefully you should get something other than all ff or 0.Steve
-
The next setp is to re-try the instructions from here but using 0x4080 in place of 0x480.
Hopefully you should get something other than all ff or 0.Steve
Indeed, the numbers are so alike that I first thought I had gotten the same response as you did.
And now, with your help, readio has given me an answer other than ff!
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(4): ./readio 0x4080 Reading 4080 :80 [2.0-BETA5][admin@firebox1.domain]/etc/rc.d(5): ./readio 0x4081 Reading 4081 :31 [2.0-BETA5][admin@firebox1.domain]/etc/rc.d(6): ./readio 0x4082 Reading 4082 :20 [2.0-BETA5][admin@firebox1.domain]/etc/rc.d(7): ./readio 0x4083 Reading 4083 :1a [2.0-BETA5][admin@firebox1.domain]/etc/rc.d(8): ./readio 0x4084 Reading 4084 :ff [2.0-BETA5][admin@firebox1.domain]/etc/rc.d(9): ./readio 0x4085 Reading 4085 :ff [2.0-BETA5][admin@firebox1.domain]/etc/rc.d(10): ./readio 0x4086 Reading 4086 :0 [2.0-BETA5][admin@firebox1.domain]/etc/rc.d(11): ./readio 0x4087 Reading 4087 :0 [2.0-BETA5][admin@firebox1.domain]/etc/rc.d(12): ./readio 0x408c Reading 408c :0 [2.0-BETA5][admin@firebox1.domain]/etc/rc.d(13): ./readio 0x408d Reading 408d :0 [2.0-BETA5][admin@firebox1.domain]/etc/rc.d(14): ./readio 0x408e Reading 408e :bf [2.0-BETA5][admin@firebox1.domain]/etc/rc.d(15): ./readio 0x408f Reading 408f :9
Unfortunately, some of the responses are still 0 or ff.
-
Unfortunately, some of the responses are still 0 or ff.
Not a problem, they should be.
So:Experimental findings of ICH2 IO space; 0x4080-0x4083 Set pins as gpio or native fuctions. 1=gpio Default 1a003180 0001 1010 0000 0000 Found 1a203180 0001 1010 0010 0000 0x4084-0x4087 Set gpios as input or output. 1=Input Default 0000ffff Found 0000ffff bit 1 is input. Possible outputs are 0000 0000 0000 0000 1111 1111 1111 1111 1 1 1 1 (set as gpio & set as output) 0x408c-0x408f GPIO Levels Default 1f1f0000 Found 09bf0000 0000 1001 1011 1111
Hmm, doesn't really line up properly on the forum but.. Edit: Better
Only four pins are both enabled as GPIO and set as ouput and only two of those are set to 1. So try seting either of those to 0.
./writeio 0x408f 0x01
Return it to it's original value after or things get confusing! Or:
./writeio 0x408e 0x9f
One of those should switch off the red led.
Once we know that we can work on green and flashing!
Steve
-
Only four pins are both enabled as GPIO and set as ouput and only two of those are set to 1. So try seting either of those to 0.
./writeio 0x408f 0x01
Return it to it's original value after or things get confusing! Or:
./writeio 0x408e 0x9f
One of those should switch off the red led.
Thanks, I've been meaning to try this.
However, when you write 'Return it to it's original value after or things get confusing!', how do I know what the original value was?
0x408e gave me a response of bf, so would that be 0xbf?
Or am I being nonsensical? -
Yes, bf is 0xbf. I never really expected anyone else to be using the program so didn't spend much time sanitising the output, sorry. :P (in fact I don't think it matters if you include the 0x or not)
When you change 408e from 0xBF to 0x9F what you are actually doing is changing only 1 bit (B=1011 and 9=1001). I say to change it back since if you change more than one thing at a time it's hard to know what change had what effect.
The fact is that we don't know what, if anything, the other gpios are connected to. It's better to return them to their original state. On the boxes I have here none of the random number setting I have done had any ill effects and it all gets reset by the bios at boot so don't worry.
Good luck!Steve
-
After trying both ./writeio 0x408f 0x01 and ./writeio 0x408e 0x9f, I found the following:
The first command (0x01) makes the red led blink red / off (looks like it blinks synchronised to re0, but I'm not sure).
The second command (0x9f) does nothing (seemingly).Afterwards, I reset 0x0408f to 0x09 and 0x408e to 0xbf.
-
Hmmm, interesting. Well it's something at least. It proves that the led is driven by the gpios i some way.
So it doesn't blink regularly, like once a second?Anyway it seems that 0x408f bit 3 is red on.
To find green leave red off (or blink in this case) and try turning on bits 1 or 4 i.e../writeio 0x408f 0x11 or 0x03.
Normally the blinking action is set by the blink register which for you should be at 0x409b, to correspond with the ouputs at 0x408f. Try reading 0x409b, by default it is 00.
Steve
-
I've tried both settings.
./writeio 0x408f 0x11 turns the led green and blinks at fast but irregular intervals.
./writeio 0x408f 0x03 does the same, but turns the led back to red.I've reset to 0x11 now, so at least the arm led is green!
This is awesome.Edit: actually, the blinking is regular. About four blinks per second.
-
Hmm, even more interesting.
So 0x408f set to 03 is the same as 01 yes?
The built in blink function is definitely 1Hz so if it's blinking at around 4Hz then something else is doing it. Still worth checking the blink registers at 0x409A and 0x409B.
It's likely only two pins actually do anything giving only 4 possible states. It appears to be 0x408F bits 3 and 4. We have tried:
01 which is default, solid red
00 red flashing
10 green flashing
11 haven't tried that yet.Try ./writeio 0x408f 19
As I said there are four possible gpio pins so 16 possible states. Since there is some confusion I think we may just have to work through them.
Steve