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?
已解决! 转到解答。
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.
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.
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.
_____address|_0________4________8________C A:0:00000000| 80000008 2001200b 00000000 0013ffff A:0:00000010| 0400ffff 00040028 00000000 00000000
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.