[PATCH 1/2] beaglebone-yocto: use correct CPU and QB_RNG

[PATCH 1/2] beaglebone-yocto: use correct CPU and QB_RNG

[Jon Mason]

The beagles use the AM3358 SoC, which is an Arm Cortex-A8.  Use that for
QB_CPU.  Also, use QB_RNG to specify the random number generator device.
Finally, correct the image deps to get qemu to run.

Signed-off-by: Jon Mason <jdmason@kudzu.us>
---
 meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
index b3d960a8cd80..06746afa96ae 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
@@ -41,16 +41,16 @@ MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
 IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${KERNEL_DEVICETREE}"
 
 # support runqemu
-EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
+EXTRA_IMAGEDEPENDS += "qemu-system-native qemu-helper-native:do_addto_recipe_sysroot"
 IMAGE_CLASSES += "qemuboot"
 QB_DEFAULT_FSTYPE = "wic"
 QB_FSINFO = "wic:no-kernel-in-fs"
 QB_KERNEL_ROOT = "/dev/vda2"
 QB_SYSTEM_NAME = "qemu-system-arm"
 QB_MACHINE = "-machine virt"
-QB_CPU = "-cpu cortex-a15"
+QB_CPU = "-cpu cortex-a8"
 QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0 systemd.mask=systemd-networkd"
-QB_OPT_APPEND = "-device virtio-rng-device"
+QB_RNG = "-device virtio-rng-device"
 QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
 QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@"
 QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0"
-- 
2.20.1

[PATCH 2/2] genericx86-common.inc: add qemu requirement

[Jon Mason]

Without the necessary fields being populated, genericx86 and
genericx86-64 fail work with runqemu.  Add qemu.inc to provide these
fields.

Signed-off-by: Jon Mason <jdmason@kudzu.us>
---
 meta-yocto-bsp/conf/machine/include/genericx86-common.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta-yocto-bsp/conf/machine/include/genericx86-common.inc b/meta-yocto-bsp/conf/machine/include/genericx86-common.inc
index 4651b37e5d68..9f465d72a9f2 100644
--- a/meta-yocto-bsp/conf/machine/include/genericx86-common.inc
+++ b/meta-yocto-bsp/conf/machine/include/genericx86-common.inc
@@ -1,5 +1,7 @@
 include conf/machine/include/x86/x86-base.inc
 require conf/machine/include/x86/qemuboot-x86.inc
+require conf/machine/include/qemu.inc
+
 MACHINE_FEATURES += "wifi efi pcbios"
 
 PREFERRED_VERSION_linux-yocto ?= "5.14%"
-- 
2.20.1

Re: [poky] [PATCH 1/2] beaglebone-yocto: use correct CPU and QB_RNG

[Tom Rini]

On Thu, Oct 14, 2021 at 10:31:23AM -0400, Jon Mason wrote:

> The beagles use the AM3358 SoC, which is an Arm Cortex-A8.  Use that for
> QB_CPU.  Also, use QB_RNG to specify the random number generator device.
> Finally, correct the image deps to get qemu to run.
> 
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
> ---
>  meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> index b3d960a8cd80..06746afa96ae 100644
> --- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> +++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> @@ -41,16 +41,16 @@ MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
>  IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${KERNEL_DEVICETREE}"
>  
>  # support runqemu
> -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
> +EXTRA_IMAGEDEPENDS += "qemu-system-native qemu-helper-native:do_addto_recipe_sysroot"
>  IMAGE_CLASSES += "qemuboot"
>  QB_DEFAULT_FSTYPE = "wic"
>  QB_FSINFO = "wic:no-kernel-in-fs"
>  QB_KERNEL_ROOT = "/dev/vda2"
>  QB_SYSTEM_NAME = "qemu-system-arm"
>  QB_MACHINE = "-machine virt"
> -QB_CPU = "-cpu cortex-a15"
> +QB_CPU = "-cpu cortex-a8"
>  QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0 systemd.mask=systemd-networkd"
> -QB_OPT_APPEND = "-device virtio-rng-device"
> +QB_RNG = "-device virtio-rng-device"
>  QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
>  QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@"
>  QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0"

Perhaps this is the wrong place to open this can of worms, so to speak,
but why is the beaglebone BSP also supporting QEMU, under the "virt"
machine that would be for qemuarm ?  It would be I think one thing to
make use of
https://qemu.readthedocs.io/en/latest/system/arm/sabrelite.html on the
appropriate machine.conf file and support running it that way as well.
But this isn't emulating the BSP hardware, it's just passing the
resulting rootfs image to qemu-system-arm.  If that's a general goal
now, shouldn't it be pushed up higher in the include files?

-- 
Tom

Re: [poky] [PATCH 1/2] beaglebone-yocto: use correct CPU and QB_RNG

[Richard Purdie]

On Thu, 2021-10-14 at 13:34 -0400, Tom Rini wrote:
> On Thu, Oct 14, 2021 at 10:31:23AM -0400, Jon Mason wrote:
> 
> > The beagles use the AM3358 SoC, which is an Arm Cortex-A8.  Use that for
> > QB_CPU.  Also, use QB_RNG to specify the random number generator device.
> > Finally, correct the image deps to get qemu to run.
> > 
> > Signed-off-by: Jon Mason <jdmason@kudzu.us>
> > ---
> >  meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > index b3d960a8cd80..06746afa96ae 100644
> > --- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > +++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > @@ -41,16 +41,16 @@ MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
> >  IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${KERNEL_DEVICETREE}"
> >  
> >  # support runqemu
> > -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
> > +EXTRA_IMAGEDEPENDS += "qemu-system-native qemu-helper-native:do_addto_recipe_sysroot"
> >  IMAGE_CLASSES += "qemuboot"
> >  QB_DEFAULT_FSTYPE = "wic"
> >  QB_FSINFO = "wic:no-kernel-in-fs"
> >  QB_KERNEL_ROOT = "/dev/vda2"
> >  QB_SYSTEM_NAME = "qemu-system-arm"
> >  QB_MACHINE = "-machine virt"
> > -QB_CPU = "-cpu cortex-a15"
> > +QB_CPU = "-cpu cortex-a8"
> >  QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0 systemd.mask=systemd-networkd"
> > -QB_OPT_APPEND = "-device virtio-rng-device"
> > +QB_RNG = "-device virtio-rng-device"
> >  QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
> >  QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@"
> >  QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0"
> 
> Perhaps this is the wrong place to open this can of worms, so to speak,
> but why is the beaglebone BSP also supporting QEMU, under the "virt"
> machine that would be for qemuarm ?  It would be I think one thing to
> make use of
> https://qemu.readthedocs.io/en/latest/system/arm/sabrelite.html on the
> appropriate machine.conf file and support running it that way as well.
> But this isn't emulating the BSP hardware, it's just passing the
> resulting rootfs image to qemu-system-arm.  If that's a general goal
> now, shouldn't it be pushed up higher in the include files?

I think the general idea has been that if there is qemu emulation, it really
should be actually emulating the hardware else it is different machine.

That said, I recognise that sometimes having a quick handy hack like this to
test things is useful so I'm a little torn. I'm not sure we'd want to make it
any more official or pushed into the tunes.

Cheers,

Richard

Re: [poky] [PATCH 1/2] beaglebone-yocto: use correct CPU and QB_RNG

[Tom Rini]

On Thu, Oct 14, 2021 at 11:45:14PM +0100, Richard Purdie wrote:
> On Thu, 2021-10-14 at 13:34 -0400, Tom Rini wrote:
> > On Thu, Oct 14, 2021 at 10:31:23AM -0400, Jon Mason wrote:
> > 
> > > The beagles use the AM3358 SoC, which is an Arm Cortex-A8.  Use that for
> > > QB_CPU.  Also, use QB_RNG to specify the random number generator device.
> > > Finally, correct the image deps to get qemu to run.
> > > 
> > > Signed-off-by: Jon Mason <jdmason@kudzu.us>
> > > ---
> > >  meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > > index b3d960a8cd80..06746afa96ae 100644
> > > --- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > > +++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > > @@ -41,16 +41,16 @@ MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
> > >  IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${KERNEL_DEVICETREE}"
> > >  
> > >  # support runqemu
> > > -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
> > > +EXTRA_IMAGEDEPENDS += "qemu-system-native qemu-helper-native:do_addto_recipe_sysroot"
> > >  IMAGE_CLASSES += "qemuboot"
> > >  QB_DEFAULT_FSTYPE = "wic"
> > >  QB_FSINFO = "wic:no-kernel-in-fs"
> > >  QB_KERNEL_ROOT = "/dev/vda2"
> > >  QB_SYSTEM_NAME = "qemu-system-arm"
> > >  QB_MACHINE = "-machine virt"
> > > -QB_CPU = "-cpu cortex-a15"
> > > +QB_CPU = "-cpu cortex-a8"
> > >  QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0 systemd.mask=systemd-networkd"
> > > -QB_OPT_APPEND = "-device virtio-rng-device"
> > > +QB_RNG = "-device virtio-rng-device"
> > >  QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
> > >  QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@"
> > >  QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0"
> > 
> > Perhaps this is the wrong place to open this can of worms, so to speak,
> > but why is the beaglebone BSP also supporting QEMU, under the "virt"
> > machine that would be for qemuarm ?  It would be I think one thing to
> > make use of
> > https://qemu.readthedocs.io/en/latest/system/arm/sabrelite.html on the
> > appropriate machine.conf file and support running it that way as well.
> > But this isn't emulating the BSP hardware, it's just passing the
> > resulting rootfs image to qemu-system-arm.  If that's a general goal
> > now, shouldn't it be pushed up higher in the include files?
> 
> I think the general idea has been that if there is qemu emulation, it really
> should be actually emulating the hardware else it is different machine.

Well, what's any of the above doing in "beaglebone-yocto" ?  If it's not
under: https://qemu.readthedocs.io/en/latest/system/target-arm.html then
QEMU doesn't support emulating the hardware, and it belongs under
qemu*conf.  I've not poked meta-yocto-bsp to see if other platforms are
doing this.

> That said, I recognise that sometimes having a quick handy hack like this to
> test things is useful so I'm a little torn. I'm not sure we'd want to make it
> any more official or pushed into the tunes.

Documenting how to adjust qemuX so that it would otherwise match the
tune of your board, so that you can do some limited sanity testing,
would be useful, yes.  What's going on here is something I find quite
puzzling.

-- 
Tom

Re: [PATCH 1/2] beaglebone-yocto: use correct CPU and QB_RNG

[Jon Mason]

Please drop this patch.  There is a bug in it.  cortex-a8 doesn't work
with the virt machine.  Also, it is still lacking the serial settings
to get it working properly.  I have a patch now that is working, but
actually waiting for CI to pass before sending it this time.

Thanks,
Jon

On Thu, Oct 14, 2021 at 10:31 AM Jon Mason <jdmason@kudzu.us> wrote:
>
> The beagles use the AM3358 SoC, which is an Arm Cortex-A8.  Use that for
> QB_CPU.  Also, use QB_RNG to specify the random number generator device.
> Finally, correct the image deps to get qemu to run.
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
> ---
>  meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> index b3d960a8cd80..06746afa96ae 100644
> --- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> +++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> @@ -41,16 +41,16 @@ MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
>  IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${KERNEL_DEVICETREE}"
>
>  # support runqemu
> -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
> +EXTRA_IMAGEDEPENDS += "qemu-system-native qemu-helper-native:do_addto_recipe_sysroot"
>  IMAGE_CLASSES += "qemuboot"
>  QB_DEFAULT_FSTYPE = "wic"
>  QB_FSINFO = "wic:no-kernel-in-fs"
>  QB_KERNEL_ROOT = "/dev/vda2"
>  QB_SYSTEM_NAME = "qemu-system-arm"
>  QB_MACHINE = "-machine virt"
> -QB_CPU = "-cpu cortex-a15"
> +QB_CPU = "-cpu cortex-a8"
>  QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0 systemd.mask=systemd-networkd"
> -QB_OPT_APPEND = "-device virtio-rng-device"
> +QB_RNG = "-device virtio-rng-device"
>  QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
>  QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@"
>  QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0"
> --
> 2.20.1
>

Re: [poky] [PATCH 1/2] beaglebone-yocto: use correct CPU and QB_RNG

[Tom Rini]

On Tue, Oct 19, 2021 at 10:38:57AM -0400, Jon Mason wrote:

> Please drop this patch.  There is a bug in it.  cortex-a8 doesn't work
> with the virt machine.  Also, it is still lacking the serial settings
> to get it working properly.  I have a patch now that is working, but
> actually waiting for CI to pass before sending it this time.

I guess I'll re-ask, given the rest of the thread.  As this isn't, and
can't, emulate the beaglebone in QEMU, should we not just drop all of
these runqemu related options?

-- 
Tom

Re: [poky] [PATCH 1/2] beaglebone-yocto: use correct CPU and QB_RNG

[Jon Mason]

On Thu, Oct 14, 2021 at 6:51 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Oct 14, 2021 at 11:45:14PM +0100, Richard Purdie wrote:
> > On Thu, 2021-10-14 at 13:34 -0400, Tom Rini wrote:
> > > On Thu, Oct 14, 2021 at 10:31:23AM -0400, Jon Mason wrote:
> > >
> > > > The beagles use the AM3358 SoC, which is an Arm Cortex-A8.  Use that for
> > > > QB_CPU.  Also, use QB_RNG to specify the random number generator device.
> > > > Finally, correct the image deps to get qemu to run.
> > > >
> > > > Signed-off-by: Jon Mason <jdmason@kudzu.us>
> > > > ---
> > > >  meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > > > index b3d960a8cd80..06746afa96ae 100644
> > > > --- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > > > +++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > > > @@ -41,16 +41,16 @@ MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
> > > >  IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${KERNEL_DEVICETREE}"
> > > >
> > > >  # support runqemu
> > > > -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
> > > > +EXTRA_IMAGEDEPENDS += "qemu-system-native qemu-helper-native:do_addto_recipe_sysroot"
> > > >  IMAGE_CLASSES += "qemuboot"
> > > >  QB_DEFAULT_FSTYPE = "wic"
> > > >  QB_FSINFO = "wic:no-kernel-in-fs"
> > > >  QB_KERNEL_ROOT = "/dev/vda2"
> > > >  QB_SYSTEM_NAME = "qemu-system-arm"
> > > >  QB_MACHINE = "-machine virt"
> > > > -QB_CPU = "-cpu cortex-a15"
> > > > +QB_CPU = "-cpu cortex-a8"
> > > >  QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0 systemd.mask=systemd-networkd"
> > > > -QB_OPT_APPEND = "-device virtio-rng-device"
> > > > +QB_RNG = "-device virtio-rng-device"
> > > >  QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
> > > >  QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@"
> > > >  QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0"
> > >
> > > Perhaps this is the wrong place to open this can of worms, so to speak,
> > > but why is the beaglebone BSP also supporting QEMU, under the "virt"
> > > machine that would be for qemuarm ?  It would be I think one thing to
> > > make use of
> > > https://qemu.readthedocs.io/en/latest/system/arm/sabrelite.html on the
> > > appropriate machine.conf file and support running it that way as well.
> > > But this isn't emulating the BSP hardware, it's just passing the
> > > resulting rootfs image to qemu-system-arm.  If that's a general goal
> > > now, shouldn't it be pushed up higher in the include files?
> >
> > I think the general idea has been that if there is qemu emulation, it really
> > should be actually emulating the hardware else it is different machine.
>
> Well, what's any of the above doing in "beaglebone-yocto" ?  If it's not
> under: https://qemu.readthedocs.io/en/latest/system/target-arm.html then
> QEMU doesn't support emulating the hardware, and it belongs under
> qemu*conf.  I've not poked meta-yocto-bsp to see if other platforms are
> doing this.
>
> > That said, I recognise that sometimes having a quick handy hack like this to
> > test things is useful so I'm a little torn. I'm not sure we'd want to make it
> > any more official or pushed into the tunes.
>
> Documenting how to adjust qemuX so that it would otherwise match the
> tune of your board, so that you can do some limited sanity testing,
> would be useful, yes.  What's going on here is something I find quite
> puzzling.

What I'm taking from this is that because it's not actually emulating
the hardware, it's not any more useful than the qemu machines in
oe-core.  If that is the case, should we simply remove all of the QB_*
entries?  If we do still want to use these, does it make sense to not
have the QB_* entries and simply reference the qemu machines in
meta/conf/machines for the architecture, as that would prevent these
from becoming stale?  I ask this because edgerouter doesn't have QB_*
entries and it's the only one here.

Also, does it make sense to have a unique layer (or perhaps part of
oe-core) where all of the Linux capable machines have a conf file and
are testable via runqemu/testimage?

Thanks,
Jon

>
> --
> Tom

Re: [poky] [PATCH 1/2] beaglebone-yocto: use correct CPU and QB_RNG

[Tom Rini]

On Tue, Oct 19, 2021 at 10:47:59AM -0400, Jon Mason wrote:
> On Thu, Oct 14, 2021 at 6:51 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Oct 14, 2021 at 11:45:14PM +0100, Richard Purdie wrote:
> > > On Thu, 2021-10-14 at 13:34 -0400, Tom Rini wrote:
> > > > On Thu, Oct 14, 2021 at 10:31:23AM -0400, Jon Mason wrote:
> > > >
> > > > > The beagles use the AM3358 SoC, which is an Arm Cortex-A8.  Use that for
> > > > > QB_CPU.  Also, use QB_RNG to specify the random number generator device.
> > > > > Finally, correct the image deps to get qemu to run.
> > > > >
> > > > > Signed-off-by: Jon Mason <jdmason@kudzu.us>
> > > > > ---
> > > > >  meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 6 +++---
> > > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > > > > index b3d960a8cd80..06746afa96ae 100644
> > > > > --- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > > > > +++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > > > > @@ -41,16 +41,16 @@ MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
> > > > >  IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${KERNEL_DEVICETREE}"
> > > > >
> > > > >  # support runqemu
> > > > > -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
> > > > > +EXTRA_IMAGEDEPENDS += "qemu-system-native qemu-helper-native:do_addto_recipe_sysroot"
> > > > >  IMAGE_CLASSES += "qemuboot"
> > > > >  QB_DEFAULT_FSTYPE = "wic"
> > > > >  QB_FSINFO = "wic:no-kernel-in-fs"
> > > > >  QB_KERNEL_ROOT = "/dev/vda2"
> > > > >  QB_SYSTEM_NAME = "qemu-system-arm"
> > > > >  QB_MACHINE = "-machine virt"
> > > > > -QB_CPU = "-cpu cortex-a15"
> > > > > +QB_CPU = "-cpu cortex-a8"
> > > > >  QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0 systemd.mask=systemd-networkd"
> > > > > -QB_OPT_APPEND = "-device virtio-rng-device"
> > > > > +QB_RNG = "-device virtio-rng-device"
> > > > >  QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
> > > > >  QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@"
> > > > >  QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0"
> > > >
> > > > Perhaps this is the wrong place to open this can of worms, so to speak,
> > > > but why is the beaglebone BSP also supporting QEMU, under the "virt"
> > > > machine that would be for qemuarm ?  It would be I think one thing to
> > > > make use of
> > > > https://qemu.readthedocs.io/en/latest/system/arm/sabrelite.html on the
> > > > appropriate machine.conf file and support running it that way as well.
> > > > But this isn't emulating the BSP hardware, it's just passing the
> > > > resulting rootfs image to qemu-system-arm.  If that's a general goal
> > > > now, shouldn't it be pushed up higher in the include files?
> > >
> > > I think the general idea has been that if there is qemu emulation, it really
> > > should be actually emulating the hardware else it is different machine.
> >
> > Well, what's any of the above doing in "beaglebone-yocto" ?  If it's not
> > under: https://qemu.readthedocs.io/en/latest/system/target-arm.html then
> > QEMU doesn't support emulating the hardware, and it belongs under
> > qemu*conf.  I've not poked meta-yocto-bsp to see if other platforms are
> > doing this.
> >
> > > That said, I recognise that sometimes having a quick handy hack like this to
> > > test things is useful so I'm a little torn. I'm not sure we'd want to make it
> > > any more official or pushed into the tunes.
> >
> > Documenting how to adjust qemuX so that it would otherwise match the
> > tune of your board, so that you can do some limited sanity testing,
> > would be useful, yes.  What's going on here is something I find quite
> > puzzling.
> 
> What I'm taking from this is that because it's not actually emulating
> the hardware, it's not any more useful than the qemu machines in
> oe-core.  If that is the case, should we simply remove all of the QB_*
> entries?  If we do still want to use these, does it make sense to not
> have the QB_* entries and simply reference the qemu machines in
> meta/conf/machines for the architecture, as that would prevent these
> from becoming stale?  I ask this because edgerouter doesn't have QB_*
> entries and it's the only one here.
> 
> Also, does it make sense to have a unique layer (or perhaps part of
> oe-core) where all of the Linux capable machines have a conf file and
> are testable via runqemu/testimage?

I'll leave anything definitive to Richard of course.  But my two cents
is that yes, unless it's one of the hardware platforms that qemu can
emulate AND we're actually testing it that way too, none of the machine
conf files should have QB_* entries, other than of course qemu* ones.  I
suspect (but could be quite wrong) that the only places that we might
have both qemu and physical hardware in the same machine conf file are
some Xilinx platforms (and I know they're very active on that front,
with my U-Boot hat on), and maybe some of the Arm Ltd platforms, as
those too are well tested via qemu in general.

-- 
Tom