Actions
Forum Thread Details
  • State Verified Answer
  • Replies 2 replies
  • Subscribers 328 subscribers
  • Views 348 views
  • Users 0 members are here
Related

Loading bitmap after boot with Zynq MMP bsp and petalinux?

Former Member

I would like to boot petalinux on my Zynq MMP 7z045 without a bitmap and then program the bitmap at a later time via the /dev/xdevcfg dev node.  I had this working on a MicroZed 7z020 board, but I now need more fabric.  I was hoping this just meant I would move up to the 7z045.

The problem I have now is that it's hanging during boot at "Starting kernel ..."  Looking around in the forums, it sounds like this is probably due to the kernel trying to probe for stuff in the device tree and since I don't have the fabric loaded, the AXI bus gets locked up when it tries to probe the fabric.

I'm using the BSP from http://microzed.org/sites/default/files/design/Zynq_MMP_z7045_PetaLinux_BSP_2014_4.zip.  And it appears that it includes some components out in the fabric:  There are 3 gpio blocks and another component listed in subsystems/linux/configs/device-tree/pl.dtsi.

Formerly, I used the BSP from http://microzed.org/sites/default/files/design/Avnet-MicroZed-7z020-v2014.4_v2.zip, and the resulting pl.dtsi in my petalinux project is empty.

Three questions:
  1. Does my hypothesis make sense that the MMP BSP includes assumptions about components in the fabric?
  2. If so, why does the new BSP include those?  Is there a board level reason they're required?
  3. What's the easiest way for me to get a BSP that will allow me to boot linux without loading the fabric?

  • 0
    1.   Yes
    2.   The fabric components are not necessary, but included for convenience. MicroZed can operate standalone, so the default hardware platform is pretty basic -- no PL peripherals at all since the PL I/Os are not available when MicroZed operates standalone.
    3.   Remove those peripherals from the devicetree, and you should be OK. If you wanted to remove all traces, you'd need to take the hardware platform provided in the BSP and strip out the PL peripherals. Then update your kernel.

     

    Bryan

  • 0 in reply to bhfletcher

    Thanks Bryan,

    I think that there are some fabric components; they show up in pl.dtsi file, and I suspect that its when their drivers try to probe for them during boot, that's when the system hangs.

    I assume that the pl.dtsi file is the one that you're talking about in paragraph 3.  It has a big warning at the top that it's "automatically generated by Xilinx", so I figured I shouldn't touch it and instead try to figure out how it's generated.  It also seems to get overwritten every time I do a petalinux-config, for example to modify the rootfs configuration.

    In any event, the solution that I have now gotten working was to use an *.hdf file instead of a *.bsp file as described on pages 19 through 26 of http://www.xilinx.com/support/documentation/sw_manuals/petalinux2015_4/ug1144-petalinux-tools-reference-guide.pdf.  I was able to load the 2015.2 reference design into vivado 2015.4 and then strip out the offending components and export the *.hdf.

    Tom