[meta-xilinx] qemuboot.conf

[Nathan Rossi]

On 29 January 2018 at 05:51, Martin Siegumfeldt <mns at gomspace.com> wrote:
>
>
>
> ________________________________
> From: Nathan Rossi <nathan at nathanrossi.com>
> Sent: Sunday, January 28, 2018 13:44
> To: Alistair Francis
> Cc: Martin Siegumfeldt; meta-xilinx at yoctoproject.org
> Subject: Re: [meta-xilinx] qemuboot.conf
>
> 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.
>
> 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