Thanks for the quick reply. I guess your response highlights two things
that aren't entirely clear to me.
On Tue, Aug 16, 2022 at 10:17:26PM -0500, Mark Hatle wrote:
> When using rel-v2022.1, we have only tested the configuration exactly as it
> is defined.
First...
I'm struggling to work out how OpenEmbedded intended for runqemu to work
from a user standpoint, so bear with me on this one. It seems to me
that some of these settings don't belong in a build script, but should
be configured by the user when they choose to launch QEMU. By burning
these parameters into the build recipes, isn't everyone forced into a
particular configuration?
But having said that, I also don't understand why there are Xilinx
recipes overriding some of the OpenEmbedded recipes. When I compare
qemu-xilinx-helper-native_1.0.bb with the qemu-helper-native_1.0.bb from
oe-core, the Xilinx version appears to do the same thing, having only
removed functionality. What was wrong with qemu-helper-native_1.0.bb
that it needed replacement?
As a side note, I was wondering how qemu-oe-bridge-helper worked,
because in my experience qemu-bridge-helper typically needs the setuid
bit set in order to work. I was considering simply updating my bbclass
to specify the host's /usr/libexec/qemu-bridge-helper rather than
qemu-oe-bridge-helper, when I decided to actually look at
qemu-oe-bridge-helper and discovered that it's only a shell script to
find the host's qemu-bridge-helper path. So now I'm even more at a loss
to why meta-xilinx would override this recipe and inhibit the deployment
of this simple script.
> However, if you look at "honister-next", you should see we have reworked
> this. I use both tun and slirp regularly, I can't say I've tried to use tap.
> So if something is missing that is required for it to work, can you please
> open a bug on github.com/Xilinx/meta-xilinx and explain _exactly_ how you
> would expect to setup and use it?
Sure, I will experiment with some workaround on my end and when I settle
on a solution that I am happy with, I'll open a bug on GitHub and share
what I'm doing. The short version (in case this reveals that I'm
misunderstanding something) is that I simply search QB_OPT_APPEND for
this text:
user,tftp=${DEPLOY_DIR_IMAGE}
And replace it with this text:
bridge,br=virbr0,helper=${STAGING_BINDIR_NATIVE}/qemu-oe-bridge-helper
Of course, virbr0 is a virtual bridge which expected to already exist on
our workstations. This is why it doesn't sit well with me for this sort
of host-specific configuration to appear in a build recipe.
> (I'm hoping tomorrow I'll finally move honister-next to honister...)
Second...
Would you recommend that I track the Yocto release named branches
instead of the Xilinx release named branches? At first I chose
rel-v2021.2, and now rel-v2022.1, only because I'm following the Vivado
release that other members of our team are using. Which do you think
makes the most sense?
Thanks,
Corey
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5042):
https://lists.yoctoproject.org/g/meta-xilinx/message/5042
Mute This Topic: https://lists.yoctoproject.org/mt/93070424/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
