Hacker News Reader

> How interesting: by moving some of the driver to firmware, Apple has effectively made it easier for OSs like Linux to have good support for the hardware, because the OS<->hardware protocol operates at a higher level of abstraction and may work across multiple chips.

If I am remembering right, this was the original idea behind UEFI drivers too — you could in theory write drivers that the firmware would load and they would present a simpler/class-compatible interface to whatever operating system was loaded after that. I think Apple did pretty much this on Intel Macs for a number of things.

Even legacy BIOS effectively served a similar purpose before the functionality provided ended up being too limited. The name BIOS, Basic Input/Output System, in fact focuses on this functionality of serving the I/O function calls more than initialization/booting the system. Of course these days a modern OS just ignores the BIOS and drives the hardware itself once booted (at least partially due to the fact its design predates protected mode).

> If I am remembering right, this was the original idea behind UEFI drivers too — you could in theory write drivers that the firmware would load and they would present a simpler/class-compatible interface to whatever operating system was loaded after that. I think Apple did pretty much this on Intel Macs for a number of things.

Not really; pretty much every UEFI driver shuts itself down when you call ExitBootServices, which is necessary before you can do virtual addressing (as required by every OS)

(My memory is fuzzy but I think the one exception is UNDI/the network driver, but you never want to use UNDI to drive your network card except out of desparation)

If I recall correctly, high end hard drives used a protocol called SCSI in the 90s that was mostly embedded in hardware.

Somewhat related, SSDs run an entire microcontroller on-board to translate from I/O requests from the OS to proper use of the flash hardware.

If I recall correctly that’s not the case on Apple platforms. They do the translation themselves across raw NAND.

No, there's firmware on the Apple NVMe drives doing FTL, etc. and exposing a traditional block device.

It's on the main SoC on M1. (ANS2 block, with the FW being loaded by iBoot1)

NVMe exposed as an MMIO device directly, not as a PCIe one.

My knowledge was about the first iPhone since I swear I sat next to the guy implementing it (I was an intern at the time). Maybe Apple was just writing the FW themselves and I’ve misremembered? Apple devices definitely have better I/O performance than any other mobile device from what I recall.

I remember hearing about how the M1 Macs were very quick to get displays running when they were plugged in and to change the display configuration. I guess the DCP is why.

No, moving it to a coprocessor doesn't really have an impact here. That's just down to their software stack being good.

The iOS software stack? Because the way I heard it, the M1 Macs are noticeably faster than other Macs at these tasks.

Their display controller driver, regardless of what CPU it runs on.

> Apple has effectively made it easier for OSs like Linux to have good support for the hardware

Wow, that's a tall stretch of a conclusion, bordering on ignorance, when the reality is that the M1 only supports macOS! Apple fans shouldn't be blind to the fact that developers are trying to reverse engineer the M1 to run Linux on it. (And they have a long way to go before they succeed). Apple has not even published any literature that can help system developers create and run alternative OSes on it. And this is by design - the M1 (and all Arm processor based macs) are designed to be a a closed box like their other iDevices.

(Honestly, except for an academic interest, I believe open source developers are wasting their time trying to support such a useless "closed" piece of hardware, and instead should be boycotting it - or we'll end up losing control over our desktop computers too as other manufacturers move towards this model too).

> On most mobile SoCs, the display controller is just a piece of hardware with simple registers. While this is true on the M1 as well, Apple decided to give it a twist. They added a coprocessor to the display engine (called DCP), which runs its own firmware (initialized by the system bootloader), and moved most of the display driver into the coprocessor. But instead of doing it at a natural driver boundary… they took half of their macOS C++ driver, moved it into the DCP, and created a remote procedure call interface so that each half can call methods on C++ objects on the other CPU! Talk about overcomplicating things… Reverse engineering this is a huge challenge ....

Oh boy if we didn't even try to reverse engineer things to bring closed systems to the open world ... Where would we even be? I don't think we'd have gotten past UNIX.

That's a fair point. I am thinking from the other end - if these efforts were instead redirected at supporting open hardware systems, how much more beneficial it would be for the open movement?

By reverse engineering closed systems, you are adding value to it but not changing its nature - you are not really making it "open" (the next iteration will just "close" it again). Meanwhile, Apple just uses these reverse engineering effort cleverly for PR for the M1 through social media marketing. In effect, you are just helping a trillion dollar company design better closed systems while helping them make more money (by attracting naive Linux users to spend money on their hardware).

There are open systems that are struggling because they don't have talented developers working on their projects. Wish these developers would instead work on these projects - Sailfish OS, PineOS, Librem - Purism etc. For example, there are a lot of Intel / Arm tablets that either run only Windows or Android. It would be nice to run one of these Linux based mobile OS distros on it, and create a genuine alternate to the Android / ios duopoly on Tablets, right?

I don't think (and experimentally, I know I'm correct) it's as zero sum as you think it is. These efforts you think better spent on open hardware are actually adding value to the open systems by making transitions from closed systems easier.

M1 is a beast and needs no further PR to attract buyers. You can ignore its advantages and yell out "our system sucks but at least it's open!", or, you can work on bringing the advantages of the product of a trillion dollar company's RND to the open world.

I can understand an academic interest in reverse engineering such devices. But yes, I really don't see any advantages in owning a closed and limiting system like the Apple M1, when better and more open alternates already exist. The limitations of such hyped-up closed system negate any short-term temporary benefits it offers.

And regardless of what you think, the M1 does need constant marketing as its limitations becomes obvious. Apple is betting their future on such closed systems and desperately needs it to be a success. That is why Apple marketing is desperate to spread PR fluffs about it to its Apple fans that ignorantly parrot them on the social media on threads like these:

- Apple has effectively made it easier for OSs like Linux to have good support for the hardware

- Ok, but they’ve done the opposite- helping linux projects get linux on M1 macs.. ( https://news.ycombinator.com/item?id=27943196 )

... and similar statements like these that try to convey that Apple is actually helping developers port Linux to their platform.

Obviously, any posts (like mine) that point out the obvious lie in these statements are downvoted / vote-brigaded because it is in Apple's interest to do so.

> Obviously, any posts (like mine) that point out the obvious lie in these statements are downvoted / vote-brigaded because it is in Apple's interest to do so.

No, quit the Dunning-Kruger, you're being downvoted because most people here disagree with you. Myself included: I don't particularly like Apple, I'm not paid by Apple, I'm a life-long proponent of FOSS and open systems, and I downvoted you because your posts are uninformed and either you haven't thought this through, or you don't have enough context to know what you're talking about.

Insinuations of shilling/astroturfing are against the guidelines, FYI.

Insinuations against particular individuals are against the guidelines, not a blanket ban on mentioning that astroturfing / shillings are an accepted reality of today's social media as part of social media marketing. And I recognize that sometimes what is said is out of ignorance on the part of the poster, (which is what I have highlighted).

That said, I have no hesitation in pointing out that that calling my posts "uninformed", without actually providing any actual context, is just a lazy and aggressive way of avoiding a discussion.

Or you can engage with me and point out where my reasoning is flawed. Here's my stated position and reasoning for what I have said so far, and you can chime in with you thoughts:

First, I started by pointing out that the beliefs of some Apple fans that Apple has made it easy and / or is actually helping developers to port Linux to the M1 is pure ignorance - Apple is doing no such things, but it is in their interest to let the public believe that. What is uninformed about this, in your opinion?

Second, I voiced the opinion that "open source developers are wasting their time trying to support such a useless "closed" piece of hardware, and instead should be boycotting it". The reasoning behind it is obvious - supporting a closed black box system, like the M1, and the proliferation of such devices will mean we will lose more of our computing freedom / right-to-repair on the computers we own.

Is it "uninformed" to point out that the M1 is a closed system that limits us, compared to Intel / AMD alternatives available? Or that the efforts of the developers will be a waste when Apple can, at any time, thwart or derail such reverse engineering attempts on the M1 by updating its firmware?

Third, porting Linux to the M1 will make it attractive, and help its sale. But it is a short-sighted and regressive move that will not help the open-source movement, and will backfire on us as it will help to make such closed box systems popular. The better approach for the open source community is to actually publicly boycott and disparage the M1, so that Apple is forced to open up the M1. Porting Linux to it then would not only be easier, but also makes more sense. What is "uninformed" about this way of thinking?

Fourth, while I do appreciate the strides made by Apple in developing their own custom ARM processors, I do genuinely believe that the technical gains (more computing power) are competitively temporary - both AMD and Intel systems have at some point always shown such leads. And it is not far fetched to say that this technical lead is even negated due to it's closed box nature. Do you think I am wrong in concluding that AMD / Intel will not catch up, or even overtake, Apple ARM processors?

> What is uninformed about this, in your opinion?

Nothing, that's not the part I (personally) had a problem with.

> Is it "uninformed" to point out that the M1 is a closed system that limits us, compared to Intel / AMD alternatives available? Or that the efforts of the developers will be a waste when Apple can, at any time, thwart or derail such reverse engineering attempts on the M1 by updating its firmware?

You just described reverse engineering. That's what it always looks like. It's not in Apple's best interest to thwart those efforts, and if they do, it becomes a game of whack-a-mole.

What I believe is uninformed about your posts, or at least your arguments, is the lack of understanding of both how we got to this point, and how progress can happen.

We are not at a point in the world where open hardware is winning. Not just CPUs, just open hardware in general. This won't change by ignoring the progress in closed systems. Reverse engineering for compatibility makes the progress more public and more accessible to the open systems. There are fundamental issues that need to be addressed before we can start on relying on open-by-default progress in hardware.

To answer your question about what is "uninformed" about it: Maybe a better world would be pointlessly idealistic. You won't address the issues above with a boycott, and it doesn't matter because a boycott won't happen anyway (if you can't convince a die-hard supporter of open source like me, you won't convince the general public). So it's all a bit of a waste of time; I like progress to not just be theoretical. Reverse engineering for compatibility is a practical way of progressing.

> Do you think I am wrong in concluding that AMD / Intel will not catch up, or even overtake, Apple ARM processors?

I think it's a good bet, but I don't think any of us can say so with certainty and definitely not "when" it will happen. Intel has been spiraling lately, who knows if they will catch up at all?

AMD and Intel are far from open hardware. ARM is not open hardware. Sure, they're better documented and therefore somewhat more open in some sense. You can't just go have a fab build you an AMD64 core or twelve and throw the chip on a custom board and sell your own laptop.

You can't just get a small batch of royalty-free ARM cores and make your own phone. Did you know there's still work going on to reverse engineer the Raspberry Pi systems because Broadcom doesn't release full docs?

> By reverse engineering closed systems, you are adding value to it but not changing its nature (the next iteration will just "close" it again).

That argument would totally hold for iOS devices: you might find a bug and create a jailbreak on a particular iOS version, but that "hole" closes by the time the next major version comes out. Apple really doesn't want to allow other operating systems (or even root access).

But reverse-engineering macOS hardware is very different. A solid Linux port like Asahi fundamentally changes the nature of Apple M1 computers: they can be great Linux machines (and given m1n1's versatility, maybe even Windows machines!), not just macOS machines. Sure, Apple might "close" things again in the future, but that future is a long way off. They have given no indication of hostility to Asahi, so it's most likely that Apple computers will run Linux without any trouble until they release their next brand-new architecture. If history is any indication, that transition is likely more than 15 years in the future (68k was 1984-1994, PowerPC was 1994-2006, x86 was 2006-2021).

> There are open systems that are struggling because they don't have talented developers working on their projects. Wish these developers would instead work on these projects - Sailfish OS, PineOS, Librem - Purism etc. For example, there are a lot of Intel / Arm tablets that either run only Windows or Android. It would be nice to run one of these Linux based mobile OS distros on it, and create a genuine alternate to the Android / ios duopoly on Tablets, right?

I agree, that would be great in many ways. But honestly, all other things being equal, given a choice between running Linux on a Qualcomm ARM64, a Apple M1, or an Intel/AMD x64 chip, which one is the most desirable? Which will likely be the most desirable after the M1x or M2 comes out?

At the most fundamental level, it's desirability that drives demand, which in turn decides which systems will be the most well-resourced.

Many Windows tablets can actually run Linux just fine these days. It's a bit of a pain to install and the specs can be quite underwhelming, but the basic hardware support is there at last.

Show me an open source hardware system as performant and power efficient as M1 and I'll throw some support (time, money, press, something) at it and forego using Asahi Linux. If, however, I can run an open software system on the M1 and also still run an open hardware system right beside it on the same desk while the hardware in the open hardware system plays catch-up, I'd rather do that. If everyone forwent open software because it didn't run on open hardware, we wouldn't have Linux, BSD, Darwin, FreeDOS, ReactOS, Haiku, OpenIndiana, X, Wayland, MySQL, Postgresql, KDE, Gnome, XFCE, i3, LibreOffice, Apache, Nginx, HAProxy, Kafka, Pulsar, gcc, clang, rust, Julia, Perl, Python, Ruby, Node, Chromium, Konqueror, Safari, Firefox, bash ... any open software at all.

Your ideal taken to its conclusion is that we wait for RISC-V or OpenMIPS or something to catch up to ARM before we write or use any software. That's simply untenable. What software would we even have to port to such things if we couldn't develop open software on closed hardware? What use would RISC-V be outside of embedded projects without QNX, Linux, BSD, RiscOS, or something else developed originally on closed hardware to run on it?

Absolutely. I’m currently reading “Open” by Rod Canion, the story about how Compaq reverse engineered the IBM PC’s BIOS. Great read so far.

Think about where we might be if that never happened.. no clones? No open hardware standards? I mean, I guess if Compaq didn’t do it, somebody else would have (maybe?), but yes, thank god for the brilliant engineers of the world who have the focus, diligence, and skill, to be able to do these sorts of things.

When studying history though, we shouldn't lose track of the fact that it needs to be analysed based on the period it happened. From fighting a closed and patented *Nix systems, Linux has emerged as the current torch bearer of open systems in our era. It has made so much stride, that we are even thinking in terms of open hardware today (and it is a reality too, even if not yet successful).

Today's computing world is no longer like the past. Open source is an accepted reality in both the corporate world and among the general population.

You are right that in the past, reverse engineering helped clone hardware and make it more open. It was necessary then. Perhaps I am ignorant here, and I would like insights on this, but I don't understand the practicality of trying to reverse-engineer Apple's custom GPU when it is not even freely available or can even be used in any custom hardware configuration. Especially when alternative GPUs with open source drivers already exist (and need work). And Apple can anytime thwart such efforts very easily with a firmware update.

My main concern is that the BigTech are again closing ranks together to fight against the open movement - today, we are at the cusp of losing our computing freedom again with the aggressive push towards cloud computing, and locked down systems like the Apple M1. Apple is in the forefront here as it has build its business with closed-box systems and resisting against right-to-repair legislation. Fighting and avoiding open systems is in their DNA.

That is why I believe porting Linux to the M1 is not only unnecessary but also a waste of resource and talent. Supporting existing and new open systems (if necessary by reverse engineering it) is more practical in the long run.

It's ancient history but Compaq only reverse-engineered the IBM PC BIOS for their own use.

Some other clone companies directly copied the IBM BIOS and got sued, so it was Phoenix that provided the first 3rd party PC-compatible provably clean-room BIOS implementation.

Ah, didn’t know that thanks for the extra tidbit!

And Science is just reverse engineering reality.

I have an M1 Macbook Pro and it beats any other laptop I've seen/had when it comes to performance and battery life. I'd love to also have Linux run on it and apparently enough people do as well.

Yes, the hardware is peculiar in many ways and Apple didn't bother to document it (it would have costed them some resources for no clear benefit to their business model) but they also didn't bother to completely lock it down, like they did with the iPhone and iPad. This is what allows other OSes to be ported to it if they are able/willing to reverse engineer and develop support for it.

This reverse engineering work was done so far by just a handful of people who would also like to have Linux run on it, partly sponsored by a few hundreds that share this desire, or just doing it voluntarily as a challenge/interesting project.

The m1n1 bootloader/hypervisor built by the team allows running macOS and logging all the hardware access.

Once the reverse engineering is done for a given component, all the other OSes can implement support for it.

The fact that a lot of the functionality is implemented in firmware blobs makes it easier to support at the OS level, essentially each OS driver only needs to give high level instructions to the firmware, without having to implement all the minutiae done in the firmware.