32 bit IFC access of FPGA via GASIC mode

[hemwant]

We are having a customized board with T1022 processor. We have connected FPGA on IFC bus with Chip select 1 of processor , and had done respective settings of GASIC mode in include/configs/T104xRDB.h file along with configuration for board/freescale/t104xrdb/law.c file. Both the files are attached .

When we are accessing the CPLD from u-boot , the u-boot generates an error suggesting to reset the board.

We have also tried to access CPLD in linux, there also the read command throws kernel panic exception.

 When we are using logic analyzer inside our FPGA then our state machine is working fine returning the correct data and ready signal at desired time as shown in the GASIC timing diagram in Reference Manual.

When using GASIC write cycle, processor is not driving low on RW signal as observed from Logic Analyzer built inside FPGA.

I am attaching the both log of kernel and uboot crash along with T104xRDB.h (config file) and law.c (Local Access Window file).

[hemwant]

ufedor‌ Please respond to the above query.

[ufedor]

You wrote:

> One additional information the read happens successfully for first time,

> every time we power on the board but u-boot gives crash log on subsequent reads.

What happens on the IFC during "subsequent" read?

[hemwant · Accepted solution]

ufedor‌ the problem is now resolved.  We are able to access FPGA via GASIC mode.

The problem was we had disabled parity error in  IFC_CSOR1_GPCM, which disables parity checking on received data but parity checking on address is always enabled. Now we have handled that case in our cpld hence the GASIC mode is working now.

I understand there is an option to disable parity checking using bit 2 (PAR_EN) of IFC_CSORn_GPCM register only for data and not for address.

If there is a parity error on address entire , shouldn't the core throw an error instead of crashing. The basic point of parity is to isolate the error so that a wrong cycle is not completed. Is there any setting we are missing to circumvent this ???

[ufedor]

Uncorrectable error during read transaction is reported to the core as error report machine check.

Please check how this error interrupt is processed in your system.

Refer to the e5500 Core Reference Manual, 4.9.3.1 General Machine Check, Error Report, and NMI Mechanism.

[hemwant]

Thanks ufedor‌ for the support. Your inputs helped us to debug and solve the problem faced by us.

[hemwant]

As per the hardware team this is the trace of failing read transaction.

What is the difference between traces of the transactions "md.w 0xffdf0000 1" and "md.w 0xffdf0050 1"?

-> No difference.  they are two different addresses of FPGA .

One additional information the read happens successfully for first time, every time we power on the board but u-boot gives crash log on subsequent reads.

=> md.l 0xffdf0000 1
ffdf0000: 05050d0d                               ....
=> md.l 0xffdf0000 1
ffdf0000:Bad trap at PC: 7ff694e0, SR: 9402fb16, vector=e00
NIP: 7FF694E0 XER: 00000000 LR: 7FEF0B6C REGS: 7faedb30 TRAP: 0e00 DAR: 00000000
MSR: 9402fb16 EE: 1 PR: 1 FP: 1 ME: 1 IR/DR: 01

GPR00: 7FF54F90 7FAEDC20 7FAEDEE8 00000009 0000003A 7FAEDAC7 00000020 7FAEDACF
GPR08: 00000000 00000020 FFDF0000 7FAEDC20 7FF057A8 28C12C0B 00000001 00000000
GPR16: 00000004 7FF705C8 00000000 0000002E FFFFFF97 7FF5CC70 00000000 7FF694E0
GPR24: 7FF62D8C 00000009 00000008 FFDF0000 FFDF0000 00000001 7FF752C8 00000004
Call backtrace:
7FF54F90 7FF057D0 7FF1A7C8 7FEFC360 7FEFCB20 7FEFCBD0 7FF191B4
7FEFA440 7FEFD474 7FF4E3D4 7FEFD848 7FEF0F50
Exception in kernel pc 7ff694e0 signal 0
### ERROR ### Please RESET the board ###

[ufedor]

In the provided T104xRDB.h:

> #define CONFIG_SYS_CSOR1        CSOR_GPCM_GPMODE_ASIC

Ensure that the FPGA asserts RDY_L within 256 cycles of IFC module input clocks.

[hemwant]

FPGA is asserting RDY_L within 256 cycles of IFC module clocks.

Still we are facing the same issue.

[ufedor]

Please provide a digital scope or logic analyzer trace corresponding for the failing read transaction.

[hemwant]

The waveform for CS and RDY_L is attached. The green waveform is for CS and the blue
waveform is for RDY_L. There are four IFC clock cycles between them (IFC running at 18MHz,
55ns clock cycle). The processor is also de-asserting CS indicating it has completed the
transaction before timeout.

[ufedor]

Please confirm that this is the trace for the failing read transaction.

What is the difference between traces of the transactions "md.w 0xffdf0000 1" and "md.w 0xffdf0050 1"?