← Back to context

Comment by amosbatto

4 years ago

> Looking up the Librem 5 devicetree in the upstream kernel, it seems it was submitted on Aug 21 2020. Aspen shipped in September 2019, so it took them about a year from shipping to upstreaming bring-up, and that's not considering internal prototypes and that the SoC was announced in mid 2018, so they had plenty of time to work on things internally. I submitted upstream bring-up for the M1 Mac Mini with the device tree on Feb 4 2021, just 4 months after it was announced in Nov 2020.

Before anything else, let me say thank you for your work on the M1, because it is essential that we have Linux support for processors even when the device maker is opposed. Considering how many millions of people have bought Apple's M1 devices, Asahi's work is critical because it provides a path for people to discover a freer system when they get disgusted with Apple's bad practices and the restrictions of its "walled garden."

Having said that, I don't think that your criticism of Purism's kernel work is very fair. Purism made its first commit to mainline Linux for the Librem 5 in July 2018 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...). Purism submitted the device tree for the Librem 5 DevKit to mainline Linux on June 17, 2019 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...), which was 7 months after it started shipping the DevKits in mid-December 2018 (https://puri.sm/posts/2018-devkits-are-shipping/). I can find emails from Purism trying to submit the device tree for the Librem 5 since May 25, 2020 (http://lkml.iu.edu/hypermail/linux/kernel/2005.3/00715.html), which was 7 months after it started shipping on Nov 17, 2019. Since Linux version 4.20, Purism has made roughly 150 commits to mainline Linux to support the Librem 5, whereas System76 has made 13 commits to the Linux kernel (https://blog.system76.com/post/667593198841069568/open-up-co...) and TUXEDO Computers has made one commit (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...), and I can find commits for the rest of Purism’s competitors (PINE64, Juno Computers, Slimbook, ThinkPenguin, F(x)tec, Planet Computers, Hallo Welte, etc.)

You are comparing the work of a company with two kernel developers (Angus Ainslie and Martin Kepplinger) to an entire community working on Linux support for the M1. Purism has only shipped 2600 Librem 5's so far, whereas Apple is shipping roughly 7 million M1 Mac PCs and 15 million M1 iPads every quarter. If you are going to brag about getting M1 support into mainline Linux within 4 months of the release of the M1, consider the fact that the first commits to mainline Linux for the i.MX 8M processors were submitted just 8 days after NXP announced that it had started volume shipping of the processors (https://www.pengutronix.de/en/blog/2018-01-17-first-mx8m-mai...). This was possible because NXP shipped early versions of the processor to many companies and has released 7000 pages of documentation on the processor, plus NXP pays several of its own employees to work on getting the i.MX 8M supported in mainline Linux. It does make a huge difference whether a company decides to collaborate with the Linux community or not.

You also have to keep in mind that Apple has shipped 2 billion devices with A-series processors that never got mainline Linux support, so we got really lucky that 1) Corellium managed to figure out how to run Linux on the M1 and 2) Apple decided to not block the use of custom kernels with the M1. Corellium (which currently has 20 employees) has been working on figuring out how Apple processors work since 2017 (https://craft.co/corellium) and company's blog makes clear that it was its previous work on the A-series (boot sequence, PCIe and USB controller) which helped it get Linux support working so fast on the M1 (https://www.corellium.com/blog/linux-m1), so Corellium wasn't starting from scratch in figuring out how the M.1 works.

By the way, it's worth pointing out that most of Purism's dev work hasn't focused on the kernel, but has instead focused on creating the Phosh mobile environment on top of GTK/GNOME, and Purism has created about a quarter million lines of new code so far (https://amosbbatto.wordpress.com/2021/12/15/amount-code-libr...), and 169.4k of that code (libhandy, libadwaita, Chats and Calls) has been incorporated as official GNOME projects. Purism purposely designed the L5's software to work as a thin overlay on top of an existing desktop Linux stack, so PureOS/Phosh has done a better job than Meego, Sailfish OS, Firefox OS, Ubuntu Touch and WebOS at making a version of mobile Linux which is compatible with the larger Linux ecosystem. Purism commits upstream as much as possible to projects like Linux, wlroots, ModemManager, Geoclue, GTK, GNOME and about 20 different GTK/GNOME apps (Nautilus, gEdit, GNOME Calendar, CNOME Contacts, GNOME Clock, etc.) so that the L5 will be easier to maintain and be able to run on other Linux distros (postmarketOS, Mobian, Ubuntu Touch, etc.).

> To my knowledge, the L5 does not support any kind of secure boot (at least it is not implemented yet; the SoC itself might)

The i.MX 8M does have a secure boot option, but Purism isn't going to use it because it isn't controllable by the user. Purism's Kyle Rankin commented that they are discussing how to implement a user-verifiable boot procedure, like they have with PureBoot + Librem Key on their laptops, but Purism has a lot of other stuff on its plate (like suspend to RAM, camera auto-focus, encryption with keys from the OpenPGP card, etc.) which is higher priority, so I doubt that it will be implemented soon. The Ubuntu Touch port should have secure boot, but UBports has put their porting of the L5 on hold to focus on the PinePhone and PineTab, so I assume that will also take a while.

>Apple decided to not block the use of custom kernels with the M1.

More like deliberately modified their design to allow it.

>Corellium (which currently has 20 employees) has been working on figuring out how Apple processors work since 2017

I don't think Corellium did have much effect on the Asahi upstreaming effort, they just posted haphazardly patched up kernel tree which they were using for validation of their virtualization platform. Majority of their patches weren't suitable for upstream submission.