cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dm78
Adventurer
Adventurer
265 Views
Registered: ‎03-15-2012

M_AXI_HPMx_FPD not working with 32 or 64 bit data width

Hi,

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:

dm78_0-1624392071019.png

dm78_1-1624392282409.png

 

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.

Tags (2)
0 Kudos
2 Replies
dgisselq
Scholar
Scholar
229 Views
Registered: ‎05-21-2015

@dm78 ,

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.

Dan

dm78
Adventurer
Adventurer
201 Views
Registered: ‎03-15-2012

arrg,

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.

Tags (1)
0 Kudos