10 ms·

I continue to be skeptical of all the "boots on Apple M1" efforts. Ultimately, I don't expect them to get much further than the "proof-of-concept" phase, as far

I continue to be skeptical of all the "boots on Apple M1" efforts. Ultimately, I don't expect them to get much further than the "proof-of-concept" phase, as far as usability goes. Apple's chips are SoCs, and as such are extremely complicated systems. There are tons of parameters to make it work efficiently that either need to be carefully reverse-engineered, or out-of-reach entirely. Apple not only won't be any help, but will be actively hindering these efforts. For example, is anyone dealing with the performance modes of the chip, tuning them for performance-vs-dissipation? What about the DRAM interface? Alyssa Rosenzweigs effort on reverse-engineering the GPU is impressive and laudable, but it's just one component of the dozens or so IP blocks in the chip, each of which require that level of work. Being able to boot your OS on the CPU is like landing on the beaches of Brittania and calling it conquered. (I couldn't come up with a better analogy) I understand the appeal of the technical challenge, and that's awesome! But people should lower their expectations if they ever expect to run an open OS with the full power (or even significant fraction) of the hardware.

rjsw 5y ago
The Apple M1 is useful as a fast build machine even if the GPU is never usable by non-Apple operating systems.
- AceJohnny2 5y ago
  Is it really the best option, performance-per-$?
- amelius 5y ago
  Yeah, but one day Apple might pull the plug on non-Apple OSes. By then, all of you people who supported Apple will have to find another solution, which may not be as appealing since the competition is now far behind because of all your support of Apple hardware. Therefore it's better to switch earlier than sooner even if it means a small step back in performance.
  - rowanG077 5y ago
    You don't actually have to find another solution. The state it's in will continue working. The only thing apple can do is release a new piece of hardware that is locked down. But that could always happen regardless of vendor. Besides I don't think that's a serious risk with macs.
    - amelius 5y ago
      > The state it's in will continue working. Maybe so. But then again, maybe not if Apple decides to blow a bunch of fuses remotely. Also, your laptop could break. Or you might want to expand to more laptops but the one you are using now runs out of production.
      - rowanG077 5y ago
        > Apple decides to blow a bunch of fuses remotely Then just... not update.
        amelius 5y ago
        You seem to be under the impression that an OS has full control over the system when it is running. This is not necessarily true, see Intel ME.
        rowanG077 5y ago
        That is a class action law suit waiting to happen. I'm not saying it's not technically possible. I think Apple is smart enough to not do that.
rowanG077 5y ago
You truly expect every IP in the SoC to require GPU level complexity? That's a far out assumption imo. The speed of progress made on getting Linux to run is extremely high and once the GPU runs they will focus on power management. I think you are over way over estimating the impossibility of this task.
- amelius 5y ago
  You missed the point. Apple may decide to make it more difficult to reverse-engineer their hardware. For now, we (the Linux/BSD community) are allowed to use their hardware, but this may not always be the case, e.g. when M1's successor hits the market.
  - rowanG077 5y ago
    So we are now speculating about future hardware? Apple macs were never locked down. Why would they now suddenly start being locked down? If Apple wanted to lock them down there would not have been a better moment then with the M1. They already have all the tech ready to go. But they obviously decided not do to that. Assuming a product line that has been not locked down for decades to suddenly start being locked down AFTER the best moment to do it is the wrong assumption.
    - amelius 5y ago
      https://news.ycombinator.com/item?id=23640746 https://news.ycombinator.com/item?id=23640746 I will believe Apple if they say they officially support booting of other OSes, and will keep doing so in the future.
      - rowanG077 5y ago
        You mean like they supported bootcamp "officially" and then just took it away suddenly with M1? I don't see how that is different then having unofficial support and apple then locking down a new Mac. In either case you lost support with a new hardware platform.
CharlesW 5y ago
> Apple not only won't be any help, but will be actively hindering these efforts. They won't hinder anything, because they make money from the hardware.
- breakfastduck 5y ago
  Seriously. Apple have absolutely fractional actual reasons to limit non macOS boots on M1 devices. The fact they've made the transition & taken macOS to a whole version beyond X and kept supporting non apple OS boots on the devices proves (to me at least) that they're not going to remove it. If there ever was a time to lock that down, it was on the architecture shift.
  - amelius 5y ago
    > and kept supporting non apple OS boots They don't officially (!) support it.
    - jolux 5y ago
      Of course they don’t, or people wouldn’t have to be reverse engineering things. But it doesn’t affect your hardware warranty.
      - amelius 5y ago
        What was your point?
        jolux 5y ago
        I don’t understand what you mean by criticizing it for not being officially supported.
    - snazz 5y ago
      They do officially support the Permissive security policy, and it is intended to allow you to boot custom kernels. Running a fully-untrusted operating system kernel is an intended feature, even if they aren't going to give you support if something breaks in the upper layers. See https://support.apple.com/guide/security/startup-disk-security-policy-control-sec7d92dc49f/web#seca904a9a35 https://support.apple.com/guide/security/startup-disk-securi...
liveoneggs 5y ago
you sound fun. I'd love to see your operating system efforts.
1vuio0pswjnm7 5y ago
"... if they expect to run an open OS with the full power (or even a significant fraction) of the hardware." When using open OS I never expect that.1 To me its a tradeoff worth making. 1 In some cases I dont want/need all the hardware features. Is there a name for the common practice where a vendor produces a low-priced and a high-priced version of a product that actually contain the exact same chip, only the lower-priced version has some features disabled. Vendors seem not to fear that buyers will reject the lower-priced version because it does not access all the chip's capabilities
- AceJohnny2 5y ago
  > Is there a name for the common practice where a vendor produces a low-priced and a high-priced version of a product that actually contain the exact same chip, only the lower-priced version has some features disabled. There's binning, and market segmentation, I think. Binning is the part where you produce all your units "identically", but then test them and put them in different output "bins" depending on their performance (or size or functional features or whatever). Market segmentation is where you break up your product into different artificially-differentiated quality/feature-tiers, in order to extract maximum value from the market (cheap tier for those budget items, high tiers for those who have more money to spend). The thing with Binning for silicon is that eventually your manufacturing process is tuned well enough that most of your parts are full-featured, so then you have to explicitly disable features to preserve your market segmentation. I don't know the term for that exact action.
  - wmf 5y ago
    It's called damaged goods price discrimination.
- 1vuio0pswjnm7 5y ago
  s/has some features disabled/has some features intentionally disabled/
marcan_42 5y ago
> need to be carefully reverse-engineered That's what the entire project is about. > or out-of-reach entirely This is nonsense. There is nothing out of reach. This is obviously provable by the fact that macOS itself runs just fine in permissive security mode, which is indistinguishable to the machine to running Linux. We even have it running on a bespoke hypervisor, booting to desktop, which is how we reverse engineer its interactions with the hardware. > is anyone dealing with the performance modes of the chip, tuning them for performance-vs-dissipation? Yes, I'll be working on that as soon as the basic GPU kernel driver prototype is done. I already wrote the clock gating driver last week, which was one of the things on my immediate TODO list. > What about the DRAM interface? On the M1, unlike typical SoCs from other vendors which are a giant mess in this area, most of these gritty power management details are handled by onboard coprocessors running Apple firmware. This makes porting an OS a lot easier, as you only need to deal with a much higher level interface than you would on other SoCs. Even CPU sleep modes have an automatic mode. You set it to auto, issue wfi, and some heuristic inside the CPU itself decides if it should do a deep sleep or a shallow sleep. Not sure if we'll use that since Linux is perfectly capable of handling CPU c-state decisions itself (and all we really have to do there is measure the latencies so Linux knows what to expect), but just to give you an idea. The CPU frequency scaling is abstracted out behind a few simple registers. Poke this register to set the CPU core cluster voltage, poke this other register to set the p-state for a core. No need for thousands of lines of code to deal with calling out to an external I²C PMU to set the vcore voltage or doing a complex PLL frequency switching dance. It's stupid easy. We haven't written a proper driver for that yet, but Corellium wrote a PoC version and it's 390 lines of code. > each of which require that level of work. Nope. We already have DART, NVMe, USB, PCIe, I²C, UART, SPI and parts of power management working. Things like I²C and SPI are trivial little blocks. The GPU is by far the biggest thing. I just got DCP display modesetting working last night on our prototype driver; Alyssa is implementing it in Linux soon. > Apple not only won't be any help, but will be actively hindering these efforts. I guess they spent a huge amount of development time writing the entire BootPolicy framework that enables other OSes just for fun then, and are planning on throwing it all away? This doesn't make any sense. I keep hearing this FUD and we have seen zero evidence that Apple plan to hinder anyone. The Mac is an open platform and always has been. They are neither helping nor hindering anyone trying to port an OS to this thing. They are tacitly saying "have fun". I'm not sure why nobody trusts us when we say we're going to make this all work properly. We aren't nobodies; the major team contributors have been reverse engineering hardware for a decade or so. We've been staring at this thing for the past 9 months. We know what to expect. We haven't been putting together a PoC all this time; we've been engineering and reverse engineering things to put together proper, full, upstreamable support. That's why it takes time. But once it comes together you'll see it's far from a mere PoC.
userbinator 5y ago
What about the DRAM interface? On x86 platforms, that is usually initialised by the BIOS (which also does things like memory testing.) On Apple's ARM platforms, I'm not really familiar with how boot works but I believe they have an equivalent firmware to handle that.

rjsw 5y ago

The Apple M1 is useful as a fast build machine even if the GPU is never usable by non-Apple operating systems.

AceJohnny2 5y ago
Is it really the best option, performance-per-$?
amelius 5y ago
Yeah, but one day Apple might pull the plug on non-Apple OSes. By then, all of you people who supported Apple will have to find another solution, which may not be as appealing since the competition is now far behind because of all your support of Apple hardware. Therefore it's better to switch earlier than sooner even if it means a small step back in performance.
- rowanG077 5y ago
  You don't actually have to find another solution. The state it's in will continue working. The only thing apple can do is release a new piece of hardware that is locked down. But that could always happen regardless of vendor. Besides I don't think that's a serious risk with macs.
  - amelius 5y ago
    > The state it's in will continue working. Maybe so. But then again, maybe not if Apple decides to blow a bunch of fuses remotely. Also, your laptop could break. Or you might want to expand to more laptops but the one you are using now runs out of production.
    - rowanG077 5y ago
      > Apple decides to blow a bunch of fuses remotely Then just... not update.
      - amelius 5y ago
        You seem to be under the impression that an OS has full control over the system when it is running. This is not necessarily true, see Intel ME.
        rowanG077 5y ago
        That is a class action law suit waiting to happen. I'm not saying it's not technically possible. I think Apple is smart enough to not do that.

rowanG077 5y ago

You truly expect every IP in the SoC to require GPU level complexity? That's a far out assumption imo. The speed of progress made on getting Linux to run is extremely high and once the GPU runs they will focus on power management. I think you are over way over estimating the impossibility of this task.

amelius 5y ago
You missed the point. Apple may decide to make it more difficult to reverse-engineer their hardware. For now, we (the Linux/BSD community) are allowed to use their hardware, but this may not always be the case, e.g. when M1's successor hits the market.
- rowanG077 5y ago
  So we are now speculating about future hardware? Apple macs were never locked down. Why would they now suddenly start being locked down? If Apple wanted to lock them down there would not have been a better moment then with the M1. They already have all the tech ready to go. But they obviously decided not do to that. Assuming a product line that has been not locked down for decades to suddenly start being locked down AFTER the best moment to do it is the wrong assumption.
  - amelius 5y ago
    https://news.ycombinator.com/item?id=23640746 https://news.ycombinator.com/item?id=23640746 I will believe Apple if they say they officially support booting of other OSes, and will keep doing so in the future.
    - rowanG077 5y ago
      You mean like they supported bootcamp "officially" and then just took it away suddenly with M1? I don't see how that is different then having unofficial support and apple then locking down a new Mac. In either case you lost support with a new hardware platform.

CharlesW 5y ago

> Apple not only won't be any help, but will be actively hindering these efforts. They won't hinder anything, because they make money from the hardware.

breakfastduck 5y ago
Seriously. Apple have absolutely fractional actual reasons to limit non macOS boots on M1 devices. The fact they've made the transition & taken macOS to a whole version beyond X and kept supporting non apple OS boots on the devices proves (to me at least) that they're not going to remove it. If there ever was a time to lock that down, it was on the architecture shift.
- amelius 5y ago
  > and kept supporting non apple OS boots They don't officially (!) support it.
  - jolux 5y ago
    Of course they don’t, or people wouldn’t have to be reverse engineering things. But it doesn’t affect your hardware warranty.
    - amelius 5y ago
      What was your point?
      - jolux 5y ago
        I don’t understand what you mean by criticizing it for not being officially supported.
  - snazz 5y ago
    They do officially support the Permissive security policy, and it is intended to allow you to boot custom kernels. Running a fully-untrusted operating system kernel is an intended feature, even if they aren't going to give you support if something breaks in the upper layers. See https://support.apple.com/guide/security/startup-disk-security-policy-control-sec7d92dc49f/web#seca904a9a35 https://support.apple.com/guide/security/startup-disk-securi...

liveoneggs 5y ago

you sound fun. I'd love to see your operating system efforts.

1vuio0pswjnm7 5y ago

"... if they expect to run an open OS with the full power (or even a significant fraction) of the hardware." When using open OS I never expect that.1 To me its a tradeoff worth making. 1 In some cases I dont want/need all the hardware features. Is there a name for the common practice where a vendor produces a low-priced and a high-priced version of a product that actually contain the exact same chip, only the lower-priced version has some features disabled. Vendors seem not to fear that buyers will reject the lower-priced version because it does not access all the chip's capabilities

AceJohnny2 5y ago
> Is there a name for the common practice where a vendor produces a low-priced and a high-priced version of a product that actually contain the exact same chip, only the lower-priced version has some features disabled. There's binning, and market segmentation, I think. Binning is the part where you produce all your units "identically", but then test them and put them in different output "bins" depending on their performance (or size or functional features or whatever). Market segmentation is where you break up your product into different artificially-differentiated quality/feature-tiers, in order to extract maximum value from the market (cheap tier for those budget items, high tiers for those who have more money to spend). The thing with Binning for silicon is that eventually your manufacturing process is tuned well enough that most of your parts are full-featured, so then you have to explicitly disable features to preserve your market segmentation. I don't know the term for that exact action.
- wmf 5y ago
  It's called damaged goods price discrimination.
1vuio0pswjnm7 5y ago
s/has some features disabled/has some features intentionally disabled/

marcan_42 5y ago

> need to be carefully reverse-engineered That's what the entire project is about. > or out-of-reach entirely This is nonsense. There is nothing out of reach. This is obviously provable by the fact that macOS itself runs just fine in permissive security mode, which is indistinguishable to the machine to running Linux. We even have it running on a bespoke hypervisor, booting to desktop, which is how we reverse engineer its interactions with the hardware. > is anyone dealing with the performance modes of the chip, tuning them for performance-vs-dissipation? Yes, I'll be working on that as soon as the basic GPU kernel driver prototype is done. I already wrote the clock gating driver last week, which was one of the things on my immediate TODO list. > What about the DRAM interface? On the M1, unlike typical SoCs from other vendors which are a giant mess in this area, most of these gritty power management details are handled by onboard coprocessors running Apple firmware. This makes porting an OS a lot easier, as you only need to deal with a much higher level interface than you would on other SoCs. Even CPU sleep modes have an automatic mode. You set it to auto, issue wfi, and some heuristic inside the CPU itself decides if it should do a deep sleep or a shallow sleep. Not sure if we'll use that since Linux is perfectly capable of handling CPU c-state decisions itself (and all we really have to do there is measure the latencies so Linux knows what to expect), but just to give you an idea. The CPU frequency scaling is abstracted out behind a few simple registers. Poke this register to set the CPU core cluster voltage, poke this other register to set the p-state for a core. No need for thousands of lines of code to deal with calling out to an external I²C PMU to set the vcore voltage or doing a complex PLL frequency switching dance. It's stupid easy. We haven't written a proper driver for that yet, but Corellium wrote a PoC version and it's 390 lines of code. > each of which require that level of work. Nope. We already have DART, NVMe, USB, PCIe, I²C, UART, SPI and parts of power management working. Things like I²C and SPI are trivial little blocks. The GPU is by far the biggest thing. I just got DCP display modesetting working last night on our prototype driver; Alyssa is implementing it in Linux soon. > Apple not only won't be any help, but will be actively hindering these efforts. I guess they spent a huge amount of development time writing the entire BootPolicy framework that enables other OSes just for fun then, and are planning on throwing it all away? This doesn't make any sense. I keep hearing this FUD and we have seen zero evidence that Apple plan to hinder anyone. The Mac is an open platform and always has been. They are neither helping nor hindering anyone trying to port an OS to this thing. They are tacitly saying "have fun". I'm not sure why nobody trusts us when we say we're going to make this all work properly. We aren't nobodies; the major team contributors have been reverse engineering hardware for a decade or so. We've been staring at this thing for the past 9 months. We know what to expect. We haven't been putting together a PoC all this time; we've been engineering and reverse engineering things to put together proper, full, upstreamable support. That's why it takes time. But once it comes together you'll see it's far from a mere PoC.

userbinator 5y ago

What about the DRAM interface? On x86 platforms, that is usually initialised by the BIOS (which also does things like memory testing.) On Apple's ARM platforms, I'm not really familiar with how boot works but I believe they have an equivalent firmware to handle that.