XaiJu
marcan
marcan

patreon


The first Asahi Linux Progress Report is out!

Hello  everyone! This has been a long time in the making, and quite a beast to write at over 10000 words. I hope it's been worth the wait!

I heard your feedback on the last post loud and clear; everyone is interested in the project's goals over sponsor perks, and several people mentioned they prefer text updates over streams. So, the sponsor rewards are now abolished, and going forward I hope to put out one of these updates monthly. The community streams can still be fun, so I'm still planning to schedule them every now and then, but it seems most people think doing them weekly isn't quite worth it.

Let me know what you think! Now it's time to go back to upstreaming code review feedback :-)

The first Asahi Linux Progress Report is out!

Comments

The NVMe and USB/Ethernet should be coming soon; we already have most of the bits and pieces working, just need to wrap things up into the right patches.

Hector Martin

What are the main obstacles to use a MacMini M1 w/ NVMe SSD as Linux Server? (SSH, no GUI) It's sad that Apple doesn't participe in the effort to port Linux to Apple Silicon like they did with MkLinux over Mach back in the PowerPC age.

Boot process for a Mac with Apple silicon https://support.apple.com/guide/security/boot-process-secac71d5623/web

Wow! I want to applaud you guys for the tremendous amount of progress you have achieved in such a short time. I am very excited to be able to watch this project evolve! This was also quite a fun read and very educational for a regular linux user such as myself with interest but very little knowledge of low-level programming...

That's already what we're doing, in fact - m1n1 reserves itself and stays in memory (it needs to do at least a bit of itself for the spin-tables, but we're doing the whole thing because it's not that large anyway, and it might come handy in the future). However, the problem is that there is no defined interface for this - i.e. to "jump back to the kernel". This is where a function-call based PSCI interface would help (instead of hypercall or supervisor call, which are the only existing options).

Hector Martin

Yup, that's a good analogy!

Hector Martin

Possible silly question: to support waking from deep sleep, instead of using a trampoline to write the kernel on top of m1n1, would it be feasible just to leave m1n1 there to do any needed post-wake re-initialization and then jump back to the kernel?

Ah, I see, that makes sense.I guess the analogy with user space signal is that on x86 it has 256 different signals to handle using different functions whereas on ARM one must read siginfo to figure out what has happened and that info is provided by the interrupt controller.

This is splendid stuff. I'm currently porting application software to Windows and macOS on ARM, and details in your progress report have already been helpful.

John Dallman

Outstanding report and great progress on the port. I love style and mix of a story telling and technical details. Thank you and the whole team!

In practice what it means is that, by necessity, all interrupts end up in the same, global handler (well, one of two with FIQs). Some CPUs, like x86, actually have multiple IRQ vectors. On those, you can keep interrupts distinct all the way (to a limit): the CPU will itself jump to a specific, distinct piece of code for each hardware interrupt (up to 256 on x86).

Hector Martin

Amazing work! I hope you take your time getting Linux to fully run so we can enjoy a lot more of these.

Thanks for this writeup, as a fellow dev I want to commend you on your documentation skills. Extremely helpful.

Maybe a naive question: you said > On AArch64 CPUs, there is a single IRQ input which basically necessitate a interupt controller. Does this "single IRQ input" have any significance? What I meant is that is this something visible to anyone other than the CPU designer? Either the software or peripheral connected to the CPU? Or is this just an abstraction when talking about the CPU? I assume it should have some significance or else you can just define the interrupt controller to be how the interrupt works?

This is so great! Makes me want to get into lower level stuff so I can contribute!

John Wells

Great write-up, very much appreciated! I've followed the tweets, read some LKML discussions and caught some of the streams (partly), but it's great to have a bit of a summary that takes all the small bits of knowledge I picked up over the months and puts it into the grander context. I think in terms of Patreon rewards, this is the best thing I can wish for :)

This is fascinating, and I've learnt so much reading this. Thanks!

WhyNotHugo

Unfortunately, only M1-based macs can act as the host, as the Intel ones are missing required functionality. You *can* use an Intel Mac as the target, and I think the "reboot" operation works, but the features you can expose over the Type C port vary; I don't think you can get a serial port from the x86 side on it, but I'm not sure. I do not recommend experimenting with patching macvdmtool when connecting two computers together, because using the wrong pin configs could cause hardware damage; best leave that to experiments where one end is a breadboard so you can use a multimeter on it before you accidentally connect a 1.2V UART to a 3.3V I²C bus.

Hector Martin

Can Intel macbooks be used with macvdmtool, or is it only M1-based macs ?


More Creators