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 (#5044):
https://lists.yoctoproject.org/g/meta-xilinx/message/5044
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]]
-=-=-=-=-=-=-=-=-=-=-=-
