Hmm. Only now that I try it (unsetting QB_NET and overriding
QB_NETWORK_DEVICE from my machine file since those were set to "none"
from versal-generic.conf), I see that runqemu's setup_net_bridge() has a
hard-coded "-device virtio-net-pci" which generates the error:
qemu-system-aarch64: -device virtio-net-pci,netdev=net0: No 'PCI' bus found
for device 'virtio-net-pci'
On Wed, Aug 17, 2022 at 08:18:51PM +0000, Thompson, Corey via
lists.yoctoproject.org wrote:
> Thanks for the detailed explanations!
>
>
> I do see that in honister-next, the "-net user,tftp=..." option is no
> longer built-in from machine/versal-generic.conf, leaving it free to be
> specified from a runqemu arg (being fair to myself, it looks like you
> control it with the "bridge=" parameter, which I didn't see mentioned by
> "runqemu --help"). I think this was part of my confusion. Thanks!
>
>
> On Wed, Aug 17, 2022 at 02:07:09PM -0500, Mark Hatle wrote:
> > All of the questions and details above are why I try to get use-cases from
> > people for complex problems. If I can understand how you expect to use it,
> > then I can determine can regular Yocto Project do this -- if so how? Once I
> > know that, I can pivot to the "Xilinx" version of QEMU and make sure it can
> > do the same -- or clearly document WHY it can't do it.
> >
> > Ultimately my goal is to enable QEMU functionality so that we can run the
> > Yocto Project test cases, and enable Yocto Project style user development.
> > (We're not there yet.). Today most of the QEMU work is handled by PetaLinux,
> > which does NOT use runqemu.
> >
>
> Sorry, I think I tunnel-visioned on Y and didn't answer X to your
> satisfaction.
>
> For context, most of us here are Yocto neophytes, but we are coming up
> to speed. In the past we have used a home grown build system and VM
> management script, and part of the problem may be a temptation to
> shoehorn workflows that we're familiar with into Yocto rather than
> picking up a new workflow. If you detect that this is the case, I
> welcome suggestions.
>
> At the moment we're not using any of Yocto's automated testing features
> or anything like that. We are still early in development. We just have
> some developers who are responsible for high level applications and/or
> off-board systems that need to connect to and interact with on-board
> applications. For us, QEMU is a platform for them to develop with so
> that the hardware can be reserved for those doing lower level work
> having a need to work with real hardware.
>
> So those users just want a process that looks something like the
> following:
>
> 1. build an image
> 2. possibly configure the VM to select bridge attachment, default
> addresses, etc.
> 3. bring up a VM (or more, each with its own config; not strictly
> required for what we're doing at the moment, but just to give you
> an idea of the sort of things we've done in the past)
> 4. manual testing, which may include configuring the VM's network
> interface settings from application code or connecting to it from
> host applications
> 5. change some code
> 6. tear down the VM
> 7. iterate from step 1, ideally without having to repeat step 2
>
> I hope that makes sense and helps.
>
>
> After seeing what the future of meta-xilinx looks like in honister-next,
> and with your runqemu pointers, I think that what I described above can
> be achieved without my janky hacks. I think our step 2 should be
> satisfied entirely with the runqemu arguments. I will open a bug in
> GitHub soon to try to help get qemu-xilinx-helper-native cleaned up.
>
>
> And thanks again for your help,
> Corey
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5045):
https://lists.yoctoproject.org/g/meta-xilinx/message/5045
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]]
-=-=-=-=-=-=-=-=-=-=-=-
