Support for Apple M1

[Alex Trusty]

Do you consider supporting  new ARM based MacBooks in the future?

Your distro would become a bestseller quickly.

[Igor]

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  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.

[lanefu]

bare metal armbian on m1 will likely never be a practical pursuit for us... But I fully intend to have good options to run Armbian as a VM on M1
 

 

[Igor]

 

[lanefu]

IInteresting i guess we should add another kernel option for the virtual then

[why2]

@Igor I have time to support you. I see a potential to make Armbian run on M1. However, I need more hints what to do or check.

[lanefu]

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.

[Igor]

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.

[why2]

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

[Igor]

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.

[Igor]

On 7/22/2021 at 11:50 PM, why2 said:

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

It seems things are proceeding faster:
 

 

[why2]

vor 22 Stunden schrieb Igor:

It seems things are proceeding faster:
 

 

What a great news. Thanks for sharing @Igor! That Hector Martin works full time to port Linux to M1.

[Igor]

10 hours ago, why2 said:

That Hector Martin works full time to port Linux to M1.

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

[why2]

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.

[Werner]

26 minutes ago, why2 said:

can't I

Short answer: No.

This cannot explained with just a few sentences. Start reading about the differences between x86 and ARM architecture.

[Igor]

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.

[lanefu]

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 

[sfx2000]

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

[sfx2000]

Running Ubuntu 20.04LTS on UTM on Macbook Air M1...

 

https://mac.getutm.app/

 

[lanefu]

41 minutes ago, sfx2000 said:

Running Ubuntu 20.04LTS on UTM on Macbook Air M1...

 

Sweet!  Runs great tho right?

My kernel's newer

 

 

[sfx2000]

2 hours ago, lanefu said:

Sweet!  Runs great tho right?

My kernel's newer

 

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

 

 

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

[lanefu]

I'll try to dig up my utm config you're not using hw accel if you see a72 cores

[lanefu]

Some hints here in my utm file.

 

https://forum.armbian.com/topic/18231-armbian-the-virtual-machine/?do=findComment&comment=127090

[lanefu]

12 hours ago, sfx2000 said:

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

 

Try some of these extra settings

 

[lanefu]

13 hours ago, sfx2000 said:

 

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

 

 

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

yeah if using acceleration would be like

[sfx2000]

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.

 

[Igor]

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?