Our Embedded Controller firmware is based on chromium ec, and we're using a mature off the shelf BIOS solution shipping in other notebooks today. We chose our key components with driver stability across both Windows and Linux in mind. We know this is something we have to get right to deliver a credible competitor to all the great notebooks already in the market, so it is something we focused on from the start.

Please support the Linux Vendor Firmware Service https://fwupd.org/ :-)

Hi, i'm interested about details. Are they on a wiki somewhere?

> driver stability across both Windows and Linux

Is "Linux" in this case mainline linux or does entail to use nvidia/ati proprietary drivers? If mainline linux, is it a free driver, or a binary blob? (see linux-libre)

> a mature off the shelf BIOS solution

Is coreboot/libreboot on your roadmap?

I'm not trying to nitpick. Congratulations on the hardware design that looks amazing (replaceable port extensions, clever!). I strongly believe software is also an important part of reliability/durability, that's why my questions :)

Have you considered providing an out of the box Linux experience?

I have no intention of using the Ubuntu provided with a Lenovo laptop if I buy one, but the fact that that there is a fully working Linux distro for that machine means that all of the requisite bits and pieces are somewhere in the Open Source community (and because I use Fedora, I'm almost certainly using a new enough version of Kernel, Gnome etc. that they're already there).

> Our Embedded Controller firmware is based on chromium ec

Sorry, I'm having trouble parsing this statement. Your 'embedded controller' (whatever that may be) firmware is based on a web browser?

I think they are referring to part of the Chromium OS project, which seems to be open source firmware for basic device functions including "power sequencing, keyboard control, thermal control, battery charging, and verified boot" [0]

[0] https://chromium.googlesource.com/chromiumos/platform/ec/+/m...

Ah, I didn't know Chrome OS had an OSS counterpart. Thanks!

Chromium EC. It's the part of Chromebooks that handles things like keypresses: https://chromium.googlesource.com/chromiumos/platform/ec/+/m...

if you have a fingerprint reader that works in Linux I'm in!

My Thinkpad fingerprint reader works in Linux. Well, it works perhaps 80-85% of the time. See https://askubuntu.com/questions/1231185/fingerprint-login-in...

Working on it!

Will the user be able to replace custom BIOS, that is a killer feature no notebook or laptop offers ?

Librem was geared towards openness/security, this just has a focus on repairability. Can Framework not just use off the shelf parts that already have the proper firmware/drivers available for windows/linux and then encounter none of the same issues? Or is the issue the interfaces b/w the modules and mainboard?

I think the particular problem for devices based on ARM SoCs is they’re not on the mainline kernel, support for hardware and for upgrading software relies on a whole pile of hacks on top of an ancient kernel version, and that means that upgrading to a new Android version requires applying a pile of new hacks on top again, and can be very laborious to get a reasonable, stable result. So Fairphone used a chipset whose manufacturer quickly dropped support for upgrading beyond a certain Android version, and that made it difficult for Fairphone to support the upgrade themselves.

Whereas if x86 systems have support on the mainline kernel, future kernel upgrades will be supported.

Is there a reason why there needs to be so much tweaks to get the kernel running on a modern SoC?

Any reason there couldn't be a "canonical" ARM64 standard for SoC?

There is a "canonical" ARM64 standard, so to speak -- ARM's ServerReady architecture, which implements UEFI+ACPI, which coupled with the right hardware, could create the same kind of ecosystem Intel/PCs have enjoyed for so long.

The problem is a lot of ARM SoCs have tightly integrated, custom hardware which requires modified or new drivers, and the tweaks needed to use them are often either very dirty and won't be accepted into mainline Linux without basically redoing them, or are occasionally just hooks for proprietary userland blobs to interface with, and are effectively obfuscated, satisfying the "letter of the law" for GPL but no more.

There are some devices like this on x86 too, FWIW -- Google's Pixelbook, as an example, has a few devices that effectively need a custom fork of Linux to get the audio device to function correctly, because it's driven over i2c (IIRC) and needs special blobs uploaded and an out-of-tree driver to function.

ARM SoCs could be more "PC like" but it'd be more expensive, which as far as I can tell is a big reason it hasn't happened. No real incentive as people don't seem to care if their OS goes out of date in 4 years.

This could change with support for Apple's M1 chip being added to the Linux mainline hopefully later this year.

For desktop computers this is a lot easier, for laptops it's still not that easy. The motherboards are not just COTS "Asus z490 prime" or whatever, and you can't just include a nice standard USB mouse which requires no drivers. If you don't have a good plan for how you will ensure you have good motherboard firmware and touchpad drivers, then they won't turn out good.

Luckily it seems like Framework do have this well under control (somewhat quietly :)

Semi off-topic, but how is working in the firmware/drivers/systems space? Everyone always talks about how hard it is, so that makes me think that companies would be paying a premium for good systems devs. On the other hand there aren't as many companies who have that need. I enjoyed the low level work I did in college and have been thinking about getting back into it, but there are no jobs involving it near me (moving to Seattle in a bit so this should change)