On Wed, Aug 17, 2022 at 04:54:11PM -0500, Mark Hatle wrote:
> Ahh ok, this may be what the helper was removed. virtio isn't supported, as
> there is no direct PCI emulation in the Xilinx QEMU. (This may change in
> the future, but my understand is this the case right now.)
>
>
> If there is a non-virtio-net-pci that you know works, let me know and I can
> attempt to work with the Yocto Project community to use that instead of that
> hard coded value. If you don't know of anything, I can ask out Xilinx QEMU
> people if this type of thing might be supportable or not.
>
Well, using my search-and-replace hack that we have in rel-v2021.2, the
APU QEMU command line turns into just...
-net nic -net
bridge,br=virbr0,helper=<snip>-image/1.0-r0/recipe-sysroot-native/usr/bin/qemu-oe-bridge-helper
Which works, at least for our purposes. I don't know why that
hard-coded virtio-net-pci device needs to be there. I can also get it
to work in rel-v2022.1 without my hack using this change to QEMU:
@@ -1046,8 +1047,10 @@ class BaseConfig(object):
self.nfs_running = True
def setup_net_bridge(self):
- self.set('NETWORK_CMD', '-netdev bridge,br=%s,id=net0,helper=%s
-device virtio-net-pci,netdev=net0 ' % (
- self.net_bridge, os.path.join(self.bindir_native,
'qemu-oe-bridge-helper')))
+ self.set('NETWORK_CMD', '%s -netdev bridge,br=%s,id=net0,helper=%s
' % (
+ self.network_device, self.net_bridge,
+ os.path.join(self.bindir_native, 'qemu-oe-bridge-helper')))
+ print("CMT NETWORK_CMD='%s'", (self.get("NETWORK_CMD"),))
def setup_slirp(self):
"""Setup user networking"""
And with these variables in my machine.conf:
unset QB_NET
QB_NETWORK_DEVICE = "-net nic,netdev=net0"
# required because I'm not on honister-next
QB_OPT_APPEND:remove:qemuboot-xilinx = "-net nic -net
user,tftp=${DEPLOY_DIR_IMAGE}"
And the network part of the APU command line ends up looking like:
-net nic,netdev=net0 -netdev
bridge,br=virbr0,id=net0,helper=<snip>/build/tmp/work/x86_64-linux/qemu-xilinx-helper-native/1.0-r0/recipe-sysroot-native/usr/bin/qemu-oe-bridge-helper
This works for me; however, now I might see the reason why
setup_net_bridge() didn't get as much love. setup_tap() is able to use
the tap number to generate a unique MAC address, but when using -netdev
bridge, tap allocation is delegated to QEMU, so runqemu can't get that
information until it's too late. Similarly, setup_slirp() uses the
hostfwd ports in its MAC pattern. Hmm, I can't think of a good source
for bridge-mode MAC generation at the moment...
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5047):
https://lists.yoctoproject.org/g/meta-xilinx/message/5047
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]]
-=-=-=-=-=-=-=-=-=-=-=-
