x230: use fbwhiptail and gui-init instead of generic-init

[merge]

NOTE: This is nothing new. It takes things from #452 and #377 applied to today's master branch, reduced to one simple change. This is what I'm running for some time now. I like it, so I thought about making this a little easier to merge or discuss:

This changes Heads' bootscript for the x230 to gui-init and adds config
options needed for it. The config is very similar to the librem13v2 config.

My comparison of startup-time from a power-button press shows 2.5 seconds
more until I see the menu to use, with these changes applied.

That said, the experience is smooth, the GUI is beautiful and easier to use
than the shell and text menu, especially during setup. That's what we
buy with startup time here.

[merge]

please don't quite merge this: I see the exact same UI glitches described here: #215 and describe the details over there.

[tlaurion]

coreboot-x230.config is missing a change.
See here

[merge]

Adding

--- a/config/coreboot-x230.config
+++ b/config/coreboot-x230.config
@@ -637,7 +637,7 @@ CONFIG_PAYLOAD_LINUX=y
 CONFIG_PAYLOAD_FILE="../../build/x230/bzImage"
 CONFIG_PAYLOAD_OPTIONS=""
 # CONFIG_PXE is not set
-CONFIG_LINUX_COMMAND_LINE="quiet"
+CONFIG_LINUX_COMMAND_LINE="intel_iommu=igfx_off quiet"
 CONFIG_LINUX_INITRD="../../build/x230/initrd.cpio.xz"
 # CONFIG_PAYLOAD_IS_FLAT_BINARY is not set
 

still leads to the same glitches that make dm-crypt booting impossible...

[tlaurion]

@merge then I guess I'll test ubuntu. Same happens with the installer, right?

[tlaurion]

Having issues booting up from iso and running out of free sdcards to dd.
#470

[merge]

UI glitches seem to be fixed now and I think that this is the minimal change for switching to gui-init on the x230.

[tlaurion]

@merge : check #480 which includes @flammit i915 fixes he proposed a while back and have always worked. :)

[merge]

@tlaurion thanks! I tested your/flammit's settings and they work just fine. I've updated this PR. Do you still see anything wrong with it?

[flammit]

@merge what do you think about having this be a new x230-gui board? my hesitation is that last I checked whiptail or its libs are not built reproducibly right now, which would make me hesitate making it the default x230 rom that is released. I do think having this around as a easy option instead of individual's branches everywhere would be nicer.

@osresearch any thoughts?

[merge]

I'd say no to a x230-gui board: The x230 board still has the useless 4M and 8M artifacts and there's the (actually optional) x230-flash board which all makes the X230 already a pretty complicated thing for users; worth simplifying. IMO adding x230-gui would make things worse and might slow down having a stable gui.

Thanks for bringing reproducibility up. I'll test.

[flammit]

@merge makes sense and I'm down for cleaning things up. I'll update and test on my x230s as well.

[merge]

Is the following test sufficient to verify reprocuibility (needs #483 applied first)?

make BAORD=x230                                                                 
(save build/x230/coreboot.rom's hash)                                           
make real.clean                                                                 
make BAORD=x230                                                                 
(compare, save)                                                                 
make real.clean                                                                 
make BAORD=x230                                                                 
(compare, save, and so on)                                                      

In the above sense, the build is reproducible for me.
I have this PR applied on today's master, and #483 on top of it.

But out of interest: @kylerankin how do you build reproducibly for the Librem 13?
Any scirpts or changes involved? After all we basically want to build the same
thing for the x230 here.

[kylerankin]

Set BOARD=librem13v2 or librem15v3 for Librem laptops.

…

On Wed, Nov 21, 2018 at 11:25:48PM -0800, Martin Kepplinger wrote: Is the following test sufficient to verify reprocuibility (needs #483 applied first)? ``` make BAORD=x230 (save build/x230/coreboot.rom's hash) make real.clean make BAORD=x230 (compare, save) make real.clean make BAORD=x230 (compare, save, and so on) ``` In the above sense, the build __is__ reproducible for me. I have this PR applied on today's master, and #483 on top of it. But out of interest: @kylerankin how do you build reproducibly for the Librem 13? Any scirpts or changes involved? After all we basically want to build the same thing for the x230 here. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #465 (comment)

[flammit]

@merge I usually just test the build on a variety of machines/distros combinations (locally and with the help of cloud servers). IIRC, I saw binary differences in libslang between Ubuntu 16.04 and Fedora 28.

[flammit]

@merge sorry I misspoke, the problem was in cairo and this seems to fix it: #486

[merge]

FWIW, this is exactly what I've been running and demostrating on my laptop at the coreboot stand at FOSDEM. It definitely was an eye-catcher. thanks @kylerankin and others who did the gui.

I'll rebase this soon, if at all necessary.