440gx GPIO

440gx GPIO

[Ed Goforth]

I am struggling with a problem and I hope someone can give me some
pointers.  We have a custom board with a 440gx.  I need to drive GPIO11
low.  The best as I can tell from the docs, I need to set bit 11 of the
TCR to 1 and bit 11 of the OR to 0 to do this.  I'm using kernel
2.4.18-timesys-4.0

Here's what I've tried:

Prior to making an calls, the values of the registers are:
or      0x00101000
tcr     0x00101700
odr     0x00000000
ir      0xeffff820


(from ibm440gx.h)
#define PPC440GX_GPIO0_ADDR  0x0000000140000700


Attempt one: write the bit directly:

  volatile gpio_t *gpio;
  volatile u32 or_reg;

  gpio = (gpio_t *) ioremap_nocache(0x40000700,
                                    sizeof(gpio_t));

  or_reg = gpio->or;
  or_reg &= 0x00100000;
  gpio->or = or_reg;


Attempt two: use the accessor routine:
  extern int ibm_gpio_out(__u32 device, __u32 mask, __u32 data);

  rc = ibm_gpio_out(0, 0x00100000, 0);


With either approach, I can read the registers fine.  But as soon as I
either modify gpio->or or call ibm_gpio_out(), the board hangs hard.

Any hints would be greatly appreciated.  On-list replies are fine; I am
a subscriber.

Thanks,
Ed

Re: 440gx GPIO

[Eugene Surovegin]

On Tue, Feb 14, 2006 at 12:20:35AM -0500, Ed Goforth wrote:
> I am struggling with a problem and I hope someone can give me some
> pointers.  We have a custom board with a 440gx.  I need to drive GPIO11
> low.  The best as I can tell from the docs, I need to set bit 11 of the
> TCR to 1 and bit 11 of the OR to 0 to do this.

Check that this pin is enabled as GPIO not as a function pin 
(SDR0_PFC0 register).

Also, just to be sure that you remapped GPIO registers correctly, use 
ioremap64 with full physical address (not just low 32 bits).

-- 
Eugene

Re: 440gx GPIO

[Ed Goforth]

I posted the original from home, and didn't have the contents of the
config register.  It is
cfg     0x00103e00
Which I interpret as having bit 11 set: "1 Enable GPIO11 as GPIO11"
from the manual.

I originally tried to call ioremap64(PPC440GX_GPIO0_ADDR,) directly, but go=
t
"unresolved symbol ioremap64".  From inspection of ioremap(), the
fixup for 0x40000700 translates to 0x140000700, and I get the same
values in my code as I see from a "/proc/ocotea/gpio".

Is my approach valid?

Thanks,
Ed

On 2/14/06, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Tue, Feb 14, 2006 at 12:20:35AM -0500, Ed Goforth wrote:
> > I am struggling with a problem and I hope someone can give me some
> > pointers.  We have a custom board with a 440gx.  I need to drive GPIO11
> > low.  The best as I can tell from the docs, I need to set bit 11 of the
> > TCR to 1 and bit 11 of the OR to 0 to do this.
>
> Check that this pin is enabled as GPIO not as a function pin
> (SDR0_PFC0 register).
>
> Also, just to be sure that you remapped GPIO registers correctly, use
> ioremap64 with full physical address (not just low 32 bits).
>
> --
> Eugene
>
>

Re: 440gx GPIO

[Eugene Surovegin]

On Tue, Feb 14, 2006 at 08:48:56AM -0500, Ed Goforth wrote:
> I posted the original from home, and didn't have the contents of the
> config register.  It is
> cfg     0x00103e00
> Which I interpret as having bit 11 set: "1 Enable GPIO11 as GPIO11"
> from the manual.
> 
> I originally tried to call ioremap64(PPC440GX_GPIO0_ADDR,) directly, but got
> "unresolved symbol ioremap64".  From inspection of ioremap(), the
> fixup for 0x40000700 translates to 0x140000700, and I get the same
> values in my code as I see from a "/proc/ocotea/gpio".
> 
> Is my approach valid?

It seems to be.

Try writing the same GPIO output register value as you read from it 
(without clearing bit 11). Also, try changing some other GPIO bit 
(e.g. one which is not connected in your design). Maybe board hangs 
exactly because you set GPIO bit 11 low :).

Also, connect scope to that GPIO pin and see what is really going on. 

-- 
Eugene

Re: 440gx GPIO

[Ed Goforth]

On 2/14/06, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Tue, Feb 14, 2006 at 08:48:56AM -0500, Ed Goforth wrote:
> > I posted the original from home, and didn't have the contents of the
> > config register.  It is
> > cfg     0x00103e00
> > Which I interpret as having bit 11 set: "1 Enable GPIO11 as GPIO11"
> > from the manual.
> >
> > I originally tried to call ioremap64(PPC440GX_GPIO0_ADDR,) directly, bu=
t got
> > "unresolved symbol ioremap64".  From inspection of ioremap(), the
> > fixup for 0x40000700 translates to 0x140000700, and I get the same
> > values in my code as I see from a "/proc/ocotea/gpio".
> >
> > Is my approach valid?
>
> It seems to be.

At least I've got that. :)

>
> Try writing the same GPIO output register value as you read from it
> (without clearing bit 11). Also, try changing some other GPIO bit
> (e.g. one which is not connected in your design). Maybe board hangs
> exactly because you set GPIO bit 11 low :).

I have successfully written back the same values that were read from
it.  I will try your suggestion about fiddling with other GPIO bits
that we aren't (supposed to be) using.

>
> Also, connect scope to that GPIO pin and see what is really going on.
>
> --
> Eugene
>

Thanks,
Ed

Re: 440gx GPIO

[Ed Goforth]

On 2/14/06, Ed Goforth <egoforth@gmail.com> wrote:
> On 2/14/06, Eugene Surovegin <ebs@ebshome.net> wrote:
> > On Tue, Feb 14, 2006 at 08:48:56AM -0500, Ed Goforth wrote:
> > > I posted the original from home, and didn't have the contents of the
> > > config register.  It is
> > > cfg     0x00103e00
> > > Which I interpret as having bit 11 set: "1 Enable GPIO11 as GPIO11"
> > > from the manual.
> > >
> > > I originally tried to call ioremap64(PPC440GX_GPIO0_ADDR,) directly, =
but got
> > > "unresolved symbol ioremap64".  From inspection of ioremap(), the
> > > fixup for 0x40000700 translates to 0x140000700, and I get the same
> > > values in my code as I see from a "/proc/ocotea/gpio".
> > >
> > > Is my approach valid?
> >
> > It seems to be.
>
> At least I've got that. :)
>
> >
> > Try writing the same GPIO output register value as you read from it
> > (without clearing bit 11). Also, try changing some other GPIO bit
> > (e.g. one which is not connected in your design). Maybe board hangs
> > exactly because you set GPIO bit 11 low :).
>
> I have successfully written back the same values that were read from
> it.  I will try your suggestion about fiddling with other GPIO bits
> that we aren't (supposed to be) using.

Well, I was able to manipulate GPIO9, GPIO10 and GPIO12.  It's time to
turn it over to the hardware people.


> >
> > Also, connect scope to that GPIO pin and see what is really going on.
> >
> > --
> > Eugene
> >

Thanks for your feedback & suggestions.

Ed

Re: 440gx GPIO

[Ed Goforth]

On 2/14/06, Eugene Surovegin <ebs@ebshome.net> wrote:
>
> Try writing the same GPIO output register value as you read from it
> (without clearing bit 11). Also, try changing some other GPIO bit
> (e.g. one which is not connected in your design). Maybe board hangs
> exactly because you set GPIO bit 11 low :).

Bingo!  The board wasn't actually hanging.  When we set GPIO11 low, it
is supposed to reset our on-board FPGAs.  One of the FPGAs controls a
TX disable signal.  And the (current) default on a reset is to leave
the TX disable low, hence no network after a FPGA reset.  Doesn't work
well with a NFS root :)


>
> Also, connect scope to that GPIO pin and see what is really going on.
>
> --
> Eugene

Re: 440gx GPIO

[Ed Goforth]

On 2/14/06, Howard, Marc <Marc.Howard@kla-tencor.com> wrote:
>
> > -----Original Message-----
> > From:
> > linuxppc-embedded-bounces+marc.howard=3Dkla-tencor.com@ozlabs.or
> > g
> > [mailto:linuxppc-embedded-bounces+marc.howard=3Dkla-tencor.com@o
> > zlabs.org] On Behalf Of Ed Goforth
> > Sent: Tuesday, February 14, 2006 1:47 PM
> > To: linuxppc-embedded@ozlabs.org
> > Subject: Re: 440gx GPIO
> > .....
> > Well, I was able to manipulate GPIO9, GPIO10 and GPIO12.  It's time to
> > turn it over to the hardware people.
> >
>
> It's AMCC's fault.  They aren't listing the latest errata on their
> website.  I downloaded their rev 3.1 ver 1.03 errata last August.
> However if you look today you get the rev 3.1 ver 1.02 release.
>

Do you recall if this errata is only against rev 3.1 chips?  We are
currently using rev 2.1 (PVR ending in 892), but will be doing some
hardware refreshes sometime.

>
> Marc

Thanks,
Ed

RE: 440gx GPIO

[Howard, Marc]

> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+marc.howard=3Dkla-tencor.com@ozlabs.or
> g=20
> [mailto:linuxppc-embedded-bounces+marc.howard=3Dkla-tencor.com@o
> zlabs.org] On Behalf Of Ed Goforth
> Sent: Tuesday, February 14, 2006 1:47 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: 440gx GPIO
> .....=20
> Well, I was able to manipulate GPIO9, GPIO10 and GPIO12.  It's time to
> turn it over to the hardware people.
>=20

It's AMCC's fault.  They aren't listing the latest errata on their
website.  I downloaded their rev 3.1 ver 1.03 errata last August.
However if you look today you get the rev 3.1 ver 1.02 release.

In the 1.03 errata there is the following bug listed:

*************

GPIO_1:SDR0_PFC[G11E] has no effect.
Category: 6
Overview:
The SDR0_PFC[G11E] bit does not control GPIO11, thus meaning that GPIO11
is always active (unless EMAC group 4 is selected and both GPHYs are in
modes 0 or 1).
  =20
Impact:No impact.
Workaround:
None.

**************

Thus the PFC bit doesn't do anything.  If you're using group 4 "modes 0
or 1" (which mode field are they talking about here?) you're screwed,
you can't use GPIO11.

Curious how they think this has "No impact".  If you're running RGMII
you don't need that pin and it should be available for GPIO11 but
apparently it isn't.

Marc