Jump to content

Support for Apple M1


Alex Trusty

Recommended Posts

2 hours ago, Alex Trusty said:

Your distro would become a bestseller quickly.

 

Our distro is already a best seller in its domain, just the problem is that is free. 1 million x 0 = 0 :D Less than 0.1% of its users chooses to donate something, which is almost enough to cover electricity costs you make while using our infrastructure. Reverse engineering - if vendor doesn't have interest in FOSS the expensive way is the only way - and supporting yet another closed private chip can be expensive. 

 

Topic was moved to board bring up section, where you can talk about how you will get where you want. If there will be enough interest and we would have some resources left, we join. Or not.

 

Add:
There is a Apple M1 dedicated Linux support initiative, which IMO didn't come very far by now but lets see how things will progress https://asahilinux.org/about/ It looks like one developer target was to raise 4000 USD per month to cover living expenses while doing that. Don't know if he manage ... Our troubles are the same.

Link to comment
Share on other sites

  • Igor changed the title to Support for Apple M1

So Armbian bare-metal on M1 is really contrary to our mission... but I do hope the community can run with the work I've started with the virtual-qemu image... because virtual armbian on M1 is fun and practice.

Link to comment
Share on other sites

On 7/18/2021 at 6:08 PM, why2 said:

I need more hints what to do or check.


Expensive bare-metal approach?

 

IMO hardest part is to support already moving initiative with a few of additional Hector Martin clones . Provide that team whatever they need and trust they will deliver ... Since a full dedication is needed to get somewhere, you need to find a way to feed this team for a year, perhaps two. I think currently only Hector have a pay. And count that they might miserably fail as well.

 

Its a long term project and having "Armbian representative" in that project as an observer is already valuable, so early implementation can happen. Once developed far enough. Currently, AFAIK, it is not developed enough to be useful. But I don't have much time to pay attention. That job has to be done by someone else.

Link to comment
Share on other sites

18 hours ago, why2 said:

OK, more than a year is too long for me.

 

My estimation is based on general knowledge and experiences. For proper research I have no time. And you can do that as well. Ask people that are already working on - we are working with different hardware, which have only general similarities.

Link to comment
Share on other sites

vor 5 Stunden schrieb Igor:


The same is with each ARM chip, just only a few people understands.

Why do we need to have different port of Armbian for each ARM Chip (e.g. M1, Rockchip RK3288, Samsung Exynos 5422)? There is Ubuntu for ARM https://ubuntu.com/download/server/arm,  and I can install it on any kind of ARM SoC can't I? At least for VM, I can use this Ubuntu for ARM image. For x86_64 like Intel and AMD Ryzen processors, we have the same Ubuntu image. I'm a little bit confused.

Link to comment
Share on other sites

3 hours ago, why2 said:

Why do we need to have different port of Armbian for each ARM Chip

 

ARM is all about diversity and customisation. It is very hard and very expensive to put things on a common ground. This multi million problem is certainly not Armbian fault. We - in this whole ecosystem - generates close to nothing. but despite all deliver you a value - providing same experience on all hardware despite this diversity. Armbian acts and works (almost) the same, regardless the hardware. But yes, you need a different - the expensive part - boot / hw layer.

Link to comment
Share on other sites

On 7/28/2021 at 9:19 AM, Werner said:
On 7/28/2021 at 8:51 AM, why2 said:

can't I

Short answer: No.

This cannot explained with just a few sentences.

 

Man we really need to write the definitive sermon on this and add it to faq / documentation.     I think there might be an issue open for it somewhere 

Link to comment
Share on other sites

Was kind of seeing if anyone would mention things, since the processor has been out for better part of a year now...

 

Spoiler

% uname -a

Darwin astro 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:24 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T8101 arm64

 

Asahi team is making good progress at bringing up the kernel at a board level, so one could probably bring debain into userland with not much effort.

 

Homebrew folks have made the port over from x86_64 to arm64 recently, so toolchain support should be a bit better.

 

Looking below - nice finegrained clocks for CPU/GPU on the chip - note that the cores are individually clocked...

 

Spoiler

**** Processor usage ****

 

E-Cluster Power: 15 mW

E-Cluster HW active frequency: 1007 MHz

E-Cluster HW active residency:  10.89% (600 MHz: 7.8% 972 MHz:  85% 1332 MHz: 1.7% 1704 MHz: 1.9% 2064 MHz: 4.0%)

E-Cluster idle residency:  89.11%

E-Cluster instructions retired: 8.61832e+08

E-Cluster instructions per clock: 1.02599

CPU 0 frequency: 1169 MHz

CPU 0 idle residency:  94.42%

CPU 0 active residency:   5.58% (600 MHz: .13% 972 MHz: 4.0% 1332 MHz: .32% 1704 MHz: .56% 2064 MHz: .57%)

CPU 1 frequency: 1205 MHz

CPU 1 idle residency:  95.53%

CPU 1 active residency:   4.47% (600 MHz: .08% 972 MHz: 3.1% 1332 MHz: .31% 1704 MHz: .37% 2064 MHz: .63%)

CPU 2 frequency: 1207 MHz

CPU 2 idle residency:  97.43%

CPU 2 active residency:   2.57% (600 MHz: .04% 972 MHz: 1.8% 1332 MHz: .21% 1704 MHz: .19% 2064 MHz: .37%)

CPU 3 frequency: 1382 MHz

CPU 3 idle residency:  97.52%

CPU 3 active residency:   2.48% (600 MHz: .01% 972 MHz: 1.2% 1332 MHz: .29% 1704 MHz: .31% 2064 MHz: .63%)

 

P-Cluster Power: 56 mW

P-Cluster HW active frequency: 671 MHz

P-Cluster HW active residency:   3.67% (600 MHz:  93% 828 MHz: .91% 1056 MHz: 2.3% 1284 MHz: .72% 1500 MHz: .65% 1728 MHz: .31% 1956 MHz: .23% 2184 MHz: .08% 2388 MHz: .17% 2592 MHz: .27% 2772 MHz: .19% 2988 MHz: .14% 3096 MHz: .09% 3144 MHz: .08% 3204 MHz: .77%)

P-Cluster idle residency:  96.33%

P-Cluster instructions retired: 9.81091e+08

P-Cluster instructions per clock: 2.97139

CPU 4 frequency: 1456 MHz

CPU 4 idle residency:  97.85%

CPU 4 active residency:   2.15% (600 MHz: .05% 828 MHz: .26% 1056 MHz: .67% 1284 MHz: .27% 1500 MHz: .14% 1728 MHz: .31% 1956 MHz: .21% 2184 MHz: .07% 2388 MHz:   0% 2592 MHz: .04% 2772 MHz: .00% 2988 MHz: .01% 3096 MHz:   0% 3144 MHz: .01% 3204 MHz: .12%)

CPU 5 frequency: 2086 MHz

CPU 5 idle residency:  98.23%

CPU 5 active residency:   1.77% (600 MHz: .01% 828 MHz: .11% 1056 MHz: .40% 1284 MHz: .21% 1500 MHz: .09% 1728 MHz:   0% 1956 MHz: .00% 2184 MHz: .02% 2388 MHz: .17% 2592 MHz: .08% 2772 MHz: .09% 2988 MHz: .09% 3096 MHz: .08% 3144 MHz:   0% 3204 MHz: .42%)

CPU 6 frequency: 1701 MHz

CPU 6 idle residency:  99.86%

CPU 6 active residency:   0.14% (600 MHz: .00% 828 MHz: .02% 1056 MHz: .01% 1284 MHz: .04% 1500 MHz: .04% 1728 MHz:   0% 1956 MHz:   0% 2184 MHz: .00% 2388 MHz:   0% 2592 MHz:   0% 2772 MHz:   0% 2988 MHz: .00% 3096 MHz:   0% 3144 MHz:   0% 3204 MHz: .03%)

CPU 7 frequency: 2700 MHz

CPU 7 idle residency:  99.96%

CPU 7 active residency:   0.04% (600 MHz: .00% 828 MHz: .00% 1056 MHz: .00% 1284 MHz:   0% 1500 MHz:   0% 1728 MHz:   0% 1956 MHz:   0% 2184 MHz:   0% 2388 MHz:   0% 2592 MHz:   0% 2772 MHz:   0% 2988 MHz:   0% 3096 MHz:   0% 3144 MHz:   0% 3204 MHz: .03%)

 

System instructions retired: 1.84292e+09

System instructions per clock: 1.57491

ANE Power: 0 mW

DRAM Power: 11 mW

CPU Power: 71 mW

GPU Power: 2 mW

Package Power: 85 mW

 

**** GPU usage ****

 

GPU active frequency: 3 MHz

GPU active residency:   0.87% (396 MHz: .87% 528 MHz:   0% 720 MHz:   0% 924 MHz:   0% 1128 MHz:   0% 1278 MHz:   0%)

GPU requested frequency: (396 MHz: .87% 528 MHz:   0% 720 MHz:   0% 924 MHz:   0% 1128 MHz:   0% 1278 MHz:   0%)

GPU idle residency:  99.13%

GPU Power: 2 mW

 

Will be nice to see what newer ARM cores bring to the table - looking forward to Cortex-A78

 

sfx

Link to comment
Share on other sites

13 hours ago, sfx2000 said:

 

Runs well enough - it's all native, but QEMU is suggesting it's a Cortex-A72

 

1404225121_ScreenShot2021-11-02at5_43_36PM.thumb.png.40bfb8cf5e2677846507fb4de1c5b100.png

 

It's a stock ISO from Ubuntu, so it's whatever kernel they're shipping with...


yeah if using acceleration would be like

image.png

Link to comment
Share on other sites

Just noticed how small the M1 MacMini mainboard is... 

 

I'm surprised it even has a fan, they could have done a heat pipe to the housing, and that likely would have been "good enough"  - that's the nice thing about my MBAir-M1, no fans, it's dead silent.

 

macmini_m1.thumb.jpeg.e84b561ee4a654877e66704eb8e864be.jpeg

Link to comment
Share on other sites

It has been silent for a year ;) Anyone has thoughts or tried to merge Asahi Linux into Armbian?

 

Apple mini could serve as a nice small Armbian build machine or just general purpose workstation. Well, compilation runs on MacOS, but running native Armbian Linux would be a lot cooler. The task of bringing Asahi family into Armbian https://docs.armbian.com/Developer-Guide_Adding-Board-Family/ probably should not be very difficult anymore https://github.com/AsahiLinux/docs ?

 

Anyone with a strong enough wish & ability?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines