EFIFB support next steps -> simpledrm ?!?

[tlaurion]

UNDONE:
Figure out what is missing for Q4.2 to be able to use efifb under dom0

• EFIFB support next steps -> simpledrm ?!? #1461 (comment)
• EFIFB support next steps -> simpledrm ?!? #1461 (comment)

---

• add https://review.coreboot.org/c/coreboot/+/76564/2 under coreboot 4.19 patches and other forks patches?
  • Add imagemagik into CircleCI apt dependencies so that any jpeg can be injected in rom, at condition that that jpeg is smaller then framebuffer (it will be centered in framebuffer per other patch).
• Push forks to add those coreboot patches (@krystian-hebel)
• Push Purism to add fbwhiptail patch so efifb/simplefb kernel driver can be used (works flawlessly) @JonathonHall-Purism done under libgfxinit/nativegfx init: efifb enforced fb (+coreboot ramstage enabled bootsplash) #1403
• Adapt nv41 and nv50 board once this libgfxinit/nativegfx init: efifb enforced fb (+coreboot ramstage enabled bootsplash) #1403 is merged (@daringer)
• Adapt all other configurations to use native res per board (tested under x230, no need to set 1376x768) done under libgfxinit/nativegfx init: efifb enforced fb (+coreboot ramstage enabled bootsplash) #1403
• Deactivate CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y
• Have QubesOS add coreboot tables so EFI->EFIFB can take ownership of fb early (otherwise happens at 20 seconds only when i915drmfb takes fb0 ownership see EFIFB support next steps -> simpledrm ?!? #1461 (comment)
  • Test newer Q4.2 iso that should fix inst.repo and integrate config: add coreboot framebuffer related settings QubesOS/qubes-linux-kernel#810
• remove all iommu options passed from coreboot to kernel to final os, enable iommu by default in Heads kernel.

Originally posted by @tlaurion in #1403 (comment) and modified here

[JonathonHall-Purism]

@tlaurion The 1366x768 patch is in fbwhiptail 1.2 🎉

[tlaurion]

@JonathonHall-Purism so I should add it under #1403? done.

• tested under x230-maximized without setting width and height to native resolution and letting max.

[tlaurion]

Also to be noted, dgpu flavors of t530/w530 are currently enabling optional rom in "insecure mode", where coreboot is said to be significantly slower initializing if we were to change the defaults to enable it:

CONFIG_PCI_OPTION_ROM_RUN_YABEL:                                                                                                              │  
  │                                                                                                                                               │  
  │ If you select this option, the x86emu CPU emulator will be used to                                                                            │  
  │ execute PCI Option ROMs.                                                                                                                      │  
  │                                                                                                                                               │  
  │ This option prevents Option ROMs from doing dirty tricks with the                                                                             │  
  │ system (such as installing SMM modules or hypervisors), but it is                                                                             │  
  │ also significantly slower than the native Option ROM initialization                                                                           │  
  │ method.                                                                                                                                       │  
  │                                                                                                                                               │  
  │ This is the default choice for non-x86 systems.

[tlaurion]

Seems like qubesos is not providing efifb in compiled kernels @marmarek ?

Would be a good idea to provide it so that early print messages can be shown on consoles prior of i915drmfb taking ownership of the framebuffer, otherwise messages show on console after i915drmfb is loaded and ownership of FB is active.

• open issue on qubesos side

[marmarek]

We do have CONFIG_FB_EFI=y in our kernel. But, there is also CONFIG_SYSFS_SIMPLEFB=y (which IIUC is the newer approach for the same thing).
That said, I'm a bit confused how it is supposed to work. Heads isn't booting OS via EFI entry point and does not synthesize EFI system table, no? So, how OS would use EFI for locating the framebuffer? What am I missing?

[marmarek]

And one more thing: dom0's kernel config isn't really relevant for early Xen messages. For that, there is a bunch of command line arguments, including vga=current which might be enough here. Xen does support getting framebuffer parameters via EFI, but again - I don't think this boot path is used under Heads at all.

[tlaurion]

We do have CONFIG_FB_EFI=y in our kernel. But, there is also CONFIG_SYSFS_SIMPLEFB=y (which IIUC is the newer approach for the same thing).
That said, I'm a bit confused how it is supposed to work. Heads isn't booting OS via EFI entry point and does not synthesize EFI system table, no? So, how OS would use EFI for locating the framebuffer? What am I missing?

@marmarek :
Since #1403 Heads avoids providing specific DRM/FB drivers, thanks to patches added to coreboot so that GOP/native GFX/vbios rom/libgfxinit offers a efifb compatible framebuffer to the kernel.

Heads kernel then kexec's into next kernel passing the FB address to next kernel, without needing to hack around newer kernel's restrictions not exposing addresses which otherwise required Heads to taint it's kernel exposing FB address (considered dangerous) and disabling framebuffer compression on i915drm module and a hack on kexec to force passing i915fb FB address as VLFB. Kexec detects Heads FB as efifb and gently provides the FB address to the next kernel without any previously needed hacks.

As if today (rudimentary testing booting latest 4.2 ISO with bug report since inst.repo is not found) Heads stays in the dark until i915drmfb takes ownership of the console.

Attempts under Heads to support simplefb didn't work since it is not possible to pass simplefb FB address through VLFB hack, there is no workaround permitting that driver to taint kernel in an insecure flashing like it is possible with i915drmfb.

I am confused into why simplefb is not kicking in prior of i915drmfb taking ownership of the FB under qubes as if now and will need to check this out.

You are right saying that OS deprecation plan for legacy boot support is to remove all advanced DRM drivers from their initrd, letting simplefb, simpledrm and efifb there for the moment, leaving initrd construction with proper advanced drm modules enablement to the final installed OS to construct it from detected GPUs.

Installation media consequently provide/will provide simpledrm/simplefb/efifb to not bloat initrd/unified kernels with all DRM/FB drivers that exist anymore and rely on UEFI to at least provide efifb compatible drivers which can after that be switched to simplefb/simpledrm or more advanced DRM drivers.

[tlaurion]

And one more thing: dom0's kernel config isn't really relevant for early Xen messages. For that, there is a bunch of command line arguments, including vga=current which might be enough here. Xen does support getting framebuffer parameters via EFI, but again - I don't think this boot path is used under Heads at all.

@marmarek AFAIK coreboot tables are now exposed but this is irrelevant here? How to check I'm not presently aware

[tlaurion]

We do have CONFIG_FB_EFI=y in our kernel. But, there is also CONFIG_SYSFS_SIMPLEFB=y (which IIUC is the newer approach for the same thing).
That said, I'm a bit confused how it is supposed to work. Heads isn't booting OS via EFI entry point and does not synthesize EFI system table, no? So, how OS would use EFI for locating the framebuffer? What am I missing?

@marmarek : Since #1403 Heads avoids providing specific DRM/FB drivers, thanks to patches added to coreboot so that GOP/native GFX/vbios rom/libgfxinit offers a efifb compatible framebuffer to the kernel.

Heads kernel then kexec's into next kernel passing the FB address to next kernel, without needing to hack around newer kernel's restrictions not exposing addresses which otherwise required Heads to taint it's kernel exposing FB address (considered dangerous) and disabling framebuffer compression on i915drm module and a hack on kexec to force passing i915fb FB address as VLFB. Kexec detects Heads FB as efifb and gently provides the FB address to the next kernel without any previously needed hacks.

As if today (rudimentary testing booting latest 4.2 ISO with bug report since inst.repo is not found) Heads stays in the dark until i915drmfb takes ownership of the console.

Attempts under Heads to support simplefb didn't work since it is not possible to pass simplefb FB address through VLFB hack, there is no workaround permitting that driver to taint kernel in an insecure flashing like it is possible with i915drmfb.

I am confused into why simplefb is not kicking in prior of i915drmfb taking ownership of the FB under qubes as if now and will need to check this out.

You are right saying that OS deprecation plan for legacy boot support is to remove all advanced DRM drivers from their initrd, letting simplefb, simpledrm and efifb there for the moment, leaving initrd construction with proper advanced drm modules enablement to the final installed OS to construct it from detected GPUs.

Installation media consequently provide/will provide simpledrm/simplefb/efifb to not bloat initrd/unified kernels with all DRM/FB drivers that exist anymore and rely on UEFI to at least provide efifb compatible drivers which can after that be switched to simplefb/simpledrm or more advanced DRM drivers.

Maybe its more practical to see with an example!

Under Heads linux-qemu.config under master, here is when the framebuffer is owned by efifb (QEMU TCG here, since qemu under Qubes so cannot have kvm).

Using rdosreport.txt shared under QubesOS/qubes-issues#8443

~ # cat rdsosreport.txt | grep -ie kernel -ie xen | grep -ie efi -ie fb -ie vga -ie 0000:00:02.0
[    1.332133] localhost kernel: clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
[    1.838870] localhost kernel: clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[    1.919100] localhost kernel: fbcon: Taking over console
[    1.929042] localhost kernel: pci 0000:00:02.0: [8086:0166] type 00 class 0x030000
[    1.929107] localhost kernel: pci 0000:00:02.0: reg 0x10: [mem 0x82c00000-0x82ffffff 64bit]
[    1.929152] localhost kernel: pci 0000:00:02.0: reg 0x18: [mem 0x90000000-0x9fffffff 64bit pref]
[    1.929185] localhost kernel: pci 0000:00:02.0: reg 0x20: [io  0x1000-0x103f]
[    1.929259] localhost kernel: pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[    1.952993] localhost kernel: pci 0000:00:02.0: vgaarb: setting as boot VGA device
[    1.952993] localhost kernel: pci 0000:00:02.0: vgaarb: bridge control possible
[    1.952993] localhost kernel: pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[    1.953005] localhost kernel: vgaarb: loaded
[   19.375778] localhost kernel: i915 0000:00:02.0: [drm] VT-d active for gfx access
[   19.375889] localhost kernel: i915 0000:00:02.0: vgaarb: deactivate vga console
[   19.468365] localhost kernel: i915 0000:00:02.0: [drm] Transparent Hugepage support is recommended for optimal performance when IOMMU is enabled!
[   19.468380] localhost kernel: i915 0000:00:02.0: [drm] DMAR active, disabling use of stolen memory
[   19.577394] localhost kernel: i915 0000:00:02.0: [drm] Skipping intel_backlight registration
[   19.578870] localhost kernel: [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[   19.872710] localhost kernel: fbcon: i915drmfb (fb0) is primary device
[   20.700506] localhost kernel: i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device

fb0 is redrawn on screen at around 20s on real hardware and around 5s on qemu.
Qubes kernel doesn't know how to draw on screen prior of i915drmfb kicking in.

---

Under Heads, it required us to make the kernel config aware of EFI and coreboot tables, and enable efifb.

You can see the changes that were required under https://github.com/osresearch/heads/pull/1403/files#diff-816b79cd9a1192fa8cf78b9737f0d3fed5a943a0d2c952da591f8a2446edc1db

@marmarek :

• Yes, the kernel needs to be EFI compatible (CONFIG_EFI=y) for efifb to even try to initialize fb
• Coreboot tables awareness needs to be activated in kernel (CONFIG_GOOGLE_COREBOOT_TABLE=y)
• And then, EFI->EFIFB will pick up fb early, and then i915drmfb will take ownership later on. The user will get fb really early.

[tlaurion]

@marmarek interesting https://forum.qubes-os.org/t/how-to-kexec-into-qubes-from-linux-livecd/17712/22

Might explain why marmarek/qubes-linux-kernel@c4ff0e4 is not enough

@JonathonHall-Purism any hunch?

The kexec with/without ebda hack works if I use QEMU with BIOS and multiboot2 (default for kexec > v2.0.22).

Important bits of the table there:

QEMU	BIOS/UEFI	multiboot/multiboot2	ebda hack	Xen patch	kexec works
Yes	BIOS	multiboot2	Yes/No	No	Yes
Yes	BIOS	multiboot	Yes	No	Yes
Yes	UEFI	multiboot	Yes	Yes	Yes
Yes	BIOS	multiboot	No	No	No
Yes	UEFI	multiboot2	Yes/No	Yes	No
Yes	UEFI	multiboot	No	Yes	No

[tlaurion]

Hmmm 2.0.27 supports device tree horms/kexec-tools@806711f

 x86: add devicetree support

Since linux kernel has dropped support for simple firmware interface
(SFI), the only way of boot newer versions on intel MID platform is
using devicetree

Also note that EBDA patch was under Heads kexec 2.0.26 but was dropped for a little while on 2.0.22

EDIT: trace of this put in branch https://github.com/tlaurion/heads/tree/enable_efi_compatibility_for_xen_efifb for further improvements