09-17-2019 03:02 PM
I've built the VCU TRD for my ZCU106 board: the design appears to work, and Linux boots and runs fine. I've now tried adding a very small module in the video pipeline (between MIPI core and the demosaic core), with an AXI-lite register interface. This caused a corrupt pl.dtsi, which has been fixed by a patch (see this thread).
Now that this has been fixed, I am able to compile a Petalinux image: but it now fails to boot: I get as far as:
[ 10.622228] xilinx-video amba_pl@0:vcap_csi: Entity type for entity a0250000.v_demosaic was not initialized! [ 10.634146] xilinx-demosaic a0250000.v_demosaic: Xilinx Video Demosaic Probe Successful [ 10.644577] xilinx-video amba_pl@0:vcap_csi: Entity type for entity a0270000.v_gamma_lut was not initialized! [ 10.656626] xilinx-gamma-lut a0270000.v_gamma_lut: Xilinx 8-bit Video Gamma Correction LUT registered
And that's it. I have used chipscope to examine the AXI bus to try and identify what is going on: I suspect there is an AXI read from a device that is not responding, and this is causing the hang. I have verified in u-boot that my peripheral is accessible and responds perfectly fine (using md to read from it), so I can't see how that could be the problem.
In u-boot, reading from the demosaic, csc, scaler or gamma causes the CPU to lock up: it looks like they're held in reset at that point (i.e. this looks like the same symptom). Sometime during the boot process, (presumably on driver load?), the reset is released (verified on chipscope). I have not touched this code at all (either software or hardware). The fact that it hangs around the point that those drivers are being loaded is obviously suspicious.
So, to my question: how do I go about debugging this? Reset for the video modules in the TRD comes from EMIO in the PS: where is this defined in the code and described in any documentation? Is there anything else you can think of that would cause boot to hang? Where is the order of driver load defined?
09-17-2019 10:13 PM
I have looked at resets for each of the video pipeline modules next to the MPI core (demosaic, csc, scaler and gamma): it looks like driver load releases the reset on each of those in turn. I do also see AXI transactions happening after reset is released, so I doubt that a bad AXI transaction is causing the hang.
My module has an empty driver (as generated by Vivado): can this cause the boot to hang? Is there a way to tell if this is happening?
I think I want my module to use UIO, but all the forum post suggestions I've seen don't seem to work for me: I've followed this wiki article:
I've compiled the UIO drivers into the kernel.
I've added to the kernel command line option and I see this in the (partial) boot:
Kernel command line: earlycon clk_ignore_unused uio_pdrv_genirq.of_id=generic-uio
I've added to project-spec/meta-user/resipces-bsp/device-tree/files/system-user.dtsi for my module:
compatible = "generic-uio"
How can I tell if that has stuck correctly? "generic-uio" is not there in components/plnx_workspace/device-tree/device-tree/pl.dtsi. Should I expect it to be there?
I'm using 2018.3 release if that makes any difference.
09-19-2019 06:11 PM
I have decompiled the .dtb: I see my module there, with
So it should be looking for the right driver for it. How else do I know where exactly the kernel is hanging?
@stephenm ? Any ideas?