Porting operating systems to Apple Silicon leagues harder than migrating software
Working with Apple Silicon directly is a tough task, a developer attempting to port Linux to run natively on the M1 chip advises, with Apple using a highly customized process to boot the Mac that is different from versions used by other 64-bit ARM systems.
In its introduction of Apple Silicon to developers, Apple has provided assistance to developers to port their Intel-compatible apps over to M1. For developers performing more ambitious feats, such as porting Linux over to Apple Silicon, the task is multiple times harder.
In a blog post about the Asahi Linux project, the team discusses its findings in trying to set up an alternative boot kernel on Apple Silicon systems. While most of the feature has been implemented, the lack of support for a command that allows the installation of a non-Apple kernel led to an attempt to document the undocumented system.
The main hurdle faced was that Apple Silicon boots differently from PCs, and works "more akin to embedded platforms" like Android or iOS devices. There are differences and a "few bespoke mechanisms" in use, though Apple apparently made the boot process "feel closer" to an Intel Mac.
These differences result in some behaviors that were unexpected, such as how Apple Silicon Macs handles booting from external storage. It was also found the bootloader cannot show a graphical user interface and that the "Boot Picker" is a "full-screen macOS app, not part of the bootloader."
The developers believe the boot process is "not based on any existing standard" and instead uses "a bespoke Apple mechanism that has slowly evolved from the early days of iOS."
DeviceTree was selected to be used as part of the boot process, in part because it is similar to Apple Device Tree, which Apple Silicon uses. Both Apple Device Tree and the open DeviceTree standard are based on the Open Firmware specification, which was used for booting older PowerPC Macs.
However, the difference in binary format that cannot be easily converted automatically without high-level details about what the data represents is a hurdle for the project to cross. "Trying to unify Apple's and Linux's ideas of how device trees should work would be a nightmare," the project team claims.
To solve the problem, the team worked on "m1n1," a bootloader for Apple Silicon to "take care of as many Apple-isms' as possible" for anyone developing their own Linux or other OS ports. Using the took, which is based on a minimal environment originally made to examine the Nintendo Wii's security CPU, the project has started to document Apple's custom ARM instructions, system registers, and hardware like the Apple Interrupt Controller.
The Asahi Linux project joins another effort by Corellium to port Linux to M1. In January, Corellium mentioned a similar untraditional boot process and the use of a non-standard controller, as well as allegedly managing to boot Linux.
Directly working with Apple Silicon is a big jump in difficulty from the experience of porting Intel-based macOS apps over to the chip.
On March 12, Adobe revealed it had a "smooth experience" in converting Photoshop over. Along with initial Intel app support using Rosetta 2, the development team partnered with Apple to refactor and implement features such as Context Aware Fill to work with M1.
Praise was also offered for Apple's "significant investment in the developer toolchain and experience," elements that teams porting Linux to Apple Silicon simply do not have.
Stay on top of all Apple news right from your HomePod. Say, "Hey, Siri, play AppleInsider," and you'll get latest AppleInsider Podcast. Or ask your HomePod mini for "AppleInsider Daily" instead and you'll hear a fast update direct from our news team. And, if you're interested in Apple-centric home automation, say "Hey, Siri, play HomeKit Insider," and you'll be listening to our newest specialized podcast in moments.
In its introduction of Apple Silicon to developers, Apple has provided assistance to developers to port their Intel-compatible apps over to M1. For developers performing more ambitious feats, such as porting Linux over to Apple Silicon, the task is multiple times harder.
In a blog post about the Asahi Linux project, the team discusses its findings in trying to set up an alternative boot kernel on Apple Silicon systems. While most of the feature has been implemented, the lack of support for a command that allows the installation of a non-Apple kernel led to an attempt to document the undocumented system.
The main hurdle faced was that Apple Silicon boots differently from PCs, and works "more akin to embedded platforms" like Android or iOS devices. There are differences and a "few bespoke mechanisms" in use, though Apple apparently made the boot process "feel closer" to an Intel Mac.
These differences result in some behaviors that were unexpected, such as how Apple Silicon Macs handles booting from external storage. It was also found the bootloader cannot show a graphical user interface and that the "Boot Picker" is a "full-screen macOS app, not part of the bootloader."
The developers believe the boot process is "not based on any existing standard" and instead uses "a bespoke Apple mechanism that has slowly evolved from the early days of iOS."
DeviceTree was selected to be used as part of the boot process, in part because it is similar to Apple Device Tree, which Apple Silicon uses. Both Apple Device Tree and the open DeviceTree standard are based on the Open Firmware specification, which was used for booting older PowerPC Macs.
However, the difference in binary format that cannot be easily converted automatically without high-level details about what the data represents is a hurdle for the project to cross. "Trying to unify Apple's and Linux's ideas of how device trees should work would be a nightmare," the project team claims.
To solve the problem, the team worked on "m1n1," a bootloader for Apple Silicon to "take care of as many Apple-isms' as possible" for anyone developing their own Linux or other OS ports. Using the took, which is based on a minimal environment originally made to examine the Nintendo Wii's security CPU, the project has started to document Apple's custom ARM instructions, system registers, and hardware like the Apple Interrupt Controller.
The Asahi Linux project joins another effort by Corellium to port Linux to M1. In January, Corellium mentioned a similar untraditional boot process and the use of a non-standard controller, as well as allegedly managing to boot Linux.
Directly working with Apple Silicon is a big jump in difficulty from the experience of porting Intel-based macOS apps over to the chip.
On March 12, Adobe revealed it had a "smooth experience" in converting Photoshop over. Along with initial Intel app support using Rosetta 2, the development team partnered with Apple to refactor and implement features such as Context Aware Fill to work with M1.
Praise was also offered for Apple's "significant investment in the developer toolchain and experience," elements that teams porting Linux to Apple Silicon simply do not have.
Stay on top of all Apple news right from your HomePod. Say, "Hey, Siri, play AppleInsider," and you'll get latest AppleInsider Podcast. Or ask your HomePod mini for "AppleInsider Daily" instead and you'll hear a fast update direct from our news team. And, if you're interested in Apple-centric home automation, say "Hey, Siri, play HomeKit Insider," and you'll be listening to our newest specialized podcast in moments.
Comments
Good grief, it isn't that big a deal. He can still buy HomePod Minis, AirPods, Apple TVs, Apple Watches, iPhones, iPads and an M1 MacBook Air for personal use. But for his job he needs capable hardware. Now were this 2019 or even 2020 you would be able to honestly tell him "just get an Intel-based MacBook Pro, iMac or Mac Mini." But now you really can't. No Mac has anything newer than a 10th gen Intel CPU. Some of them even have 9th gen. But Windows and Linux machines with 11th gen Intel inside have better CPU performance and MUCH better GPU performance. Not only that but 12th gen Intel machines launch later this year, as do next-gen AMD machines. Those are all going to have 30%-50% better performance than any Intel Mac.
Of course the M1X and M2 Macs are going to blast away anything that x86 will be capable of for some time beyond a top end Xeon or Threadripper CPU meant for servers. But that won't mean anything if those Macs can't run the software that you need for your job. He should wait until it can before he buys it no matter how fast it runs. I am someone who had the same experience. I badly wanted the Mac Mini, but my job required a machine with A. VMWare and B. 32 GB of RAM so that I could run at least 3 VMs simultaneously. So, I had to get an HP desktop - with the same hexacore Intel i5 that is in the Mac Mini - and a pair of RAM sticks. (The combined cost was what I would have paid for the $699 M1 Mac Mini with 8 GB RAM and less than the Intel Mac Mini. Yes, the Apple tax is real.) Later I needed another PC ... but needed to be able to virtualize Windows Server. So I got an 16 GB Intel NUC (again for significantly less than a Mac Mini). I may FINALLY be able to get an M1 Mac Mini later this year if the old Intel Mac Mini that I am currently using as an HTPC kicks the bucket, but that would be a personal device, not a work one.
Want and need are two different things and for work the latter has to be the driver. Had I gotten a Mac Mini instead of the HP or Intel NUC, I wouldn't be able to use either for work. And ultimately guys, yes the switch from x86 to ARM is going to cost Apple some pro users. It is no big deal as Apple will replace them with the iPhone and iPad casual users who now use Windows PCs.
could use any old Intel machine really. or pick up an old Dell server for a few hundred off eBay if you have some place to put it (fan noise reasons mostly).
That being said, all operating systems that run on more than a single type of machine are generally designed with a hardware abstraction layer, and that interacts as needed with low-level boot code, which may also need to be done custom. Once that’s done, the rest of the OS (once you have compilers designed to properly use the CPU instructions correctly) should largely just be a recompile, combined with ensuring there are device-specific drivers.
So, if you have more to worry about than adapting compiler toolchains, boot code, a little abstraction code for certain optimized APIs in the OS, and the HAL and device drivers, you’re doing it wrong.
The rest is mechanical in nature.
Tomorrow is a different story.
Point 2: "You're doing it wrong ... the rest is mechanical in nature." Ah. That is where you are going with this. The first is FALSE and the second is VERY FALSE. Clearly you haven't done this before. Let the people who have be the ones to talk about this because they are the ones who are actually qualified to do so. Go try to port a major application from x86 to ARM on the same OS (i.e. Linux or Android) and see how "mechanical" it is. Not even that ... merely port a 32 bit application to a 64 bit one. Done it before? It is neither easy or fun. But I guess it should have been "mechanical" and it was "being done wrong" eh? Goodness where do people like this come from?
Open standards (like USB for ports!), Java and other multiplatform tools, the web, cloud, SaaS etc. created a situation where "everything is a PC" whether it was running Windows, macOS or even Linux. (ChromeOS is the only outlier.) The current generation of tech workers expects to be able to use pretty much any hardware they buy basically the same way. If you are someone who actually "uses a Mac like a Mac" - meaning that you rely primarily on software written for macOS - then you won't understand how big a chance this is for these people. Some people "get it" ... I saw the first raft of articles stating that Macs should no longer be considered PCs last year. But if you are someone that has made building applications, networks and infrastructure based on open multiplatform standards with hardware as interchangeable parts the basis of your entire career - and if you are under 40 you have done exactly that - then this is a major change.
Enough to take your rack-mounted Mac Minis and your Xeon Mac Pros out of your infrastructure? Well if you were responsible for 500 devices, would you still use 75 of them if they didn't boot the same way? Or would you go for uniformity? Exactly. It wasn't a problem for iPhones and iPads because no one deploys the Apache applications on iPhones and iPads that are used to encrypt outbound web traffic. Instead, they deployed it on rack-mounted Mac Minis running Linux that were used to encrypt web traffic that originated on the iPhones and iPads. These folks would prefer to continue to use the Mac Minis for this because they perform well, are extremely reliable and have small footprints. But if problems like this can't be solved, they won't be able to. They will likely switch to Intel Nucs or small form factor Dells instead, even if a single M1 Mac is capable of handling the load of 2 Dells.