[HN Gopher] Asahi Linux for M1 Macs: progress report for Septemb...
___________________________________________________________________
Asahi Linux for M1 Macs: progress report for September 2021
Author : fanf2
Score : 391 points
Date : 2021-10-05 17:38 UTC (5 hours ago)
(HTM) web link (asahilinux.org)
(TXT) w3m dump (asahilinux.org)
| bgorman wrote:
| "On typical SoCs, drivers have intimate knowledge of the
| underlying hardware, and they hard-code its precise layout: how
| many registers, how many pins, how things relate to each other,
| etc......
|
| However, Apple is unique in putting emphasis in keeping hardware
| interfaces compatible across SoC generations ..... the device
| tree then can be used to represent the dependency relationships
| between these power domains dynamically. ... This approach is
| unfamiliar to most upstream subsystem maintainers, but we hope
| they recognize the benefits over time. Who knows, perhaps this
| will inspire other manufacturers to do it this way!"
|
| This is really weird commentary to me, as far as I know Device
| Tree has been the standard for embedded ARM drivers in the Linux
| kernel for years, and for several years on PowerPC before that.
| When I worked in embedded linux, often the "bringup" for
| components in new ASICs was to create the device tree definition.
| What am I missing here?
| marcan_42 wrote:
| This is about compatible properties. On typical DTs and SoCs,
| you end up with entirely new compatibles for tons of stuff
| every SoC generation, and it'd never work with the old ones.
| What we're doing is putting on generic compatibles that old
| drivers can continue to bind to, and designing the rest of the
| binding to be generic enough to describe _parameters_ of the
| device.
|
| So, a GPIO driver for a random SoC might hardcode that it has
| 42 pins. Ours uses a property instead. The vast majority of
| clock and power management drivers for other SoCs hard code the
| clock or power hierarchy and provide static sets of outputs. We
| put every single clock control in a separate DT node and
| describe their relationships. A typical cpufreq driver has
| intimate knowledge of the clocking controls for the whole SoC,
| and hardcodes the layout of the clock registers. My prototype
| for that just has a separate instance for each CPU cluster, and
| describes the performance states in the DT. And so on and so
| forth.
|
| Basically, on a typical SoC, either a hardware block is
| _identical_ to last generation 's, or it's incompatible.
| Apple's blocks instead follow _patterns_ , so we're building
| parameterizable bindings that can handle any configuration of
| those blocks with a single driver.
| kelnos wrote:
| > _The NVMe hardware in the M1 is quite peculiar: it breaks the
| spec in multiple ways, requiring patches to the core NVMe support
| in Linux, and it also is exposed as a platform device instead of
| PCIe. In addition, it is managed by an ASC, the "ANS", which
| needs to be brought up before NVMe can work, and that also relies
| on a companion "SART" driver, which is like a minimal IOMMU._
|
| Stuff like this makes me wonder: why does Apple do this? If I try
| to give them the benefit of the doubt, I can assume that these
| changes are done for performance, cost, power-saving, or maybe
| even security reasons. Otherwise it just seems like Apple does
| these things in order to make it harder for other OSes to run on
| their hardware. Which is certainly their prerogative, but it just
| makes me think less of them.
|
| On the other hand, this is really cool:
|
| > _However, Apple is unique in putting emphasis in keeping
| hardware interfaces compatible across SoC generations - the UART
| hardware in the M1 dates back to the original iPhone! This means
| we are in a unique position to be able to try writing drivers
| that will not only work for the M1, but may work -unchanged- on
| future chips as well._
|
| ... but cynically (or perhaps just _realistically_ ), I can
| easily believe that this isn't done for reasons of openness, but
| because this makes maintenance of macOS itself easier for Apple.
| jeffbee wrote:
| I believe this has come up multiple times on HN but the reason
| Apple breaks NVMe is because NVMe command structure isn't large
| enough to hold all the crypto state information they need to
| shove down to the device. The spec would not support what they
| are doing, so their choice was to either tweak NVMe to suit, or
| abandon their feature.
| floatboth wrote:
| Why are they even doing crypto at the NMVe level?! Why is it
| not good enough for them to do it at the filesystem level
| (like ZFS native encryption) or at least block device level
| (GELI/dm-crypt/etc)?
| marcan_42 wrote:
| Because that way the OS does not need to ever see the low
| level keys. It allows them to feed them straight from the
| Secure Enclave, which means an OS compromise can never
| result in compromise of storage encryption. Plus they do
| the crypto in a hardware accelerator, so it's free for the
| CPU.
| [deleted]
| jrockway wrote:
| What's the threat model here? If you install malware that
| runs as your user, it can see and edit any of your files
| regardless of whether or not the OS knows decryption keys
| for them. If you require a password to cold boot the
| device, then stealing someone's powered-off laptop
| doesn't get the data. (That's without any special
| hardware.)
|
| So the scenarios that remain are: fingerprint to unlock
| device to boot (need to do some crypto before the OS,
| unless you want the fingerprint to just flat-out give up
| the key to anything sniffing the SPI bus), or somehow
| resisting data modification without requiring the user to
| type a password. I feel like Bitlocker tries to do the
| latter, but I don't know what attacks they are trying to
| protect against. (It's on by default on new laptops, but
| you can just sniff the key over SPI when the OS is
| booting, so what security does it actually provide?)
| r00fus wrote:
| > What's the threat model here?
|
| I'm guessing they're protecting devices against APTs:
| state-level actors with lots of funding, competitors
| intent on discrediting their ecosystem, NSO Group, etc.
|
| As a side benefit for users and Apple it makes the entire
| chain more difficult to introspect/attack.
| mhh__ wrote:
| Also gives them a bigger lock-in opportunity.
| boardwaalk wrote:
| ... what lock-in opportunity? Who's stopping anyone from
| copying files off a Mac?
| chrisseaton wrote:
| Are you asking why they don't the expose the plain-text
| keys to the kernel software? That's your answer.
| marcan_42 wrote:
| Everything Apple does they do because it makes sense for them.
| They are neither trying to help nor hinder third-party OSes.
| They just don't care.
|
| The NVMe design makes sense in the context of their common ASC
| architecture and how their SoC works. Various quirks are due to
| things like supporting their storage encryption. Even for
| things which we can't quite explain, I have no trouble
| believing that it made sense for them for whatever reason.
| joshstrange wrote:
| > Everything Apple does they do because it makes sense for
| them. They are neither trying to help nor hinder third-party
| OSes. They just don't care.
|
| That's my read on this as well. They designed it so it would
| work well with their other hardware/software and this is what
| they landed on. I seriously doubt they paid even a second of
| thought to other OSs running on their hardware. Some people
| will call that "user-hostile" but it's much closer to apathy
| IMHO and as a macOS and Apple hardware user I'm fine with
| that. It's cool that Linux can/will run on the M1 but I'll
| never be doing that myself. It reminds me of that scene in
| Mad Men "I don't think about you at all" [0] but Apple's
| feeling isn't even as sinister or hostile as the comment made
| by Don.
|
| [0] https://youtu.be/LlOSdRMSG_k?t=40
| p2t2p wrote:
| > They just don't care.
|
| Exactly this. I can easily imagine somewhere in some OS slack
| channel in Apple:
|
| hardware dev: hey dear @channel we're breaking NVME spec in
| couple places and we're kinda running out of time to fix it,
| would be so kind to address it in you drivers if it's not too
| hard?
|
| os guy: yeah, no worries those seem trivial, we can easily
| adjust.
|
| hardware guy: cool, thanks a bunch.
| kelnos wrote:
| Thanks for the even-handed reply, which I imagine is much
| easier to have after diving into all this stuff first-hand (I
| assume you're the same 'marcan' who wrote the progress
| report).
|
| As much as many of us want to attribute positive or negative
| reasons or motivations to things companies do -- especially
| secretive companies like Apple -- it's a nice reminder that
| most decisions are made without malice, because they make the
| most sense based on the requirements at hand.
|
| Having control over the entire hardware and software
| ecosystem means that there's no reason to follow standards to
| the letter when those standards get in your way and make
| things harder, more expensive, or even just not possible.
|
| Anyhow, just wanted to finish by saying all of this work is
| truly impressive. Obviously there's still a lot to be done to
| support everything to the same level as, say, a Dell XPS
| machine, but the progress made so far is pretty amazing, and
| even though I have no plans to buy an M1 Mac any time soon,
| I'm always excited to read these updates.
| xoa wrote:
| > _As much as many of us want to attribute positive or
| negative reasons or motivations to things companies do --
| especially secretive companies like Apple -- it 's a nice
| reminder that most decisions are made without malice,
| because they make the most sense based on the requirements
| at hand._
|
| Keep in mind too that "requirements at hand" can include a
| significant degree of path dependency, and that it can be a
| mistake to read too much reasoning into something too.
| Sometimes there just isn't any master plan, some decision
| made years earlier has created a dilemma due to
| dependencies built on it since and there just isn't the
| resources (or ROI, particularly without any spec
| compatibility to worry about) to deal with it right then.
| For a hardware company with necessarily very long lead
| times (they can't exactly start having chips fabbed and
| making electronics two weeks before launch) Apple runs a
| pretty hectic schedule with major new launches every single
| year. Even a vertically integrated company on their scale
| is not completely immune to the challenges of tight
| coupling or thinks of it all ahead, and there are
| definitely decisions Apple has made that they regret but
| can't easily get out from under. For example, just a few
| weeks ago HN had a sizable thread on "Swift Regrets" [0] by
| Jordan Rose:
|
| > _" I worked on Swift at Apple from pre-release to Swift
| 5.1. I'm at least partly responsible for many things people
| like about Swift and many things people hate about Swift.
| This list is something I started collecting around when I
| left Apple, and I'm putting them up so other language
| designers can learn from our mistakes. These are all things
| that would be hard to change in Swift today, because they'd
| break tons of people's code. That's what happens with real-
| world languages and libraries: the more users you have, the
| fewer breaking changes you can make."_
|
| For Apple same definitely turns up in hardware once in a
| while too, though of course they try to be careful and have
| a lot of institutional knowledge about pitfalls by this
| point. Can't always look at something they're doing now and
| assume that if they were greenfielding it they'd do the
| exact same thing again.
|
| That's part of why they've long been (even before iOS) such
| hardasses about stuff like 3rd party use of private APIs
| under development. They certainly don't have any active
| incentive to break existing stuff, if everything could
| magically work forever that'd be awesome, but
| simultaneously they know they fuck up sometimes and want to
| be able to make changes. Hard to balance those in software
| without some kind of push to devs on putting experimental
| OS frameworks into production software or spraying all over
| the drive for installs. Users will inevitably come to
| depend on it anyway and now you're stuck.
|
| For hardware I think it's obscure enough they're not
| worried about it, as absolutely awesome as it is Asahi
| Linux is never going to pinch them there.
|
| ----
|
| 0: https://news.ycombinator.com/item?id=28603794
| bscphil wrote:
| > Keep in mind too that "requirements at hand" can
| include a significant degree of path dependency, and that
| it can be a mistake to read too much reasoning into
| something too.
|
| This is why I'd say there's some value in sticking to
| spec even if it doesn't 100% meet your needs or do things
| the way you think they ought to be done. Tacking away is
| as likely to screw you in the long run as it is to
| benefit you. The benefits would be much more obvious, of
| course, in a world that's almost an unimaginable utopia
| from our perspective: one without intellectual property,
| in which major advances like Apple's ARM silicon were
| widely shared and put to the good of humankind in
| general, rather than held privately for the profit of a
| single corporation.
| oneplane wrote:
| It's also the cost of those decisions would have quite the
| impact on the investment in R&D which is already bonkers as
| it is.
|
| A lot of people try to attribute some human aspect to a
| large multinational (as they are mostly just sociopaths
| controlled by shareholders in a sense), but technology-wise
| it's often just "it made sense for us at our scale".
|
| Same with the weird USB-C PD controllers that are 'almost
| normal' but then specialised for Apple; it's not that they
| want to make it hard to repair, use custom software with or
| patent it and screw with other companies.. it just makes
| sense to change that part instead of changing another part.
| At scale, that is a choice you have, but also a choice you
| must make in such an implementation. This is of course not
| exclusive to Apple, a lot of the really high quantity mass
| produced electronics contain slightly modified versions of
| existing parts because that turns out to be cheaper/more
| reliable/better fit-to-spec than modifying the rest of the
| design around an existing part.
|
| This is one of the baffling things about calculators or toy
| electronics (for light and sound effects) in the same vein;
| modifying an ancient chip with very crude software on a
| single-sided extra thin older style PCB material with no
| silk screen and only partial solder mask with a die-on-PCB
| with wire bonding and epoxy blob... all to make the
| assembly 3 cents instead of 4 cents, and reduce the lack of
| connections to make that 3 cent assembly have less
| possibilities of defects and causing less of a multi-
| thousand-cent service process to be activated (swap in a
| store, callcenter, website, email etc). Every time you get
| one less customer to call about a crappy firetruck where
| the lights stopped flashing in a 3 cent assembly is a huge
| win. This is of course an extreme example, more complicated
| hardware and software extrapolates quite extremely from
| there.
|
| Oddly enough, some of those practises are implemented at a
| much less impactful scale in HP and Dell desktops where
| they might have one large non-standard PCB hosting all the
| normal PC components but also all the DC-DC converters,
| front I/O and on-board WiFi. It makes almost no sense at
| all to do that, but the reduced number of connectors
| apparently makes the products cheaper to support, last
| longer and since people don't upgrade them anyway they are
| often just 'used up' and thrown away. That last part is bad
| of course but something that a design-for-manufacture
| department is unlikely to care about or mitigate using a
| trade-in or recycling program (which often just ends up
| meaning: ship the trash to china or Africa and let them
| deal with it).
|
| The amount of details and their impact at this scale is
| astounding. Add custom silicon and you're almost in a new
| dimension.
| lucb1e wrote:
| > it makes sense for them. They are neither trying to help
| nor hinder third-party OSes. They just don't care.
|
| That sounds eerily similar to a paperclip maximizer
| (https://wiki.lesswrong.com/wiki/Paperclip_maximizer). I
| suppose we all know what Apple is maximizing, but I never
| drew this parallel before.
| wwweston wrote:
| See also:
|
| https://omniorthogonal.blogspot.com/2013/02/hostile-ai-
| youre...
| DCKing wrote:
| > Stuff like this makes me wonder: why does Apple do this? If I
| try to give them the benefit of the doubt, I can assume that
| these changes are done for performance, cost, power-saving, or
| maybe even security reasons. Otherwise it just seems like Apple
| does these things in order to make it harder for other OSes to
| run on their hardware. Which is certainly their prerogative,
| but it just makes me think less of them.
|
| The reason for most of these things is most likely that Apple
| didn't start from scratch with the M1. M1 Macs in many respects
| appear to be an exercise in "how can we make our existing
| iPhone / iPad system architecture into a general purpose
| computer", and so comes with a surprising amount of legacy
| idiosyncrasies. For example, Apple started using NVMe-like
| storage all the way back in the 2015 iPhone 6S, and therefore
| was 1) very concerned with fitting everything into a small,
| power efficient package and 2) not very concerned with being
| standards compliant at all.
|
| If Apple started from scratch with the M1, it would have most
| likely been more standards compliant. Out of Apple's self
| interest and ease of maintenance, not to help the community. If
| there's anything Apple has shown - on Macs only - is that
| they're not really hostile with respect to standards compliance
| and helping third party OS support. It's just that they don't
| care _at all_ about supporting that, and prefer supporting
| their own internal processes every step of the way.
|
| (Not an expert on this topic at all, just echoing my impression
| of the system architecture choices)
| heavyset_go wrote:
| > _If there 's anything Apple has shown - on Macs only - is
| that they're not really hostile with respect to standards
| compliance and helping third party OS support. It's just that
| they don't care _at all_ about supporting that, and prefer
| supporting their own internal processes every step of the
| way._
|
| Apple wrote Boot Camp drivers and the Boot Camp Installer for
| Windows on Intel Macs. The Boot Camp Assistant itself also
| paves the way for users to install Windows, for example, by
| partitioning storage for Windows installation.
| techrat wrote:
| > why does Apple do this?
|
| User hostility.
|
| They started soldering ram onto motherboards, even in devices
| that had plenty of space (iMacs) when it cut too much into
| their margins because people were doing upgrades themselves
| instead of paying for the 2000% premium to have Apple do it for
| them.
|
| Then they soldered the SSD to the Macbook boards.
|
| Despite having a long running bug that prematurely wears out
| the SSD.
|
| Glue in Macbooks with the batteries where it wasn't necessary.
|
| Soldered down glass backs on iPhones.
|
| Serialized hardware AND batteries that cannot be swapped
| between identical models.
|
| Everything they do is user hostile and anticompetitive.
|
| Every step of the way, when something was found to be user
| repairable or replaceable, the next iteration had that 'fixed.'
|
| * The fanboys have arrived. Factual discussion will not be
| tolerated. Downvotes shall commence without comment! *
| kelnos wrote:
| I don't think this really makes sense. I agree that you could
| characterize things like soldering on RAM and storage, or
| gluing the battery in, as user-hostile (because that means
| the user can't repair or replace or upgrade), but changing
| the interface used by a component that's already integrated
| just won't matter to any user (at least one that is staying
| in the Apple ecosystem). This sort of thing only matters to
| people who want to run Linux or Windows (or something else)
| on Apple hardware.
|
| > _The fanboys have arrived. Factual discussion will not be
| tolerated. Downvotes shall commence without comment!_
|
| Please don't do this. Complaining about downvotes is a waste
| of time, and ultimately detracts further from what you're
| trying to say.
| [deleted]
| simonh wrote:
| I don't get the glued battery complaint though. I've
| replaced the battery on 4 iPhones of 3 different models and
| the glue is just a sticky blob holding the battery in
| place. It was trivial to prize the battery off and press a
| new one into place.
| techrat wrote:
| When the glued batteries first started showing up, they
| were showing up in devices with security screws and the
| expectation of being able to swap batteries out at will.
| (Macbooks vs regular Laptops of the day)
|
| The glue was so strong that you could not avoid damaging
| the battery when attempting to remove it.
|
| You also could not safely remove the battery if it had
| started to bloat/become swollen.
|
| This was, of course, about 10 years before pulltabs and
| adhesives that were solvent sensitive were used.
| [deleted]
| jsight wrote:
| I have a lot of issues with the things Apple chooses to do,
| but I think "user hostility" is an incorrect interpretation.
|
| They have a very specific customer set in mind and they
| optimize for that really well. Its unfortunate that they
| don't cater to every market, but they definitely aren't
| "hostile" to their primary market.
| techrat wrote:
| Forcing people who have broken their new iPhone's screen to
| trade it in for a refurb because no third party repair shop
| can swap out a serialized display isn't user hostile?
| psutor wrote:
| You are saying that the "why" of Apple doing these things
| is purely "user hostility", which is highly implausible.
|
| A company does not make decisions based on a pure "will
| to be evil".
|
| They probably think that the reputation hit from not
| allowing repair is less damaging than the reputation hit
| from users dissatisfied with repairs. Other design
| choices can be for cost cutting in design or production.
|
| So sure, it is not nice for the user, but the reason is
| not a desire to spite users. They likely simply think the
| additional costs, tangible and intangible, of being
| repair-friendly are not worth it.
| techrat wrote:
| > A company does not make decisions based on a pure "will
| to be evil".
|
| That goes against the messaging on here whenever Google
| does something that contradicts "Don't be evil."
|
| > They probably think that the reputation hit from not
| allowing repair is less damaging than the reputation hit
| from users dissatisfied with repairs. Other design
| choices can be for cost cutting in design or production.
|
| Adding code and microchips to enforce serial paring of
| batteries, screens and camera modules to the device it
| was originally installed in... is a cost cutting measure?
|
| Usually when one wants to cut costs, you SIMPLIFY the
| hardware... not make it more complex.
|
| > So sure, it is not nice for the user, but the reason is
| not a desire to spite users.
|
| Right off the top of my head, how they refused to
| implement a battery replacement program for iPods until
| they got massive negative media attention for it (since
| your iPod is functionally useless when the battery dies,
| even if it's plugged in) is one example of Apple's
| extremely long line of ongoing actions that are extremely
| hostile to the end user.
|
| Refusing to adopt USBC for some devices after YEARS seems
| spiteful, especially when people have been asking for it.
|
| Shutting down iOS emulation projects seems spiteful.
| Sending C&D's to an open source project for using the
| term 'App Store' in a completely different context seems
| spiteful.
|
| https://www.omgubuntu.co.uk/2011/06/apple-hit-small-open-
| sou...
|
| 'You're holding it wrong' also seems spiteful.
|
| Hell, Jobs' existence was built upon being spiteful. His
| daughter. Pencil sharpener remark for people who asked
| for a smaller iPad. It's impossible to not imagine how
| his attitude bled into the company culture.
|
| But it's not _deliberate,_... right? Despite the fact
| that these hardware lockdowns and anti repair tactics
| continue to happen, and with more severity, each and
| every hardware iteration for decades now?
| jjtheblunt wrote:
| really naive question:
|
| why not run Parallels since it now uses the native macOS
| hypervisor.framework, and then Linux / Haiku / FreeBSD /
| whatever?
|
| i thought of that as it somewhat outsources device driver
| digressions.
| marcan_42 wrote:
| Because virtual hardware will never work as well as real
| hardware. You're layering one OS on top of another; that's not
| free. No GPU acceleration, etc.
|
| (Plus, we actually support the M1's vGIC which
| Hypervisor.framework does not yet, so VMs running on Linux
| should perform better than VMs running on macOS! Yes, we beat
| Apple at supporting some parts of the M1 already.)
| horsawlarway wrote:
| Because then you still don't own the hardware - Apple does.
|
| Support can be pulled out from underneath you at any point and
| you're limited to the exposed hardware interfaces.
|
| Throw on top that (at least for me) I have _zero_ desire to
| maintain a macOS machine.
| rubatuga wrote:
| Amazing progress. However I don't imagine GPU driver progress
| will be fast, or ready in the near future.
| marcan_42 wrote:
| Reminder that GPU userspace is passing 90% or so of the GLES2
| tests. It's just missing kernelspace, which is arguably the
| easier part.
| Rob_Polding wrote:
| I cannot wait for this to come to fruition. Thanks for all the
| hard work, I'll be installing it as soon as sound and GPU
| acceleration hit.
|
| Amazing work :-)
| masterof0 wrote:
| This is a truly amazing project. I'm contributing financially (as
| I don't have the time to contribute code) to help Alyssa and the
| rest of the team. If you can, you should too.
| vletal wrote:
| Observing the achievements of this group of young talented devs
| only increases my imposter syndrome.
|
| Awesome job, love the enthusiasm.
| stiltzkin wrote:
| I used to have the same sentiment when the same dev hacked the
| original Wii and PS3.
| morganvachon wrote:
| Agreed, I have a M1 mini sitting around doing mostly nothing
| and I'd love to use it to contribute to the project but I'm not
| a developer so I don't know where to start. I am definitely
| looking forward to the mentioned installer release so I can try
| it out myself though. I can believe the hype about how blazing
| fast it is on the desktop even in software rendering, given how
| powerful a Linux VM on Parallels can be on it. It rivals my
| Ryzen 5 3600 machine and even surpasses it in some metrics, and
| that runs Linux bare metal.
| trangon wrote:
| Reverse engineering and hacking can be a crazy time sink. It's
| truly a game for those with lots of free time.
| noizejoy wrote:
| There are many things that are crazy time sinks - either
| because they are difficult, or because they are emotionally
| or intellectually engaging. Or because they are mandatory in
| the context of the person doing them.
|
| And the concept of "free" time is also relative. For example,
| you could argue that child rearing is a game for those with
| lots of free time.
| andy_ppp wrote:
| It's so good that I decided to sponsor the project a while back.
| I will probably never use it but I really like these guys talent
| and dedication!
| silasb wrote:
| This is just embarrassing.
|
| > the M1's CPUs are so powerful that a software-rendered desktop
| is actually faster on them than on e.g. Rockchip ARM64 machines
| with hardware acceleration.
| alin23 wrote:
| I wonder if Alyssa (or other devs that took a deeper look at the
| DCP) have any idea why the builtin HDMI port of the Mac Mini
| would not send DDC messages to the connected monitor.
|
| I've been struggling with this in Lunar (https://lunar.fyi) for a
| long time and while I tried my best by comparing ioreg dumps and
| looking at the DCP driver in IDA, I couldn't find any obvious
| logic would block this communication voluntarily.
|
| I should mention that on M1, the DDC messages are sent to the
| monitor by calling IOAVServiceWriteI2C on the DCPAVServiceProxy
| of the monitor as seen here:
| https://gist.github.com/alin23/b476a02a8cd298436848e28476aed...
|
| I'm thinking that this logic might either exist in the DCP
| firmware which is not accessible from userspace, or it might just
| be a side effect of some out of spec behavior that the HDMI port
| might have.
| lyssa wrote:
| The DCP firmware has multiple endpoints. Currently, we only use
| and understand the main endpoint, which lacks raw I2C/DDC/EDID
| interfaces. Presumably this is available on another endpoint,
| but we haven't looked at this yet. Your gist gives me hope.
|
| The HDMI port on the Mini is funny. The M1 supports exactly one
| internal display (the panel on a MacBook or iThing) and one
| external display (over DisplayPort/Thunderbolt). This is why M1
| MacBooks can only drive a single external monitor.
|
| For the Mini, the "internal" display is an internal DisplayPort
| connection, converted to HDMI with a mcdp29xx chip, and stuck
| on the HDMI port. Expect weirdness.
| gigatexal wrote:
| Anyone know if the *BSDs are following this work in parallel or
| plan on doing the same? It would be nice to have some choice --
| yea I know MacOS is Darwin plus the BSD userland but I like the
| idea of throwing FreeBSD on an old M1 when I get sick of Linux
| (even if I eventually go back to a distro...)
| my123 wrote:
| So far NetBSD and OpenBSD are working on the M1 port.
|
| https://wiki.netbsd.org/ports/evbarm/apple/ for NetBSD install
| instructions.
|
| I don't see a focus on the FreeBSD side (yet?) however.
| gigatexal wrote:
| wow they've made a ton of progress -- wish this work got more
| press. Not to take away from the Asahi linux folks's work but
| I had no idea the netbsd for example was this far along.
| marcan_42 wrote:
| Mark Kettenis has been working on the OpenBSD and U-Boot
| ports with us, and we'll be relying on U-Boot for our end
| user installs :)
|
| We're also dual licensing all our bespoke drivers, so the
| BSDs can take code from there (particularly important for
| the GPU driver, as there is already a lot of shared code in
| that subsystem).
|
| I'm actually thinking I'm going to rewrite the WiFi support
| patch for Linux from scratch, based on the OpenBSD version,
| just because they did a great job distilling what matters
| out of the original messy PoC patch that Corellium dumped
| earlier this year.
| Syonyk wrote:
| Hm.
|
| I've got an M1 Mini laying around (Apple annoyed me enough in the
| past six months that I've gone away from them entirely, replacing
| a M1 Mini with an ODroid N2+, among other things). If it's daily
| drivable, I suppose I should see about getting Linux installed on
| it. I've not gotten around to selling it yet...
| wayneftw wrote:
| I put Manjaro on my 2012 Mac Pro and it was so frustrating to
| even get the boot loader running that I'll never run Linux on a
| Mac again. Once it was running, Apple's garbage BIOS continued
| to present issues too.
|
| If I don't have to work with iOS anymore then I'll never even
| buy another Mac.
| pengaru wrote:
| If Apple has really annoyed you, put that Mini on the used
| market ASAP where it can potentially displace a new unit sale.
|
| Not that I'm unsupportive of the Asahi project, it's just a
| fact that you're dong Apple a favor by keeping that M1 Mini
| around collecting dust, while every passing day it becomes
| increasingly irrelevant WRT offsetting new unit sales.
| lyssa wrote:
| > replacing a M1 Mini with an ODroid N2+,
|
| Hey, if you're running Linux, you're using my drivers either
| way ;-)
|
| Now back to typing away at Panfrost on my M1 Linux to debug an
| issue on the Odroid N2 I have Ethernet connected to the M1...
| techrat wrote:
| Sell it and buy something better with actual Linux support.
| Anything that involves installing Linux onto an M1 will always
| be an unsupported hack*, at best.
|
| * Some of y'all need to unwad your panties and look at the
| overall picture here.
|
| Without Apple contributing to the kernel or at least
| documenting the system, getting ANYTHING running on an M1 is
| still a hack...
|
| ...regardless of the quality of the end result.
|
| I wish the Asahi Linux folks the best of luck and have no doubt
| that they're capable.
|
| I just wish it wasn't so much effort put towards hardware from
| a company that is known for its incredibly hostile response to
| users doing what they want with the hardware they own.
|
| And for those who insist that 'unsupported hack' is an insult,
| you should look up other meanings in the dictionary sometime.
|
| * Definition of Unsupported: (of a program, language, or
| device) not having assistance for the user available from a
| *manufacturer* or systems manager.
|
| * Definition of Hack: an act of computer hacking.
| coldtea wrote:
| Well, this kinda pisses on the work whose progress report is
| posted here...
| techrat wrote:
| No, it doesn't. It pisses on Apple for being an incredibly
| and unnecessarily restrictive company.
| Syonyk wrote:
| That's absolutely no fun at all!
|
| I've dropped Apple pretty hard (to the point where I've gone
| back to a flip phone - my objections to Android are
| significant as well), and I've accepted that if I want to use
| computers, it's probably best to use weird configurations
| that are often broken, because it discourages me from
| spending too much time on them.
|
| I mean, I feel like even using x86 Linux boxes is lazy. :/
| This box, currently, is an ODroid N2+ that's working fine.
| I've got a Raspberry Pi 4 over on the other side of my office
| (the "solar shed" posted yesterday, for some reason), and
| I've made that into a nice little desktop too. Still working
| on Spotify support, and I was actually quite surprised to
| find out that I can watch something on YouTube today...
|
| My laptop is a PineBook Pro running a custom kernel (I really
| should push the sleep/resume patches I wrote for the sound
| card upstream... one of these days...).
|
| Unsupported hacks are fun! They're challenging, and also
| reduce my dependence on computers, because odds are good that
| one or more simply don't work at any given moment.
|
| And it's not just computers. The closest thing I have to a
| "daily driver" (other than the family car, which my wife and
| kids have priority for) is a 2005 Ural - sidecar motorcycle,
| evolution on a late 1930s BMW, quite literally the most vile
| handling thing you'll ever encounter on the road. It works, I
| work on it, I get places eventually, just no longer at the
| speed limit.
|
| Anyway, the very insanity of bare metal Linux on the M1
| actually appeals an awful lot to me.
| r00fus wrote:
| Makes sense, even as someone who wishes I had an M1 mini
| lying about (all non-trivial purchases need home CFO
| approval) I would be hesitant to install Linux on it as I'm
| not a kernel hacker.
| stormbrew wrote:
| Linux on basically every computer platform at least started
| out as, if not still is, "an unsupported hack". Even on x86
| it's pretty questionable to call it supported on the vast
| majority of PCs out there.
| techrat wrote:
| I disagree.
|
| Intel and AMD both contribute heavily to the Linux Kernel.
| This means that on the vast majority of Intel or AMD based
| systems, you can boot from USB and have a working system.
|
| Apple doesn't even release _documentation_ on their SOCs.
|
| Apple doesn't use standard, open boot methods to allow
| other OSes to simply boot from USB. No BIOS/Standard UEFI.
|
| There is a huge chasm between what you can do on the vast
| majority of PCs out there... and what you have to do to get
| anything else running on Apple hardware. IF you can get
| anything running. (Eg, locked bootloaders on iDevices)
| randomguy1234 wrote:
| For Linux and BSD, everything has been reverse engineered
| and hacked from the beginning. Linux has been ported to
| hundreds of unsupported computing devices. If everyone
| had your mindset, Linux and BSD would not even exist,
| only proprietary operating systems would exist. You just
| don't get it. Linux on M1 is a worthy challenge for the
| most talented and creative software engineers, which you
| are definitely not one of. Not even close.
| stormbrew wrote:
| Intel and AMD don't make the computer (most of the time).
| They make the CPU. ARM is as open a CPU platform as x86
| is at any rate, so if you're gonna pick your line only
| based on the CPU there's literally no difference there.
| But you obviously know that's not all there is.
|
| Most computers anyone can buy are full of components that
| only have drivers or support in the linux kernel because
| people reverse engineered them. Most are also full of
| components that linux only works with because of
| extracted firmware blobs from other systems.
|
| EFI is more or less an open boot system (which.. you know
| intel macs used that right?), though with plenty of
| proprietary extensions and alterations in most booting
| computers, but the BIOS boot that predated it? Yeah you
| know that was a proprietary system right? Linux booted
| off it because people reverse engineered and cloned it
| until it was forced to be an 'open' thing. It didn't just
| magically happen one day and IBM even sued about it back
| in the day.
| CarelessExpert wrote:
| As a bit of meta-commentary, the fact that anyone is even
| arguing with the points you're making is deeply
| disappointing to me.
|
| It seems like there's an entire generation of folks out
| there who can no longer tell the difference between an
| open technology ecosystem and a closed one...
| stormbrew wrote:
| Hi I grew up with a TRS-80 and a Tandy 1000. I'm not sure
| what generation you think I'm from but I suspect you're
| wrong.
|
| What disappoints me is a "generation of folks" who can't
| tell that openness is a spectrum and that every bit of
| openness they enjoy was hard-fought for by pushing the
| boundaries of the platforms that existed beyond their
| original intentions, and now treat an effort to do the
| same on new platforms as some kind of windmill tilting.
| CarelessExpert wrote:
| > What disappoints me is a "generation of folks" who
| can't tell that openness is a spectrum
|
| And Apple is very far on the closed end of that spectrum
| relative to their competitors, and always has been.
|
| There is simply no arguing this point.
|
| > every bit of openness they enjoy was hard-fought for by
| pushing the boundaries of the platforms that existed
| beyond their original intentions, and now treat an effort
| to do the same on new platforms as some kind of windmill
| tilting.
|
| Let's be real: Asahi isn't gonna change Apple's corporate
| culture. It's a super cool technical project and I
| absolutely applaud these sorts of efforts simply because
| they're cool.
|
| But you're not the Jedi fighting the empire here. You're
| not gonna blow open the M1 and suddenly change Apple
| hearts and minds.
|
| The PC industry became more open for one reason and one
| reason only: Money.
|
| The IBM monopoly was destroyed because clones were cheap,
| not because of ragtag freedom fighters.
|
| Linux won over in the embedded space because it doesn't
| cost anything, not because folks suddenly got stars in
| their eyes over the GPL.
|
| Apple will only change their practices when economics
| force them to. But it's _very_ clear that they view a
| walled garden of hardware and software as key to their
| financial success, and everything they 're doing is
| intended to build those walls just a little bit higher.
|
| So until you can change that financial equation, nothing
| in the Apple ecosystem will change.
|
| But, honestly, keep plugging away! Have fun! I personally
| _love_ repurposing hardware to make it do cool things for
| which it was never intended. When I see projects like
| this, I think of Everest: We do it because it 's there.
|
| But let's not pretend that you're somehow going to change
| Apple just because you get the Linux kernel booting on
| the M1.
| stormbrew wrote:
| Fundamentally, if people with your and the spawner of
| this thread's attitudes had won the day we wouldn't have
| any of the things this thread is allegedly about loving
| so much. That's my main point here.
|
| Also I am not involved in or affiliated with or even a
| likely user of the Asahi project, to be clear. I just
| find this attitude incredibly frustrating, and I'm
| definitely bristling at accused of being a young'un or
| some shit for believing people can actually do surprising
| things. I am not the dewy-eyed idealist you seem to think
| I am, I believe what I'm saying here because I've seen it
| happen over and over and over again.
| CarelessExpert wrote:
| > I just find this attitude incredibly frustrating
|
| What attitude? The attitude that Apple's hardware is
| closed and Apple should be criticized for building a
| walled garden? That we should, where possible, invest in
| open hardware and technology and put our money where our
| mouths are, so as to create the kinds of economic
| incentives that ensure that technology remains open in
| the future?
|
| Do you really disagree with that?
|
| > I am not the dewy-eyed idealist you seem to think I am,
| I believe what I'm saying here because I've seen it
| happen over and over and over again.
|
| What "it" are we talking about here?
|
| What do you think the end game is going to be?
|
| I genuinely have no idea what your argument is, other
| than to tell me how I'm wrong without providing any
| specifics regarding _how_ I 'm wrong.
|
| Please, enlighten me, I'm happy to listen!
| stormbrew wrote:
| The attitude that pushing on technology that seems hard
| isn't worth it.
|
| We can do both. We _should_ do both.
|
| At any rate, I'd suggest you go read marcan_'s replies
| and the OP submitted to HN because the picture you paint
| and the picture they paint of this platform are not quite
| the same to begin with. I think the people doing the work
| deserve a little more credit to describe the platform
| they're working on.
| CarelessExpert wrote:
| > We can do both. We _should_ do both.
|
| So, other than for the intellectual curiosity (which is
| absolutely a great reason!), I have a simple question:
| why?
|
| Edit:
|
| By the way, thinking about it, I have my own answer to
| this question: So that this hardware can continue to
| remain useful long after Apple has ended support for it.
|
| Of course, I continue to believe that it's better, now,
| to simply buy hardware that doesn't need this kind of
| reverse engineering to ensure longevity, and I steer my
| hardware purchases accordingly.
|
| But the hardware exists, and people are buying it, so
| this project is a way to keep it alive after Apple
| eventually abandons it (which, granted, could be a long
| time; while I have a lot of problems with Apple, they are
| very good about continuing to support old gear).
| techrat wrote:
| > Please, enlighten me, I'm happy to listen!
|
| His argument seems to be that of "if it was difficult for
| us then, it should be difficult for you now."
| stormbrew wrote:
| Not a "his" thanks.
|
| And no. That is not even remotely my argument.
| techrat wrote:
| > Not a "his" thanks.
|
| Okay, Miss and/or It, I shall specifically address you by
| your gender of choice, however impossible it is to
| normally tell online.
| CarelessExpert wrote:
| Just gonna jump in here and say: not cool. Yours is, to
| say the least, a disproportionate response and pretty
| unnecessary.
| [deleted]
| reacharavindh wrote:
| I understand the subtlety involved in your argument that
| Apple may and probably will make closed decisions that
| strictly benefit their own ecosystem even if at cost of
| making life difficult for those running Linux on this
| hardware.
|
| However, "Unsupported hack, at best" is pretty dismissive of
| the engineering effort going on with this. People running
| Linux on "windows branded PCs" of the not so distant past
| could have easily said the same thing because Say Dell and
| Microsoft would be commercially motivated to only keep
| Windows running on their hardware. However the ecosystem
| around Linux made things happen such that it is almost a no-
| brained that most systems you buy _will_ run say Ubuntu with
| more than reasonable success.
|
| With enough motivation, and the efforts of engineers such as
| those listed in this article, I bet we might even see better
| use of Apple hardware than MacOS. Apple might optimise for
| their stuff, but Linux can bring the power built for other
| needs(HPC, Real-time systems etc) to the table and can leap
| over MacOS given the right abstractions. The future is
| exciting for the hopeful.
| [deleted]
| stormbrew wrote:
| > People running Linux on "windows branded PCs" of the not
| so distant past could have easily said the same thing
| because Say Dell and Microsoft would be commercially
| motivated to only keep Windows running on their hardware.
|
| I don't think this needs qualification. It's still true
| today.
| bscphil wrote:
| We recently purchased a cheap (<$500) Dell Inspiron, and
| it advertises support for Ubuntu in the specs. Not even
| one of those fancy XPS "developer edition" laptops or
| whatever, just an ordinary Inspiron.
|
| It's fine to worry about it (and UEFI was a real threat
| until Microsoft mandated support for other-os booting),
| but support for Linux in the PC world has never been as
| fragile as support for it on Macs. You're entirely at the
| mercy of Apple's whims; I support the Asahi project, but
| that's just the truth.
| marcan_42 wrote:
| Our project's goal is not to produce an "unsupported hack",
| it's to make these machines work at least as good as, if not
| better than, any other machine with "actual Linux support"
| ;-)
| techrat wrote:
| An admirable goal. Except this is Apple you're dealing
| with.
|
| Since they provide zero means or support for other OS
| compatibility... so even if you still get everything
| running as it should, it's still an unsupported (by Apple)
| hack (due to lack of Apple's code and documentation).
|
| Compare this to where people make a LineageOS release for
| their mobile device. Still unsupported by the manufacturer,
| but GPL requirements often mean there's still device code
| to work with, if not at least the device ROM being released
| that images can be used to boot another OS.
|
| Apple is still one of the only hardware companies who have
| gone out of their way to _prevent_ Linux from being run on
| their hardware. As such, I cannot see why open source
| advocates would continue to try to get any distro running
| on Apple hardware, the allure of their devices be damned.
| marcan_42 wrote:
| Apple spent countless development hours writing an entire
| BootPolicy framework to _allow_ other OSes (and self-
| built macOS kernels) to run on these machines. Not only
| that, their secureboot implementation implements _per-OS_
| security modes, which means you can dual boot Linux with
| a full secure macOS, including running iOS apps and
| Netflix in 4K. Can 't do that with LineageOS!
|
| Linux on M1 Macs is "supported" exactly the same as Linux
| on any random PC without manufacturer support. Sure, it's
| more work to get running, because it's a new undocumented
| platform... but we've signed up to do the work. If Linux
| on these machines is an "unsupported hack" then so is
| Linux on the vast majority of desktop/laptop computers
| people use.
| techrat wrote:
| > Linux on Macs is "supported" exactly the same as Linux
| on any random PC without manufacturer support.
|
| Bullshit.
|
| Intel and AMD both contribute to the Linux kernel to have
| their hardware, CPUs and GPUs both, supported.
|
| Show me Apple's commits for supporting the M1 within the
| kernel and we'll talk.
|
| Until then, in this situation where you're trying to get
| Asahi Linux running for the M1, it is not exactly the
| same.
| marcan_42 wrote:
| And yet here I am, with Linux on an Intel laptop that
| can't play video without tearing. Our M1 DCP driver
| already does that properly.
|
| Support from chip manufacturers doesn't mean you're
| actually going to end up with a better user experience.
| CarelessExpert wrote:
| > And yet here I am, with Linux on an Intel laptop that
| can't play video without tearing.
|
| Odd, because here I am with an Intel laptop running Linux
| that manages that just fine.
|
| > Support from chip manufacturers doesn't mean you're
| actually going to end up with a better user experience.
|
| Honestly, this is just ridiculous. Go ask the Nouveau
| folks how their reverse engineering project is going.
|
| I love the drive you guys have, and I wish you the best
| of luck. But Apple could pull the rug out from under you
| any time they want in a future hardware rev (either
| deliberately or accidentally), and all you can do is keep
| on reverse engineering in the hopes of keeping up.
|
| Edit: Updated pronouns since apparently the OP is one of
| the project maintainers.
| marcan_42 wrote:
| > Odd, because here I am with an Intel laptop running
| Linux that manages that just fine.
|
| Then it's not an Ivy Bridge running multiple external
| displays on KDE.
|
| > Honestly, this is just ridiculous. Go ask the Nouveau
| folks how their reverse engineering project is going.
|
| Nvidia created an actively hostile firmware situation. We
| already have the firmware story worked out. Plus having
| to support a bazillion GPU generations with incompatible
| interfaces burns people out. We're starting with one, and
| Apple has a much better track record of incremental
| change and avoiding hardware churn. This is unique, and
| we've literally heard from Apple employees that this is
| an explicit goal. It shows all throughout the SoC design.
|
| > and all you can do is keep on reverse engineering in
| the hopes of keeping up.
|
| And we will keep on reverse engineering, and we'll keep
| up :-)
| smoldesu wrote:
| I think you're being incredibly reductive with your
| claims about screen tearing. I've run a 1080p display off
| my horribly outdated i5 520m, and I never noticed any
| tearing on it. Same goes for my Skylake notebook, desktop
| Haswell iGPU and even my old Raspberry Pi from 2014. You
| may have just gotten extremely unlucky with your
| hardware.
| CarelessExpert wrote:
| > Then it's not an Ivy Bridge running multiple external
| displays on KDE.
|
| Tiger Lake (whose microarchitecture I just learned is
| Willow Cove) running Gnome via Wayland (damn HiDPI...),
| single external display via USB C dock plus an onboard.
|
| More fully, previously I was running a Lenovo X1C5 with
| Intel integrated graphics. Again, no issues there. In
| that case I ran Xorg with TearFree enabled.
|
| I'm currently running a Framework sporting an i7-1165G7
| with the aforementioned setup.
|
| It was genuinely a little shocking, having spent my
| earlier days manually hacking modelines in X, to see this
| hardware come up flawlessly on first boot with Ubuntu
| 21.04... amazing what a reasonably open hardware
| ecosystem will enable. _jab jab_ ;)
|
| > We're starting with one, and Apple has a much better
| track record of incremental change and avoiding hardware
| churn. This is unique, and we've literally heard from
| Apple employees that this is an explicit goal. It shows
| all throughout the SoC design.
|
| Absolutely a fair point! I concede that the reverse
| engineering story with Apple may very well be less
| painful than it is with other vendors. Honestly, I hope
| for your sanity that it is! :D
| cyberpunk wrote:
| _cough_ You may as well say "you" instead of "these guys"
| btw, perhaps a careless mistake but you were speaking to
| the lead developer of the Asahi effort and I would hazard
| a guess his views on the Linux kernel and vendor support
| are a tad more nuanced than "ridiculous"
| CarelessExpert wrote:
| LOL, just because they're running the project, doesn't
| mean their opinions are sacrosanct or unquestionable.
|
| The statement they made is ridiculous, and I stand by my
| decision to label it as such.
|
| If you want to explain to me how I'm wrong instead of
| simply appealing to authority, you're obviously free to
| do so.
| techrat wrote:
| And yet you're potentially just seconds away from Apple
| deciding they don't like what you're doing and releasing
| an update that prevents any other OS from running on
| their hardware.
|
| This is where I address the issue of developing for such
| a user hostile company.
|
| If they won't even provide _documentation_ why should I
| trust they 'll even continue to provide _access_ when
| their history has shown that they do anything but?
| easton wrote:
| And Microsoft could ask the OEMs to push a UEFI update
| that enforces secure boot with only the Windows keys. I
| don't think they will though.
| CarelessExpert wrote:
| > And Microsoft could ask the OEMs to push a UEFI update
| that enforces secure boot with only the Windows keys. I
| don't think they will though.
|
| Well, let's be fair: They could try, but again, that'd
| require those OEMs to cooperate. And you'd still end up
| with folks like System76 and Framework that'd go their
| own way because nothing can stop a vendor from creating
| an open x86-based design. They just wouldn't be able to
| ship Windows pre-installed.
|
| Apple, by contrast, could just do it by fiat because they
| own the entire ecosystem, and no one could do a damn
| thing about it.
|
| That's the difference between an open, interoperable
| ecosystem and a closed one.
|
| I genuinely don't understand the debate, here. Are you
| seriously trying to claim that the Apple hardware
| platform and the x86 ecosystem are equally open/closed?
| marcan_42 wrote:
| Apple are absolutely not going to do that. That would be
| illegal. Sony lost a class action over this, and Apple
| have a lot more to lose in the PR realm than them. Please
| don't spread FUD like this. Apple have never, not once,
| locked down a Mac, post facto or otherwise. It always has
| been a platform open to third party OSes.
| mtone wrote:
| They did it on iOS countless times to prevent rooting the
| device. Not sure how that's supposed to be different as
| the tech converges, but I never owned a Mac so that's all
| I know of Apple.
| spookthesunset wrote:
| To my knowledge all jailbreaks on iOS are literally
| exploiting security vulnerabilities that root your phone.
| Lord knows what these things installed...
| Macha wrote:
| The early ones were often open source, but between
| competition in the scene and making it harder for Apple
| to patch them, a lot of the newer ones are not, which
| makes it a lot harder to trust them.
| floatboth wrote:
| iOS devices _never_ advertised support for booting
| whatever you want; Macs _always_ did. Very, very
| different product lines.
| mtone wrote:
| So the 15" M1 laptop will let you custom boot if you
| manage to decipher its undocumented internals, but the
| 10" M1 tablet will actively shut down attempts on the
| next update. Great.
| techrat wrote:
| Yep. This seems to be the point the "FUD! FUD!" criers
| are ignoring.
|
| Apple has a long, continuous history of locking down
| hardware. Never having a bootloader unlockable iDevice,
| unibody, glue, soldered on components that are
| traditionally user replaceable, soldering in displays and
| backs when people try to repair batteries, serializing
| the components so you can't even swap official parts.
|
| Apple has never gone in the reverse direction to make
| components more easily user serviceable. It's always been
| in the more restrictive direction. More proprietary with
| every iteration. Now it's the CPU. Bootloader locking on
| an M1 Macbook is the next logical step.
| floatboth wrote:
| If that is the next logical step why would they go out of
| their way to design a whole mechanism for running custom
| kernels?
|
| They could've just released a locked down Macbook in the
| first place if that was the goal.
| bscphil wrote:
| I'm sympathetic to marcan's points and I don't think
| Apple is likely to do anything like this, personally, but
| this argument isn't very convincing. All this means is
| that they can't release a firmware update blocking use of
| a third party OS on existing hardware (contra techrat).
|
| OK, great, but we're talking about a manufacturer that
| makes products designed to go in the rubbish bin 2-4
| years after manufacture (witness the half dozen comments
| by users in this thread saying they have _already_ put
| their M1 computers in a drawer somewhere!). Apple are
| constantly iterating, and the goal of a project like
| Asahi is to stay ahead of the game and continue running
| on new hardware.
|
| The proper and correct point that techrat should have
| made is that the second something like Asahi is a threat
| to Apple for any reason, Apple can release new hardware
| that's locked down similar to iOS. You'll even have
| people on this site defending the changes too, in the
| name of security or something.
| techrat wrote:
| The bigger point that I've been trying to make
| (regardless of whether or not you think Apple would try
| to lock down an M1 Macbook) is that I don't trust Apple
| because of their history.
|
| They have a LONG history of making decisions that
| ultimately are hostile to the user. Apple also has a
| history of explicitly locking out Linux users.
|
| https://www.phoronix.com/scan.php?page=news_item&px=Apple
| -T2...
|
| > It looks like even if disabling the Secure Boot
| functionality, the T2 chip is reportedly still blocking
| operating systems aside from macOS and Windows 10.
|
| This is further than Microsoft has ever gone with
| hardware.
|
| Apple has been dipping their toes into the telemetry and
| ad tracking waters for a while now. If they see Asahi
| cutting into those margins because people are buying
| Apple hardware and installing an OS that prevents them
| from collecting user data, I can believe they'd see them
| as a threat.
|
| Why? Again, history. Apple has shut down numerous
| developers who made "competing" features for iOS via apps
| in the App Store... even though those developers had the
| app first before Apple decided to add the features into
| iOS.
|
| But yeah, something something security something...
| techrat wrote:
| > Sony lost a class action over this
|
| Sony explicitly advertised an OtherOS feature and then
| pulled it.
|
| Apple doesn't advertise support for booting another OS on
| their devices.
|
| Huge difference. You're being disingenuous and you know
| it.
|
| > Apple are absolutely not going to do that. That would
| be illegal.
|
| Illegality has never stopped Apple before.
|
| After all, this is the same company that prevents other
| web browser engines from being able to run on their
| hardware.
|
| If that isn't more restrictive than anything Microsoft
| did with IE (and they faced an antitrust suit over
| this)... I don't know what is.
|
| Take off your rose colored glasses and stop seeing Apple
| as a company that hasn't locked shit down whenever they
| could get away with it.
|
| Drawing a line between Macs and iDevices is ignoring all
| the big fucking warning signs. It's still the same
| company in the end... and their Macs are now using the
| same SOCs that their most restricted devices uses.
|
| Tick, tock, tick, tock...
| marcan_42 wrote:
| Of _course_ Apple advertise running your own kernel code
| on these machines. Here 's the official documentation on
| custom kernel extensions (which are functionally
| equivalent to allowing other OSes):
|
| https://developer.apple.com/documentation/apple-
| silicon/inst...
|
| And here's the kmutil manpage that explicitly describes
| the option they added to support fully custom kernels,
| which is what we use:
|
| https://keith.github.io/xcode-man-pages/kmutil.8.html
|
| And here's a blog by the head of XNU development at Apple
| explaining how to build and run your own XNU kernel for
| these machines:
|
| https://kernelshaman.blogspot.com/2021/02/building-xnu-
| for-m...
|
| This isn't an accident. This is a documented, explicitly
| advertised feature that Apple put a significant amount of
| engineering time into developing.
| techrat wrote:
| Show me in a print advertisement that Apple advertises
| running another OS on the M1 based machines.
|
| THAT is what Sony did with the OtherOS feature on the PS3
| and THAT was why they faced a class action lawsuit over
| it.
|
| A post on BLOGSPOT of all places does not strike me as
| _OFFICIAL_ documentation.
| crad wrote:
| Are you familiar with BootCamp, an explicitly advertised
| feature to boot into Windows
| (https://support.apple.com/boot-camp) - They've
| advertised it quite a bit. They maintain Windows drivers
| for their hardware.
|
| Re on the M1 specifically, Apple suggests they'd totally
| be on board should Microsoft put in the effort:
|
| https://www.macrumors.com/2021/09/14/arm-windows-m1-macs-
| not...
|
| > Apple's software engineering chief Craig Federighi last
| year said that Windows coming to M1 Macs is "up to
| Microsoft." The M1 chip contains the core technologies
| needed to run Windows, but Microsoft has to decide
| whether to license its Arm version of Windows to Mac
| users.
|
| I imagine that once Windows on Arm is supported, they'd
| be totally be on board.
|
| Perhaps if you weren't so hostile in your replies, you'd
| be down-voted less. You come across as angry.
| techrat wrote:
| Bootcamp is not allowing someone to fully boot any OS
| from the device. It is still a walled garden that limits
| hardware access, preventing the user from getting full
| performance out of the device.
|
| > Perhaps if you weren't so hostile in your replies,
| you'd be down-voted less. You come across as angry.
|
| You get what you read into it.
|
| Majority of my posts are statements of fact yet they get
| downvoted because there's no placating the Apple horde
| with the truth.
| wtallis wrote:
| > It is still a walled garden that limits hardware
| access, preventing the user from getting full performance
| out of the device.
|
| What limits are you referring to, and by what performance
| metrics is Boot Camp unable to make full use of the
| hardware capabilities?
| crad wrote:
| I understand you see it that way, but...
|
| > ... there's no placating the Apple horde with the
| truth.
|
| Pretty much summarizes what's I was suggesting as
| hostile.
| crad wrote:
| > It is still a walled garden that limits hardware
| access, preventing the user from getting full performance
| out of the device.
|
| That's not been my experience, but I guess in such
| circumstances your mileage may vary.
| theodric wrote:
| You're right, we should just give up and devote our time
| to other things.
| techrat wrote:
| What I'm saying is that I feel it's a better use of man
| hours of open source advocates to code for hardware from
| companies that support OSS and not one that is viciously
| hostile to its users.
| marcan_42 wrote:
| I'd much rather reverse engineer proprietary hardware; I
| get to have fun doing that _and_ I get to play the
| upstreaming game better than any of those companies that
| "support open source" that you love so much (have you
| _seen_ the mess AMD made? They have hundreds of megabytes
| of autogenerated headers in the Linux tree now!), while
| working with a team of motivated and experienced
| developers and working to make everyone 's life as
| pleasant as possible, minimizing churn, red tape, and
| inefficiency.
|
| Seriously, there's no way I'd be half as happy working at
| Intel on Linux drivers as I am working on the M1. And
| it's not like they support external developers either -
| most of the chip documentation for Intel/AMD stuff is not
| public. You can't actually build working graphics drivers
| from their public docs, not even remotely close. Heck, I
| had to reverse engineer AMD's GPU microcode to get the
| variant in the PS4 to work. Totally undocumented stuff.
| techrat wrote:
| You'd much rather support proprietary hardware made by
| companies who are hostile to open source software by
| coming up with questionable excuses ("Have you seen the
| mess AMD made?")...
|
| Your rationale for supporting Apple is that of a gordian
| knot. I'd say even cult-like.
| marcan_42 wrote:
| I didn't even own any modern Apple hardware until last
| year. My rationale for supporting these machines is that
| they're awesome machines, better than anything with
| Intel/AMD chips, and people should be able to run Linux
| on them.
|
| Of course, if that doesn't convince you, we can always
| fall on the fact that you aren't the person writing the
| code, and in the world of free software you don't get to
| tell others what they ought to spend their time on.
| techrat wrote:
| Glad to see you're enjoying the kool aid.
| marcan_42 wrote:
| Well, they _do_ run kooler and quieter than literally
| every x86 machine I 've ever owned, yes ;)
| butterisgood wrote:
| All I can say is I wish you luck!
| nextos wrote:
| That's cool. Some Macs rank near the top in terms of Linux
| support and openness. E.g., the MacBook 2,1 is one of the
| very few laptops supported by Libreboot. Others are totally
| unusable.
|
| I like Apple hardware (and ThinkPads), but I prefer the
| openness of Linux (and BSD).
|
| Current MacBook Airs are pretty competitive in terms of
| price, and the fanless CPU is very appealing. Is it much of
| a gamble to purchase one now expecting to run mainline
| Linux in a year or so?
|
| Aside from the new architecture, some components Apple has
| been using are quite unfriendly. Broadcom wireless cards
| tend to perform really poorly with open source drivers.
| marcan_42 wrote:
| The Broadcom fullmac cards should be well supported in
| Linux. I've seen people complain about poor WiFi range
| and the like on other Macs, but that is almost certainly
| caused by wrong/mismatched firmware and NvRAM distributed
| with linux-firmware for those machines. We're going to be
| using Apple's blobs exactly the same way macOS does,
| which are tuned to each specific machine and module
| variant, so radio performance should be identical to
| macOS.
|
| I wouldn't buy an M1 right now... just because the next
| generation is likely around the corner :-). But yes, I
| can't promise all the polish or that every single thing
| will be upstream, but things should be solidly in the
| "daily driver" category a year from now. I'd be surprised
| if there was any non-optional (i.e. excluding
| accelerators - no idea if anyone cares about the Neural
| Engine yet...) hardware left without usable support by
| then. GPU is a big question mark that should become clear
| in the next month or two as I poke at the kernel side,
| but honestly I expect solid OpenGL a year from now, at
| the very least.
| my123 wrote:
| For the user-mode part of the neural engine,
| https://github.com/geohot/tinygrad/tree/master/accel/ane
| helps quite a bit today. There is also no generic neural
| engine support infrastructure at all in user-mode on
| Linux. :-(
|
| For the kernel mode part, ANE is behind an ASC.
| marcan_42 wrote:
| It's really just a matter of someone caring. I don't see
| finding myself with enough time to work on that any time
| soon, but if someone has a good use case for it and
| motivation to get it done I'm sure it'll happen (and I'll
| gladly help).
|
| Some things are dodgier - e.g. though supporting the AMX
| CPU extensions is quite viable in a kernel fork, I'm not
| sure if that kind of thing would fly upstream. Same with
| security features like SPRR - not likely to happen. But
| these aren't really things the average end user has to
| care about; they're bonus features, not anything core.
| setpatchaddress wrote:
| Just curious: if someone was inclined to build a set of
| good (correct style, well-documented, etc) patches to
| support those extensions, why would the kernel refuse
| them?
|
| (Put another way: I'm wondering whether you think the
| difficulty is technical or political.)
| marcan_42 wrote:
| It's a bit of both. It basically boils down to it being
| an invasive change to core kernel code that doesn't have
| demonstrable benefit to users, and is specific to one
| platform. If we can point at a specific application and
| say "look, this speeds up 300% with AMX" then that might
| help convince people, but there would definitely be quite
| some political discussion, not in the least because what
| Apple did is a violation of the architecture.
|
| I'm hoping we can at least push through a prctl to turn
| on TSO mode for x86 emulation. I think that one will be
| simple enough and have enough benefits to convince
| people.
| matthewmacleod wrote:
| It's honestly pretty disrespectful to the people who have put
| a bunch of absolutely amazing work into this project to
| dismiss it as an "unsupported hack".
|
| It's true that we are never going to see first-party support
| for Linux from Apple. That kind of sucks, and it would be
| much better for everyone if they had a more open and
| documented approach to this new platform. But it does at
| least have explicit support for booting third-party operating
| systems, and the attitude of the team behind the project is
| clearly not "hack together a prototype and we are done".
|
| I guess the point is that it's not black and white, and
| there's a large spectrum between "first-party support" and
| "unsupported hack".
| techrat wrote:
| Perhaps you should expand your definition of what
| 'unsupported hack' means instead of taking it as an insult.
|
| I support the work of anyone who gets Linux running on any
| hardware, I condemn the difficulty in which Apple
| unnecessarily restricts people from doing what they want
| with the hardware they own.
|
| It is an unsupported hack because Apple doesn't provide
| means (such as documentation or code) for people to run
| what they want. So anything you can do will always end up
| being a method that Apple may decide to close up with later
| software updates and everything has to be reverse
| engineered from scratch.
|
| Contrast this with AMD and Intel code in the Linux Kernel
| contributed by those companies themselves and being able to
| just boot from USB using a user accessible BIOS/UEFI
| loader.
|
| It's Apple's restrictions that make this necessary to be a
| hack.
| fay59 wrote:
| Support can be effective even if it doesn't come from a first
| party. As long as someone is signed up to fix your problems,
| it's not an unsupported hack.
| thoughtsimple wrote:
| Mind blowing progress! So impressed with the Asahi team.
| asdff wrote:
| Meta but does the name have any relation or maybe give homage to
| the other Asahi?
|
| https://en.wikipedia.org/wiki/Asahi_Pentax
| HMH wrote:
| Their about page only says:
|
| > Asahi means "rising sun" in Japanese, and it is also the name
| of an apple cultivar. Xu ringo (asahi ringo) is what we know as
| the McIntosh Apple, the apple variety that gave the Mac its
| name.
| marcan_42 wrote:
| There are lots of things called Asahi (a beer, a newspaper, an
| ISP, ...), but our project is specifically named after the
| Asahi apple, which is the Japanese name for the McIntosh Apple.
|
| https://asahilinux.org/about/
| gilbetron wrote:
| That's ridiculously clever.
| barkingcat wrote:
| There are tons of "other Asahi" - among other things it's a
| beer (super dry), baseball team, ramen noodle moniker
| [deleted]
| [deleted]
| dirtybirdnj wrote:
| This looks super cool! I just got an M1 MBA, it's fast as
| lightning. Its nice knowing a project like this is percolating
| and that in a few years when this daily driver becomes an extra
| machine there will be fun linux alternatives to try.
| saagarjha wrote:
| > It's not perfect, as it can't support a select few corner case
| drivers (that do things that are fundamentally impossible to
| support in this situation), but it works well and will support
| everything we need to make 4K kernels viable.
|
| I'm curious what these corner cases are; could anyone share?
| marcan_42 wrote:
| eGPUs for one, but there are bigger problems to solve there.
| Other than that, IIRC some v4l stuff did this, and a few
| others. It's a tiny subset of drivers.
| floatboth wrote:
| > bigger problems to solve there
|
| It's not the fucking "maximum BAR size is tiny" problem again
| is it? (hello Rockchip :D)
| marcan_42 wrote:
| Nah, but I was informed the other day that GPU drivers
| apparently like to map BARs as normal cacheable memory
| and... I'm not sure the M1 supports that.
|
| And then if you don't do that you run into problems with
| apps mapping GPU memory and doing unaligned accesses (plus
| it's a performance problem).
| floatboth wrote:
| drm likes uncacheable write-combining as an
| optimization... but that's disabled on arm64
| https://patchwork.kernel.org/project/linux-arm-
| kernel/patch/... because it can cause image corruption
| glitches (saw them myself, had to find and cherry-pick
| that commit into FreeBSD's drm back then)
|
| Generally I don't think "normal" is necessary? In
| FreeBSD/aarch64 we interpret most ioremaps (all other
| than WC and WB) as "device":
| https://reviews.freebsd.org/D20789
|
| and there doesn't seem to be a performance problem. Well,
| I haven't scientifically tested the performance but
| SuperTuxKart can do >100fps at 4K on an RX 480 :)
| schmichael wrote:
| Asahi Linux progress reports rank up there with Dolphin[1]
| progress reports for being excellent examples of technical
| writing as well as simply reminding me why I fell in love with
| computers in the first place. Love reading this stuff even if I
| may never use it (although I would love to run Linux on M1
| hardware someday!).
|
| [1] https://dolphin-emu.org/blog/
| m4rtink wrote:
| Still a bit sad that in both cases its effectively righting of
| wrongs caused by closed down undocumented computing platform.
|
| On the other hand if the respective authors like accepting such
| challenges and working on these projects, there is nothing
| wrong with that. :)
| gringo_flamingo wrote:
| This fascinates me, all these negative comments that seem to stem
| from projections of fear of failure. Yeah, this project has a
| chance to fail, like everything else in life.
|
| But to me I think this project will be indeed ready in a few
| years, and I will certainly be running this on my M1 as soon as
| it is stable and useful. It will be interesting to see how this
| turns out, I just wanted to comment on the next-level narcissism
| going on. Why most of you choose to be pessimistic and make not
| your problem, your problem, is beyond me.
|
| Keep up the great work Team, Asahi!
| webmobdev wrote:
| > _all these negative comments that seem to stem from
| projections of fear of failure._
|
| No. I criticise this project because it _adds value_ to a
| device that we should all be boycotting.
|
| We absolutely do not want to see the proliferation of custom,
| locked down SoCs on the desktop platform with each one being
| incompatible with each other, and limiting our freedom to run
| what code we want on it. That is why this project is extremely
| _short-sighted_ for the future of our computing freedom.
|
| The M1 is a locked blackbox. It is designed to take away user
| control on both hardware and software. These are legitimate
| criticism that many Apple fans try to deflect. They claim that
| the M1 isn't a locked down machine by comparing it with the ios
| platform as proof. After all, iPhones and iPads have locked
| bootloaders that prevent you from even running any other OS,
| while this is not so with the M1 computers.
|
| That's just plain denial. Just look at what has been happening
| to the Mac Mini:
|
| 1. The first few Intel Mac Minis allowed you some level of
| customisation of both the hardware (change RAM or HDD / SSD)
| and software (install other full featured OS).
|
| 2. Then came the Mac Minis with soldered RAM and SSD. You could
| no longer customise the hardware. Software was still
| customisable and you could still install other OSes. (Recall
| that Apple even offered free drivers for another OS, i.e.
| Windows).
|
| 3. The current generation of M1 Mini now doesn't allow you to
| customise both the hardware (everything is soldered) and the
| software. _Technically_ you can install other OSes, but the
| reality is that currently only _crippled versions_ of Linux and
| xBSD is available and practically the only full-featured OS
| available for it is macOS.
|
| These are clear indicators of how Apple has been working slowly
| to lockdown the Mac platform like their ios platforms. (Right
| now, projects like these give Apple and M1 publicity without
| harming their end goals. And so they are tolerated. Want to bet
| that as soon as some alternate fully featured viable OS appears
| for the M1, the bootloader will be locked, and the next Apple
| SoC will cripple it again?).
|
| The frog is still slowly boiling -
| https://en.wikipedia.org/wiki/Boiling_frog - to keep you in
| denial.
|
| There's another reason why I call this particular project
| short-sighted. Remember what happened when Apple introduced the
| Mini with soldered RAM and SSD's? It wasn't popular and didn't
| sell. _Apple was forced to backtrack_ and the next Mini didn 't
| have soldered RAM (but the SSD was still soldered). A similar
| thing could have been possible with the M1 too. Apple has bet
| their future on the success of their ARM processors. But if
| people boycotted Apple Silicon desktop platform for not being
| as open as AMD / Intel, Apple would have been forced to
| compromise a bit (at least strategically for the short-term)
| and released more literature to make the platform seem a little
| more open. And we might have seen Linux and xBSD being
| supported on the platform by now.
| crad wrote:
| > No. I criticise this project because it adds value to a
| device that we should all be boycotting.
|
| That's a pretty loaded, holier than thou attitude.
|
| Keep your politics out of my computing and open source,
| please.
| CarelessExpert wrote:
| > Keep your politics out of my computing and open source,
| please.
|
| Open source started as _a political movement_.
|
| Are you gonna ask me to keep the government out of your
| Medicare next? :)
|
| (no, that's not an invitation to debate broader politics,
| it's just the first example that springs to mind)
| crad wrote:
| > Open source started as a political movement.
|
| GNU is not the sole foundation of open source.
| webmobdev wrote:
| > Keep your politics out of my computing and open source,
| please.
|
| Then ignore me and go do the politics that you want rather
| than unnecessarily choosing to target someone with whom you
| don't agree or want to meaningfully engage.
| temptemptemp111 wrote:
| You don't realize you're being at least as political as the
| comment you're replying to because you're a full blown
| ideologue. We are allowed to talk about what software does
| and if it is good or bad. And you are allowed to deny the
| existence of morality - despite the fact that you're
| appealing to it in the very same sentence. If you had
| faculties you'd realize this comment destroys yours, but
| alas I wrote it in vein.
| [deleted]
___________________________________________________________________
(page generated 2021-10-05 23:00 UTC)