Dump GPIO I/O Registers

Hello,
How do I dump the GPIO I/O Registers in linux. I need to dump the  
GPIO's from the southbridge. Anyone?

Thanks - Joe

[Gregg C Levine]

Hello!
Isn't the southbridge part of the basic PCI structure? I seem to recall a
discussion on the earlier list for what we do here, and it came up that you
can dump the registers for the bridges via the lspci and probably manage
them via the setpci commands from the pcitools stuff.

According to the cover sheet for them for my distribution it is possible to
adjust the latency timers of the whole thing via the setpci command. Ideally
simply doing a man lspci should tell you what and who behind them. Oh and
one more thing? Be careful.
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]

On
> Behalf Of [e-mail]
> Sent: Saturday, February 16, 2008 11:58 AM
> To: Coreboot
> Subject: [coreboot] Dump GPIO I/O Registers
>
> Hello,
> How do I dump the GPIO I/O Registers in linux. I need to dump the
> GPIO's from the southbridge. Anyone?
>
> Thanks - Joe

Quoting Gregg C Levine :
> Hello!
> Isn't the southbridge part of the basic PCI structure? I seem to recall a
> discussion on the earlier list for what we do here, and it came up that you
> can dump the registers for the bridges via the lspci and probably manage
> them via the setpci commands from the pcitools stuff.
>
> According to the cover sheet for them for my distribution it is possible to
> adjust the latency timers of the whole thing via the setpci command. Ideally
> simply doing a man lspci should tell you what and who behind them. Oh and
> one more thing? Be careful.

Greg lspci works ok to find/set pci configuration registers. I need  
something that will probe the GPIO's to find out which one is asserted  
and if the signal is in or out? Does that make more sense?
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
>
> On
> > Behalf Of [e-mail]
> > Sent: Saturday, February 16, 2008 11:58 AM
> > To: Coreboot
> > Subject: [coreboot] Dump GPIO I/O Registers
> >
> > Hello,
> > How do I dump the GPIO I/O Registers in linux. I need to dump the
> > GPIO's from the southbridge. Anyone?
> >
> > Thanks - Joe

[Peter Stuge]

On Sun, Feb 17, 2008 at 08:38:30PM -0500, [e-mail] wrote:
> I need something that will probe the GPIO's to find out which one is
> asserted and if the signal is in or out? Does that make more sense?

Unfortunately you are now at the point where you would need the board
schematic.

It can't be probed easily, but perhaps reverse engineered with a bit
of effort.

//Peter

Quoting Peter Stuge :
> On Sun, Feb 17, 2008 at 08:38:30PM -0500, [e-mail] wrote:
> > I need something that will probe the GPIO's to find out which one is
> > asserted and if the signal is in or out? Does that make more sense?
>
> Unfortunately you are now at the point where you would need the board
> schematic.

That would be a miracle :-)
> It can't be probed easily, but perhaps reverse engineered with a bit
> of effort.

You mean just probing the GPIO pins with a meter to find out which  
ones are asserted? There has got to be something easier than that?  
Like dumping the I/O space?? But how??
> //Peter

Thanks - Joe

[Peter Stuge]

On Sun, Feb 17, 2008 at 09:15:55PM -0500, [e-mail] wrote:
> > It can't be probed easily, but perhaps reverse engineered with a
> > bit of effort.
>
> You mean just probing the GPIO pins with a meter to find out which
> ones are asserted?

Right.
> There has got to be something easier than that?

Sometimes it's the only option. :(
> Like dumping the I/O space?? But how??

Even if you manage to find these registers it seems the documentation
you've got still doesn't say anything about how to interpret the
data. That's a problem without an easy solution. :\

//Peter

[Carl-Daniel Hailfinger]

On 18.02.2008 03:25, Peter Stuge wrote:
> On Sun, Feb 17, 2008 at 09:15:55PM -0500, [e-mail] wrote:
> > > It can't be probed easily, but perhaps reverse engineered with a
> > > bit of effort.
> >
> > You mean just probing the GPIO pins with a meter to find out which
> > ones are asserted?
>
> Right.
> > There has got to be something easier than that?
>
> Sometimes it's the only option. :(

You two are possibly misunderstanding each other. Joe wants to simply 
dump the register contents (probably to make sure they match between 
coreboot and proprietary BIOS). Peter suggests ways to find out where 
each GPIO is connected to. Right?
> > Like dumping the I/O space?? But how??
>
> Even if you manage to find these registers it seems the documentation
> you've got still doesn't say anything about how to interpret the
> data. That's a problem without an easy solution. :\

OK, now that may be a problem, but since Joe already knows the iobase 
for these registers, he is probably primarily interested in dumping them 
for comparison.

Regards,
Carl-Daniel

Quoting Carl-Daniel Hailfinger :
> On 18.02.2008 03:25, Peter Stuge wrote:
> > On Sun, Feb 17, 2008 at 09:15:55PM -0500, [e-mail] wrote:
> > > > It can't be probed easily, but perhaps reverse engineered with a
> > > > bit of effort.
> > >
> > > You mean just probing the GPIO pins with a meter to find out which
> > > ones are asserted?
> >
> > Right.
> > > There has got to be something easier than that?
> >
> > Sometimes it's the only option. :(
>
> You two are possibly misunderstanding each other. Joe wants to simply
> dump the register contents (probably to make sure they match between
> coreboot and proprietary BIOS). Peter suggests ways to find out where
> each GPIO is connected to. Right?

Yup. The datasheet does give register definitions for the 64-byte I/O  
space. Specifically I need to know if GPIO 24, 25, 27, or 28 are  
asserted.
> > > Like dumping the I/O space?? But how??
> >
> > Even if you manage to find these registers it seems the documentation
> > you've got still doesn't say anything about how to interpret the
> > data. That's a problem without an easy solution. :\
>
> OK, now that may be a problem, but since Joe already knows the iobase
> for these registers, he is probably primarily interested in dumping them
> for comparison.

Yes.
> Regards,
> Carl-Daniel

Thanks - Joe

[Gregg C Levine]

Hello!
Perfectly.
As others have stated, you have reached the point where you might really
need the board's schematic. Plus a good understanding of the datasheets for
the appropriate part.

I was under the understanding that you had already gotten this far on other
systems.
--
Gregg C Levine [e-mail]
"The Force will be with you always." Obi-Wan Kenobi
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]

On
> Behalf Of [e-mail]
> Sent: Sunday, February 17, 2008 8:39 PM
> To: Gregg C Levine
> Cc: 'Coreboot'
> Subject: Re: [coreboot] Dump GPIO I/O Registers
>
> Quoting Gregg C Levine :
> > Hello!
> > Isn't the southbridge part of the basic PCI structure? I seem to recall

a
> > discussion on the earlier list for what we do here, and it came up that

you
> > can dump the registers for the bridges via the lspci and probably manage
> > them via the setpci commands from the pcitools stuff.
> >
> > According to the cover sheet for them for my distribution it is possible

to
> > adjust the latency timers of the whole thing via the setpci command.

Ideally
> > simply doing a man lspci should tell you what and who behind them. Oh

and
> > one more thing? Be careful.
>
> Greg lspci works ok to find/set pci configuration registers. I need
> something that will probe the GPIO's to find out which one is asserted
> and if the signal is in or out? Does that make more sense?
> > > -----Original Message-----
> > > From: [e-mail]

[mailto:[e-mail]]
> > On
> > > Behalf Of [e-mail]
> > > Sent: Saturday, February 16, 2008 11:58 AM
> > > To: Coreboot
> > > Subject: [coreboot] Dump GPIO I/O Registers
> > >
> > > Hello,
> > > How do I dump the GPIO I/O Registers in linux. I need to dump the
> > > GPIO's from the southbridge. Anyone?
> > >
> > > Thanks - Joe

[Carl-Daniel Hailfinger]

On 16.02.2008 17:57, [e-mail] wrote:
> Hello,
> How do I dump the GPIO I/O Registers in linux. I need to dump the  
> GPIO's from the southbridge. Anyone?

Depends on the southbridge. It could be directly/indirectly 
memory-mapped or port-based. Simply tell us what the data sheet says 
about reading the GPIO state and we can help.

Regards,
Carl-Daniel

Quoting Carl-Daniel Hailfinger :
> On 16.02.2008 17:57, [e-mail] wrote:
> > Hello,
> > How do I dump the GPIO I/O Registers in linux. I need to dump the    
> > GPIO's from the southbridge. Anyone?
>
> Depends on the southbridge. It could be directly/indirectly
> memory-mapped or port-based. Simply tell us what the data sheet says
> about reading the GPIO state and we can help.
>
> Regards,
> Carl-Daniel

The southbridge is the Intel 82801DB ICH4. I don't see anything in the  
datasheet about reading the GPIO state....just says:

The control for the general purpose I/O signals is handled through a  
separate 64-byte I/O space.

I can find out the base offset address from the LPC pci configuration  
registers, but how do I dump it into human readable form??

Thanks - Joe

[Carl-Daniel Hailfinger]

On 18.02.2008 02:45, [e-mail] wrote:
> Quoting Carl-Daniel Hailfinger :
> > On 16.02.2008 17:57, [e-mail] wrote:
> > > Hello,
> > > How do I dump the GPIO I/O Registers in linux. I need to dump the    
> > > GPIO's from the southbridge. Anyone?
> >
> > Depends on the southbridge. It could be directly/indirectly
> > memory-mapped or port-based. Simply tell us what the data sheet says
> > about reading the GPIO state and we can help.
>
> The southbridge is the Intel 82801DB ICH4. I don't see anything in the  
> datasheet about reading the GPIO state....just says:
>
> The control for the general purpose I/O signals is handled through a  
> separate 64-byte I/O space.
>
> I can find out the base offset address from the LPC pci configuration  
> registers, but how do I dump it into human readable form??

Is this a memory address or I/O port number? Once you know that, you can 
modify existing utilities for your purpose. If you have no idea, tell us 
the values and we can guess. Having /proc/ioports and /proc/iomem 
contents would help guessing.

Regards,
Carl-Daniel
> Thanks - Joe

Quoting Carl-Daniel Hailfinger :
> On 18.02.2008 02:45, [e-mail] wrote:
> > Quoting Carl-Daniel Hailfinger :
> > > On 16.02.2008 17:57, [e-mail] wrote:
> > > > Hello,
> > > > How do I dump the GPIO I/O Registers in linux. I need to dump the  
> > > >     GPIO's from the southbridge. Anyone?
> > >
> > > Depends on the southbridge. It could be directly/indirectly
> > > memory-mapped or port-based. Simply tell us what the data sheet says
> > > about reading the GPIO state and we can help.
> >
> > The southbridge is the Intel 82801DB ICH4. I don't see anything in   
> > the datasheet about reading the GPIO state....just says:
> >
> > The control for the general purpose I/O signals is handled through   
> > a  separate 64-byte I/O space.
> >
> > I can find out the base offset address from the LPC pci   
> > configuration  registers, but how do I dump it into human readable   
> > form??
>
> Is this a memory address or I/O port number? Once you know that, you
> can modify existing utilities for your purpose. If you have no idea,
> tell us the values and we can guess. Having /proc/ioports and
> /proc/iomem contents would help guessing.

Here is /proc/ioports:
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
0376-0376 : ide1
03c0-03df : vga+
03f8-03ff : serial
0400-047f : 0000:00:1f.0
   0400-0403 : ACPI PM1a_EVT_BLK
   0404-0405 : ACPI PM1a_CNT_BLK
   0408-040b : ACPI PM_TMR
   0410-0415 : ACPI CPU throttle
   0420-0420 : ACPI PM2_CNT_BLK
   0428-042f : ACPI GPE0_BLK
   0460-047f : iTCO_wdt
0500-053f : 0000:00:1f.0
0a00-0a3f : pnp 00:0b
0cf8-0cff : PCI conf1
c000-cfff : PCI Bus #01
   cc00-cc3f : 0000:01:08.0
     cc00-cc3f : e100
d800-d81f : 0000:00:1d.0
   d800-d81f : uhci_hcd
d880-d89f : 0000:00:1d.1
   d880-d89f : uhci_hcd
dc00-dc1f : 0000:00:1d.2
   dc00-dc1f : uhci_hcd
e000-e01f : 0000:00:1f.3
   e000-e01f : i801_smbus
e080-e0bf : 0000:00:1f.5
   e080-e0bf : Intel 82801DB-ICH4
e400-e4ff : 0000:00:1f.5
   e400-e4ff : Intel 82801DB-ICH4
e800-e8ff : 0000:00:1f.6
ec00-ec7f : 0000:00:1f.6
ffa0-ffaf : 0000:00:1f.1
   ffa0-ffa7 : ide0
   ffa8-ffaf : ide1

Here is /proc/iomem:
00000000-0009fbff : System RAM
   00000000-00000000 : Crash kernel
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-077cffff : System RAM
   00400000-006200ec : Kernel code
   006200ed-00736543 : Kernel data
077d0000-077defff : ACPI Tables
077df000-077fffff : ACPI Non-volatile Storage
10000000-100003ff : 0000:00:1f.1
e8000000-efffffff : 0000:00:02.1
f0000000-f7ffffff : 0000:00:02.0
ff700000-ff7fffff : PCI Bus #01
   ff7ff000-ff7fffff : 0000:01:08.0
     ff7ff000-ff7fffff : e100
ff980000-ff9fffff : 0000:00:02.1
ffa7f400-ffa7f7ff : 0000:00:1d.7
   ffa7f400-ffa7f7ff : ehci_hcd
ffa7f800-ffa7f8ff : 0000:00:1f.5
   ffa7f800-ffa7f8ff : Intel 82801DB-ICH4
ffa7fc00-ffa7fdff : 0000:00:1f.5
   ffa7fc00-ffa7fdff : Intel 82801DB-ICH4
ffa80000-ffafffff : 0000:00:02.0
ffc00000-fff7ffff : pnp 00:08

According to the original bios I think the 64 bytes of I/O space for  
GPIO is 0x14. Does that make sense???

Thanks - Joe

[Tom Sylla]

If you want to look at the GPIOs, from the 82801DB datasheet, it looks
like you should look at:

9.1.14 GPIOBASE—GPIO Base Address (LPC I/F—D31:F0)
and
9.1.15 GPIO_CNTL—GPIO Control (LPC I/F—D31:F0)
(offsets 58 and 5c in D31:f0, lspci -xxx as root is one way to dump)

What value is in those registers? Check to see if an address is
assigned, and if the decode is enabled. If so, you have something to
dump.

That register is not a real PCI BAR, so it may not show up in /proc/ioports

Once you have the base address, you can read the GPIO control
registers from /dev/port, with the seek equal to the base address. It
looks like the register set is described in:

9.10 General Purpose I/O Registers (D31:F0)

and Table 9-12 in the 82801DB datasheet.

On Feb 18, 2008 8:15 AM,   wrote:
> Quoting Carl-Daniel Hailfinger :
> > On 18.02.2008 02:45, [e-mail] wrote:
> > > Quoting Carl-Daniel Hailfinger :
> > > > On 16.02.2008 17:57, [e-mail] wrote:
> > > > > Hello,
> > > > > How do I dump the GPIO I/O Registers in linux. I need to dump the
> > > > >     GPIO's from the southbridge. Anyone?
> > > >
> > > > Depends on the southbridge. It could be directly/indirectly
> > > > memory-mapped or port-based. Simply tell us what the data sheet says
> > > > about reading the GPIO state and we can help.
> > >
> > > The southbridge is the Intel 82801DB ICH4. I don't see anything in
> > > the datasheet about reading the GPIO state....just says:
> > >
> > > The control for the general purpose I/O signals is handled through
> > > a  separate 64-byte I/O space.
> > >
> > > I can find out the base offset address from the LPC pci
> > > configuration  registers, but how do I dump it into human readable
> > > form??
> >
> > Is this a memory address or I/O port number? Once you know that, you
> > can modify existing utilities for your purpose. If you have no idea,
> > tell us the values and we can guess. Having /proc/ioports and
> > /proc/iomem contents would help guessing.
>
> Here is /proc/ioports:
> 0000-001f : dma1
> 0020-0021 : pic1
> 0040-0043 : timer0
> 0050-0053 : timer1
> 0060-006f : keyboard
> 0070-0077 : rtc
> 0080-008f : dma page reg
> 00a0-00a1 : pic2
> 00c0-00df : dma2
> 00f0-00ff : fpu
> 0170-0177 : ide1
> 0376-0376 : ide1
> 03c0-03df : vga+
> 03f8-03ff : serial
> 0400-047f : 0000:00:1f.0
>    0400-0403 : ACPI PM1a_EVT_BLK
>    0404-0405 : ACPI PM1a_CNT_BLK
>    0408-040b : ACPI PM_TMR
>    0410-0415 : ACPI CPU throttle
>    0420-0420 : ACPI PM2_CNT_BLK
>    0428-042f : ACPI GPE0_BLK
>    0460-047f : iTCO_wdt
> 0500-053f : 0000:00:1f.0
> 0a00-0a3f : pnp 00:0b
> 0cf8-0cff : PCI conf1
> c000-cfff : PCI Bus #01
>    cc00-cc3f : 0000:01:08.0
>      cc00-cc3f : e100
> d800-d81f : 0000:00:1d.0
>    d800-d81f : uhci_hcd
> d880-d89f : 0000:00:1d.1
>    d880-d89f : uhci_hcd
> dc00-dc1f : 0000:00:1d.2
>    dc00-dc1f : uhci_hcd
> e000-e01f : 0000:00:1f.3
>    e000-e01f : i801_smbus
> e080-e0bf : 0000:00:1f.5
>    e080-e0bf : Intel 82801DB-ICH4
> e400-e4ff : 0000:00:1f.5
>    e400-e4ff : Intel 82801DB-ICH4
> e800-e8ff : 0000:00:1f.6
> ec00-ec7f : 0000:00:1f.6
> ffa0-ffaf : 0000:00:1f.1
>    ffa0-ffa7 : ide0
>    ffa8-ffaf : ide1
>
> Here is /proc/iomem:
> 00000000-0009fbff : System RAM
>    00000000-00000000 : Crash kernel
> 0009fc00-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000f0000-000fffff : System ROM
> 00100000-077cffff : System RAM
>    00400000-006200ec : Kernel code
>    006200ed-00736543 : Kernel data
> 077d0000-077defff : ACPI Tables
> 077df000-077fffff : ACPI Non-volatile Storage
> 10000000-100003ff : 0000:00:1f.1
> e8000000-efffffff : 0000:00:02.1
> f0000000-f7ffffff : 0000:00:02.0
> ff700000-ff7fffff : PCI Bus #01
>    ff7ff000-ff7fffff : 0000:01:08.0
>      ff7ff000-ff7fffff : e100
> ff980000-ff9fffff : 0000:00:02.1
> ffa7f400-ffa7f7ff : 0000:00:1d.7
>    ffa7f400-ffa7f7ff : ehci_hcd
> ffa7f800-ffa7f8ff : 0000:00:1f.5
>    ffa7f800-ffa7f8ff : Intel 82801DB-ICH4
> ffa7fc00-ffa7fdff : 0000:00:1f.5
>    ffa7fc00-ffa7fdff : Intel 82801DB-ICH4
> ffa80000-ffafffff : 0000:00:02.0
> ffc00000-fff7ffff : pnp 00:08
>
> According to the original bios I think the 64 bytes of I/O space for
> GPIO is 0x14. Does that make sense???
>
> Thanks - Joe

[ron minnich]

I think you guys are going in circles :-)

Here is my chance to help :-)

For the last gazillion years the IO ports on the intel parts have been
about the same. You could probably even reference an old PIIX document
to see how they are programmed. (you'd be surprised how much all the
new stuff looks like a PIIX ...)

You could also take the basic code from superio probe and modify it to
work on southbridge parts -- I looked at this, it looked doable, I ran
out of time and need for it.

And, yes, who knows why, but on all of the ICH parts (you pronounce
this "ICK!") I know of the GPIO IOBASE is not a config space register.
BLEAH!

So you do something like this:
1. id the vendor/dev id (use libpci -- see flashrom for example)
2. From that, call a chip-specific function that returns the GPIO
IOBASE set. Plan to make it an arbitrary sized array or a struct that
has the info (use the code from flashrom)
3. With that data from (2), write chip-specific functions that display:
- enable info
- direction info
- value of the gpio port info
(Some of the code from the superio tool might be very useful here
--it's all inx/outx bit mask/extract bits at this point, nothing
special)

Anyway, this is a bit more work, but ... if you do it, we'll have a
tool we can extend the same way as the superiotool, and your
grandchildren will thank you.

btw, this type of tool is incredibly useful, as you doubtless know. We
found the FLASH write enable on the K8N in about 10 minutes with
superiotool, and it only took 10 mins as we had to write a little
support code for the superio ... would have taken 30 seconds
otherwise. I feel so safe now that I know how well the write line on
FLASH is protected :-)

ron

Quoting ron minnich :
> I think you guys are going in circles :-)
>
> Here is my chance to help :-)
>
> For the last gazillion years the IO ports on the intel parts have been
> about the same. You could probably even reference an old PIIX document
> to see how they are programmed. (you'd be surprised how much all the
> new stuff looks like a PIIX ...)
>
> You could also take the basic code from superio probe and modify it to
> work on southbridge parts -- I looked at this, it looked doable, I ran
> out of time and need for it.
>
> And, yes, who knows why, but on all of the ICH parts (you pronounce
> this "ICK!") I know of the GPIO IOBASE is not a config space register.
> BLEAH!
>
> So you do something like this:
> id the vendor/dev id (use libpci -- see flashrom for example)
> From that, call a chip-specific function that returns the GPIO
>
> IOBASE set. Plan to make it an arbitrary sized array or a struct that
> has the info (use the code from flashrom)
> 3. With that data from (2), write chip-specific functions that display:
> enable info
> direction info
> value of the gpio port info
>
> (Some of the code from the superio tool might be very useful here
> --it's all inx/outx bit mask/extract bits at this point, nothing
> special)
>
> Anyway, this is a bit more work, but ... if you do it, we'll have a
> tool we can extend the same way as the superiotool, and your
> grandchildren will thank you.
>
> btw, this type of tool is incredibly useful, as you doubtless know. We
> found the FLASH write enable on the K8N in about 10 minutes with
> superiotool, and it only took 10 mins as we had to write a little
> support code for the superio ... would have taken 30 seconds
> otherwise. I feel so safe now that I know how well the write line on
> FLASH is protected :-)
>
> ron

Thanks Ron, I know this tool would be incredibly useful too me right now:-)
I'll see what I can come up with, with everyones help of course:-)

Thanks - Joe

Quoting Tom Sylla :
> If you want to look at the GPIOs, from the 82801DB datasheet, it looks
> like you should look at:
>
> 9.1.14 GPIOBASE—GPIO Base Address (LPC I/F—D31:F0)

0x00000501
> and
> 9.1.15 GPIO_CNTL—GPIO Control (LPC I/F—D31:F0)
> (offsets 58 and 5c in D31:f0, lspci -xxx as root is one way to dump)

0x10
> What value is in those registers? Check to see if an address is
> assigned, and if the decode is enabled. If so, you have something to
> dump.
>
> That register is not a real PCI BAR, so it may not show up in /proc/ioports
>
> Once you have the base address, you can read the GPIO control
> registers from /dev/port, with the seek equal to the base address.

How?? This is the part I am looking for, this would be the golden ticket:-)
> It
> looks like the register set is described in:
>
> 9.10 General Purpose I/O Registers (D31:F0)
>
> and Table 9-12 in the 82801DB datasheet.

Yup, that is what I am going to reference it with.

Thanks for you help Tom.

Thanks - Joe

[Peter Stuge]

On Mon, Feb 18, 2008 at 07:45:55PM -0500, [e-mail] wrote:
> > Once you have the base address, you can read the GPIO control
> > registers from /dev/port, with the seek equal to the base address.
>
> How?? This is the part I am looking for, this would be the golden
> ticket:-)

Oh! This can be fairly simple.

dd if=/dev/ioport bs=1 skip=$[0xbasehere] count=asmanyasyouwant | xxd

//Peter

Quoting Peter Stuge :
> On Mon, Feb 18, 2008 at 07:45:55PM -0500, [e-mail] wrote:
> > > Once you have the base address, you can read the GPIO control
> > > registers from /dev/port, with the seek equal to the base address.
> >
> > How?? This is the part I am looking for, this would be the golden
> > ticket:-)
>
> Oh! This can be fairly simple.
>
> dd if=/dev/ioport bs=1 skip=$[0xbasehere] count=asmanyasyouwant | xxd

OK, so lets clarify?

GPIOBASE?GPIO Base Address (LPC I/F?D31:F0)
31:16 Reserved
15:6 Base Address ? R/W. Provides the 64 bytes of I/O space for GPIO.
5:1 Reserved
0 Resource Indicator ? RO. Hardwired to 1; indicates I/O space.

1. My value is 0x00000501. So if only bits 15:6 are the base address  
this would make my base address 0x14 correct? This value would become  
"0xbasehere"?

2. Would I put 64 in "asmanyasyouwant" to dump the whole 64 bytes of  
I/O space?

3. What is the pipe xxd for?

Thanks again for the help:-)

Thanks - Joe

[Russell Whitaker]

On Tue, 19 Feb 2008, [e-mail] wrote:
> Quoting Peter Stuge :

[..]
> > dd if=/dev/ioport bs=1 skip=$[0xbasehere] count=asmanyasyouwant | xxd
> What is the pipe xxd for?

The default output of dd is stdout, so it writes stdout to file xxd.
However, why not use of=xxd instead?  Same result.

Russ

[Martin]

Russell Whitaker skrev:
> On Tue, 19 Feb 2008, [e-mail] wrote:
> > Quoting Peter Stuge :
>
> [..]
> > > dd if=/dev/ioport bs=1 skip=$[0xbasehere] count=asmanyasyouwant | xxd
> > What is the pipe xxd for?
>
> The default output of dd is stdout, so it writes stdout to file xxd.
> However, why not use of=xxd instead?  Same result.
> Russ

I thought the point of the pipe to xxd was to process the output into 
readable output(in hex)?

Martin

[Stefan Reinauer]

Sorry for joining in late. I wrote a utility a while ago that dumped the
GPIO registers of an ICH7. Maybe your registers look pretty similar.

My output is something like:
Intel Southbridge: 8086:27b8
GPIOBASE = 0x0480

gpiobase+0x0000: 0x1f1ff7c0
gpiobase+0x0004: 0xe0e8efc3
gpiobase+0x0008: 0x00000000
gpiobase+0x000c: 0xebffeeff
gpiobase+0x0010: 0x00000000
gpiobase+0x0014: 0x00000000
gpiobase+0x0018: 0x00000000
gpiobase+0x001c: 0x00000000
gpiobase+0x0020: 0x00000000
gpiobase+0x0024: 0x00000000
gpiobase+0x0028: 0x00000000
gpiobase+0x002c: 0x00002180
gpiobase+0x0030: 0x000000ff
gpiobase+0x0034: 0x00000030
gpiobase+0x0038: 0x00010035
gpiobase+0x003c: 0x00000000

* [e-mail]  [080219 10:59]:
> Quoting Peter Stuge :
> > On Mon, Feb 18, 2008 at 07:45:55PM -0500, [e-mail] wrote:
> > > > Once you have the base address, you can read the GPIO control
> > > > registers from /dev/port, with the seek equal to the base address.
> > >
> > > How?? This is the part I am looking for, this would be the golden
> > > ticket:-)
> >
> > Oh! This can be fairly simple.
> >
> > dd if=/dev/ioport bs=1 skip=$[0xbasehere] count=asmanyasyouwant | xxd
>
> OK, so lets clarify?
>
> GPIOBASE?GPIO Base Address (LPC I/F?D31:F0)
> 31:16 Reserved
> 15:6 Base Address ? R/W. Provides the 64 bytes of I/O space for GPIO.
> 5:1 Reserved
> 0 Resource Indicator ? RO. Hardwired to 1; indicates I/O space.
> My value is 0x00000501. So if only bits 15:6 are the base address
>
> this would make my base address 0x14 correct? This value would become  
> "0xbasehere"?
> Would I put 64 in "asmanyasyouwant" to dump the whole 64 bytes of
>
> I/O space?
> What is the pipe xxd for?
>
> Thanks again for the help:-)
>
> Thanks - Joe

Quoting Stefan Reinauer :
> Sorry for joining in late. I wrote a utility a while ago that dumped the
> GPIO registers of an ICH7. Maybe your registers look pretty similar.
>
> My output is something like:
> Intel Southbridge: 8086:27b8
> GPIOBASE = 0x0480
>
> gpiobase+0x0000: 0x1f1ff7c0
> gpiobase+0x0004: 0xe0e8efc3
> gpiobase+0x0008: 0x00000000
> gpiobase+0x000c: 0xebffeeff
> gpiobase+0x0010: 0x00000000
> gpiobase+0x0014: 0x00000000
> gpiobase+0x0018: 0x00000000
> gpiobase+0x001c: 0x00000000
> gpiobase+0x0020: 0x00000000
> gpiobase+0x0024: 0x00000000
> gpiobase+0x0028: 0x00000000
> gpiobase+0x002c: 0x00002180
> gpiobase+0x0030: 0x000000ff
> gpiobase+0x0034: 0x00000030
> gpiobase+0x0038: 0x00010035
> gpiobase+0x003c: 0x00000000

Stefan, Stefan, Stefan. You are the bomb:-)
I wish you would have brought this up earlier....
As Ron said "btw, this type of tool is incredibly useful, as you  
doubtless know". I think we should mofify it for all the ICH's and add  
it to the utils or at least a wiki page maybe?

Thanks - Joe

[Stefan Reinauer]

* [e-mail]  [080219 15:40]:
> I wish you would have brought this up earlier....

Sorry. I had it on my CF disk for a while :(
> As Ron said "btw, this type of tool is incredibly useful, as you doubtless 
> know". I think we should mofify it for all the ICH's and add it to the 
> utils or at least a wiki page maybe?

I think that's a good plan. It should print at least the name of the
probed registers though to be a real "dump tool". It was merely a quick
attempt to find out how to set up the GPIOs so that serial console would
finally work and no other bad surprises jump in until we can verify with
the board schematics.

I have another one of those for the "MCHBAR" of the i945. Maybe we
should make this "intel-debugtools" or something?

Stefan

Quoting Stefan Reinauer :
> [e-mail]  [080219 15:40]:
> > I wish you would have brought this up earlier....
>
> Sorry. I had it on my CF disk for a while :(
> > As Ron said "btw, this type of tool is incredibly useful, as you doubtless
> > know". I think we should mofify it for all the ICH's and add it to the
> > utils or at least a wiki page maybe?
>
> I think that's a good plan. It should print at least the name of the
> probed registers though to be a real "dump tool". It was merely a quick
> attempt to find out how to set up the GPIOs so that serial console would
> finally work and no other bad surprises jump in until we can verify with
> the board schematics.
>
> I have another one of those for the "MCHBAR" of the i945. Maybe we
> should make this "intel-debugtools" or something?
>
> Stefan

Sounds like a great plan:-)
I have 4 or 5 intel boards lined up for coreboot development so  
"intel-debugtools" works.

Thanks - Joe

Sweet:-)
With Stefan's great tool I think I found my ethernet enable GPIO!!
I run it with the original bios (ethernet enabled) and then with the  
original bios (ethernet disabled). The only difference is in the 0x0C  
register looks like GPIO 23 is drivin to high (asserted), enabling the  
LAN Controller. This would have taken me forever to trace it manually  
without any schematics. For fun I ran it with the coreboot and yup the  
0x0C register looks just like the original bios with ethernet  
disabled. There are alot of other differences with the coreboot one,  
should I be worried about those (one of them could have to do with my  
flashrom issues??)?

Anyways, the question now is how can I assert GPIO 23 before the pci  
bus scan so coreboot will recognize my ethernet device?? Anyone??

Thanks - Joe

original bios ethernet enabled
[root@localhost dumpgpio]# ich_gpio
Intel Southbridge: 8086:24c0
GPIOBASE = 0x0500

gpiobase+0x0000: 0x1a003180
gpiobase+0x0004: 0x0900ffff
gpiobase+0x0008: 0x00000000
gpiobase+0x000c: 0x1bbf0000
gpiobase+0x0010: 0x00000000
gpiobase+0x0014: 0x00000000
gpiobase+0x0018: 0x00040000
gpiobase+0x001c: 0x00000000
gpiobase+0x0020: 0x00000000
gpiobase+0x0024: 0x00000000
gpiobase+0x0028: 0x00000000
gpiobase+0x002c: 0x00003000
gpiobase+0x0030: 0x00000fff
gpiobase+0x0034: 0x00000e00
gpiobase+0x0038: 0x00000fff
gpiobase+0x003c: 0x00000000

original bios ethernet disabled
[root@localhost ~]# ich_gpio
Intel Southbridge: 8086:24c0
GPIOBASE = 0x0500

gpiobase+0x0000: 0x1a003180
gpiobase+0x0004: 0x0900ffff
gpiobase+0x0008: 0x00000000
gpiobase+0x000c: 0x1b3f0000
gpiobase+0x0010: 0x00000000
gpiobase+0x0014: 0x00000000
gpiobase+0x0018: 0x00040000
gpiobase+0x001c: 0x00000000
gpiobase+0x0020: 0x00000000
gpiobase+0x0024: 0x00000000
gpiobase+0x0028: 0x00000000
gpiobase+0x002c: 0x00003000
gpiobase+0x0030: 0x00000fff
gpiobase+0x0034: 0x00000e00
gpiobase+0x0038: 0x00000fff
gpiobase+0x003c: 0x00000000

coreboot ethernet not working
[root@localhost ~]# ich_gpio
Intel Southbridge: 8086:24c0
GPIOBASE = 0x0500

gpiobase+0x0000: 0x1a003180
gpiobase+0x0004: 0x0000ffff
gpiobase+0x0008: 0x00000000
gpiobase+0x000c: 0x1b3f0000
gpiobase+0x0010: 0x00000000
gpiobase+0x0014: 0x00000000
gpiobase+0x0018: 0x00040000
gpiobase+0x001c: 0x00000000
gpiobase+0x0020: 0x00000000
gpiobase+0x0024: 0x00000000
gpiobase+0x0028: 0x00000000
gpiobase+0x002c: 0x00000000
gpiobase+0x0030: 0x00000fff
gpiobase+0x0034: 0x00000000
gpiobase+0x0038: 0x00000fff
gpiobase+0x003c: 0x00000000

[Corey Osgood]

On Thu, Feb 21, 2008 at 2:39 AM,  wrote:
> Sweet:-)
> With Stefan's great tool I think I found my ethernet enable GPIO!!
> I run it with the original bios (ethernet enabled) and then with the
> original bios (ethernet disabled). The only difference is in the 0x0C
> register looks like GPIO 23 is drivin to high (asserted), enabling the
> LAN Controller. This would have taken me forever to trace it manually
> without any schematics. For fun I ran it with the coreboot and yup the
> 0x0C register looks just like the original bios with ethernet
> disabled. There are alot of other differences with the coreboot one,
> should I be worried about those (one of them could have to do with my
> flashrom issues??)?
>
> Anyways, the question now is how can I assert GPIO 23 before the pci
> bus scan so coreboot will recognize my ethernet device?? Anyone??

Rather simple. Some time pre-ram init, set up the GPIO base, then use
inb()/outb() to modify the contents of the GPIO register you need to change.

-Corey

Hello,
I would like to report that I asserted GPIO23 early in the boot  
process from auto.c and my ethernet is now powering on:-)
coreboot detects it and sets it up:-)
Although I don't think it is setup all the way though, I can't get it  
to obtain a ip address in Linux from DHCP. I may have to figure out  
how to setup the CSR registers in I/O space. I'll keep plugging away  
though.....

I will be submitting a patch soon for Stepan's great GPIO dump tool, I  
hope everyone will find it as usefull as I did:-)

Thanks - Joe

intel-debugtools #1.ich_gpio

> > As Ron said "btw, this type of tool is incredibly useful, as you doubtless
> > know". I think we should mofify it for all the ICH's and add it to the
> > utils or at least a wiki page maybe?
>
> I think that's a good plan. It should print at least the name of the
> probed registers though to be a real "dump tool". It was merely a quick
> attempt to find out how to set up the GPIOs so that serial console would
> finally work and no other bad surprises jump in until we can verify with
> the board schematics.
>
> I have another one of those for the "MCHBAR" of the i945. Maybe we
> should make this "intel-debugtools" or something?

Looks like the only difference between all the ICH's is that ICH to ICH5
use 0x58 for the GPIO Base Address and ICH6 and up use 0x48 for the  
GPIO Base Address. So I modded the program with a simple if statement  
on the device id's.
This should work on all the ICH series. Check it out, and let me know  
what you think? Add it to the utils?

Thanks - Joe

[Tom Sylla]

The dump tool is the way to go now, but just to answer a couple of your 
questions:

[e-mail] wrote:
> OK, so lets clarify?
>
> GPIOBASE?GPIO Base Address (LPC I/F?D31:F0)
> 31:16 Reserved
> 15:6 Base Address ? R/W. Provides the 64 bytes of I/O space for GPIO.
> 5:1 Reserved
> 0 Resource Indicator ? RO. Hardwired to 1; indicates I/O space.
> My value is 0x00000501. So if only bits 15:6 are the base address
>
> this would make my base address 0x14 correct? This value would become  
> "0xbasehere"?

Bits 15:6 of that register become bits 15:6 of the address range, 
meaning your base is just 0x500. (that isn't really stated in the 
datasheet, but that is they way those type of registers usually work, 
see regular PCI BARs for another example)

Also, 0x14 would just not be an appropriate I/O base, take a look at an 
I/O port reference (i.e., ports.lst from Ralf Brown), and you will see 
that 14 is in the legacy DMA controller's I/O space. Anything less than 
0x100 is really only for legacy stuff.
> Would I put 64 in "asmanyasyouwant" to dump the whole 64 bytes of
>
> I/O space?

Yes
> What is the pipe xxd for?

When you use dd to read from /dev/port, you get out raw binary data. xxd 
turns that binary into a human-readable hex listing. (there are other 
tools to do this too, hexdump, etc)

Quoting Tom Sylla :
> The dump tool is the way to go now, but just to answer a couple of your
> questions:
>
> [e-mail] wrote:
> > OK, so lets clarify?
> >
> > GPIOBASE?GPIO Base Address (LPC I/F?D31:F0)
> > 31:16 Reserved
> > 15:6 Base Address ? R/W. Provides the 64 bytes of I/O space for GPIO.
> > 5:1 Reserved
> > 0 Resource Indicator ? RO. Hardwired to 1; indicates I/O space.
> > My value is 0x00000501. So if only bits 15:6 are the base
> >
> > address  this would make my base address 0x14 correct? This value   
> > would become  "0xbasehere"?
>
> Bits 15:6 of that register become bits 15:6 of the address range,
> meaning your base is just 0x500. (that isn't really stated in the
> datasheet, but that is they way those type of registers usually work,
> see regular PCI BARs for another example)
>
> Also, 0x14 would just not be an appropriate I/O base, take a look at an
> I/O port reference (i.e., ports.lst from Ralf Brown), and you will see
> that 14 is in the legacy DMA controller's I/O space. Anything less than
> 0x100 is really only for legacy stuff.
> > Would I put 64 in "asmanyasyouwant" to dump the whole 64 bytes
> >
> > of  I/O space?
>
> Yes
> > What is the pipe xxd for?
>
> When you use dd to read from /dev/port, you get out raw binary data.
> xxd turns that binary into a human-readable hex listing. (there are
> other tools to do this too, hexdump, etc)

Thanks again Tom that makes alot of sense.

Thanks - Joe

[Rudolf Marek]

Hi all,

Just a note. Isadump util form Lm-sensors can do the SIO dumps as well 
as "flat" io dumps. It can even unlock the SIO with a key :)
Supports SIO LDNs etc etc.

Rudolf