From: Ed Goforth <hidden> Date: 2006-02-14 05:30:44
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
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
From: Ed Goforth <hidden> Date: 2006-02-14 13:48:58
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 [off-list ref] wrote:
On Tue, Feb 14, 2006 at 12:20:35AM -0500, Ed Goforth wrote:
quoted
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
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
From: Ed Goforth <hidden> Date: 2006-02-14 17:10:37
On 2/14/06, Eugene Surovegin [off-list ref] wrote:
On Tue, Feb 14, 2006 at 08:48:56AM -0500, Ed Goforth wrote:
quoted
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
quoted
"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
From: Ed Goforth <hidden> Date: 2006-02-14 21:47:15
On 2/14/06, Ed Goforth [off-list ref] wrote:
On 2/14/06, Eugene Surovegin [off-list ref] wrote:
quoted
On Tue, Feb 14, 2006 at 08:48:56AM -0500, Ed Goforth wrote:
quoted
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
quoted
quoted
"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. :)
quoted
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.
quoted
Also, connect scope to that GPIO pin and see what is really going on.
--
Eugene
From: Ed Goforth <hidden> Date: 2006-02-20 17:20:34
On 2/14/06, Eugene Surovegin [off-list ref] 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