Skip to content
Snippets Groups Projects

Draft: external-hdf: find XSA files in a folder

Closed Patrick Huesmann requested to merge hdf_path into rel-v2020.2
2 unresolved threads

Previously each variant would be defined in PL_VARIANTS and the XSA files placed into a folder local to the recipe.

With this change, only the folder location PL_VARIANT_DIR is specified. In the simplest case this is the recipe folder, e.g.:

PL_VARIANTS_DIR := "

{THISDIR}/
{MACHINE}"

It adds Python code that runs before the script functions are called and recursively globs for all XSA files in it. The SRC_URI and FILES variables are updated accordingly. Changes to the XSA files should be noticed by bitbake so it rebuilds everything.

Alternatively one can still specify a single XSA file with HDF_PATH.

The way XSA files are installed into the sysroot should not have changed. The pl-variants file still gets populated.

Code was partly taken from Xilinx' fpga-manager-util_1.0.bb recipe which does a very similar thing.

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Patrick Huesmann requested review from @huesmann

    requested review from @huesmann

    By Michael Buechler on 2023-04-28T16:21:17 (imported from GitLab)

  • Patrick Huesmann assigned to @mbuechl

    assigned to @mbuechl

    By Michael Buechler on 2023-04-28T16:21:17 (imported from GitLab)

    • @huesmann may I ask you to test if this has the same issue that you mentioned, where bitbake would not notice when an XSA file changes when it is globbing for files? I'm not sure if I tested this in the same way as you.

      By Michael Buechler on 2023-04-28T16:57:55 (imported from GitLab)

    • It does not have that issue here, b/c the SRC_URI itself does not do the globbing. The globbing is done by the Python code which then populates SRC_URI with explicit file names. The BitBake fetcher only skips checksumming, if SRC_URI contains a glob expression. I verified this by modifying one of the .xsa files and BitBake immediately picked up the change.

      By Patrick Huesmann on 2023-05-02T08:47:33 (imported from GitLab)

    • Please register or sign in to reply
  • Patrick Huesmann marked this merge request as draft

    marked this merge request as draft

    By Michael Buechler on 2023-05-05T15:25:01 (imported from GitLab)

  • Patrick Huesmann added 2 commits

    added 2 commits

    Compare with previous version

    By Michael Buechler on 2023-05-05T15:25:27 (imported from GitLab)

  • added 1 commit

    • 0bcc325f - WIP allow filtering of PL_VARIANTS

    Compare with previous version

    By Michael Buechler on 2023-05-26T13:55:06 (imported from GitLab)

  • added 1 commit

    • 70cef045 - Fix bitstream filename in pl-var-*.dtsi

    Compare with previous version

    By Michael Buechler on 2023-06-05T11:32:22 (imported from GitLab)

  • Patrick Huesmann added 2 commits

    added 2 commits

    • fbb21583 - WIP allow filtering of PL_VARIANTS
    • 9ff418fa - Fix bitstream filename in pl-var-*.dtsi

    Compare with previous version

    By Michael Buechler on 2023-06-05T13:13:32 (imported from GitLab)

  • Patrick Huesmann added 3 commits

    added 3 commits

    • 8aa5e7f6 - WIP allow filtering of PL_VARIANTS
    • eeb446b7 - Fix bitstream filename in pl-var-*.dtsi
    • 71917246 - fpgautil-init: depend on external-hdf

    Compare with previous version

    By Michael Buechler on 2023-06-07T14:59:12 (imported from GitLab)

  • Patrick Huesmann added 3 commits

    added 3 commits

    • 8fe4804e - WIP allow filtering of PL_VARIANTS
    • c52bd64c - Fix bitstream filename in pl-var-*.dtsi
    • dc3bd77f - fpgautil-init: depend on external-hdf

    Compare with previous version

    By Michael Buechler on 2023-06-08T18:05:03 (imported from GitLab)

  • This breaks the demo image. When I run fpgautil now, it suddenly expects a different name for the binfile, even though I give it explicitly (with the -b option). I don't know where fpgautil gets the idea of that different filename from.

      root@damc-fmc1z7io-rev-a  ~  chip_variant="7z045"; ls -lr /lib/firmware/base/${chip_variant}                                                                                                                           
    
    total 4892
    -rw-r--r-- 1 root root 13321408 Jul 12  2023 damc_fmc1z7io_top.bit.bin
    -rw-r--r-- 1 root root     8504 Jul 12  2023 base.dtbo
      root@damc-fmc1z7io-rev-a  ~  fpgautil -b /lib/firmware/base/${chip_variant}/damc_fmc1z7io_top.bit.bin -o /lib/firmware/base/${chip_variant}/base.dtbo
    fpga_manager fpga0: writing 7z045.bit.bin to Xilinx Zynq FPGA Manager
    fpga_manager fpga0: Direct firmware load for 7z045.bit.bin failed with error -2
    fpga_manager fpga0: Error requesting firmware 7z045.bit.bin
    fpga_region region0: failed to load FPGA image
    OF: overlay: overlay changeset pre-apply notifier error -2, target: /fpga-full
    OF: overlay: overlay changeset pre-apply notify error -2
    create_overlay: Failed to create overlay (err=-2)
      root@damc-fmc1z7io-rev-a  ~ 

    By Patrick Huesmann on 2023-07-12T13:32:57 (imported from GitLab)

    • But even when I rename the binfile and change the fpgautil argument it will refuse to load it.

        root@damc-fmc1z7io-rev-a  ~  chip_variant="7z045"; ls -lr /lib/firmware/base/${chip_variant}                                                         
      
      total 4892
      -rw-r--r-- 1 root root     8504 Jul 12  2023 base.dtbo
      -rw-r--r-- 1 root root 13321408 Jul 12  2023 7z045.bin
        root@damc-fmc1z7io-rev-a  ~  fpgautil -b /lib/firmware/base/${chip_variant}/7z045.bit.bin -o /lib/firmware/base/${chip_variant}/base.dtbo
      cp: cannot stat '/lib/firmware/base/7z045/7z045.bit.bin': No such file or directory
      fpga_manager fpga0: writing 7z045.bit.bin to Xilinx Zynq FPGA Manager
      fpga_manager fpga0: Direct firmware load for 7z045.bit.bin failed with error -2
      fpga_manager fpga0: Error requesting firmware 7z045.bit.bin
      fpga_region region0: failed to load FPGA image
      OF: overlay: overlay changeset pre-apply notifier error -2, target: /fpga-full
      OF: overlay: overlay changeset pre-apply notify error -2
      create_overlay: Failed to create overlay (err=-2)
      rm: cannot remove '/lib/firmware/7z045.bit.bin': No such file or directory
        root@damc-fmc1z7io-rev-a  ~ 

      By Patrick Huesmann on 2023-07-13T17:50:51 (imported from GitLab)

    • When you tell fpgautil to load a binfile + a device tree, the program only copies the binfile to /lib/firmware/ and applies the device tree overlay to the kernel. The kernel finds a node with a property firmware-name = "foo.bit.bin" and calls the firmware loading mechanism to find and load this firmware [1].

      This device tree property is generated in XSCT based on the filename of XSA file that was chosen when it was exported from Vivado with write_hw_platform.

      If I remember correctly then my problem was that XSCT generates firmware-name in the pl.dtsi that is common to all PL variants, so most variants would have loaded the wrong firmware. I think this also affected the techlab layers without any msk-fwk stuff. In this set of changes I worked around this in recipes-bsp/device-tree/device-tree.bbappend.

      [1] https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841645/Solution+Zynq+PL+Programming+With+FPGA+Manager#SolutionZynqPLProgrammingWithFPGAManager-TestProcedure

      By Michael Buechler on 2023-07-13T17:50:51 (imported from GitLab)

    • A firmware-name common in all PL variants is actually a non-issue, b/c each of these binfiles live in their own subdirectory (just like the different instances of base.dtbo).

      By Patrick Huesmann on 2023-07-14T07:43:21 (imported from GitLab)

      Edited by Patrick Huesmann
    • This is how the GigEVision FMC2ZUP loads the appropriate binfile (1G or 10G) for instance. The filenames for binfile and overlay are always the same (damc_fmc2zup_top.bit.bin and base.dtbo) but they are pulled from the appropriate subdirectory.

      #!/bin/sh
      
      # Get GigEVision configuration
      . /etc/default/gigevision
      
      scriptname="fpgautil-init"
      
      echo "${scriptname}: Downloading FPGA image '${GEV_PL_VARIANT}'"
      fpgautil -b /lib/firmware/xilinx/base/${GEV_PL_VARIANT}/damc_fmc2zup_top.bit.bin -o /lib/firmware/xilinx/base/${GEV_PL_VARIANT}/base.dtbo
      echo "${scriptname}: FPGA image download done"

      By Patrick Huesmann on 2023-07-14T07:47:52 (imported from GitLab)

      Edited by Patrick Huesmann
    • Maybe we just have to remove this sed statement or make it consider the actual bitfile name. https://msktechvcs.desy.de/techlab/software/yocto-layers/meta-techlab-bsp/-/merge_requests/8/diffs#c6a413baab892b6a35436b1242db3fe36c3fdf37_53_60

      By Patrick Huesmann on 2023-07-14T07:57:17 (imported from GitLab)

    • Please register or sign in to reply
  • added 1 commit

    • 4002b1ab - fix: force binfile name to pl-full.bit.bin

    Compare with previous version

    By Patrick Huesmann on 2023-07-14T10:26:37 (imported from GitLab)

  • added 1 commit

    • 82da7520 - fix: force binfile name to pl-full.bit.bin

    Compare with previous version

    By Patrick Huesmann on 2023-07-14T13:22:09 (imported from GitLab)

  • I built the latest version of this change with z7io_example_design (within MSK fwk). dnf reinstalled fpgautil-init and fpga-manager-util. Rebooted, and dmesg says: fpga_manager fpga0: writing pl-full.bit.bin to Xilinx Zynq FPGA Manager Now I realized one problem: how do you know which variant this actually was? You can do cat /proc/device-tree/fpga-full/firmware-name but this is useless now. Previously it would tell you the exact PL variant, e.g. "fmc1z7io_example_design_default_0.0.0-22-gcb4597f8-daq-mskpcx29858".

    By Michael Buechler on 2023-07-14T14:19:21 (imported from GitLab)

  • Maybe fpgautil-init should write it into syslog.

    By Patrick Huesmann on 2023-07-14T14:34:52 (imported from GitLab)

  • Squash merged 9c800441

    By Patrick Huesmann on 2023-07-20T10:59:32 (imported from GitLab)

  • Please register or sign in to reply
    Loading