Merge tag 'arm-Apple-M1-5.13' of Linux(git.kernel.org)
git.kernel.org
Merge tag 'arm-Apple-M1-5.13' of Linux
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c855563182001c829065faa17f8e29e9ceffe13
105 comments
The pinephone does this, they call it "convergence".
https://twitter.com/hadrianweb/status/1384548445579583489
https://pine64.com/product/pinephone-beta-edition-with-conve...
(be aware the pinephone software is still very much in beta, also sorry I couldn't find a better link then a few tweets)
https://twitter.com/hadrianweb/status/1384548445579583489
https://pine64.com/product/pinephone-beta-edition-with-conve...
(be aware the pinephone software is still very much in beta, also sorry I couldn't find a better link then a few tweets)
Does the pine phone still run at 5FPS and barely run youtube videos?
If you use acceleration it can play 1080p H264 videos at 60FPS. Any other questions?
...no? Maybe that was the case when it first came out, but that hasn't been the case for a while.
If you need more performance, consider Librem 5 instead.
What a loaded question.
No. Even when it first came out you could just run an X11 WM on it and it would run in real time.
Motorola also did it a decade ago. I remember seeing these at RadioShack:
https://en.wikipedia.org/wiki/Motorola_Atrix_4G#Webtop
The dock was a commercial failure.
https://en.wikipedia.org/wiki/Motorola_Atrix_4G#Webtop
The dock was a commercial failure.
I was always intrigued by the concept, but never really wanted to buy such a device for one simple reason: performance. Mobile phones, especially back then, don't exactly have great performance characteristics for desktop use. The Atrix has a 1GHz processor and 1GB of RAM, those were low specs for a cheap laptop even back then.
The same problem still exists on the PinePhone and Ubuntu's attempt, and Microsoft's failed attempt to use Qualcom chips as mobile workstations have so far all failed. When it comes to powerful yet power-efficient chips, Apple simply has no real competitor. Sure, AMD and Intel can outperform the M1, in some cases even at similar power draws, but Apple has mastered the base and idle power draw and caching that give their devices such a great battery life during simple, normal use.
With the processor unification, Apple may be able to provide a decent experience if they can think of a system that won't kill the battery (external battery the phone switches to?) and can cool the processor sufficiently while it's in a dock. Apple seems more than capable of solving those problems, if they'd want to.
I'm 100% sure I won't buy an iPhoneBook because I strongly dislike Apple's operating systems and the way the company itself operates, but if Apple fans will buy the product, competitors should soon follow with a device I'd find acceptable to use. Maybe, by then, the Linux smartphone ecosystem has grown to the point where it's actually usable for day-to-day operations (unlike the Librem/Pinephone/pmOS in their current state).
The same problem still exists on the PinePhone and Ubuntu's attempt, and Microsoft's failed attempt to use Qualcom chips as mobile workstations have so far all failed. When it comes to powerful yet power-efficient chips, Apple simply has no real competitor. Sure, AMD and Intel can outperform the M1, in some cases even at similar power draws, but Apple has mastered the base and idle power draw and caching that give their devices such a great battery life during simple, normal use.
With the processor unification, Apple may be able to provide a decent experience if they can think of a system that won't kill the battery (external battery the phone switches to?) and can cool the processor sufficiently while it's in a dock. Apple seems more than capable of solving those problems, if they'd want to.
I'm 100% sure I won't buy an iPhoneBook because I strongly dislike Apple's operating systems and the way the company itself operates, but if Apple fans will buy the product, competitors should soon follow with a device I'd find acceptable to use. Maybe, by then, the Linux smartphone ecosystem has grown to the point where it's actually usable for day-to-day operations (unlike the Librem/Pinephone/pmOS in their current state).
> With the processor unification, Apple may be able to provide a decent experience if they can think of a system that won't kill the battery (external battery the phone switches to?) and can cool the processor sufficiently while it's in a dock.
Why not just power the device off the lightning (hopefully Usb-c soon) cable used for docking? That's how all docks work now. When you're charging a single cell (most phones) you draw power from the charger, with the battery helping out during bursts if needed. No need to invent anything.
Why not just power the device off the lightning (hopefully Usb-c soon) cable used for docking? That's how all docks work now. When you're charging a single cell (most phones) you draw power from the charger, with the battery helping out during bursts if needed. No need to invent anything.
There are still a lot of things that you can do in a 4-core 1.1GHz Cortex-A53 / 3GiB RAM context of a pinephone, where performance is more than good enough.
Perfectly useable for i3 wm, terminal/ssh usage, light browsing in firefox, playing 1080p@60fps video, viewing photos, and plenty of other things, in docked mode.
Perfectly useable for i3 wm, terminal/ssh usage, light browsing in firefox, playing 1080p@60fps video, viewing photos, and plenty of other things, in docked mode.
Yes, so many people seems to be dreaming of that "phone that turns into a laptop" but I don't see it becoming a thing.
It might have made sense 20 years ago when everything wasn't online and sharing files was a pain, but nowadays it makes more sense to have independent devices than a single phone/laptop/desktop.
You need a screen+keyboard anyway, so why would you make that a dumb terminal instead of an independent device?
It might have made sense 20 years ago when everything wasn't online and sharing files was a pain, but nowadays it makes more sense to have independent devices than a single phone/laptop/desktop.
You need a screen+keyboard anyway, so why would you make that a dumb terminal instead of an independent device?
Also, let's not forget Asus Transformer Book V, which is Android {phone|tablet|laptop} and Windows {tablet|laptop}, 5-in-1:
https://www.gsmarena.com/flashback_the_phone_that_was_a_tabl...
https://www.gsmarena.com/flashback_the_phone_that_was_a_tabl...
As kube-system said, Motorola had this, and Microsoft phone also tried to fill this niche. Personally, I would love to have everything in a phone, with a good docking system for my desk, interop with a living room large monitor, and of course supporting all the dev setups that I use. After seeing what functionality Apple packs into their Apple Watch, it seems like the tech exists for a ubiquitous phone device - if only there was a large enough market so a company like Apple, or a Linux based phone company to build it.
The A14 is basically a M1 with less CPU and GPU cores, so I guess most of the work done for supporting the M1 on Linux could be reused for the A14.
What would be cool is if apps (like Uber etc) were all available on web and many people would actually be ok with a simple Linux-with-a-browser phone
That’s exactly what Firefox OS was. It didn’t work… at the time.
https://en.m.wikipedia.org/wiki/Firefox_OS
https://en.m.wikipedia.org/wiki/Firefox_OS
I very much agree with you. It would be amazing. We even have the ".app" domain extension. Apple don't like the idea but I think it's great.
Apple likes the idea fine, they just don’t want every website in the universe being able to send notifications to a user’s device. I don’t understand why people don’t see why that’s a bad idea.
It's more about bridging the gap between mobile and web. Installable web apps that have as much access to the OS as a native app (through user-initiated consent) is a great direction to move towards.
The browser can now run any language through web assembly, threads and all. The HTML/CSS layer is just a portable, expressive markup for visual assets.
I made a fitness goal tracking web app that worked completely offline. If you've used "strong" on android, it's basically a free clone that.
It stored all the records on the browser via indexeddb and the timer would ping you with a push notification when the rest timer would expire.
iOS erases the persisted storage after 7 days and doesn't let me use push notifications. I'd love it if iOS asked "hey this web app wants to store data long term" or whatever, but it doesn't.
The browser can now run any language through web assembly, threads and all. The HTML/CSS layer is just a portable, expressive markup for visual assets.
I made a fitness goal tracking web app that worked completely offline. If you've used "strong" on android, it's basically a free clone that.
It stored all the records on the browser via indexeddb and the timer would ping you with a push notification when the rest timer would expire.
iOS erases the persisted storage after 7 days and doesn't let me use push notifications. I'd love it if iOS asked "hey this web app wants to store data long term" or whatever, but it doesn't.
Or even just have an option somewhere you can manually toggle per site, to avoid the issue of being bombarded by permission requests.
I would be down with this if apps aren't allowed to ask for notification permissions until the user adds it to the home screen, the same way that game controller and full screen work now. Therefore the user consented for it to "become an app".
If Apple like the idea fine then they don’t fund/pay attention to it accordingly. Safari is full of weird PWA bugs and long standing ones, too.
As for the notifications, it’s easily solved. Softest touch: don’t let a notification prompt show without there being a user interaction first. Hardest touch: only allow it for webapps that are installed to the home screen.
I have a much less charitable view: Apple doesn’t like webapps because they’re a threat to the App Store ecosystem. Not so much from a monetary perspective but an exclusivity one: if you can run all the exact same apps on all mobile platforms they lose an edge. (though I’m sure they don’t mind the money either!)
As for the notifications, it’s easily solved. Softest touch: don’t let a notification prompt show without there being a user interaction first. Hardest touch: only allow it for webapps that are installed to the home screen.
I have a much less charitable view: Apple doesn’t like webapps because they’re a threat to the App Store ecosystem. Not so much from a monetary perspective but an exclusivity one: if you can run all the exact same apps on all mobile platforms they lose an edge. (though I’m sure they don’t mind the money either!)
> Apple doesn’t like webapps because they’re a threat to the App Store ecosystem
Steve Jobs in 2010:
>"We have two platforms we support. One is completely open and uncontrolled and that is HTML 5. We support HTML 5. We have the best support for HTML 5 of anyone in the world. We then support a curated platform, which is the App Store."
https://web.archive.org/web/20100605065858/http://www.cbsnew...
They've been pointing out that you can do anything you like through the web since the App Store was new.
Steve Jobs in 2010:
>"We have two platforms we support. One is completely open and uncontrolled and that is HTML 5. We support HTML 5. We have the best support for HTML 5 of anyone in the world. We then support a curated platform, which is the App Store."
https://web.archive.org/web/20100605065858/http://www.cbsnew...
They've been pointing out that you can do anything you like through the web since the App Store was new.
Just because Steve Jobs said it doesn’t make it true. Apple have lagged behind webapp standards for years. Even with the release of iOS 14.5 there are no notes about changes in the browser, despite there being a bunch.
Claiming Apple fully support the web because of something a former CEO said in a marketing presentation over a decade ago just doesn’t work.
Claiming Apple fully support the web because of something a former CEO said in a marketing presentation over a decade ago just doesn’t work.
Uber is available on the web! m.uber.com
In the past (pre-Android 10), you could do that with Samsung Galaxy phones - plug them into USB-C dock, launch Linux-on-Dex and you got Linux desktop.
you can do that right now with a PinePhone.
Wait... What?!
EDIT: ah, sadly looks like it's not something that's daily drive-able
https://www.youtube.com/watch?v=fCKMxzz9cjs
EDIT: ah, sadly looks like it's not something that's daily drive-able
https://www.youtube.com/watch?v=fCKMxzz9cjs
you can get a convergence pack with more RAM (3GB) and storage and with a USB-C docking bar (that you can also buy separately). Once plugged, you have a desktop GNU/Linux, I've tested with Plasma Mobile and it's working quite well (got a few crashes, but it's not flagged as fully stable yet).
The software is OKish and getting better at a steady rate. The SOC in the PinePhone is nowhere near beefy enough though.
Running the same stack on an M1-chip would probably a game changer usability-wise.
Running the same stack on an M1-chip would probably a game changer usability-wise.
What changed with Android 10?
Samsung discontinued support for Linux-on-DeX (which was always experimental/beta anyway). I assume whatever hacks they had in place to make the thing work were too hard to port to Android 10 for what was essentially a feature for hobbyists.
You can still use DeX itself to get a desktop environment when you plug your phone into a dock, but it's an Android desktop environment, with Android apps running in floating windows.
You can still use DeX itself to get a desktop environment when you plug your phone into a dock, but it's an Android desktop environment, with Android apps running in floating windows.
Linux on Dex (ubuntu in container) was abandoned and cannot be launched anymore.
Dex itself works, but that is just an Android desktop.
Dex itself works, but that is just an Android desktop.
Still works with my Samsung on Android 11.
ETA: actually, still an android interface, not X or anything.
ETA: actually, still an android interface, not X or anything.
That's why I wrote Linux-on-Dex, not Dex. Dex itself works, Linux-on-Dex doesn't anymore. Linux-on-Dex was Ubuntu container with X11.
Can do that already:
* Termux on any android
* dex on highend Samsung
* moto has something similar
* chromeos also has a built-in VM
* Termux on any android
* dex on highend Samsung
* moto has something similar
* chromeos also has a built-in VM
The AnLinux app is great to setup a linux rootfs on linux.
But it's limited, you can't run docker for example.
I would love to recycle old phones into Kubernetes nodes !
I would love to recycle old phones into Kubernetes nodes !
This is pretty cool. I could host my development environment on my desktop PC and using Termux, ssh into it and use vim as an IDE.
I can also forward ports so I can access things from my browser, though no debug, console, network tooling. There is an obvious lack of tooling - a full fat Linux desktop would be much better equipped, but it is incredible that this is possible at all.
I'll experiment with this.
I can also forward ports so I can access things from my browser, though no debug, console, network tooling. There is an obvious lack of tooling - a full fat Linux desktop would be much better equipped, but it is incredible that this is possible at all.
I'll experiment with this.
Samsung Dex, Motorola Ready For, and I'm sure there's others. Many have tried this before, "no one" is interested in it.
Maybe Apple can do this themselves by creating a partition in iPhone that contains iPad OS, and releasing an Apple Cinema touch screen, like the Wacom screen, I guess only make sense for them if the profits of people buying the touch screen would be bigger than people buying current devices, iPhone, iPad and current screen.
This has been the dream for so long. Computer in your pocket. Dock at a desktop. Same computer. Ubiquitous
I'm sure you know this but:
"Computer in some far away server. Dock at a local thin client. Connect to VDI via VNC or RDP or comparable."
"Computer in some far away server. Dock at a local thin client. Connect to VDI via VNC or RDP or comparable."
That really is the dream, but the natural data barrier between phone and desktop is very useful too. I wouldn’t install some npm package on such a Linux iPhone device.
I think the probability of Apple allowing that is pretty slim.
I'm not hugely familiar with the Linux release cycle, can anyone explain why such rudimentary support should be merged in now, instead of waiting until it's ready?
Release early, release often?
Merge the portions that you know are correct and will have no affect on anyone else now, which makes future work easier as you do not have to keep those "working" commits up to date.
We do this all the time with kernel development, and is one reason why breaking changes up into tiny pieces is so powerful. We can take the pieces that make sense now, and allow the developer to redo the portions that are not ready yet, instead of having to reject the whole thing if it were done in one single "chunk."
Also note that the TTY/serial portions of this hardware support was already merged through the serial tree because they were independent and didn't affect anyone else.
We do this all the time with kernel development, and is one reason why breaking changes up into tiny pieces is so powerful. We can take the pieces that make sense now, and allow the developer to redo the portions that are not ready yet, instead of having to reject the whole thing if it were done in one single "chunk."
Also note that the TTY/serial portions of this hardware support was already merged through the serial tree because they were independent and didn't affect anyone else.
Interesting, thanks for the explanation. Has this style of development ever come back to bite you?
Off the top of my head, no.
The big "downside" is that it takes more work on the patch submitter side. But the benefits in the end are almost always more than worth it (easier reviewer time, easier time to track down problems, better development cycle as feedback can be more specific, easier evolution of changes, etc.)
I wrote a whole chapter in the book "Beautiful Code" about how this development model can help create an end result that is almost always better than the initial "huge" submission model. Check it out if you are interested, it should be free online somewhere...
The big "downside" is that it takes more work on the patch submitter side. But the benefits in the end are almost always more than worth it (easier reviewer time, easier time to track down problems, better development cycle as feedback can be more specific, easier evolution of changes, etc.)
I wrote a whole chapter in the book "Beautiful Code" about how this development model can help create an end result that is almost always better than the initial "huge" submission model. Check it out if you are interested, it should be free online somewhere...
I found it, Greg's chapter `The Linux Kernel Driver Model: The Benefits of Working Together` on page 267
- https://www.oreilly.com/library/view/beautiful-code/97805965...
- https://github.com/stormtrooper96/books/blob/master/software...
So I'll definitely give it a read. Thanks!
- https://www.oreilly.com/library/view/beautiful-code/97805965...
- https://github.com/stormtrooper96/books/blob/master/software...
So I'll definitely give it a read. Thanks!
My instinct would have been that it's easier for the submitter (as they have less to polish and test) and more irksome for the reviewer as they have to go through multiple rounds of submissions, but naturally I'll take your word for it!
This kind of discussion is always of interest to me, I'll check out the book, thank you.
This kind of discussion is always of interest to me, I'll check out the book, thank you.
Reviewing three changelists, which individually do only a single thing each, is in my experience much easier than reviewing a single changelist bundling the changes from all three.
This is true even if the same lines are changed multiple times. It's something you'll learn with experience, but it's also not even close. Break your patches up as much as possible, and everyone will be happier.
This is true even if the same lines are changed multiple times. It's something you'll learn with experience, but it's also not even close. Break your patches up as much as possible, and everyone will be happier.
Not GP, but... In the context of recent event, [0] where not reviewing thoroughly enough some tiny patches had a major come-back-to-bite fallout, I can't help but wonder:
How, exactly are you expecting an increase in average patch size to help?
[0] https://news.ycombinator.com/item?id=26887670
How, exactly are you expecting an increase in average patch size to help?
[0] https://news.ycombinator.com/item?id=26887670
I did read through this debacle when it came out actually, I'm thoroughly on team Greg. I suppose my question was separate from malicious patches - I was interested in knowing if this incremental "merge tiny patches as and when they're ready" mode of development has ever caused issues with half-baked solutions affecting other parts of the kernel where perhaps it wouldn't have otherwise done so if the release was given more time for polishing and testing.
One idea might be building a relationship of trust around a certain architecture in the Kernel, another idea is that it makes future work faster to merge in if the basics are already in.
There's a relatively low cost to having this merged as it becomes available. It's not like x86 distros will be building it into their kernel.
It lets others build on it.
Obviously you should listen to Greg and not me, but in many ways you can summarise it as "are the changes correct and do they work?". That they don't amount to end-user useful support is a very separate matter. What's the benefit of delaying submission of correct and working branches?
If you plan for such model beforehand you already might be lowering overall efficiency. You know that you can't get the whole thing you want as one piece, but you plan "one third now, another third in a couple of months and the last third in more couple of months". Overall you might end up with twice the effort, since you had to account for that split, but in the context of kernel it still makes sense because of all the complexity and many people working on it simultaneously. And of course it also depends on "splitability" of the thing you're working on.
It's actually more efficient to do it this way. When you develop in a fork, you end up having to both keep rebasing on mainline, and then on submission, you might find that large parts of the code are the wrong approach or do not meet upstream standards, and need to be rewritten.
By planning for incremental merges, you ensure that your foundation is solid and acceptable and avoid wasted work.
By planning for incremental merges, you ensure that your foundation is solid and acceptable and avoid wasted work.
It seems like it's ready to go in mailine. Linux doesn't really do "Big-bang" Everything is done releases of new features. Support is added incrementally. Here it says USB, PCIe, IOMMU, NVMe. Haven't been finished. But given those features are spread occross difference subsystems and have different maintainers it'll be easier to work on those once the platform is in Mainline. (You won't be able to expect all the PCIe developers to have the special M1 mac branch ready for testing)
So it seems to be it's primarily solving branching issues rather than providing any benefit of the incremental support, is that correct?
Depends what you mean by incremental support. It would definitely help someone to base new work on what's already approved, merged and supported without the need to hunt for the latest updated external branch and reconciling it with their local version. (But maybe that's what you're calling branching issues)
I'd rather spend time writing new branches against approved, merged upstream rather than submitting to an upstream branch that may never get reviewed and merged. Keep in mind, too, that the longer a branch lives the more rebasing it goes through. Also, the bigger the branch is, the more it is to review when finally considering whether to merge it. I think giving people a foundation on which to build is a good way to prevent a lot of extraneous work and also to build confidence in the direction of development.
Easier to address feedback on the initial code now than when you have hundreds of lines building on top of it.
This is an example of "integrate early, integrate often" which is a core part of Continuous Integration (CI). These days people tend to focus on the automation aspect of CI, but getting code into mainline early is also key.
So, if the machines last a long time without Louis Rossman style of issues, getting a M1 Macbook for NixOS in about a few years might make sense. Very nice.
Who is Louis Rossman? What are his style of issues? Why should I know this?
He's a popular repair YouTuber that does videos on repairing Apple products.
From what I understand he has been a proponent of Right to Repair and has lobbied the US government about it.
From what I understand he has been a proponent of Right to Repair and has lobbied the US government about it.
He is an outspoken advocate of electronics repair, educator on repair techniques and has a repair business. You can find his many videos about repair on YouTube. He comes up in pretty much any thread on the "Right to Repair" movement, so people who read those threads on HN usually hear about him.
https://en.wikipedia.org/wiki/Louis_Rossman
https://en.wikipedia.org/wiki/Louis_Rossman
He is the owner of a repair shop in New York and specializes in repairing Apple Products.
He became famous for his Youtube Channel[1] where he regularly rages about Apples repair policy and for his regular appearance in Right-to-Repair Law hearings[2].
[1]https://www.youtube.com/user/rossmanngroup [2]https://www.youtube.com/results?search_query=louise+rossmann...
[1]https://www.youtube.com/user/rossmanngroup [2]https://www.youtube.com/results?search_query=louise+rossmann...
The style of issues he has to deal with are stupid design on Apple part that compromises longevity and resilience. Like really retarded, easily avoidable crap. And sheer spite.
e.g. https://www.youtube.com/watch?v=jahtu1_idVU
https://www.youtube.com/watch?v=AUaJ8pDlxi8
https://www.youtube.com/watch?v=NVAmnV65_zw
e.g. https://www.youtube.com/watch?v=jahtu1_idVU
https://www.youtube.com/watch?v=AUaJ8pDlxi8
https://www.youtube.com/watch?v=NVAmnV65_zw
Would be great if everything were ready by the time 16" M models come out. :)
A guy who earns his money by repairing apple products, talking bad about apple products. I get it. Everything for the clicks and subscriptions on youtube.
While apple is known to be unfriendly for 3rd party repairs, the sad reality is that a lot of hardware vendors are going that way. Also, stating you will have to wait a couple of years to buy a M1 macbook makes 0 sense as by then the latest macbooks will have M<something> and the issues with 3rd party repairs wont be addressed in the hardware revisions of the M1 macbooks released now.
While apple is known to be unfriendly for 3rd party repairs, the sad reality is that a lot of hardware vendors are going that way. Also, stating you will have to wait a couple of years to buy a M1 macbook makes 0 sense as by then the latest macbooks will have M<something> and the issues with 3rd party repairs wont be addressed in the hardware revisions of the M1 macbooks released now.
> the sad reality is that a lot of hardware vendors are going that way
I upgraded and replaced the RAM, SSD, display and wifi card in my thinkpad. Wouldn’t have been able to do the same with a macbook.
I upgraded and replaced the RAM, SSD, display and wifi card in my thinkpad. Wouldn’t have been able to do the same with a macbook.
Although thinkpads are particularly bad with their PCIe vendor whitelists.
Only for wifi. And you can unblock them at least in some models very easily.
You will need to buy one now on speculation that Linux support will ever be finished. Apple will quit making the m1 long before work is finished. The battery may not even be good by that time. Just today, news of m2 going to production is on hn front page.
nix23(1)
Does anyone know about any progress about getting the latest Intel Macbooks working on Linux?
I have a 2020 Intel MBA and it "works" as in it boots, but the laptop trackpad and keyboard don't do anything.
Externals work, so it seems like a driver thing.
There could be other problems, but I haven't gotten far enough to hit them because I don't see a point in using it unless the keyboard and trackpad work.
I have a 2020 Intel MBA and it "works" as in it boots, but the laptop trackpad and keyboard don't do anything.
Externals work, so it seems like a driver thing.
There could be other problems, but I haven't gotten far enough to hit them because I don't see a point in using it unless the keyboard and trackpad work.
I don't think this works with 2019 or later Intel Macbooks, but as far as I know the most recent relevant information and drivers are here: https://github.com/roadrunner2/macbook12-spi-driver. In my own experience, it's the trackpad, keyboard, and built-in speakers that don't work, but everything else seemed to be fine (2015 macbook).
Edit: this driver got the keyboard and trackpad to work, but the microphone, speakers, and webcam did not work. I also needed to downgrade to an older kernel (4.14) to get storage to work. All external things worked fine even through a hub, and the headphone jack also worked fine.
Edit: this driver got the keyboard and trackpad to work, but the microphone, speakers, and webcam did not work. I also needed to downgrade to an older kernel (4.14) to get storage to work. All external things worked fine even through a hub, and the headphone jack also worked fine.
A quick search led me to this: https://github.com/Dunedan/mbp-2016-linux#keyboard--touchpad
It seems to be related to the T2 chip and the BCE driver linked there should solve it.
It seems to be related to the T2 chip and the BCE driver linked there should solve it.
[deleted]
Doesn't Linux already have mature support for ARM? What's so different about the M1 that it needs all this extra work?
ARM is just an instruction set architecture specification. It is not any specific CPU; there are many different implementations (different chip designs). They can differ to various degrees, and often have at least a few non-standard features.
Hence, each ARM chip/platform often needs at least a little bit of special support (or drivers) to fully work in Linux, besides the standard ARM stuff.
Apple's platform is actually very different, with much more non-standard stuff, compared to other ARM implementations. Hence, much more extensive work was required to support them, than would be typical for other ARM platforms.
Even some of the really low-level features are different. For example, Apple have their own Interrupt Controller. Supporting it (in place of ARM's standard General Interrupt Controller) was a prerequisite to even be able to boot the linux kernel. Another weird thing about this platform is the bus configuration.
Also, Power management is something that is virtually always chip-specific, and the Apple M1 has some unusual quirks on top of that.
Hence, each ARM chip/platform often needs at least a little bit of special support (or drivers) to fully work in Linux, besides the standard ARM stuff.
Apple's platform is actually very different, with much more non-standard stuff, compared to other ARM implementations. Hence, much more extensive work was required to support them, than would be typical for other ARM platforms.
Even some of the really low-level features are different. For example, Apple have their own Interrupt Controller. Supporting it (in place of ARM's standard General Interrupt Controller) was a prerequisite to even be able to boot the linux kernel. Another weird thing about this platform is the bus configuration.
Also, Power management is something that is virtually always chip-specific, and the Apple M1 has some unusual quirks on top of that.
Peripherals
ARM is a CPU ISA. A MacBook is a whole computer. A general purpose OS to be really useful needs to support the CPU, yes, but also the boot hardware, the bus, the video devices, keyboard, pointing devices, speakers, mic, line in, line out, the network hardware, internal storage, external storage, and preferably any peripheral through the USB ports or wirelessly that's USB or Bluetooth with a standard profile.
Also remember that M1 is not only ARM. It's a SOC which combines ARM cores with GPU cores and AI-targeted cores. Targeting just that is a lot more work than just porting the ARM portion from a Raspberry Pi or an Android phone. I'm sure just getting a framebuffer up was a lot of new work. Fully supporting the GPU cores will be necessary for a lot of people's use cases. Once that and most of the peripherals are sorted, maybe the AI cores will be addressed.
Also remember that M1 is not only ARM. It's a SOC which combines ARM cores with GPU cores and AI-targeted cores. Targeting just that is a lot more work than just porting the ARM portion from a Raspberry Pi or an Android phone. I'm sure just getting a framebuffer up was a lot of new work. Fully supporting the GPU cores will be necessary for a lot of people's use cases. Once that and most of the peripherals are sorted, maybe the AI cores will be addressed.
Imagine running Linux on your iPhone. I just can’t wait for that day but the it doesn’t seem to happen anytime soon
I guess that is already possible, I remember seeing a guy doing that somewhere in the internet.
"A developer got Ubuntu Linux booting on the Apple iPhone 7"
https://www.xda-developers.com/apple-iphone-7-ubuntu-linux-c...
https://www.xda-developers.com/apple-iphone-7-ubuntu-linux-c...
I've seen ways of running Android (Linux kernel) on iPhones for over a decade on-line, though I don't know that any ever fully supported it.
My dream would be to run nixos on my phone so I could have all my devices configured from a single set of config files. Could then unify entire infra from config to sync and backups.
Why though? Is the iPhone hardware that much better than their high-end competitors? I’m a big Apple fanboy but I buy an iPhone (and indeed a Mac) to run iOS (and macOS)
Yes it is. Apple is way ahead of the competition in CPU design. Which is why the M1 is making Intel look so bad right now.
Plug it into a thunderbolt dock and you have a full Linux desktop.