Since I’ve heard about Libreboot maintainer’s plans to bring Chromebook support to their famed coreboot distribution, I thought it’s time to write something about what stuff is currently blocking modified Chromebooks from things “just working” on standard Linux distributions.

#linux #chromebook #chrultrabook #coreboot #libreboot

🧵

For example, audio. Modern Chromebooks aren't using your old HD Audio system, but rather tend to depend on dumb DAC and ADC chips connected to dedicated DSP block in Intel and AMD processors.
Since this is not standarized, additional work needs to be done on ALSA and audio servers' level: UCM mappings, equalizer/effects configuration for getting good enough sound from built-in speakers, safeguards to prevent blowing up your speakers with loud music.

And you need to prepare such mappings and configs for practically every Chromebook model, because vendors use various combinations of DAC/ADC chips and speakers themselves also vary between models. 🧵

Other examples: USB-C multiplexing (requiring cooperation between CPU vendor USB drivers and Chromium EC driver), non-standard keyboard layouts.

And don't get me started on edge cases like AMD Stoney Ridge, where we're just one patch (on LKML, ignored) away from getting audio working out of the box. 🧵

Firmware on x86 Chromebooks is mostly a completed job, with most models supported by upstream coreboot. MrChromebox already provides ready-to-install builds with a simple installation script, so what's the point of bringing up a yet another distribution? A different payload?

Without kernel and userland parts of the whole stack available on popular distros, users will still need to hack around with custom kernel builds and dedicated installation scripts - and CPU vendors aren't always helping, since this is not directly related to their business. 🧵

And what about ARM devices? The only coreboot payloads working on ARM are depthcharge and LinuxBoot. There's also u-boot port for a few older 32-bit ARM Chromebooks. Bringing up EDKII or u-boot with EFI support on ARM platforms will surely take some time. And then we get to the Linux support part again...

We need to care about the whole stack, not just firmware on main CPU or kernel patches. 🧵

Some help will be needed to get all required stuff pushed to the upstream and packaged in distros, more details will be published later (currently working on new page with resources, etc.).

If someone wants to redo the job for 500+ models of ChromeOS devices without providing the rest, then good luck with support. 👋

end of 🧵

@BluRaf
> DSP
> USB-C mux
> coordination between different drivers

so basically all the problems Asahi hit, but now at the scale of tens of laptop models, all different?

@wolf480pl it wasn't that bad, last thing in this case I remember is wrong order of loading cros-ec-typec and intel-pmc-mux modules on Intel TigerLake and AlderLake

@BluRaf oh like macintosh computers

@BluRaf As far as I know, three reasons:

• Different payloads as you mentioned (libreboot has SeaBIOS, GRUB, and U-Boot)
• Libreboot will use libgfxinit rather than FSP GOP and NRI rather than MRC when supported. (I’m not sure if MrChromebox uses NRI or MRC, but IIRC it uses FSP GOP instead of libgfxinit)
• ARM Chromebooks

@noisytoot Is NRI supporting anything newer than Haswell?
As for ARM Chromebooks, you still need to fix device trees to get rid of kernel hacks and enable proper ACPI support + a payload that will be useful for most people (in practice something with UEFI)

@BluRaf NRI doesn't support anything newer than Haswell but there are Haswell (and Ivy/Sandy Bridge) Chromebooks.
The ARM Chromebooks currently supported in libreboot both use U-Boot, which does support UEFI (or the libreboot documentation is incorrect). Presumably other ARM Chromebooks would use the same, although it will of course take more work to make U-Boot work on them. (Also, the currently supported Chromebooks are both 64-bit (RK3399). The 32-bit (RK3288) Chromebooks were dropped because modern versions of U-Boot stopped working on them.)
Is there any other coreboot distro with support for ARM Chromebooks?

@noisytoot @BluRaf So only a single platform is supported. @elly, @9lore, and I are working on u-boot as a coreboot payload for modern mediatek chromebooks.

@noisytoot @BluRaf It’s worth mentioning that Haswell NRI (Native Ram Init) is a reverse-engineered implementation… created by my coworker. Just so you know.

https://review.coreboot.org/q/topic:%22haswell-nri%22

Most pre-TGL systems in coreboot are using libgfxinit.

(❯ grep -r LIBGFXINIT src/mainboard/google)

It’s simply a matter of choice. We don’t ship it because it breaks Windows compatibility, but nothing stops you from writing gma-mainboard.ads and adding select MAINBOARD_HAS_LIBGFXINIT to Kconfig. Literally a minute of work required.