GPIO causing bus error

[Wyse, Chris]

Hi,
 
I'm having trouble with an unusual problem.  I'm working on relatively
new hardware, so it's possible that there could be a hardware issue
involved. 
 
I have an FPGA on my PPC440GX board that gets loaded via JTAG during the
kernel boot process (Linux 2.6.10).  It uses the 440GX GPIO lines to
send the necessary JTAG commands to the FPGA to perform the initial
load.  This process is USUALLY functional, but on some of the boards
(which we produce), the GPIO write fails with a bus error.  On the
boards that fail, it only occurs after a cold boot, and only if the
board has been powered off for a few minutes.  A quick hard reboot will
not generate the problem.  When I issue the failing write to the GPIO
lines, some of the SDRAM gets corrupted.  I don't appear to be taking
any interrupts that might have corrupted the RAM.
 
I've checked the TLB entries, and it maps correctly to the PPC register
area.  Additionally, I can read and write to other registers using the
same TLB mapping WITHOUT any error.  I can also READ the GPIO lines
without an error - the error is only on the write.   I've checked the
SDR0_PFC0 bits to make sure everything is set properly (it is).  The bus
error indicates "PLB Timeout Error Status Master 2, Master 2 slave error
occurred" (Master 2 is the write-only data cache unit (DCU)) and "Write
Error Interrupt Master 2, Write error detected - master 2 interrupt
request is active".  I'm not sure why there would be any error in the
DCU, since the region I'm writing to is cache inhibited and guarded.
 
If I issue a soft reset of the GPIO subsystem, I can read and write to
the GPIO lines again.
 
The error does not occur on the first write to the GPIO.  I go through
the failing routine several times before it fails.  However, when it
fails, it consistently fails at the same spot, after the same number of
passes through the code.
 
I'm using RGMII ethernet on EMAC2 (Group 4), but the GPIO lines that I'm
using are not the Trace/GPIO lines (26-31) so I believe that they should
work fine (and they usually do).  Also, the errata mentions that
SDR0_PFC0[G11E] has no effect - but I'm not using GPIO 11 anyway.
 
Here are some relevant register values after the error:
 
SDR0_PFC0 :     0x083FFE00
POB0_BESR0:     0x00008400
POB0_BEARH:     0x00000001
POB0_BEARL:     0x40000701
GPIO0_OR  :     0x000400C0
GPIO0_TCR :     0x00278AE0
GPIO0_ODR :     0x00000000
GPIO0_IR  :     0x00000000
 
I've attached two log files, that contain most of the 440 registers, one
for before the error and one after.  In the log files, the bus error has
been cleared, so use the values shown above.
 
I'm looking for some suggestions on what to try to debug/resolve this
issue.  I'm open to both hardware and software based suggestions.  Any
help would be greatly appreciated.
 
 
Chris Wyse
Senior Member of Technical Staff
Embedded Technologies
860-978-0849 cell/office
413-778-9101 fax
http://www.windriver.com <http://www.windriver.com/> 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20071221/0f72ae85/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pre_error.log
Type: application/octet-stream
Size: 27172 bytes
Desc: pre_error.log
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20071221/0f72ae85/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: post_error.log
Type: application/octet-stream
Size: 27172 bytes
Desc: post_error.log
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20071221/0f72ae85/attachment-0003.obj