[meta-xilinx] [meta-xilinx-tools][PATCH] xilinx-bootbin: Convert to recipe instead of bbclass
boot.bin should be deployed either using SPL methodology or using bootgen. Change the bbclass to recipe so that it can be used as recipe with a provider setting. This patch is based of the inital patch sent to mailing list by Jean-Francois Dagenais https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-July/003029.html Signed-off-by: Manjukumar Matha --- Changelog 1) Remove unnecessary tasks which are not used in bootbin recipe classes/xilinx-bootbin.bbclass | 83 --- conf/machine/include/machine-xilinx-zynq.inc | 19 - conf/machine/include/machine-xilinx-zynqmp.inc | 41 -- recipes-bsp/bootbin/machine-xilinx-zynq.inc| 17 recipes-bsp/bootbin/machine-xilinx-zynqmp.inc | 35 recipes-bsp/bootbin/xilinx-bootbin_1.0.bb | 107 + 6 files changed, 159 insertions(+), 143 deletions(-) delete mode 100644 classes/xilinx-bootbin.bbclass delete mode 100644 conf/machine/include/machine-xilinx-zynq.inc delete mode 100644 conf/machine/include/machine-xilinx-zynqmp.inc create mode 100644 recipes-bsp/bootbin/machine-xilinx-zynq.inc create mode 100644 recipes-bsp/bootbin/machine-xilinx-zynqmp.inc create mode 100644 recipes-bsp/bootbin/xilinx-bootbin_1.0.bb diff --git a/classes/xilinx-bootbin.bbclass b/classes/xilinx-bootbin.bbclass deleted file mode 100644 index 31a38a6..000 --- a/classes/xilinx-bootbin.bbclass +++ /dev/null @@ -1,83 +0,0 @@ -inherit xsct-tc - -BIF_COMMON_ATTR ?= '' -BIF_PARTITION_ATTR ?= '' -BIF_PARTITION_IMAGE ?= '' -BIF_PARTITION_DEPENDS ?= '' -BIF_FILE_PATH = "${WORKDIR}/bootgen.bif" - -def create_bif(config, attrflags, attrimage, common_attr, biffd, d): -import re, os -for cfg in config: -if cfg not in attrflags and common_attr: -error_msg = "%s: invalid ATTRIBUTE" % (cfg) -bb.error("BIF attribute Error: %s " % (error_msg)) -else: -if common_attr: -cfgval = attrflags[cfg].split(',') -cfgstr = "\t [%s] %s\n" % (cfg,', '.join(cfgval)) -else: -if cfg not in attrimage: -error_msg = "%s: invalid or missing elf or image" % (cfg) -bb.error("BIF atrribute Error: %s " % (error_msg)) -imagestr = d.expand(attrimage[cfg]) -if os.stat(imagestr).st_size == 0: -bb.warn("Empty file %s, excluding from bif file" %(imagestr)) -continue -if cfg in attrflags: -cfgval = attrflags[cfg].split(',') -cfgstr = "\t [%s] %s\n" % (', '.join(cfgval), imagestr) -else: -cfgstr = "\t %s\n" % (imagestr) -biffd.write(cfgstr) - -return - -python do_create_bif() { - -fp = d.getVar("BIF_FILE_PATH", True) -biffd = open(fp, 'w') -biffd.write("the_ROM_image:\n") -biffd.write("{\n") - -bifattr = (d.getVar("BIF_COMMON_ATTR", True) or "").split() -if bifattr: -attrflags = d.getVarFlags("BIF_COMMON_ATTR") or {} -create_bif(bifattr, attrflags,'', 1, biffd, d) - -bifpartition = (d.getVar("BIF_PARTITION_ATTR", True) or "").split() -if bifpartition: -attrflags = d.getVarFlags("BIF_PARTITION_ATTR") or {} -attrimage = d.getVarFlags("BIF_PARTITION_IMAGE") or {} -create_bif(bifpartition, attrflags, attrimage, 0, biffd, d) - -biffd.write("}") -biffd.close() -} -addtask do_create_bif before do_xilinx_bootbin - -do_create_bif[vardeps] += "BIF_PARTITION_ATTR BIF_PARTITION_IMAGE BIF_COMMON_ATTR" -do_create_bif[depends] += "${@get_bootbin_depends(d)}" - -def get_bootbin_depends(d): -bootbindeps = "" -bifpartition = (d.getVar("BIF_PARTITION_ATTR", True) or "").split() -attrdepends = d.getVarFlags("BIF_PARTITION_DEPENDS") or {} -for cfg in bifpartition: -if cfg in attrdepends: -bootbindeps = bootbindeps + " " + attrdepends[cfg] + ":do_deploy" - -return bootbindeps - -do_xilinx_bootbin[depends] += "${@get_bootbin_depends(d)}" - -do_xilinx_bootbin () { -cd ${WORKDIR} -rm -f BOOT.bin -bootgen -image ${BIF_FILE_PATH} -arch ${KMACHINE} -w -o BOOT.bin -if [ ! -e BOOT.bin ]; then -bbfatal "bootgen failed. See log" -fi -install -m 0644 BOOT.bin ${DEPLOY_DIR_IMAGE}/BOOT.bin -} -addtask do_xilinx_bootbin before do_image diff --git a/conf/machine/include/machine-xilinx-zynq.inc b/conf/machine/include/machine-xilinx-zynq.inc deleted file mode 100644 index 1955748..000 --- a/conf/machine/include/machine-xilinx-zynq.inc +++ /dev/null @@ -1,19 +0,0 @@ -IMAGE_CLASSES_append ?= " xilinx-bootbin" - -#specify BIF partition attributes required for BOOT.bin -BIF_PARTITION_ATTR ?= "fsbl bitstream u-boot" - -#specify BIF partition attributes for FSBL -#bootloader is FSBL. Location where FSBL binary is present and dependency to build FSBL -BIF_PARTITION_ATTR[fsbl] ?= "bootloa
Re: [meta-xilinx] [meta-xilinx-bsp][PATCH v2 3/3] linux-xlnx.inc: Support simpleImage.mb support for MB
Hi Nathan, > -Original Message- > From: Nathan Rossi [mailto:nat...@nathanrossi.com] > Sent: Sunday, January 28, 2018 5:29 AM > To: Manjukumar Harthikote Matha > Cc: meta-xilinx@yoctoproject.org > Subject: Re: [meta-xilinx] [meta-xilinx-bsp][PATCH v2 3/3] linux-xlnx.inc: > Support > simpleImage.mb support for MB > > On 23 January 2018 at 10:55, Manjukumar Matha ma...@xilinx.com> wrote: > > Support simpleImage.mb for MB machines. simpleImage.mb depends on dts > > to be included while kernel is being compiled. This patch enables > > copying the dts from device-tree recipe to kernel work area so that > > simpleImage.mb can be built > > > > Signed-off-by: Manjukumar Matha > > > > --- > > meta-xilinx-bsp/recipes-kernel/linux/linux-xlnx.inc | 18 > > ++ > > This should be implemented in a kernel-simpleimage.bbclass, so that is can be > also > used for linux-yocto and even contributed upstream (since powerpc also > supports > simpleimage). > > > 1 file changed, 18 insertions(+) > > > > diff --git a/meta-xilinx-bsp/recipes-kernel/linux/linux-xlnx.inc > > b/meta-xilinx-bsp/recipes-kernel/linux/linux-xlnx.inc > > index 7b4f9ac..e05890c 100644 > > --- a/meta-xilinx-bsp/recipes-kernel/linux/linux-xlnx.inc > > +++ b/meta-xilinx-bsp/recipes-kernel/linux/linux-xlnx.inc > > @@ -23,6 +23,24 @@ do_kernel_metadata_prepend () { > > [ -n "${KBUILD_DEFCONFIG}" ] && [ -e ${WORKDIR}/defconfig ] && > > rm ${WORKDIR}/defconfig } > > > > +python __anonymous () { > > + kerneltypes = d.getVar('KERNEL_IMAGETYPES') or "" > > This should take KERNEL_IMAGETYPE into account as well, in case a user only > wants > simpleImage and is using the KERNEL_IMAGETYPE variable which should work. > > Something like this gets a unique list to check against: > > kerneltypes = set((d.getVar("KERNEL_IMAGETYPE") or "").strip()) kerneltypes |= > set((d.getVar("KERNEL_IMAGETYPES") or "").split()) > Ok thanks, > > + if 'simpleImage.mb' in kerneltypes.split(): > > The simpleImage. targets can work for any dtb, this check can instead > something like: > > if any(t.startswith("simpleImage.") for t in kerneltypes): > ... > > Though you will need to update the copying steps below to handle multiple > dtbs. > > > + providerdtb = d.getVar("PREFERRED_PROVIDER_virtual/dtb") or "" > > + if providerdtb: > > Its not worth doing this check, since "" is a valid provider which is used to > automatically select based on available providers. And this will force > bitbake to fail if > it cant find a provider which will list possible options/etc, and most > usefully why > they were skipped. > > > + d.appendVarFlag('do_compile', 'depends', ' > virtual/dtb:do_populate_sysroot') > > + else: > > + bb.error("For MB dts/dtb provider needs to be set") } > > + > > +do_compile_prepend_microblaze () { > > + if (echo "${KERNEL_IMAGETYPES}" | grep -wq "simpleImage.mb"); > > +then > > I would suggest doing this as a separate task that do_compile becomes > dependent > on if simpleImage is enabled. That also means you can make the separate task > dependent on the virtual/dtb instead of do_compile. > Which might likely speed up some parallelism of tasks. > Ok agreed > > + install -d ${B}/arch/microblaze/boot/dts > > + cp ${RECIPE_SYSROOT}/boot/devicetree/*.dts > > + ${B}/arch/microblaze/boot/dts/mb.dts > > It is possible to build the simpleImage targets without needing the dts, > populating > the .dtb into the build/..boot/dts/ directory and then calling the make > simpleImage. target works as intended. > I have to check this, every time I compiled using kernel Makefile it was checking for dts file to be present > That also means you wont need the disassembled version of the dtb from device- > tree.bb (thus making that patch unnecessary). And prevents any issues caused > by > rebuilding the dtb (e.g. differing pad size). > Thanks for the review! Thanks, Manju -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
[meta-xilinx] Ethernet functionality of QEMU (zcu102-zynqmp)
Hi, Are there any limitations regarding the ethernet capabilities of the QEMU instance of theĀ zcu102-zynqmp machine? runqemu seems to allocate IP address to the tap interface, no obvious errors are present from the kernel log, however no IP address is assigned to eth0. I have manually tried to assign address, gateway etc., however I am not able to gain ssh access. The qemux86 seems to automatically gain the 'runqemu' allocated IP address. Similar observations seem reported for Zynq (https://forums.xilinx.com/t5/Zynq-All-Programmable-SoC/Zynq-QEMU-Network-Issues/td-p/797050) however no definite conclusion seems drawn. Thanks, Martin -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] qemuboot.conf
On 29 January 2018 at 05:51, Martin Siegumfeldt wrote: > > > > > From: Nathan Rossi > Sent: Sunday, January 28, 2018 13:44 > To: Alistair Francis > Cc: Martin Siegumfeldt; meta-xilinx@yoctoproject.org > Subject: Re: [meta-xilinx] qemuboot.conf > > On 24 January 2018 at 09:04, Alistair Francis wrote: >> On Tue, Jan 23, 2018 at 12:53 AM, Martin Siegumfeldt >> wrote: >>> Hi, >>> >>> We are rendering a custom piece of HW based on Ultrascale+, and have the >>> Xilinx QEMU successfully running. An extensible SDK (eSDK) is delivered to >>> the application developers and to close the loop we would like to be capable >>> of delivering also the QEMU instance. The machine image- and qemuboot.conf >>> is not part of the eSDK and is thus delivered next to the eSDK. >>> Unfortunately, the Xilinx conf file describes a few absolute path variables >>> (caused by e.g. >>> https://github.com/Xilinx/meta-xilinx/blob/73921b4a599834308fc0dadb785f395dded89f9e/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf#L55 >>> I believe) prohibiting this conf file to be shared between the application >>> developers. AFACICS, this is in contrast to the generic QEMU machine configs >>> (http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.1/machines/) >>> which only describes relative path variables - I assume this is related to >>> the "custom" Xilinx PMU. > > These are not directly related to the PMU part of QEMU execute, since > that part is executed by runqemu. It is simply that runqemu does not > make generic find/replace with all args, only specific ones. > >>> >>> Do you see any way around these absolute paths, which thus enables >>> directly sharing the QEMU instance with eSDK developers? >> >> All of these files should be in the deploy directory, I don't see any >> reason why they need to be absolute. How do the other configs point to >> the images? > > They need to be absolute because the runqemu script does not rewrite > the paths for those arguments, and in turn with runqemu not executing > with the cwd being the deploy directory it is not known where the > intended path to these files are. > > Other configs like QB_ROOTFS_OPT use "@ROOTFS@" replacement strings > that are substituted during runqemu execution. > > http://git.openembedded.org/openembedded-core/tree/scripts/runqemu#n1030 > > Unfortunately I don't think there is a good solution to remove these > fields without improving runqemu itself. Since the paths are only > known by runqemu and cannot be relative to an unknown execution > working directory. > > Thanks Nathan, I was kind of expecting this answer - it can fairly easy > worked around with a sed command. However, for the "staging_bindir_native" > variable, is there a reason this is absolute as apposed to the other > "staging_dir_..." variables? AFAICS, other machines describe this variable > in a relative manner? > That is simply a case of qemuboot.bbclass getting changes that are not reflected in the qemuboot-xilinx.bbclass in meta-xilinx. This change in oe-core added relative pathing, http://git.openembedded.org/openembedded-core/commit/?id=55a0028a961c0ad3c2e5729a9e3919cbbf256fe1 But qemuboot-xilinx.bbclass modifies staging_bindir_native to put in the qemu-xilinx-helper-native specific path. Which doesn't do the relative path logic, since it was created before the oe-core change. http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/classes/qemuboot-xilinx.bbclass#n20 Please send a patch to fix it if you need the relative paths. Regards, Nathan -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx