06-22-2021 01:08 PM
I had trouble connecting axi4lite peripherie at one of the M_AXI_HPM0_FPD interfaces of a xczu7ev. As axi4lite has 32 bit data width, I configured the interface width to 32 bit (I'm not using a axi data width downsizer in the PL). But I could not read most of the register, only these, which are 16 byte aligned. Same with the M_AXI_HPM1_FPD interface. Using the M_AXI_HPM0_LPD with 32 bit, everything work perfectly.
It sounds like the AR 66295, but this should be solved in Vivado 2017.1 and I'm using 2020.2.
Also the setup seems to be right (psu_init.c):
17706 /* 17707 * AFIFM INTERFACE WIDTH 17708 */ 17709 /* 17710 * Register : afi_fs @ 0XFD615000 17711 17712 * Select the 32/64/128-bit data width selection for the Slave 0 00: 32-bit 17713 * AXI data width (default) 01: 64-bit AXI data width 10: 128-bit AXI data 17714 * width 11: reserved 17715 * PSU_FPD_SLCR_AFI_FS_DW_SS0_SEL 0x0 17716 17717 * afi fs SLCR control register. This register is static and should not be 17718 * modified during operation. 17719 * (OFFSET, MASK, VALUE) (0XFD615000, 0x00000300U ,0x00000000U) 17720 */ 17721 PSU_Mask_Write(FPD_SLCR_AFI_FS_OFFSET, 0x00000300U, 0x00000000U);
The issue remains when connecting a simple BRAM to the port:
Using Linux devmem, i got:
# devmem 0xa0000000 32 0xaa # devmem 0xa0000000 0x000000AA # devmem 0xa0000004 32 0xbb # devmem 0xa0000008 32 0xcc # devmem 0xa000000C 32 0xdd # devmem 0xa0000010 32 0xee # devmem 0xa0000010 0x000000EE # devmem 0xa000000c 0x00000000 # devmem 0xa0000008 0x00000000 # devmem 0xa0000004 0x00000000 # devmem 0xa0000000 0x000000AA #
Checking with an ILA, the data on the AXI interface are correct transfered to the MPSoC.
Is this a regression bug? Or do I miss something?
As a workaround: Using 128 bit and let an axi-interconnect do the down-sizer work, everything seems to be working.
06-22-2021 08:02 PM
There seems to be an ongoing issue between PS configuration and the PL. This is not the first issue where this has come up. From reading other reports alone, it seems related to the PS being configured for one bus width and the PL expecting another. The 128bit bus width is only one example of this missed encoding issue.
I've been told that rebuilding the project should help, but I'm also aware that some individuals have tried rebuilding everything from scratch and it hasn't fixed the problem.
06-22-2021 10:21 PM
I got the root cause: It's me. Although, the whole build process, the creation of the boot files and the uploading to the target/sdcard is scripted, the system was still not "up-to-date". On the sdcard, everything is updated, but the target boots from qspi first (fsbl, atf, pmu, uboot) and then, the uboot loads the remaining from sdcard.
In short: I updated the qspi too and now the other data widths works too.