linux-yocto: add drm-bochs support
PATCH 1/3 linux-yocto: add drm-bochs support
This allows better modesetting support for the '-vga std' emulated hardware provided by Qemu, which we want to standardize on.
See here for background:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466
--- meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.19.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_5.0.bb | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-)
meta/recipes-kernel/linux/linux-yocto-dev.bb +1 -1
@@ -46,7 +46,7 @@ KERNEL_DEVICETREE_qemuarmv5 = "versatile-pb.dtb" # Functionality flags KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc" KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" -KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc" +KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc features/drm-bochs/drm-bochs.scc" KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc" KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " cfg/x32.scc", "" ,d)}"
meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb +1 -1
@@ -38,7 +38,7 @@ KERNEL_DEVICETREE_qemuarmv5 = "versatile-pb.dtb" # Functionality flags KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc" KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" -KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc" +KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc features/drm-bochs/drm-bochs.scc" KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" KERNEL_FEATURES_append = "${@bb.utils.contains("DISTRO_FEATURES", "ptest", " features/scsi/scsi-debug.scc", "" ,d)}"
meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb +1 -1
@@ -38,7 +38,7 @@ KERNEL_DEVICETREE_qemuarmv5 = "versatile-pb.dtb" # Functionality flags KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc" KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" -KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc" +KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc features/drm-bochs/drm-bochs.scc" KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" KERNEL_FEATURES_append = "${@bb.utils.contains("DISTRO_FEATURES", "ptest", " features/scsi/scsi-debug.scc", "" ,d)}"
meta/recipes-kernel/linux/linux-yocto_4.19.bb +1 -1
@@ -43,7 +43,7 @@ COMPATIBLE_MACHINE = "qemuarm|qemuarmv5|qemuarm64|qemux86|qemuppc|qemumips|qemum # Functionality flags KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc" KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" -KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc" +KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc features/drm-bochs/drm-bochs.scc" KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " cfg/x32.scc", "" ,d)}"
meta/recipes-kernel/linux/linux-yocto_5.0.bb +1 -1
@@ -47,7 +47,7 @@ COMPATIBLE_MACHINE = "qemuarm|qemuarmv5|qemuarm64|qemux86|qemuppc|qemumips|qemum # Functionality flags KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc" KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" -KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc" +KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc features/drm-bochs/drm-bochs.scc" KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " cfg/x32.scc", "" ,d)}"
Signature · 1 line
2.17.1
PATCH 2/3 qemuboot.bbclass: increase the default RAM to 512M
This was already the case for various specific qemu machines, and 256M was found to be no longer sufficient for x86 either when switching X from vmware to standard vga+bochs vesa driver as provided by qemu (Xorg would then attempt to clone() itself with ENOMEM returned).
Let's just accept this new reality :)
--- meta/classes/qemuboot.bbclass | 2 +- meta/conf/machine/include/qemuboot-mips.inc | 1 - meta/conf/machine/include/riscv/qemuriscv.inc | 1 - meta/conf/machine/qemuarm.conf | 1 - meta/conf/machine/qemuarm64.conf | 1 - 5 files changed, 1 insertion(+), 5 deletions(-)
meta/classes/qemuboot.bbclass +1 -1
@@ -57,7 +57,7 @@ # IMAGE_CLASSES += "qemuboot" # See "runqemu help" for more info -QB_MEM ?= "-m 256" +QB_MEM ?= "-m 512" QB_SERIAL_OPT ?= "-serial mon:stdio -serial null" QB_DEFAULT_KERNEL ?= "${KERNEL_IMAGETYPE}" QB_DEFAULT_FSTYPE ?= "ext4"
meta/conf/machine/include/qemuboot-mips.inc +0 -1
@@ -1,6 +1,5 @@ # For runqemu IMAGE_CLASSES += "qemuboot" -QB_MEM = "-m 256" QB_MACHINE = "-machine malta" QB_KERNEL_CMDLINE_APPEND = "console=ttyS0 console=tty" QB_OPT_APPEND = "-vga cirrus -show-cursor -usb -device usb-tablet"
meta/conf/machine/include/riscv/qemuriscv.inc +0 -1
@@ -24,7 +24,6 @@ UBOOT_ENTRYPOINT_riscv64 = "0x80200000" # qemuboot options QB_KERNEL_CMDLINE_APPEND = "earlycon=sbi" -QB_MEM = "-m 512" QB_MACHINE = "-machine virt" QB_DEFAULT_KERNEL = "fw_jump.elf" QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
meta/conf/machine/qemuarm.conf +0 -1
@@ -11,7 +11,6 @@ SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0" # For runqemu QB_SYSTEM_NAME = "qemu-system-arm" -QB_MEM = "-m 512" QB_MACHINE = "-machine virt" QB_CPU = "-cpu cortex-a15" # Standard Serial console
meta/conf/machine/qemuarm64.conf +0 -1
@@ -11,7 +11,6 @@ SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0" # For runqemu QB_SYSTEM_NAME = "qemu-system-aarch64" -QB_MEM = "-m 512" QB_MACHINE = "-machine virt" QB_CPU = "-cpu cortex-a57" QB_CPU_KVM = "-cpu host"
Signature · 1 line
2.17.1
Re: [PATCH 2/3] qemuboot.bbclass: increase the default RAM to 512M
Quoted 7 lines · Alexander Kanavin
This was already the case for various specific qemu machines, and 256M was found to be no longer sufficient for x86 either when switching X from vmware to standard vga+bochs vesa driver as provided by qemu (Xorg would then attempt to
clone()itself with ENOMEM returned).Let's just accept this new reality :)
I'm not sure I agree with this.
We are meant to work on embedded systems and 256MB should be enough to let us bring up X under qemu.
I'm fine with some sdk/ptest images having more memory, that makes sense but 256MB not allowing X under qemu seems rather poor.
Are we really saying the minimal image size we can emulate is 256MB ram?
Cheers,
Richard
Re: [PATCH 2/3] qemuboot.bbclass: increase the default RAM to 512M
Quoted 11 lines · Richard Purdie
I'm not sure I agree with this.
We are meant to work on embedded systems and 256MB should be enough to let us bring up X under qemu.
I'm fine with some sdk/ptest images having more memory, that makes sense but 256MB not allowing X under qemu seems rather poor.
Are we really saying the minimal image size we can emulate is 256MB ram?
Note that riscv/arm/arm64 qemu configs *already* override this setting to 512M, as seen in the patch (and so does meta-yocto-bsp/conf/machine/beaglebone-yocto.conf), so this simply brings x86/mips/ppc as well to that level.
In our local development we have bumped it even to 2048M, because with 256M there are cryptic boot failures (that have nothing to do with X), and the final SoC target will have far more memory anyway. Embedded does not necessarily mean "not a lot of RAM".
If there is a need to test tight-memory scenarios, that can be adjusted per-image (or per-distro like poky-tiny), but I would argue that the default should be such that no one has to stare at mysterious error messages that are ultimately due to lack of RAM. It is not easy to diagnose such situations, e.g. the error message here was "unable to execute xkbcomp", so I had to rebuild the image with strace, and then run X under it to see that the problem was clone() returning with ENOMEM. We'll be surely seeing more of the same as software bloat marches on.
Alex
Re: [PATCH 2/3] qemuboot.bbclass: increase the default RAM to 512M
In reply to Richard PurdieQuoted 8 lines · Richard Purdie
I'm not sure I agree with this.
We are meant to work on embedded systems and 256MB should be enough to let us bring up X under qemu.
I'm fine with some sdk/ptest images having more memory, that makes sense but 256MB not allowing X under qemu seems rather poor.
I poked a bit more at this. The main difference between vmware emulated hardware and std emulated hardware is that X uses the standard 2D framebuffer interface for the former, and the full 3D stack for the latter (via use of glamor: https://www.freedesktop.org/wiki/Software/Glamor/). The 3D stack (mesa and friends) is what causes the memory usage to swell.
It is possible to disable this behaviour and enforce framebuffer usage (see 'man modesetting'), and I have verified that the RAM usage drops to similar levels as vmware, but that is not the upstream default; they have more or less obsoleted 2D drivers and are defaulting to 3D rendering nowadays. I'd rather follow that.
Alex
Re: [PATCH 2/3] qemuboot.bbclass: increase the default RAM to 512M
Maybe we should drop x11 from default DISTRO_FEATURES :)
Will resolve the memory consumption and image size.
Well the image size isn't much different, I was just surprised to see libx11 being included even in core-image-minimal (because systemd -> dbus -> libx11: "dbus.do_package" -> "libx11.do_packagedata"), but in the end the difference in ext4 was only 2MB (61MB/63MB), caused by following 4 packages:
libx11-6 core2-64 1:1.6.8-r0.0
libxau6 core2-64 1:1.0.9-r0.15
libxcb1 core2-64 1.13.1-r0.15
libxdmcp6 core2-64 1:1.1.3-r0.15
so I guess embedded no longer have neither small ram nor small flash.
Quoted 33 lines · Alexander Kanavin
Quoted 8 lines · Richard Purdie
I'm not sure I agree with this.
We are meant to work on embedded systems and 256MB should be enough to let us bring up X under qemu.
I'm fine with some sdk/ptest images having more memory, that makes sense but 256MB not allowing X under qemu seems rather poor.
I poked a bit more at this. The main difference between vmware emulated hardware and std emulated hardware is that X uses the standard 2D framebuffer interface for the former, and the full 3D stack for the latter (via use of glamor: https://www.freedesktop.org/wiki/Software/Glamor/).
The 3D stack (mesa and friends) is what causes the memory usage to swell.It is possible to disable this behaviour and enforce framebuffer usage (see 'man modesetting'), and I have verified that the RAM usage drops to similar levels as vmware, but that is not the upstream default; they have more or less obsoleted 2D drivers and are defaulting to 3D rendering nowadays. I'd rather follow that.
Alex
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
PATCH 3/3 qemu: switch to '-vga std' emulated hardware from vmware/cirrus for x86/mips
In reply to Alexander KanavinThis is the qemu default since qemu 2.2, is generally supported better, and is recommended by upstream. It also has already been in use for arm/risc and ovmf.
Additional information:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466
https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
'-vga virtio' emulated hardware remains in use when virgl is enabled via a runqemu override.
--- meta/conf/machine/include/qemuboot-mips.inc | 2 +- meta/conf/machine/include/qemuboot-x86.inc | 2 +- meta/conf/machine/qemux86-64.conf | 1 + meta/conf/machine/qemux86.conf | 1 + scripts/runqemu | 6 ------ 5 files changed, 4 insertions(+), 8 deletions(-)
meta/conf/machine/include/qemuboot-mips.inc +1 -1
@@ -2,7 +2,7 @@ IMAGE_CLASSES += "qemuboot" QB_MACHINE = "-machine malta" QB_KERNEL_CMDLINE_APPEND = "console=ttyS0 console=tty" -QB_OPT_APPEND = "-vga cirrus -show-cursor -usb -device usb-tablet" +QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet" # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0" QB_SYSTEM_NAME = "qemu-system-${TUNE_ARCH}"
meta/conf/machine/include/qemuboot-x86.inc +1 -1
@@ -9,7 +9,7 @@ QB_CPU_KVM_x86-64 = "-cpu core2duo" QB_AUDIO_DRV = "alsa" QB_AUDIO_OPT = "-soundhw ac97,es1370" QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=${UVESA_MODE} oprofile.timer=1 uvesafb.task_timeout=-1" -QB_OPT_APPEND = "-vga vmware -show-cursor -usb -device usb-tablet" +QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet" # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0"
meta/conf/machine/qemux86-64.conf +1 -0
@@ -24,6 +24,7 @@ XSERVER = "xserver-xorg \ xf86-video-fbdev \ xf86-video-vmware \ xf86-video-modesetting \ + xf86-video-vesa \ xserver-xorg-module-libint10 \ "
meta/conf/machine/qemux86.conf +1 -0
@@ -24,6 +24,7 @@ XSERVER = "xserver-xorg \ xf86-video-fbdev \ xf86-video-vmware \ xf86-video-modesetting \ + xf86-video-vesa \ xserver-xorg-module-libint10 \ "
scripts/runqemu +0 -6
@@ -145,8 +145,6 @@ class BaseConfig(object): # to be added with -drive if=pflash. # Found in the same places as the rootfs, with or without one of # these suffices: qcow2, bin. - # Setting one also adds "-vga std" because that is all that - # OVMF supports. self.ovmf_bios = [] # When enrolling default Secure Boot keys, the hypervisor # must provide the Platform Key and the first Key Exchange Key
@@ -1280,10 +1278,6 @@ class BaseConfig(object): for ovmf in self.ovmf_bios: format = ovmf.rsplit('.', 1)[-1] self.qemu_opt += ' -drive if=pflash,format=%s,file=%s' % (format, ovmf) - if self.ovmf_bios: - # OVMF only supports normal VGA, i.e. we need to override a -vga vmware - # that gets added for example for normal qemux86. - self.qemu_opt += ' -vga std' self.qemu_opt += ' ' + self.qemu_opt_script
Signature · 1 line
2.17.1
Quoted 7 lines · Alexander Kanavin
This allows better modesetting support for the '-vga std' emulated hardware provided by Qemu, which we want to standardize on.
See here for background:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466
Quoted 8 lines
Signed-off-by Alexander Kanavin <[email protected]>--- meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.19.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_5.0.bb | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-)
https://autobuilder.yoctoproject.org/typhoon/#/builders/41/builds/929
Cheers,
Richard
Quoted 18 lines · Richard Purdie
Quoted 7 lines · Alexander Kanavin
This allows better modesetting support for the '-vga std' emulated hardware provided by Qemu, which we want to standardize on.
See here for background:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466Quoted 8 lines
Signed-off-by Alexander Kanavin <[email protected]>--- meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.19.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_5.0.bb | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-)
4.19 didn't have the drm-bochs fragment. I just cherry picked it to the branch and pushed it to the repo. I'll send a SRCREV bump for the 4.19 meta data shortly that should fix it, and this patch can stay as-is.
Bruce
Quoted 10 lines
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 3 lines
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II