Xilinx / meta-xilinx-tools

Yocto Project layer enables AMD Xilinx tools related metadata for MicroBlaze, Zynq, ZynqMP and Versal devices.
MIT License
55 stars 50 forks source link

Issues importing HDF in FSBL generation #1

Closed bigbrett closed 7 years ago

bigbrett commented 7 years ago

I'm trying to use this layer to create an FSBL from an HDF file while building my image. I keep running into failures building the FSBL like this one:

[ERROR] : Can't read file - /home/brett/Thesis/Zynq_Linux/Yocto/poky/build/tmp/deploy/images/zedboard-zynq7/fsbl-zedboard-zynq7.elf

which indicates that the fsbl could not be built since the tools couldn't find the hdf file. The FSBL logs for log.do_configure show that xsct was given an improper path to the HDF file.

After digging through the source code, I believe I know why. The problem may be that the instructions (on both the README and in the xilinx yocto wiki) are written ambiguously, such that most people will provide the wrong path to the HDF in conf/local.conf.

Three issues on the mailing list (one of which is mine) seem to be dealing with this same issue.

The problem is that the recipes-fsbl expects the hdf file to be at a LOCAL path to the workdir, whereas the example in the instructions seems to hint that it can be an absolute path anywhere outside the workspace itself.

The instructions say the following:

meta-xilinx-tools recipes depends on HDF to provided, HDF_BASE can be set to git: or file: HDF_PATH will be git repository or the path containing HDF Ex: HDF_BASE = "file://" HDF_PATH = "" // ex: HDF_PATH = "/home/user/system.hdf" # << misleading example path HDF_BASE = "git://" HDF_PATH = "" //ex: HDF_PATH = "github.com/hdf-base.git" # << this should be clarified as well, with an example path from an ACTUAL git repo

However this is misleading. In the recipe to import the hdf, we can see that the hdf file is expected to be at ${WORKDIR}/${HDF_PATH} and NOT at ${HDF_PATH} like the example in the instructions seems to suggest.

# in recipes-hdf/hdf/external-hdf/bb
# . . . 

do_deploy() {
    install -d ${DEPLOYDIR}
    if [ "${HDF_BASE}" = "git://" ]; then
       install -m 0644 ${WORKDIR}/git/${MACHINE}/system.hdf 
${DEPLOYDIR}/Xilinx-${MACHINE}.hdf
    else
        install -m 0644 ${WORKDIR}/${HDF_PATH} ${DEPLOYDIR}/Xilinx-${MACHINE}.hdf
    fi
}

I found a workaround, but since I'm a Yocto newbie, I don't know if what I did is bad form. I changed the HDF path in the external-hdf.bb recipe from ${WORKDIR}/${HDF_PATH} to just ${HDF_PATH} but I'm not sure if this will break things down the line. Maybe I need to create a new layer with its own .bbappend?

Please advise a proper solution, as the mailing list shows a number of people struggling with this issue, and none have resolved it.

bigbrett commented 7 years ago

EDIT: The proposed workaround is not actually correct, and results in build errors with u-boot, which did not occur before. New errors as a result of running bitbake fsbl succesfully, then attempting bitbake core-image-full-cmdline are shown below

NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: core-image-full-cmdline-1.0-r0 do_xilinx_bootbin: Function failed: do_xilinx_bootbin (log file is located at /home/brett/Thesis/Zynq_Linux/Yocto/poky/build/tmp/work/zedboard_zynq7-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/temp/log.do_xilinx_bootbin.21531)
ERROR: Logfile of failure stored in: /home/brett/Thesis/Zynq_Linux/Yocto/poky/build/tmp/work/zedboard_zynq7-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/temp/log.do_xilinx_bootbin.21531
Log data follows:
| DEBUG: Executing shell function do_xilinx_bootbin
| [ERROR]  : Can't read file - /home/brett/Thesis/Zynq_Linux/Yocto/poky/build/tmp/deploy/images/zedboard-zynq7/u-boot-zedboard-zynq7.elf
| WARNING: /home/brett/Thesis/Zynq_Linux/Yocto/poky/build/tmp/work/zedboard_zynq7-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/temp/run.do_xilinx_bootbin.21531:1 exit 1 from 'bootgen -image /home/brett/Thesis/Zynq_Linux/Yocto/poky/build/tmp/work/zedboard_zynq7-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/core-image-full-cmdline-1.0/bootgen.bif -arch zynq -w -o BOOT.bin'
| ERROR: Function failed: do_xilinx_bootbin (log file is located at /home/brett/Thesis/Zynq_Linux/Yocto/poky/build/tmp/work/zedboard_zynq7-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/temp/log.do_xilinx_bootbin.21531)
ERROR: Task (/home/brett/Thesis/Zynq_Linux/Yocto/poky/meta/recipes-extended/images/core-image-full-cmdline.bb:do_xilinx_bootbin) failed with exit code '1'
NOTE: Tasks Summary: Attempted 3846 tasks of which 3833 didn't need to be rerun and 1 failed.
Summary: 1 task failed: 
 /home/brett/Thesis/Zynq_Linux/Yocto/poky/meta/recipes-extended/images/core-image-full-cmdline.bb:do_xilinx_bootbin
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
mharth commented 7 years ago

The instructions are correct, please see https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-hdf/hdf/external-hdf.bb#L12 Please check Yocto documentation on how SRC_URI works wrt file path

bigbrett commented 7 years ago

@mharth thank you for the response.

I did see the documentation, however I don't understand how that affects anything with regards to line 25 in external-hdf:

install -m 0644 ${WORKDIR}/${HDF_PATH} ${DEPLOYDIR}/Xilinx-${MACHINE}.hdf

which does not use the SRC_URI variable

brett@wintermute:~/Thesis/Zynq_Linux/Yocto/poky/build$ bitbake -e fsbl | grep ^WORKDIR=

WORKDIR="/home/brett/Thesis/Zynq_Linux/Yocto/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/fsbl/0.2+xilinx+gitAUTOINC+a931a8d447-r0"

Unless the file was put there by another do_install somewhere else.

Regardless, the original issue was that before I did this change, the fsbl file was not being built. After I made this change, it was. Please see here: https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-May/002756.html

I greatly appreciate the help

mharth commented 7 years ago

If you follow our manifest and build it works ( I just tested it) http://www.wiki.xilinx.com/Getting+Started+With+Yocto+using+Repo+to+build+RPM+Packages The one additional thing I had to do was IMAGE_LINGUAS="" but this has nothing to do with error you are seeing

SRC_URI fetches the required files and gets copied in $WORKDIR, hence the usage

bigbrett commented 7 years ago

@mharth appreciate the help.

Is there no way to use the standard Yocto flow to build a linux image using the xilinx meta layers, without using repo or petalinux?

All I would like to do is build a simple image using the standard yocto build flow. However I am unable to build the fsbl because of the errors mentioned in the mailing list thread. I guess the workaround proposed above was incorrect, since I was misinterpreting how the SRC_URI variable is supposed to work, however I am still unable to generate the fsbl using bitbake core-image-full-cmdline or bitbake fsbl :(

Any suggestions would be greatly appreciated

kylemanna commented 7 years ago

Is there no way to use the standard Yocto flow to build a linux image using the xilinx meta layers, without using repo or petalinux?

I've had success overriding (or overlaying?) the external-hdf recipe in my internal meta layer and pointed it directly to my git repo hosting a hdf file. That way it gets pulled in like any other recipe. The fsbl builds after the external-hdf repo and works as expected.

bigbrett commented 7 years ago

@kylemanna hmm ok that is indeed what I'm doing now, and it builds fine, however it does not load the bitfile at boot time so I figured something was still wacky..... Have you been able to get a BOOT.bin generated from your HDF using the meta-xilinx-tools that succesfully loads the PL bitstream before handing off to u-boot?

kylemanna commented 7 years ago

You would need to embed the bitstream file in the BOOT.bin if you want the FSBL to load it (but, not sure why you'd ever do this on Linux), integrate it in to a FIT image with your kernel and let U-Boot load it, or load it in userspace via /dev/xdevcfg.

I prefer loading the bitstream as late as possible so that I don't need to muck with my early stage bootloaders every time I update the bitstream.

bigbrett commented 7 years ago

Ah ok got it. I figured fsbl was the place to do it but might just wait until uboot then. Thanks for the help.

mharth commented 7 years ago

https://github.com/Xilinx/meta-xilinx-tools/blob/rel-v2017.1/conf/machine/include/machine-xilinx-zynq.inc This is one way pf packing bitstream in BOOT.bin.