Closed bigbrett closed 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.
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
@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
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
@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
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.
@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?
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.
Ah ok got it. I figured fsbl was the place to do it but might just wait until uboot then. Thanks for the help.
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.
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:
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:
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.
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.