LS1021A IFC Interface Aborts During Read

[cpyocum]

I am working on a custom LS1021A board. We are currently booting U-Boot and Linux from flash on IFC CS0 with no issues. We are attempting to set up an FPGA on CS1 and expose a section of memory to the ARM processor using the IFC bus. Here's the U-Boot configuration:

/* ARRIA */
#define CONFIG_SYS_ARRIA_BASE   0x7c000000
#define ARRIA_BASE_PHYS         CONFIG_SYS_ARRIA_BASE

#define CONFIG_SYS_ARRIA_CSPR_EXT       (0x0)
#define CONFIG_SYS_ARRIA_CSPR       (CSPR_PHYS_ADDR(ARRIA_BASE_PHYS) | \
                                        CSPR_PORT_SIZE_16 | \
                                        CSPR_MSEL_GPCM | \
                                        CSPR_V)
#define CONFIG_SYS_ARRIA_AMASK          IFC_AMASK(32 * 1024 * 1024)
#define CONFIG_SYS_ARRIA_CSOR       (CSOR_GPCM_ADM_SHIFT(4) | \
                                        CSOR_GPCM_GPMODE_ASIC | \
                                        CSOR_GPCM_GPTO(256) | \
                                        CSOR_GPCM_GAPERRD(1) | \
                                        CSOR_GPCM_TRHZ_20)
#define CONFIG_SYS_ARRIA_FTIM0      (FTIM0_GPCM_TACSE(0x1) | \
                                        FTIM0_GPCM_TEADC(0x1) | \
                                        FTIM0_GPCM_TEAHC(0xff))
#define CONFIG_SYS_ARRIA_FTIM1      (FTIM1_GPCM_TACO(0x1) | \
                                        FTIM1_GPCM_TRAD(0x21))
#define CONFIG_SYS_ARRIA_FTIM2      (FTIM2_GPCM_TCS(0x1) | \
                                        FTIM2_GPCM_TCH(0x1) | \
                                        FTIM2_GPCM_TWP(0x21))
#define CONFIG_SYS_ARRIA_FTIM3      FTIM3_NAND_TWW(0x3)
#define CONFIG_SYS_CSPR1_EXT        CONFIG_SYS_ARRIA_CSPR_EXT
#define CONFIG_SYS_CSPR1            CONFIG_SYS_ARRIA_CSPR
#define CONFIG_SYS_AMASK1           CONFIG_SYS_ARRIA_AMASK
#define CONFIG_SYS_CSOR1            CONFIG_SYS_ARRIA_CSOR
#define CONFIG_SYS_CS1_FTIM0        CONFIG_SYS_ARRIA_FTIM0
#define CONFIG_SYS_CS1_FTIM1        CONFIG_SYS_ARRIA_FTIM1
#define CONFIG_SYS_CS1_FTIM2        CONFIG_SYS_ARRIA_FTIM2
#define CONFIG_SYS_CS1_FTIM3        CONFIG_SYS_ARRIA_FTIM3‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

On the FPGA side of things, everything looks perfect, exactly as detailed in Section 23.7.2 of the LS1021ARM reference manual. In Linux, the write appears to work, but the read generates the following:

Nov 12 19:56:04 ls1021atwr user.alert kernel: Unhandled fault: synchronous external abort (0x1210) at 0x76ff6080
Nov 12 19:56:04 ls1021atwr user.alert kernel: pgd = be565900
Nov 12 19:56:04 ls1021atwr user.alert kernel: [76ff6080] *pgd=bd6a0003, *pmd=bd671003, *pte=56000007c000fc3‍‍‍‍‍‍

I've been writing 0xfeedface to 0x7c000080, but using an address in the space generates a similar error. Is there a misconfigured signal on the IFC interface that could be generating this type of abort?

[cpyocum · Accepted solution]

It appears that the bus error was caused by not driving PERR_B. Once we set IFC_PERR_L pin high, the bus error went away. This is confusing since we disabled the parity checking in the configuration registers. The pin had not been set since parity was not planned for use, but driving it low didn't change anything and driving it high fixed the abort/bus error.

Now that I can read without a bus error, I am simply getting the lower 16-bits of the address back as the data values. The output of the signal tap has not changed, and shows the AD bus moving to the first 16-bits of data before RDY_B is asserted, so I'm not sure why this is.

[cpyocum]

Here are the signal taps of the write and read. They both appear to be within spec, but the read triggers a synchronous external abort in Linux. This is the write:

And this is the read:

The write includes the decoded data inside the FPGA, but the read doesn't. However, you can see that it's outputting the same values to the AD lines as came in during the write.

[ufedor]

Please provide raw memory dump of the CCSR area containing involved IFC registers after initialization.

Example of the raw memory dump:

_____address|_0________4________8________C A:0:00000000| 80000008 2001200b 00000000 0013ffff A:0:00000010| 0400ffff 00040028 00000000 00000000

[cpyocum]

Here is my U-Boot print of the IFC registers:

CSPR1:0x7C000105        AMASK1:0xFE000000       CSOR1:0x80008010
IFC_FTIM0:0x10010001
IFC_FTIM1:0x01000100
IFC_FTIM2:0x01040001
IFC_FTIM3:0x04000000‍‍‍‍‍

Which matches manually reading them from memory in Linux:

CSPR_EXT and CSPR:
01530018: 00000000
0153001c: 7c000105

AMASK
015300ac: fe000000

CSOR and CSOR_EXT
0153013c: 80008010
01530140: 00000000

FTIM0-3:
015301f0: 10010001
015301f4: 01000100
015301f8: 01040001
015301fc: 04000000

IFC_GPCM_EVTER_STAT
01531800: 00000000
01531804: 00000000
01531808: 00000000
0153180c: 05400000
01531810: 00000000
01531814: 00000000
01531818: 00000000
0153181c: 00000000
01531820: 00000000
01531824: 00000000
01531828: 00000000
0153182c: 00000000
01531830: 00000000‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

All of the FTIMs don't seem to apply to GASIC, so I've set them to 1 for each field. I didn't mention it in the original post, but the GPCM_EVTER_STAT registers don't change after the failed read. It will signal a parity error, even though I've disabled it in the CSOR, but masking off that bit in 153180c will prevent that and no error will be signaled in that case.

While checking that lead, I noticed that hardware does not ever to seem the SOFT_RST_ALL bit in the IFC GCR, but the reference manual states

If this bit is set, hardware will clear it once reset operation is completed. Software should poll this bit to get
cleared before initiating any new transaction.

Could this be an indication that something else is amiss with IFC? I'm running Linux from a ramdisk, and it is just the flash chip and FPGA on the IFC bus, so nothing else should be using IFC.