I am curious what the boot situation is. It seems like Qualcomm actually has pretty good support for their cores. But since these PC systems sort of lack a bios, each one needing a hand built DeviceTree: it makes supporting them kind of a nightmare. Even a raspberry pi has a much more advanced and accommodating boot environment than these frustrating Qualcomm laptops. Alas. I don't know but I expect Asahi has to do similar hand tailoring. I am curious to know what the boot chain looks like! How much the system willingly helps vs how much hard to be bespoke hand coded system config! (Wish it wasn't like this, it's so bad)
Just several months after leaving Qualcomm, distinguished CPU and system architects Gerard Williams, John Bruno, and Ram Srinivasan, who are celebrated for their high-performance processors developed at Apple, Nuvia, and, more recently, Qualcomm, established a new CPU startup — Nuvacore — that promises no less than to 'rewrite the rules of silicon.'BecauseMicrosoft is at this time in different to the Surface computers they are all in on copilot. It is basically copilot or bust for Microsoft.
And in many ways that probably is true. But it's not uninform. There's a lot of places where Qualcomm is clearly working very hard to get upstream, to get mainline support. https://www.phoronix.com/search/Qualcomm
I was super impressed with their work offloading sound to a USB sound card, to let the CPU sleep more. Really wild subsystem to build. And they did it! Kept at it! Really cool stuff to have in the kernel.
They've hired some good people for GPU support, which is rad. I feel like Qualcomm is so so close to having a great system people can genuinely love. But there's always some missing pieces, it's always an end result that is far far far quirkier and more difficult than a PC would be. Some of the other comments in this thread give me some hope that there is a more normal boot chain here at least, that it's other troubles. But it's hard. And Qualcomm only has so much power over what their OEM partners actually build.
Qualcomm is the only name in wifi right now for OpenWRT like systems. MediaTek looks good, is present too, but supposedly their drivers are just a total garbage fire, buggy & crash tastic beyond words.
I think it's important we reassess our old biases. And give some credit where due. Qualcomm has an absolutely forsaken reputation & their lawyerliness is a thing of legend, forbidding as heck. But there are also a lot of signs that at least some of the company is tired of making chips that are utterly unsupportable, and has some real drive towards good open source support. Thank you, warriors of light there.
Really hoping we see some Linux running Snapdragon X2 Elite Extreme units in the next 12 months. Looks like an amazing system! Good job engineering the new cores ya'll!! Amazing performance.
It offers an A/B test of "similar" SoC performance and battery life (which users now expect from laptops), without a vertically integrated operating system that was also created by the company who designed the SoC.
Modern PC ARM systems like Snapdragon Elite X use UEFI and ACPI. This is actually what makes them difficult, because they're trying to operate in a "new world" while most ARM SOC IP and peripheral drivers work in the "old world."
The issue with ARM has never _really_ been early boot; yes, it's arcane and a pain in the butt on some platforms, but it really only needs to be done once - once your DRAM is trained and running (this is usually the hardest part) and you can load and jump into a kernel, you're set. Hypervisor / security processor driven systems like Qualcomm (and for that matter, Intel and AMD) actually make this even easier at the expense of openness, because the vendor blob usually brought everything up for you already.
The issue has always been hardware discovery and mutable device configuration. When ARM devices were first supported by Linux, they were mostly embedded devices with one configuration, ever. So, they used devicetree, which is a fixed structure for each board, defined before boot and provided by the bootloader.
Because of this, most SOC / platform / IP soft-core drivers were built to work with fixed, proprietary configurations and usually only tested against a single platform to start.
On the other hand, x86 devices have been forced to work as highly mutable, arbitrary combinations of hardware (Plug n Play) with dynamic reconfiguration using ACPI since the start, so the drivers for x86 peripherals have always had to cope with a completely unpredictable environment.
What this means is that there's a ton of effort required to transition ARM _peripheral drivers_ from the "devicetree" world where drivers took fixed arbitrary, proprietary key=value parameters provided by a magic blob at boot to the ACPI world, where everything is dynamic, scripted, and abstract.
I'd actually argue that Pi have the most hacked tooling on top of the "old devicetree way," which means they're the most set on it. Pi peripherals are usually configured at pre-boot time using devicetree overlays and their drivers usually don't support any kind of probing/autodiscovery. As far as I know there's no real plan to change this (and maybe there doesn't have to be; it seems to work for them).
Anyway, this is all to say: I don't think the issue with either system is the "boot situation," it's the "peripheral configuration situation." In this sense, Asahi are actually in a fine situation to use devicetrees, which they do, because basically all of the SOC peripherals are proprietary and there are a fixed number of Apple devices to target and the only external interfaces are existing hot plug standards (USB/Thunderbolt/HDMI/DP). Qualcomm are smart to have started to try to use ACPI, because their SoCs could be hosted on boards with standard peripherals configured in thousands of different ways, like all PCs. But, they're playing on hard mode because most of the existing ARM peripheral drivers weren't made to support this model.
Originally, embedded Linux ARM devices used a board file with a platform bus and hard-coded device metadata. The bootloader had to pass a machine id which told the kernel which hardware you were running on and which board file to use.
You can see remenants of this in the kernel still, though it's quickly being removed. I'm actually working on a hybrid kernel with the goal of bringing modern Linux support (on an lts branch) to old MSM7x300 devices, like the Evo 4G Shift I intent to use a tmux console/cyberdeck.
On another note, ACPI/UEFI doesn't always give you a clean abstract surface to work with either. ACPI is notorious for building in OS checks into it's compiled bytecode to the point that Linux often lies to it about what OS is running.
> ACPI/UEFI doesn't always give you a clean abstract surface to work with either.
That's putting it lightly. I think the best abstraction would probably land somewhere inside the big gap in the board config headers -> devicetree --------------> ACPI complexity continuum, but I'm not sure it's possible to do that at this point in the game as both sides are so entrenched.
> ACPI is notorious for building in OS checks into it's compiled bytecode to the point that Linux often lies
The problem with ACPI in this dimension is that there's a bidirectional errata game: the bytecode tries to work around the OS and the OS tries to work around the bytecode.
Unfortunately, there was never a real version standard for the Linux firmware interface early on (the _OSI("Linux") debacle), so the only testable versioned ACPI interface is Windows. This means that Linux is basically forced to become a Windows ACPI emulator. I think there are political reasons for this (obviously the 90s and 2000s were a bad time for Linux/Microsoft coexistence) but also just some decisions that look like big engineering mistakes in hindsight - the historic allergy of Linux maintainers to any kind of specified or versioned interface aimed at anything but user land definitely strikes again here.
I think that the versioning/errata issue and the native code trapdoor are the two biggest issues with ACPI (and admittedly both are large enough to drive a bus through); otherwise it's a kind of nasty thing but it fills in nicely for a lot of much nastier ideas and covers a really broad problem space reasonably well.