|
|
Subscribe / Log in / New account

Asahi Linux progress report

The Asahi Linux project, which is working to build a distribution for M1-based Apple systems, has published a progress report for January and February. "Apple Silicon Macs boot in a completely different way from PCs. The way they work is more akin to embedded platforms (like Android phones, or, of course, iOS devices), but with quite a few bespoke mechanisms thrown in. However, Apple has taken a few steps to make this boot process feel closer to that of an Intel Mac, so there has been a lot of confusion around how things actually work. For example, did you know that Apple Silicon Macs cannot boot from external storage at all, in the traditional sense? Or that the bootloader on Apple Silicon Macs cannot show a graphical user interface at all, and that the “Boot Picker” is in fact a full-screen macOS app, not part of the bootloader?"

to post comments

Asahi Linux progress report

Posted Mar 11, 2021 16:22 UTC (Thu) by darwi (subscriber, #131202) [Link] (28 responses)

Oh, if that's the future of laptop computing, I don't want to be part of it :(

With all the faults of Microsoft and Intel, at least they worked hard in making PC computing a (relatively) open standard. They also pushed for standard hardware/firmware interfaces (UEFI, ACPI, USB hardware classes, standardized hardware interface for audio, PCI before that, etc. etc.)

Asahi Linux progress report

Posted Mar 11, 2021 18:30 UTC (Thu) by mss (subscriber, #138799) [Link] (21 responses)

These standard interfaces (and hiding platform details behind them) were required in part because otherwise older Windows versions would not run properly on newer hardware.

Asahi Linux progress report

Posted Mar 11, 2021 23:03 UTC (Thu) by flussence (guest, #85566) [Link] (20 responses)

...and also partly so newer Windows versions had an excuse to not run properly on older hardware (DRM).

Asahi Linux progress report

Posted Mar 12, 2021 0:10 UTC (Fri) by mss (subscriber, #138799) [Link] (19 responses)

What kind of DRM you have on mind?

As far as I know Windows 10 runs fine without TPM or Secure Boot on open-source UEFI implementation.

Asahi Linux progress report

Posted Mar 12, 2021 16:07 UTC (Fri) by ledow (guest, #11753) [Link] (8 responses)

Windows Server requires TPM and Secure Boot.

It won't be long before that's rolled down to consumer versions.

Asahi Linux progress report

Posted Mar 12, 2021 17:02 UTC (Fri) by mss (subscriber, #138799) [Link] (4 responses)

> Windows Server requires TPM and Secure Boot.

Which specific Windows Server versions require them to run?

Microsoft has sait it will require TPM and Secure Boot for the *hardware to be certified* for the next (not yet retail) version of Windows Server (2022), but there hasn't been any announcement that it will require these features to actually run.

And Windows Server 2019 certainly doesn't require either.

> It won't be long before that's rolled down to consumer versions.

Most consumer "enthusiast" motherboards offered today lack TPM chip, some (many?) don't even have the necessary LPC bus connector.

Asahi Linux progress report

Posted Mar 13, 2021 5:56 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> Which specific Windows Server versions require them to run?
It's a new requirement that will be enforced starting next month for new installations of WS. It can be overridden if necessary.

Asahi Linux progress report

Posted Mar 13, 2021 13:04 UTC (Sat) by mss (subscriber, #138799) [Link] (2 responses)

> > Which specific Windows Server versions require them to run?
> It's a new requirement that will be enforced starting next month for new installations of WS. It can be overridden if necessary.

Which specific Windows Server versions you have on mind?

Do you have any link to Microsoft annunciation of the policy change next month?

Asahi Linux progress report

Posted Mar 13, 2021 14:48 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I think all of them. https://cloudblogs.microsoft.com/windowsserver/2020/06/11... - there is now a requirement for new Windows Server hardware to include TPMs and they are automatically used by the installer.

You can disable the TPM after the installation.

Asahi Linux progress report

Posted Mar 13, 2021 15:15 UTC (Sat) by mss (subscriber, #138799) [Link]

> there is now a requirement for new Windows Server hardware to include TPMs and they are automatically used by the installer.

They are required for new Windows Server *certified* hardware, that is, for hardware to be specifically blessed by Microsoft.

As I have said in the comment above:
> Microsoft has sai[d] it will require TPM and Secure Boot for the *hardware to be certified* for the next (not yet retail) version of Windows Server (2022),
> but there hasn't been any announcement that it will require these features to actually run.

Nothing in the article you mentioned says that Windows Server will run only on hardware certified by Microsoft.

That is, you can run Windows on hardware that lacks these features.
Just the hardware will not get "blessed by Microsoft" badge.

Asahi Linux progress report

Posted Mar 13, 2021 5:55 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Microsoft has a very serious stake in keeping Windows Server secure, so a TPM requirement is a good idea and it costs pretty much nothing for the server-class hardware.

It simply won't work for foreseeable future on commodity hardware, because TPM chips are not standard and are not present on a lot of hardware. My brand-new gaming PC doesn't have one, for example.

Asahi Linux progress report

Posted Mar 15, 2021 0:28 UTC (Mon) by zlynx (guest, #2285) [Link] (1 responses)

Pretty much any CPU made in the last three years supports "fTPM" which is implemented via the secure compute element in the CPU itself. That goes for Intel and AMD Ryzen.

Asahi Linux progress report

Posted Mar 15, 2021 1:21 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

Not quite - the Intel implementation runs on the ME, which is on the chipset for non-SoC devices. AMD's implementation is on the PSP, which *is* on the CPU package. But yes, assuming the system vendor has wired it up, you don't need a physical TPM for TPM functionality these days. In some ways, it's even preferable - the LPC bus that discrete TPMs are attached to is extremely easy to interpose, which is far less true for fTPMs.

Asahi Linux progress report

Posted Mar 14, 2021 20:19 UTC (Sun) by flussence (guest, #85566) [Link] (9 responses)

The OP mentioned audio interfaces, and it's common knowledge Intel's HDA interface was crippled compared to AC97 at the behest of the music industry.

Asahi Linux progress report

Posted Mar 15, 2021 17:11 UTC (Mon) by ttuttle (subscriber, #51118) [Link] (5 responses)

Whoa, I would love to hear more about this. Do you have a link?

Asahi Linux progress report

Posted Mar 18, 2021 20:56 UTC (Thu) by flussence (guest, #85566) [Link] (4 responses)

It happened in the Windows Vista era, so nope. The main change was completely removing any hardware ability to capture raw data being sent to line out, which was more or less standard by the end of AC97. Pretty much useless at stopping casual piracy but it hurt a lot of legitimate use cases.

Asahi Linux progress report

Posted Mar 18, 2021 23:08 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

This is likely a result of Vista completely overhauling the audio stack. It basically stopped supporting anything complex for output.

Asahi Linux progress report

Posted Mar 19, 2021 0:00 UTC (Fri) by flussence (guest, #85566) [Link] (1 responses)

The base OS removed that ability, but I've heard enough irritated tales of having to “reboot into ASIO mode” that high end sound cards apparently didn't die out entirely.

Asahi Linux progress report

Posted Mar 19, 2021 0:06 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

There was nothing stopping you from talking with audio cards directly, you just needed a driver for that. Some "pro" audio cards tried that approach, but it just wasn't worth it. Floating point software mixing just became way superior to any fixed DSP magic, especially at the pro level.

Asahi Linux progress report

Posted Mar 19, 2021 11:51 UTC (Fri) by farnz (subscriber, #17727) [Link]

That ability was not removed by Intel HDA - in the HDA spec, you have Selectors which can be controlled by the host software to route audio signals in any fashion the codec designer chooses to allow.

Some codecs allow you to route audio in a loopback fashion, some don't - those with processing tend to. Same as AC'97 - some AC'97 devices allow loopback, some don't. The difference is that Windows Vista doesn't expose a full set of controls - just the minimal set they want for "consumer" audio - on HDA, whereas it can't do that on AC'97 devices.

Nothing to do with hardware, and everything to do with the choice of software you run on that hardware. Linux never had this issue :)

Asahi Linux progress report

Posted Mar 16, 2021 11:41 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

I can't find documentation of this anywhere, and having spent a lot of time in past jobs with HDA and AC97 devices, I can't see anything different about HDA that enables DRM as compared to AC97 - from the CPU side, the distinctions are that HDA supports higher bit rates than AC97, and more complex analogue codec configurations (e.g. an 8 channel audio output that can be split into 4 stereo outs, or used as 7.1 channel surround, where AC97 has only fixed setups).

Do you have a reference listing the features of HDA that make it crippled as compared to AC97?

Asahi Linux progress report

Posted Mar 16, 2021 12:32 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

Well, HDA does provide an interface to set the "protected bit" of SP/DIF outputs.

But so did every AC97 codec that supported SP/DIF output, so that's hardly a regression.

(I think my first kernel contribution was a patch enabling that feature for various Crystal Semi codecs -- The receiver I was trying to use refused to accept data that didn't have that bit set, and forcing it on was enough to get it working...)

Asahi Linux progress report

Posted Mar 16, 2021 12:52 UTC (Tue) by farnz (subscriber, #17727) [Link]

It also has a set of verbs defined to confirm HDCP is in place before sending audio, but there's no standard way to encrypt the audio on a HDA link, just as there's no standard way to encrypt the audio on an AC97 link. And there's no standard way to do HDMI audio on AC97 at all, so the fact that HDCP can be checked in a standard fashion on HDA is neither here nor there - any AC97 audio implementation would do the same.

Asahi Linux progress report

Posted Mar 12, 2021 6:26 UTC (Fri) by hrw (subscriber, #44826) [Link]

Arm architecture has standards. Properly designed hardware with standard firmware boots normal Linux, BSD or MS Windows out of the box.

Just there are many vendors who chosen own way. Apple being one of them.

Asahi Linux progress report

Posted Mar 12, 2021 10:15 UTC (Fri) by rsidd (subscriber, #2582) [Link] (3 responses)

When Compaq and others created the IBM PC clone market, it became a necessity to push standardised hardware, because people wanted to run MS-DOS (later Windows) on all these machines. Microsoft and the hardware makers had an interest in interoperable hardware, and Linux benefited. Meanwhile, Apple sold its own hardware and did not need to follow any standards.

Same story today, except it's not so easy to install what OS you like on most ARM hardware (can be done, but not by just booting off a floppy or USB drive.) But, for what it's worth, Android (therefore Linux) is the OS compatible with a vast range of hardware, whose manufacturers must follow some standards if porting Android is not to be a complete nightmare. While iOS (and now macOS) are specific to Apple hardware which need not follow any standards. In this picture, Microsoft has been replaced by Google, otherwise nothing has changed since the 1980s.

Asahi Linux progress report

Posted Mar 12, 2021 10:47 UTC (Fri) by geert (subscriber, #98403) [Link] (2 responses)

In Android, Linux has overtaken the role of the BIOS in the IBM PC?

Asahi Linux progress report

Posted Mar 14, 2021 18:19 UTC (Sun) by WolfWings (subscriber, #56790) [Link] (1 responses)

In some cases, essentially yes. Even some niche x86 hardware are booting Linux as the "bios" and then that in turn can kexec a final Linux image, or failing that you're already in a 'rescue shell' instead of having to explicitly reboot into one. And in some distros they do likewise so you can end up passing through 2 Linux kernel's before reaching your actual login prompt in the 3rd layer. CoreBoot -> Linux Payload -> Linux as a Bootloader -> Linux Desktop

Asahi Linux progress report

Posted Mar 19, 2021 9:36 UTC (Fri) by geert (subscriber, #98403) [Link]

I didn't mean any of the solutions using kexec (milo/kboot/petitboot/...) to boot Linux from Linux, but Linux really being the common ground.
MS-DOS ran on anything providing the PC BIOS API.
Android runs on anything providing (a specific) Linux userspace API.

Asahi Linux progress report

Posted Mar 13, 2021 4:03 UTC (Sat) by BirAdam (guest, #132170) [Link]

I don’t think that’s just the future of laptop computing. Locked down devices that you do not own seems to be the future of all devices: phones, tablets, TVs, laptops, desktops, SBCs, etc.

I hope that some group like Pine64 can make something on truly open hardware and be the Compaq of the new era, but we shall see.

Asahi Linux progress report

Posted Mar 12, 2021 11:02 UTC (Fri) by dottedmag (subscriber, #18590) [Link] (16 responses)

I wonder why there is so much negativity about anything Apple does.

If anything, M1 is a powerful readily-available consumer computer with little proprietary undebuggable code:
- There is nothing like Intel ME
- There is no vendor's bring up code (even chicken bits are in m1n1)
- There is no vendor's buggy ACPI (instead iBoot gives m1n1 a device tree, what else would anyone need?)
- Hardware for key storage is separated from the rest of the system
- iBoot is small, and while iBoot1 is in ROM and hard to obtain, once it's finished it does not leave any code running on the system

A regular PC is way, way, way worse in this regard.

Asahi Linux progress report

Posted Mar 12, 2021 11:18 UTC (Fri) by juliank (guest, #45896) [Link] (5 responses)

We wanted M1 Macs to boot using standard-ish UEFI like ARM servers, given Apples commitment to UEFI when they were on Intel. It would have been great to have a "real" ARM64 PC.

Asahi Linux progress report

Posted Mar 12, 2021 11:33 UTC (Fri) by dottedmag (subscriber, #18590) [Link] (3 responses)

It is a real ARM64 computer, not less real than any other ARM64 device.

Count the number of quirks in arch/x86 and drivers for various ostensibly "standard-ish" PCs. Remember the amount of work every new PC laptop brings to the kernel due to "works on Windows" ACPI tables.

Asahi Linux progress report

Posted Mar 12, 2021 12:41 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> Remember the amount of work every new PC laptop brings to the kernel due to "works on Windows" ACPI tables.

You mean "Works on Windows using device-specific drivers"

But I think you vastly underestimate the number of new models that come out every year.

The ones that need special work are the exceptions.

Asahi Linux progress report

Posted Mar 12, 2021 16:57 UTC (Fri) by dottedmag (subscriber, #18590) [Link]

True, to an extent.

However, Apple is ~7% of the whole PC market, they tend to have 1-2 hardware models at the same time, and they mass-produce them.

Given the number of hardware decisions M1 has inherited from previous Apple devices and the contents of the initial patch series, one can try to extrapolate the amount of kernel work, and it seems to be quite small, for ~7% of all new PCs sold in the world.

Asahi Linux progress report

Posted Mar 16, 2021 4:21 UTC (Tue) by TRS-80 (guest, #1804) [Link]

It's missing EL3 (read the article), so it's less real in that respect.

Asahi Linux progress report

Posted Mar 12, 2021 12:33 UTC (Fri) by johannbg (guest, #65743) [Link]

There is no reason for Apple to be part of some standards. Apple owns/controls/manufactures everything from a-z within and governs it's own ecosystem. It just has to ensure that Apple products work well with other Apple products within their ecosystem.

Asahi Linux progress report

Posted Mar 12, 2021 11:20 UTC (Fri) by xdbob (subscriber, #112586) [Link] (2 responses)

> - There is no vendor's buggy ACPI (instead iBoot gives m1n1 a device tree, what else would anyone need?)

PCIe hotplug is a thing, how would you do that with a device tree ?

> - iBoot is small, and while iBoot1 is in ROM and hard to obtain, once it's finished it does not leave any code running on the system

Apple doesn't load it's `sepOS` on the secure enclave if booting a custom kernel ?

Asahi Linux progress report

Posted Mar 12, 2021 11:30 UTC (Fri) by dottedmag (subscriber, #18590) [Link]

> PCIe hotplug is a thing, how would you do that with a device tree ?

PCIe (or USB for that matter) enumeration does not go away just because there is no ACPI.

> Apple doesn't load it's `sepOS` on the secure enclave if booting a custom kernel ?

Secure Enclave does not sit on the same bus, AFAICT, so it's just another bit of firmware.

Asahi Linux progress report

Posted Mar 12, 2021 13:53 UTC (Fri) by mfuzzey (subscriber, #57966) [Link]

> PCIe hotplug is a thing, how would you do that with a device tree ?

I don't see the connection. If a bus supports enumeration (be it PCIe or USB or something else) you can do hotplug,
regardless of the presence or absence of either ACPI or DT.

ACPI and DT are both about describing *non enumerable* hardware so the OS can use it.

Asahi Linux progress report

Posted Mar 13, 2021 4:07 UTC (Sat) by pabs (subscriber, #43278) [Link] (1 responses)

Isn't iBoot1 in NOR flash rather than ROM? IIRC NOR flash is potentially writeable, but presumably iBoot1 is signed and the bootrom checks the signature though? (Although on some Apple devices the 'checkm8' bootrom exploit and the checkra1n jailbreak can bypass that).

Asahi Linux progress report

Posted Mar 13, 2021 8:36 UTC (Sat) by dottedmag (subscriber, #18590) [Link]

You're right on both counts.

Asahi Linux progress report

Posted Mar 13, 2021 10:54 UTC (Sat) by wookey (guest, #5501) [Link] (2 responses)

"I wonder why there is so much negativity about anything Apple does."

Because they are a horrible outfit who've done some disgusting things over the years. I'm never going to forgive them for the outrageous abuse of design patents in the Samsung 'oblong phones with round corners' case, for example. Also their walled garden approach is the antithesis of what I want in my computing (which I why I have never bought anything from them). On the other hand their approach to privacy makes them significantly less reprehensible than other large players these days, so they aren't _all_ bad :-)

But the M1 is really nice hardware (I am very impressed with the battery life, at least under macos) and so long as it's not 'tivo'd' then I don't really care how it's booted. UEFI would have been nice, but if we have to deal with some other special scheme then it's annoying (especially for distros), but we can cope.

Asahi Linux progress report

Posted Mar 14, 2021 2:34 UTC (Sun) by rsidd (subscriber, #2582) [Link] (1 responses)

Steve Jobs was obnoxious and was responsible for the Samsung case. I think Apple has been much more innovative, in ways that matter, under Cook and has been no worse a member of the open source community than most other corporates. The M1 laptop could have been much more locked down (like iPad) than it actually seems to be. Making it easy for other OS's wasn't Apple's priority but hindering them doesn't seem to have been the goal either. The good thing is they have kicked the ARM laptop door open (there were chromebooks but they were not regarded as high-performance machines) and other vendors, and Microsoft, need to take notice and maybe evolve some standards.

Asahi Linux progress report

Posted Mar 14, 2021 4:45 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> The M1 laptop could have been much more locked down (like iPad) than it actually seems to be.
Give it time.

M1 laptop is replacing a fully open X86-based laptop. Of course they can't lock it down immediately. But I'd be surprised if it stays equally open in 10 years.

Asahi Linux progress report

Posted Mar 13, 2021 18:17 UTC (Sat) by dxld (subscriber, #90530) [Link]

> There is no vendor's bring up code (even chicken bits are in m1n1)

That's incorrect. There is a proprietary, signed, bootloader "iBoot2". The post has this to say about the boot flow:

> [...] the entire boot process ends up looking like this:
>
> - The SecureROM inside the M1 SoC starts up on cold boot, and loads iBoot1 from NOR flash
>
> - iBoot1 reads the boot configuration in the internal SSD, validates the system boot policy, and chooses an “OS” to boot [...]
>
> - iBoot2, which is the “OS loader” and needs to reside in the OS partition being booted to, loads firmware for internal devices, sets up the Apple Device Tree, and boots a Mach-O kernel (or in our case, m1n1).

and later:

> Note that we cannot replace iBoot2 (it requires an Apple signature), [...]

Asahi Linux progress report

Posted Mar 19, 2021 13:07 UTC (Fri) by jschrod (subscriber, #1646) [Link]

> I wonder why there is so much negativity about anything Apple does.

Apple -- hmm. The company that tried to copyright the WIMP (Windows, Icons, Menu, Pointer) interface after they stole it from Xerox. The company who tried to establish design patents on rounded corners. The company who's the leader of the "walled garden" approach.

Yes, I also really wonder why there's this amount of negativity. I would have expected more.

Asahi Linux progress report

Posted Mar 14, 2021 8:02 UTC (Sun) by watersb (guest, #10230) [Link]

Reading this epic of engineering exploration is super inspiring to me.

Incredible work.

Just read this thing! 10,000 words of education.


Copyright © 2021, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds