<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3243" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>Hi Chris,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>I'm going to look at this problem from the FPGA hardware
level because I used to work for one of the FPGA companies.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>I'm not familiar with your PPC440GX board, so some of
my suggestions may be difficult to implement or totally unreasonable, especially
if it requires soldering to an FPGA in a ball grid array or extermely fine pitch
pins.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>(1) You should capture the configuration sequence on FPGA's
JTAG pins using a logic analyzer in functional mode.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>In functional mode, you can capture an extermely long
sequence of configuration events. Also, in the past, I've used this mode
and found that when the FPGA doesn't configure, usually there are too few or too
many clocks on the TCK line.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>(2) Sometimes, rarely, the FPGA design itself can cause a
boot up problem.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>Instead of using the real design, send a 'blank' design
with no logic implemented at all. If this works, then it's the FPGA design
itself that is causing the boot problem.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>(3) When the boot process happens, what is the power
sequence of the FPGA?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>Most FPGA's out there like a nice smooth power profile that
ramps up quickly. Check and see if the profile is quick and smooth vs.
spikey and erratic. Also, sometimes configuration data gets sent before
the FPGA is ready to receive data. Try delaying the sending of
configuration data by a millisecond or so.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>(4) Manually delay the configuration of the
FPGA.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>In other words, let the system boot, but modify the code to
allow the FPGA to configure only after a button is pushed. In theory, if
the FPGA power has properply initialized the FPGA, you could keep the system
this way forever until a 'button' is pushed to configure the FPGA. if this
works, this tends to imply that there is a timing issue. If it doesn't
work, it's possible that the FPGA's JTAG tap is actually in a state that won't
allow configuration to complete, such as non shift-dr or non shift-ir
state.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>(5) If your FPGA is using one of the SVF-based software
configuration methods via JTAG, make sure you are using the latest SVF player
and latest software for generating the FPGA bitstream. The configuration
method may have changed. The FPGA silicon you are using may be newer than
the configuration algorithm that has been implemented.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>I hope this helps!</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>Regards,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>Bernie Elayda</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=060240916-21122007><FONT face=Arial
color=#0000ff size=2>the ex-X guy</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> owner-techfield@windriver.com
[mailto:owner-techfield@windriver.com] <B>On Behalf Of </B>Wyse,
Chris<BR><B>Sent:</B> Friday, December 21, 2007 7:55 AM<BR><B>To:</B>
linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org; +techfield;
+linux-embedded; +linux-eng; linux-kernel; Wessel, Jason;
support@amcc.com<BR><B>Cc:</B> Touron, Emmanuel; Read, Tricia; Ayer, Charles;
Slimm, Rob<BR><B>Subject:</B> [techfield] GPIO causing bus
error<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial
size=2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial size=2>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. </FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial size=2>If I issue a soft
reset of the GPIO subsystem, I can read and write to the GPIO lines
again.</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial size=2>Here are some
relevant register values after the error:</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=201052213-21122007><FONT face="Courier New" size=2>SDR0_PFC0
: 0x083FFE00</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face="Courier New"
size=2>POB0_BESR0: 0x00008400</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face="Courier New"
size=2>POB0_BEARH: 0x00000001</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face="Courier New"
size=2>POB0_BEARL: 0x40000701</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face="Courier New"
size=2>GPIO0_OR
: 0x000400C0</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face="Courier New" size=2>GPIO0_TCR
: 0x00278AE0</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face="Courier New" size=2>GPIO0_ODR
: 0x00000000</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face="Courier New"
size=2>GPIO0_IR : 0x00000000</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=201052213-21122007><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV align=left><FONT size=2>Chris Wyse</FONT></DIV>
<DIV align=left><FONT size=2>Senior Member of Technical Staff</FONT></DIV>
<DIV align=left><FONT size=2>Embedded Technologies</FONT></DIV>
<DIV align=left><FONT size=2>860-978-0849 cell/office</FONT></DIV>
<DIV align=left><FONT size=2>413-778-9101 fax</FONT></DIV>
<DIV align=left><FONT size=2><A
href="http://www.windriver.com/">http://www.windriver.com</A></FONT></DIV>
<DIV align=left><FONT size=2></FONT> </DIV>
<DIV> </DIV></BODY></HTML>