Actions
Forum Thread Details
  • State Not Answered
  • Replies 2 replies
  • Subscribers 177 subscribers
  • Views 294 views
  • Users 0 members are here
Related

Microzed7020+FMC carrier, Vivado+Petalinux 2019.2 - SD card boot, porting a working project from Digilent Arty Z7-20

imanyakin

I am trying to port a working Zynq 7000 project from the Digilent Arty Z7-20 to a Microzed 7020. So far I have done the following steps:

 

Load the board definition file from the avnet/bdf repo:

https://github.com/Avnet/bdf

My first question here is whether there are more recent version of the above bdfs, version in repo is Vivado 2018.3 and whether anyone knows about any incompatibilities that can be raised at this stage?

 

I then replace the .xdc constraint file of the Digilent/Arty with that of the Microzed from avnet/hdl (2019.2 version), [commenting out all of the pin assignments for now]:
https://github.com/Avnet/hdl/tree/2019.2

 

Following this I update the project constraint file, rebuild and export the bitstream without any errors and then use the following bash script to build (using petalinux 2019.2) the boot.bin and image.ub files:

 

source ${PETALINUX_ENV}/settings.sh

petalinux-create -t project -n ${PROJECT_NAME} --template "zynq"

sudo sysctl -n -w fs.inotify.max_user_watches=524288

cd $PROJECT_NAME

petalinux-config --get-hw-description=${HARDWARE_DEFINITION}

petalinux-build

BIT_FILEPATH=${HARDWARE_DEFINITION}/test_project.runs/impl_1/design_1_wrapper.bit

cd "./images/linux"

petalinux-package --boot --fsbl zynq_fsbl.elf --fpga ${BIT_FILEPATH} --u-boot --force

 

Turning on the microzed, connecting via a serial console (cutecom on ubuntu 20.04) does not work for this build. However I can say that it is neither the JP1-JP3 boot configs on the board of the serial interface on the computer - I can boot other boot configurations available online for the microzed, so I think it's just an issue with the boot.bin/image.ub being created above. Hence the main question is this - what else could be significantly different between the config of a Arty Z7-20 and a Microzed 7020 which would mean that the project works fine on one system but fails to boot on the other, given that the process for building the images seems identical to me. Or have I missed something?

 

Note: at the moment I am currently only trying to boot the the microzed without the fmc, once I can do that, I plan to attach FMC and boot with it connected.


Thanks,

 

Ilya

  • 0

    To answer your first question - the BDF for the MicroZed hasn't changed since Vivado 2018.3 and is still compatible with the current (2020.1) Vivado tools.

     

    The problem you describe sounds like a mismatch between the Zynq Processing System (PS) configuration for the Arty/Z7 board and what is needed for the MicroZed.  Did you re-run block automation after changing the Vivado project target board settings from the Arty/Z7 to the MicroZed?  It may be simpler to start with a known-good Vivado hw project and PetaLinux Board Support Packages (BSPs) for the MicroZed and change it to add/remove the Programmable Logic (PL) bits and pieces you need from the Arty/Z7 project.  You can find PetaLinux BSPs (packaged with the underlying Vivado hw project) for MicroZed here:

     

    https://www.element14.com/community/community/designcenter/zedboardcommunity/microzed#e14tab2

     

    Once you "install" the BSP and edit the PL of the included Vivado hw project and re-implement you will be at the step to 'petalinux-config --get-hw-description=${HARDWARE_DEFINITION}' and rebuild the PetaLinux OS image, recreate the boot.bin, etc.

     

    --Tom

  • 0 in reply to narrucmot

    Yes - that's solved it, I got the hint that the block automation was doing something strange when the PS on the MicroZed enabled different ports in a dummy MicroZed project compared to the Arty. Scripts for building BSPs for Microzed also give a hint of what's happening: https://github.com/Avnet/hdl/blob/master/Boards/MZ7020_FMCCC/MZ7020_FMCCC.tcl ). I basically rebuilt the top level project and updated all imported IP cores - so it all works now. One thing that's strange to me is that this isn't picked up during validation/synthesis or implementation and that Vivado doesn't recursively update even their own "generic" IP cores which aren't specific to the board - only sometimes giving vague warnings, but even those are sporadic.

     

    In the end basically rebuilding the top level project containing the Zynq PS solved it. Rerunning block automation on the PS along didn't do it for some reason.

     

    Thanks for your input Tom! image