docs

the process for end users. The install script will create and setup the boot partition itself instead of requiring a secondary macOS installation, so it will be much faster and not waste disk space. Doing this requires manually creating several disk partitions for the macOS bootloader, downloading a firmware image from Apple, and copying a bunch of firmware blobs into the right places across those partitions, so it’s not really suited for a manual install. Note also that Corellium’s implementation was more of a proof-of-concept than something designed for long-term use. If you want to see “how Linux does things” you should be looking at the Asahi project, which is being upstreamed into mainline Linux and is already much further along in development than Corellium’s demo. [0]: https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart... [1]: https://github.com/AsahiLinux/asahi-installer

s using all this to experiment with a Chinese MP4 player. That version ended up being called "minimp" [2]. Another thing that happened on the way to the M1 was deleting the "P_RENDER_BUNNY" command [3]. So yeah, what I'm doing now on the M1 is literally, down to the code, shell.py, and proxy command names, the same damn thing I was doing 13 years ago on the Wii. AES engine [4] back then, IRQ controller [5] now... though evidently I put a bit more effort into the MediaWiki register documentation templates back then; the GitHub wiki is a bit more limited... :-) [1] https://mrcn.st/t/ios_stub_vs_m1n1.png [2] https://marcan.st/2009/06/sunplus-spmp305x-media-player-hack... [3] https://www.youtube.com/watch?v=3tg7KSSUl8Q [4] https://wiibrew.org/wiki/Hardware/AES_Engine [5] https://github.com/AsahiLinux/docs/wiki/HW:AIC

SD isn't going to help you. If you start messing at that level, you'd better be prepared with another Mac and Apple Configurator 2 to get a proper clean start.

c (DFU mode). Disk Utility, the GUI, is broken sometimes. If something doesn't work properly there, ditch it and use the command line. Both Disk Utility, the GUI, and diskutil, the CLI, will hide the first and last APFS containers from you to stop you from shooting yourself in the foot. They're still there, just hidden from the main listing. You can get info for them. Be careful with that. To do OS reinstalls, you want to be in 1TR. This is not the macOS recovery. Hold down the power button and pick Startup Options from there. Then you can use diskutil (preferably the command line version). You should delete the whole APFS container (disk0s2 usually) corresponding to your install, which will contain multiple volumes. Re-create it as APFS. That will create a container with one volume. You can then install to it and the macOS installer will create all the other volumes. Additionally, the SEP data is stored separately from the OS (in one of the volumes of the first container). To wipe that, after wiping the partition and before reinstalling, run `xartutil --erase-all`. I've never tried that myself, and I suspect it's not really required because a reinstall should start with a fresh store, but it's probably a good idea to try if you have authentication/user-related issues after reinstalling. There is also OS recovery, which is the recovery instance that comes with an OS install. It looks exactly the same as 1TR, but it's not the same, and this is highly confusing. For any serious digging around, you want to be in 1TR. Booting holding down the power button will get you there, usually; after a failed macOS boot I've seen it go into regular recovery anyway. To be absolutely sure, boot into 1TR (holding down power, then startup options), then do a clean shutdown, and boot again the same way. More info on what's on the SSD of these things: https://github.com/AsahiLinux/docs/wiki/SW:Storage

cOS made to look similar. So how does external boot work? The "blessing" process done by the Startup Options screen involves copying the entire macOS Preboot partition - iBoot2 OS loader, Darwin kernel, auxiliary CPU/device firmwares, device tree, and some additional stuff - to the internal SSD. It then creates a local, signed boot policy that allows system firmware to boot this macOS install. You aren't booting from an external disk. You are booting from the internal SSD, with the root filesystem on the external disk. Additionally, the integration of the macOS user credentials with the SEP means that you can't "just" take an install made on another machine and use it on a separate one. It involves importing user credentials into the local machine. This process isn't implemented properly yet. As you might expect, this entire mechanism introduces a ton of corner cases around updates, boot selection, etc., and it is still very buggy and broken. The M1 launch was, when you look at details such as this, very obviously rushed. Further reading for those interested: https://github.com/AsahiLinux/docs/wiki/M1-vs.-PC-Boot https://github.com/AsahiLinux/docs/wiki/SW:Boot https://github.com/AsahiLinux/docs/wiki/SW%3AStorage I'm actually eagerly waiting for Apple to fix this in future system firmware releases, because my plan for installing Asahi Linux for end users with a minimal amount of fuss is to abuse the mechanism to adopt foreign macOS installations. This elides the current need to have a completely wasted, 60+GB macOS install as a dummy to actually launch Linux (we could clean it up and resize it to get the space back, but it still makes for a very annoying install process that I'm hoping to avoid). On the plus side, this dual-booting mechanism is very cleverly designed to separately secure different OSes, so you do not need to downgrade security on your machine to install an unsigned OS like Linux. It is a separate OS with a separate security policy. You can keep your macOS install fully secure, and capable of running iOS apps and other actions that require secureboot, and install Linux (or another macOS with a custom kernel, kexts, etc) in parallel, completely unintrusively. So kudos to Apple for designing this whole thing, and for opening it up for us to use :)

spent most of Saturday debugging the source of L2 memory subsystem bus error exceptions in our bootloader, m1n1. Corellium's codebase and preloader just turns off reporting those errors entirely, all the way into Linux. There are very, very different approaches going on here. FWIW, Corellium had been developing their kernel in secret for A14 devices (that's the extremely similar iPhone version of the M1) for months now, plus had previous versions for older Apple SoCs, so it's not like they did this in two weeks; rather that they are currently piecewise releasing and adapting code they've had for a while and developed on jailbroken devices, while we/Asahi Linux started from scratch mid-January when Apple finally published the tools to run your own kernels on M1 Macs. I'm happy to pull any drivers they develop and release that are clean and upstreamable, but we're working step by step and I'm not in a race with them; we're in this for the long run and I want to make sure anything we work on is the right way of doing things. We're also working on GPU acceleration, which is a hard requirement for a usable desktop, and which as far as I know Corellium have nothing on. Alyssa is working on the userspace side already; I'll jump on the kernel side as soon as the necessary kernel dependencies are in. I'm currently writing a quick start guide to help other kernel devs with interest get started with development, and in the coming weeks I will be taking some time to develop an open hardware design for a serial debug cable for these machines, and building some prototypes to send to other kernel devs to help bootstrap community members who want to help. Today I'm also working on using one M1 machine as a serial terminal for another, with a standard type C cable (it should be possible AIUI, but I need to reverse engineer some details to get the right commands sent to the Type C controller) - not the cheapest solution but certainly the lowest effort one right now, if you have the money for two M1 boxes.