On 29 January 2018 at 05:51, Martin Siegumfeldt <[email protected]> wrote: > > > > ________________________________ > From: Nathan Rossi <[email protected]> > Sent: Sunday, January 28, 2018 13:44 > To: Alistair Francis > Cc: Martin Siegumfeldt; [email protected] > Subject: Re: [meta-xilinx] qemuboot.conf > > On 24 January 2018 at 09:04, Alistair Francis <[email protected]> wrote: >> On Tue, Jan 23, 2018 at 12:53 AM, Martin Siegumfeldt <[email protected]> >> 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 [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
