cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
pno21
Observer
Observer
568 Views
Registered: ‎11-07-2019

arm-smmu: Unexpected global fault when encoding via VCU

Currently, we have a problem with the VCU module on a XILINX ZYNQ Ultrascale+ XCZU4EV.
This chip is part of a custom board design that is driven by a Linux 5.3 mainline kernel.
We used the vivado toolchain 2018.3 and the reference design in PG252 May 22, 2019 to implement the VCU design.

As the 5.3 mainline VCU driver does not correctly reset the VCU at probe time, we backported the xlnx_vcu driver (we used the tag xilinx-v2018.3) from (https://github.com/Xilinx/linux-xlnx).
We made some small modifications to the driver, to ensure that it compiles with Linux kernel 5.3 (replace replace clk_{readl,writel} with {readl,writel}, updated divider_recalc_rate()-call, removed CLK_IS_BASIC) as optional module.
Additionally, we added a delay between the calls `xvcu_pll_enable_disable()` and `readl_poll_timeout()` in `drivers/soc/xilinx/xlnx_vcu_clk.c` because otherwise, the kernel module crashed sometimes.
See the attached patches for more informations about the modifications.

Additionally, we compiled the allegro out-of-tree kernel module (we used the tag xilinx-v2018.3) from (https://github.com/Xilinx/vcu-modules) as optional module.
We made some small modifications to the module, to ensure that it compiles with Linux kernel 5.3 (by cherry-picking the commit "Support 4.19 dmabuf api change": 61e942e6db902e045571aa30e1efd8b181da2361 and removed the macro `DMA_MEMORY_EXCLUSIVE` in the call `dma_alloc_coherent()` in `common/al_codec.c`).
Also the Macro `AL5_DEBUG` in `include/al_traces.h` was set to `1`.
See the attached patches for mor information about the modifications.

Furthermore, we compiled the kernel with 1024MB of CMA:

# cat /proc/meminfo | grep Cma
CmaTotal: 1048576 kB
CmaFree: 940624 kB

With the previous modifications both modules compiled successfully and could be probed successfully by calling `modprobe xlnx_vcu_core`.

# lsmod
Module Size Used by
al5d 16384 0
al5e 20480 0
allegro 36864 2 al5e,al5d
xlnx_vcu_clk 16384 0
xlnx_vcu_core 16384 4
xlnx_vcu 16384 1 allegro

Than we tried to set the QoS and ISSUE settings accordingly (as mentioned on page 130, PG252 May 22, 2019):
Since we used S_AXI_HP2 on M_AXI_DEC0 and M_AXI_ENC0 and S_AXI_HP1 on M_AXI_DEC1, M_AXI_ENC1 and M_AXI_MCU (both connected via AXI-Interconnect), we needed to update the addresses of page 130.
Note that all these commands were executed before the vcu kernel modules were loaded.

# devmem 0xFD3A0008 w 0x3 # Set the S_AXI_HP2_FPD RDQoS register to LOW PRIORITY
# devmem 0xFD3A001C w 0x3 # Set the S_AXI_HP2_FPD WRQoS register to LOW PRIORITY
# devmem 0xFD390008 w 0x3 # Set the S_AXI_HP1_FPD RDQoS register to LOW PRIORITY
# devmem 0xFD39001C w 0x3 # Set the S_AXI_HP1_FPD WRQoS register to LOW PRIORITY
# devmem 0xFD3A0004 w 0xF # Set the S_AXI_HP2_FPD RDISSUE register to allow 16 commands
# devmem 0xFD3A0018 w 0xF # Set the S_AXI_HP2_FPD WRISSUE register to allow 16 commands
# devmem 0xFD390004 w 0xF # Set the S_AXI_HP1_FPD RDISSUE register to allow 16 commands
# devmem 0xFD390018 w 0xF # Set the S_AXI_HP1_FPD WRISSUE register to allow 16 commands

To test the vcu, we tried to execute the command `ctrlsw_encoder` as mentioned on page 244, PG252 May 22, 2019.
We used for this command the configuration file `test/config/encode_example.cfg` and the video `test/config/simple.yuv` both from the `https://github.com/xilinx/vcu-ctrl-sw.git` repo (tag xilinx-v2018.3):

# mkdir -p test/config
# cp /uploads/encode_example.cfg test/config/
# cp /uploads/simple.yuv test/config/
# ctrlsw_encoder -cfg test/config/encode_example.cfg

But when we execute the ctrlsw_encoder tool, it hangs after encoding the third frame with the following output:

Allegro DVT2 - AVC/HEVC Encoder Reference Software v1.0.41 - Copyright (C) 2018
Confidential material
> 0
> 1
> 2

And `dmesg` outputs a problem with the arm-smmu:

[ 68.930987] VCU PLL: enable
[ 68.950627] xilinx-vcu xilinx-vcu: xvcu_probe: Probed successfully
[ 68.982511] allegro: loading out-of-tree module taints kernel.
[ 68.990939] al5e a0100000.al5e: icache phy is at 00000000f71dbcac
[ 68.997504] al5e a0100000.al5e: firmware size is 1fa10
[ 69.002641] al5e a0100000.al5e: bootloader firmware size is 4588
[ 69.011193] Got irq from Mcu
[ 69.024534] al5e a0100000.al5e: l2 prefetch size:0 (bits), l2 color bitdepth:10
[ 69.031913] Got irq from Mcu
[ 69.043837] al5d a0120000.al5d: icache phy is at 0000000074250da7
[ 69.050199] al5d a0120000.al5d: firmware size is 8fb4
[ 69.055255] al5d a0120000.al5d: bootloader firmware size is 34c0
[ 69.063217] Got irq from Mcu
[ 69.076425] al5d a0120000.al5d: l2 prefetch size:0 (bits), l2 color bitdepth:10
[ 69.083812] Got irq from Mcu

[ 101.856584] ioctl AL_MCU_CONFIG_CHANNEL from user 1
[ 101.863474] Got irq from Mcu
[ 101.868423] end AL_MCU_CONFIG_CHANNEL for user 1
[ 101.874091] ioctl AL_MCU_WAIT_FOR_STATUS from user 1
[ 101.880702] ioctl AL_MCU_ENCODE_ONE_FRM from user 1
[ 101.886544] end AL_MCU_ENCODE_ONE_FRM for user 1
[ 101.887222] arm-smmu fd800000.smmu: Unexpected global fault, this could be serious
[ 101.892206] ioctl AL_MCU_ENCODE_ONE_FRM from user 1
[ 101.899660] arm-smmu fd800000.smmu: GFSR 0x80000002, GFSYNR0 0x00000000, GFSYNR1 0x000012cc, GFSYNR2 0x00000000
[ 101.915673] end AL_MCU_ENCODE_ONE_FRM for user 1
[ 101.921330] ioctl AL_MCU_ENCODE_ONE_FRM from user 1
[ 101.927178] end AL_MCU_ENCODE_ONE_FRM for user 1


In summary, we execute the following commands after boot and get the previous error message.

devmem 0xFD3A0008 w 0x3
devmem 0xFD3A001C w 0x3
devmem 0xFD390008 w 0x3
devmem 0xFD39001C w 0x3
devmem 0xFD3A0004 w 0xF
devmem 0xFD3A0018 w 0xF
devmem 0xFD390004 w 0xF
devmem 0xFD390018 w 0xF
modprobe xlnx_vcu_core
mkdir -p test/config
cp /uploads/encode_example.cfg test/config/
cp /uploads/simple.yuv test/config/
ctrlsw_encoder -cfg test/config/encode_example.cfg

 

What can we do to get the VCU working?

Tags (2)
0 Kudos
1 Reply
florentw
Moderator
Moderator
462 Views
Registered: ‎11-09-2015

Hi @pno21 

Can you reproduce this issue if you build the systems with petalinux without any modification to the driver?

Kindly note that Xilinx is not supporting updates to the drivers.

Regards,


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos