qemu_x86 's SeaBIOS clears the screen every time it runs

[andrewboie]

Steps to reproduce:

Build and run any test case for qemu_x86.
Observe that the screen is cleared before the emulator prints any output.

Expected behavior:

Screen is not cleared

Impact:

This is VERY annoying when using 'sanitycheck -i' as we can't see a proper log of all the output of all the failing test cases.

Only QEMU on x86 seems to be affected.

[nashif]

not a zephyr bug, did not find any way to change this behavior in qemu.

[marc-hb]

• SeaBIOS does this, will edit description.
• SeaBIOS also breaks my macOS terminal (fixed with tput smam a.k.a.` Automatic Margins, no idea why).
• SeaBIOS's message "Booting ...." also races with Zephyr's boot banner which makes test logs non-deterministic. There are plenty tests which have non deterministic logs but SeaBIOS makes ALL test logs non-deterministic.

[marc-hb]

I found this great workaround, recommended:

export QEMU_EXTRA_FLAGS="-bios $HOME/OVMF_CODE-32.fd"

I looked into making this the default but hit two issues:

1.a Different Linux distributions package OVMF differently (or not at all?). Zephyr could probably re-package it though, maybe in the SDK next to Qemu
1.b The -bios option requires write permission on the OVMF.fd file.

2 QEMU_EXTRA_FLAGS is not per-arch and I couldn't get any combination to work with qemu_x86_64. Funny enough all other archs are unaffected, I think all other qemus just silently drop the -bios option.

Considering qemu -kernel zephyr.elf doesn't even need a BIOS (thanks @andyross and @inakypg for teaching me this), I wonder whether something like -bios /dev/null would be possible, any QEMU expert knows?

Mentioning this much longer alternative to -bios for completeness, also works. Not sure which is "best" or why:

QEMU_EXTRA_FLAGS="-drive file=${HOME}/OVMF_CODE-32.fd,if=pflash,format=raw"

[marc-hb]

Forgot to mention this: OVMF makes sanitycheck 10-20% faster than SeaBIOS when JOBS is small, say below 20 threads. The higher is JOBS and the smaller the speedup, negligible after say 80 threads.

[andrewboie]

SeaBIOS also breaks my macOS terminal

Messes up my Linux terminal as well.
It's subtle, basically after showing any QEMU output, long lines do not wrap any more. A 'reset' command fixes it. I imagine one of the escape codes in the SeaBIOS message has something to do with it.

I wonder whether something like -bios /dev/null would be possible, any QEMU expert knows?

Worth trying. Definitely don't need a BIOS, we handle matters from the reset vector onwards. [edit:] Not strictly true. Something in QEMU transfers the PC to the ENTRY point in the ELF binary. Don't believe the BIOS has any involvement though,

[nashif]

@marc-hb I tried with OVMF_CODE.fd, but it does not work or boot into qemu. This is the one I copied from the ovmf package:

/usr/share/edk2/ovmf-ia32/OVMF_CODE.fd

Any hints?

[marc-hb]

Any hints?

Yes. It recently stopped working for me too and I bisected it at the qemu flash size commit above. I asked there but no answer.

[andyross]

That patch just reorganizes the memory map of the emulated hardware and allows Zephyr to use more of it (and potentially modifies where things get placed, though I'd have to check link results to be sure).

One possibility is that OVMF is actually using some of that memory, and that it's doing something important when qemu comes alone and scribbles over memory with the imaged passed in the -kernel argument.

Qemu's -kernel is sort of weird: it doesn't coordinate with normal firmware boot at all AFAIK, it just writes an image into place and arranges to force the PC to point to the entry point. But it has to do that "after" the firmware has tried to do something sane (because you have to allow the BIOS to get the machine ready), and it's possible that this detection gets fouled up somehow by the change in memory map.

It's an idea anyway. Alas we don't really have a serious qemu expert in zephyr to answer questions like this, and we really need one.

[gvancuts]

Hi @marc-hb , not sure how I can help with this issue? I'm not much of a QEMU expert. But if you have something you'd like me to test, I'm happy to!

[marc-hb]

not sure how I can help with this issue? I'm not much of a QEMU expert.

I saw some of your GRUB-related work so I thought you could maybe find some documentation about booting Zephyr "for real", without any qemu -kernel shortcut / hack.

[marc-hb]

Googling a bit more I found that Clear Linux has already solved this
here https://download.clearlinux.org/image/ OVMF.fd

zephyr-sdk-0.10.0/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-x86_64 -bios boots this OVMF.fd to the EFI shell and -kernel zephyr-qemu.elf is ignored.

UPDATED: based on that old discussion https://lists.gnu.org/archive/html/qemu-devel/2016-03/threads.html#04844 I first thought Clear Linux used -kernel but apparently not.

Interesting bit from https://download.clearlinux.org/image/ start_qemu.sh

# 10/25/2018: keep back compatibility for a while
UEFI_BIOS="-bios OVMF.fd"

if [ -f OVMF_VARS.fd -a -f OVMF_CODE.fd ]; then
    UEFI_BIOS=" -drive file=OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on "
    UEFI_BIOS+=" -drive file=OVMF_VARS.fd,if=pflash,format=raw,unit=1 "
fi

[marc-hb]

Here's my newest and... greatest workaround. Totally unrelated to OVMF.

    find sanity-out -name handler.log | while read -r HLOG; do
         sed -i -e '1,5 s/.*SeaBIOS/SeaBIOS/' \
  -e 's/Booting from ROM.*Booting Zephyr/Booting from ROM...\r\n***** Booting Zephyr/' \
             "$HLOG"
     done

This removes the control characters from log files (and makes them deterministic).

Hope it helps.

[nashif]

Here's my newest and... greatest workaround.

???

[pfalcon]

Weird I didn't see this year-old issue, I'm suffering from it all this time.

To remind a short history with qemu_x86 options: we used to have different set of options, which didn't use SeaBIOS and thus didn't clear screen. But that config had its own weird issues and corner cases, e.g. we had issues with #9112, which worked for the original author, but not for folks who tried to test it. So, there were a series of refactors and fixes to QEMU options (e.g. #11710) to clean it up, side effect of which was this screen clearing issues with SeaBIOS. I played with it for some time then to see if something can be done to both get right PCI config and no SeaBIOS, but couldn't get it at that time.

Anyway, I have high hopes for zephyrproject-rtos/sdk-ng#124