[meta-xilinx] qemuboot.conf

[Nathan Rossi]

On 24 January 2018 at 09:04, Alistair Francis <alistair23 at gmail.com> wrote:
> On Tue, Jan 23, 2018 at 12:53 AM, Martin Siegumfeldt <mns at gomspace.com> 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.

Regards,
Nathan