41–50 of 69 posts
> I recommend Will Deacon’s talks, such as this one and this one.
They're both the same link! Is the talk that amazing, or is there a second one? I've been looking into ARM lately, and I'll take anything that'll help me understand memory ordering/synchronization.
I noticed the author is active on this thread, so > I recommend Will Deacon’s talks, such as this one and this one. They're both the same link! Is the talk that amazing, or is there a second one? I've been looking into ARM lately, and I'll take anything that'll help me understand memory ordering/synchronization.
I got a real kick out of "our ARM Mac bootloader is actually the thing you used to backup and restore your Wii NAND a decade ago".
This thing actually goes back further than the name "mini" and BootMii; in the beginning it was a never-released thing called "ios_stub" and actually served the very same purpose on the Wii, to experiment with the hardware over a USB Gecko (which was a USB serial-like interface that plugged into the memory card slot) using the very same Python approach. That code hasn't changed much in checks Git history 13 years... though it obviously flipped endianness on its way from the Wii to other ARM32 platform experiments, before making it to ARM64 and Apple Silicon [1].
The Python side is still mostly the same too, other than getting ported from Python 2 to Python 3 and growing a bunch of utility functions. The Python-side malloc implementation actually got written when I was 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
> On the other hand, the rest of the 64-bit ARM world has largely converged on two competing standards: UEFI + ACPI (largely used by servers running Windows or Linux), It's not supposed to be just for servers, the Arm Base Boot Requirements (BBR) require it for any non-embedded use https://developer.arm.com/documentation/den0044/latest The new ARM64 laptops follow BBR so they have UEFI+ACPI, which means they can run…
I spent about five minutes wandering through the doc you linked trying to figure out how they define "embedded" and gave up. In any case I've done plenty of hairy "embedded" development stuff (kernels, uboot, weird hardware drivers, etc) but I draw the line at device trees. I may have some kind of PTSD or something but I just refuse to deal with them in any way. Of course passing a path to a compiled binary device tr…
Like when you need to write support for a new board or if you need to patch your ACPI tables, because of bugs in there: https://www.kernel.org/doc/html/latest/admin-guide/acpi/init...
`PTSD` sound more like an ACPI table name ;)
Earlier quoted context omitted.
That's mostly just imported from existing iPhone research, where people have been reverse engineering iBoot (from exploitable phones, since it's encrypted) for a long time now. Combining that with what is known about how the M1 works from observation / the boot config data structures yields a decent picture, without actually seeing the code. Here's a fun one though: how I found and documented the Apple-proprietary me…
>my plan is to run macOS under a thin hypervisor built on m1n1 that can log hardware accesses The fact that people like you exist in this world really makes me happy.
Earlier quoted context omitted.
>my plan is to run macOS under a thin hypervisor built on m1n1 that can log hardware accesses The fact that people like you exist in this world really makes me happy.
If you read the post, the guy says that is the same approach used to make the nouveau nvidia drivers.
I could do it that way too (XNU is vaguely open source, and the most recent source release is buildable for M1), but I honestly find the idea of writing a little hypervisor a lot more appealing than learning to hack on XNU, and it's probably a similar amount of effort all things considered.
Technically, m1n1 is already a "hypervisor" for very small values of hypervisor; as of last week you can `chainload.py --el1` another m1n1 into VM guest mode and run a kernel from there, and will get exception report dumps if it crashes in a way a hypervisor would notice, but there is no virtual memory in use. So it's mostly just taking that, making some page tables, adding exception handlers to handle page faults and and log MMIO as I want to, and somewhat virtualizing the CPU startup hardware (which is the only thing we can't just pass through because we need to control the CPU boot process). And making chainload.py able to load macOS kernels (needs some extending to support missing Mach-O features and handling some memory structures properly).
> Welcome to the first Asahi Linux Progress Report! In this series we’ll be taking a page from the Dolphin playbook and giving you monthly updates on the progress of the project. Nice work! let's see the progress... ~60,000+ words later... > We could keep talking in depth for another 10000 words, but alas, this post is already too long. Please no. A TL;DR is just enough for the busy. The Dolphin report even shows mor…
Device bringup is, as you say, complex. This complex.
I signed up as a GitHub sponsor based on this post. Thanks for the great work and write up marcan!
Earlier quoted context omitted.
Hmm, I see them participating on linux-arm-kernel list, nothing since January though: https://lore.kernel.org/linux-arm-kernel/?q=corellium
Mohamed is not a Corellium employee, but rather a third party who early on volunteered to attempt to upstream some of their patches. The only e-mail from a Corellium employee to Linux mailing lists, to date, is this one: https://lore.kernel.org/linux-arm-kernel/ce74bb29-1237-b0e7-... This is the most puzzling bit to me: nobody from Corellium participated in the upstreaming discussion about their own code either.
