X230 - working fbwhiptail support

[tlaurion]

Changes required for the x230 to boot fbwhiptail.

[osresearch]

Does this change the startup time significantly? I recall testing with the x230 i915 driver and seeing five seconds before anything was displayed.

[osresearch]

Also need to check the size of the resulting kernel against the x230 flasher image -- it shares the same config/linux-x230.config file.

[tlaurion]

EDIT: This is functioning now.
@osresearch : There are glitches. There is 3 flickering phases, totalizing around 10s, between kexec of xen and linux kernel initializing the DRM fb itself. There is also a 5 seconds delay before heads showing up with fbwhiptail.

Not sure just enabling DRM is the good way to do it.
Discussion here
@kakaroto said:

I use the DRM interface for drawing on the framebuffer, I also had a linuxfb 'driver' to draw the cairo surface into /dev/fb but since on my machine, it didn't support double buffering (which caused horrible tearing at every refresh), that's why I implemented the DRM 'driver'.
So, your issue here is either because you use the VGA text framebuffer, which means the framebuffer doesn't work/exist, or because your kernel driver doesn't support the DRI interface at all and you should use the linuxfb driver (which I removed, so I'd need to commit that back and make it use it if DRI fails).
You can check if there's a /dev/dri/card0 device on your machine, and you could also define DRI_DEBUG in fbwhiptail/cairo_dri.c and recompile, see if the debugging information from DRI are more helpful (no DRI card, no screens, no valid modes, etc...)

EDIT: I think that even if coreboot initializes the graphics in vga text mode, it won't matter, once the i915 kernel driver of heads loads up, it will set it up differently, no ? In the case of the librem, we don't include the vgabios or vbt, and we don't do any graphics initialization in coreboot, the i915 driver does it for us once Heads is loaded, and that saves some time in boot time from coreboot not initializing the GPU needlessly

[paulmenzel]

Why is a module not enough? Because no initrd is used?

[tlaurion]

Exactly.

[paulmenzel]

Nice, but could you please elaborate on the commit Reduce required changes to minimum to x230 Linux config. It says Reduce, but the configuration is extended.

Additionally, it’d be great if you could statements as the commit message summaries, that means, start with a verb in imperative mood. But that’s only my preference.

[tlaurion]

Nice, but could you please elaborate on the commit Reduce required changes to minimum to x230 Linux config. It says Reduce, but the configuration is extended.

Those additional config parameters are added when i915 DRM is activated. This is what I meant by "reduced Linux changes to minimum" for fbwhiptail to function, with glitches I do not know how to fix. @kakaroto told there was a fb module in fbwhiptail that could work?

As previously said, this adds a total of 15 seconds and garbage on the screen. If there is no way of passing the fb from linux payload to kexec'd one, i'm not sure this is better then going with the console based whiptail option (based on NEWT and SLANG options).

[kakaroto]

I just added back the linux FB support in fbwhiptail @da306967
Try disabling the i915 driver again (and re-enable the vga init from coreboot) and see if it works. I assume there will be a /dev/fb0 in Heads (if not, then maybe don't init vga in text mode?).
I had to make it try double buffering and fall back on single buffering if it doesn't work because on my machine I can't get it to support double buffering.
If it works, then you can use that and not enable i915 which should speed back your boot time.
Just rm -rf build/fbwhiptail and rebuild it so it fetches the latest from git.
Let me know how it works (or not) for you with the fb driver (which hasn't been tested as much) and if you have fixes for it, then patches are welcome! :)

[tlaurion]

Failing attempts to date: https://github.com/tlaurion/heads/tree/x230_fbwhiptail

[kakaroto]

@tlaurion How does it fail exactly ? Do you get a /dev/dri/card0 device in heads or not? if not, do you get a /dev/fb? What errors does it print when you run fbwhiptail ?

[tlaurion]

@kakaroto Difficult to say, cause there is no screen at all :)

My last attempt of today was to add FB_SIMPLE into linux.

git diff osresearch/master config/linux-x230.config

diff --git a/config/linux-x230.config b/config/linux-x230.config
index 9a31dc12b3..84c9f01c9d 100644
--- a/config/linux-x230.config
+++ b/config/linux-x230.config
@@ -1591,7 +1591,7 @@ CONFIG_FB_VESA=y
 # CONFIG_FB_MB862XX is not set
 # CONFIG_FB_BROADSHEET is not set
 # CONFIG_FB_AUO_K190X is not set
-# CONFIG_FB_SIMPLE is not set
+CONFIG_FB_SIMPLE=y
 # CONFIG_FB_SM712 is not set
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 # CONFIG_LCD_CLASS_DEVICE is not set

While using high-resolution frame-buffer support with native VGA init of coreboot.

git diff osresearch/master config/coreboot-x230.config

diff --git a/config/coreboot-x230.config b/config/coreboot-x230.config
index 7edc29996d..1c4ac7d0fa 100644
--- a/config/coreboot-x230.config
+++ b/config/coreboot-x230.config
@@ -12,7 +12,7 @@ CONFIG_CBFS_PREFIX="fallback"
 CONFIG_COMPILER_GCC=y
 # CONFIG_COMPILER_LLVM_CLANG is not set
 # CONFIG_ANY_TOOLCHAIN is not set
-# CONFIG_CCACHE is not set
+CONFIG_CCACHE=y
 # CONFIG_FMD_GENPARSER is not set
 # CONFIG_UTIL_GENPARSER is not set
 # CONFIG_USE_OPTION_TABLE is not set
@@ -447,8 +447,9 @@ CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT=y
 #
 # Display
 #
-CONFIG_VGA_TEXT_FRAMEBUFFER=y
-# CONFIG_GENERIC_LINEAR_FRAMEBUFFER is not set
+# CONFIG_VGA_TEXT_FRAMEBUFFER is not set
+CONFIG_GENERIC_LINEAR_FRAMEBUFFER=y
+CONFIG_LINEAR_FRAMEBUFFER=y
 # CONFIG_SMBUS_HAS_AUX_CHANNELS is not set
 CONFIG_PCI=y
 CONFIG_MMCONF_SUPPORT=y

Any suggestion into linux FB/DRI configuration options I should try? Or any troubleshooting path?

[kakaroto]

@tlaurion what do you mean there's no screen at all? You should still have a configured screen. Just don't use gui-init as your start script and use the old generic-init script instead and in the recovery shell you should be able to see if /dev/fb exists or /dev/dri/card0. Also, if you run fbwhiptail manually in the recovery shell, you should see what errors it prints.
If you compile fbwhiptail with -DDRI_DEBUG and if you uncomment the prints in https://github.com/kakaroto/fbwhiptail/blob/master/cairo_linuxfb.c then you should have all the debug info you need so that I could advise you on how to proceed.

[tlaurion]

@kakaroto

@tlaurion what do you mean there's no screen at all?

coreboot 4.7 initializing VGA FB with libgfx or native high res, without linux having i915 driver doesn't bring any console up. There is only screen trash.

On slack:
compare the librem13v2 linux kernel config with the x230 and pay particular attention to differences around intel graphics and fb? also compare the x230 overall board config and librem13v2 for kernel command-line args

There is some advancement, though.
coreboot not initialising VGA nor FB, and setting "iommu=on iommu=pt" for linux kernel with i915 brings Heads up as fast as in text console. There is still some screen corruption when kexec'ing. Thought vga=current would reuse FB, but it doesn't seem to be the case.

[tlaurion]

@osresearch @flammit : any idea why this screen corruption takes places? Can you guys test it?

[tlaurion]

@osresearch @flammit: this is working now, no flicker.

[tlaurion]

Exactly.

[tlaurion]

This is now working, no flicker at all but a small screen freeze while the FB gets rewritten.
Questioning the need to have FB support at all in coreboot, though.

[tlaurion]

Combined with #404, I think this is ready to be UX tested in training environments.

@osresearch Would you guys be ready to reach out?
Guys from https://usable.tools, accessnow, QubesOS and Freedom of Press foundation are ready for this!

[kakaroto]

@tlaurion yes, coreboot doesn't need to do any kind of graphics init. On the librem with heads, there was no vgabios and no vbt, and coreboot graphics initialization was set to "None" (I eventually added the VBT back into coreboot only because without it, the OS wasn't able to control the screen brightness).
The i915 driver is able to initialize the graphics entirely on its own, but with IOMMU support in coreboot, it does cause issues when the OS boots, so we had to add the iommu=pt to the kernel boot args (or intel_iommu=igfx_off).
That issue doesn't happen when using the original AMI firmware, so we think it has something to do with the RMRR entries in the DMAR ACPI table. We have someone looking into this and trying to get it fixed so we can drop the iommu=pt argument.

[tlaurion]

@osresearch @flammit : This is ready to merge.

[tlaurion]

@osresearch

Also need to check the size of the resulting kernel against the x230 flasher image -- it shares the same config/linux-x230.config file.

This is why boards/x230-flash/x230-flash.config depends on config/linux-x230-flash.config so that i915 is not included since unnecessary.

[tlaurion]

In an ideal world, x230-flash should boot gui-init (through FBWHIPTAIL) without TPMTOTP and other dependencies, which should be cherry-pickable from a config perspective.

With FBWHIPTAIL, GPG, FLASHROM and FLASHTOOLS, the user could add his keys through the GUI to downloaded reproducible build rom in one single step prior to flashing the 12mb rom, from a minimalist and trusted environment.

[tlaurion]

Smaller change set under #465. Closing.