Re: GPIO causing bus error

[Jeff Mock <jeff@mock.com>]

Well, I have a system that is pretty similar to yours.  Our boards have 
a 440GX and two Xilinx 2VP70's.  The FPGAs are loaded using slave serial 
mode (not jtag) from GPIO pins, but still pretty similar.

I haven't had any problems loading the FPGAs this way.

 From your description I can't tell when you load the FPGAs during the 
boot process.  Our approach is as follows:

A module is loaded that creates /dev/fpga. You can 'cat' a bitstream 
file to /dev/fpga and the driver will wiggle the GPIO pins appropriately 
to the load the bitstream in the FPGAs.  The script run at boot time 
will do something like:

    # zcat /etc/fpga_img.gz > /dev/fpga

At that point we load modules that create devices appropriate for the 
FPGA image and the system is off running a domain specific application. 
The process can be reversed to unload the drivers, load a new FPGA image 
and new drivers without rebooting.

One thing that comes to mind is that our GPIO pins are used for a number 
of disparate needs beyond FPGA loading.  I keep a semaphore for 
accessing the GPIO pins so that the different drivers that touch the 
GPIO pins don't step on each other.  Only one driver can touch the GPIO 
pins at a time.  Failing to do this in our application would definitely 
create occasional failures.

jeff


Wyse, Chris wrote:
> 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/>
>  
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded