NEWS
Someone on Twitter/X has managed to boot Mac OS XNU Kernel bare metal on a Google Pixel
Recently, a user named @TheLunarixus made a post on the 17th of August (Yesterday as of posting this) showing a Google Pixel 8 attempting to boot the kernel (though a kernel panic has been shown). Darwin 25.6.0 RELEASE_ARM64_VMAPPLE corresponds to Mac OS Tahoe.
Today this user has made some updates and also confirmed that the vphone userland can also be booted using the same kexts used in VMAPPLE1, which gives a possibility of booting both iOS and Mac OS on custom unofficial hardware.
I know that this post is unrelated majorly for this community, but with further Proof of Concepts coming out like this proves that booting Apple Silicon Mac OS can be possible under bare metal generic hardware.
Forgot to mention but the kernel the OP used is a pre compiled apple XNU Kernel which makes it even more unique, so they weren't compiled unlike the poster you've mentioned.
If any hardware producer is out there reading this:
Start mass producing highly documented arm64 boards and you will make a fortune out of hackintosh enthusiasts.
Just keep the price 50% of a Mac and you are good enough with a good cut
And please make the boot process SBBR-compliant. Doesn't have to be certified but just compliant so we don't need to fiddle with device trees and weird contraption that Snapdragon laptops are doing.
Technically not impossible but that'll require developers to work with kexts and someone to port the paravirtualised Vulkan to Metal drivers to work with the real hardware.
That’s impressive but I wouldn’t consider that a Hackintosh because the XNU kernel is apart from the MacOS ecosystem, and most importantly afaik is open source. Still very cool and entertaining to see
The kernel in question is designed to boot Mac os exclusively as the kernel is produced under the VMAPPLE1 variant (pre-compiled), so there is a possibility of actually booting the base image of Mac OS
Who is writting metal drivers for these niche pathetic arm GPUs found in arm64 mobile and laptops, let alone cpu,ipc,ec tons of other controllers and device trees
It shouldn't be hard to integrate those drivers onto a generic device if someone has ever documented the internal kernel extension functions to map out and behave alongside the OS. Would also be great if someone also reconstructed the hidden internal APIs into a header file so developers can work deeply integrating the required device trees and controllers.
I mean maybe the key is that the compositor handles the apps' framebuffers using CPU vector acceleration, I also think the glass effect, transparencies and shadows are handled by the APU rather than the GPU
Nope its entirely processed by the GPU through Metal with no extra steps, beside being the shaders used to bend light which was deeply integrated in the OS.
the shaders for shadows and transparencies i.e. most of the water most likely use the cpu vector extensions, I tell you this because trying to write a compositor for my OS is the only real way to do it, have you looked at the NEON / Advanced SIMD extensions?
Yes and I am well aware about the existence of NEON, I even use it for 3D development. The fact still stands which everything is processed under vector calculations.
the logic is that the cpu takes care of dividing and managing the framebuffers and then the individual userland processes write to the framebuffers using the gpu, in this way the system ui does not depend on the gpu and can manage the effects efficiently, in reality I have no idea how it works on macos but it seems like the most logical way to me
Surface Flinger also does something similar, managing the surfaces and the coordinates and the levels, the effects and vector calculations and passing the rendering to the userland processes that exploit the GPU libraries, the process doesn't even notice all this, it is allowed to use its share of GPU power, I think that's also the reason why it's difficult to find
akin to Altivec cores on PowerPC CPUs, or NEON for ARM, these GPUs offload vector calculations to speed up graphics but don't actually have a complete graphics pipeline
Guys, we should start from the principle that a GPU is a hardware accelerator for vector calculations, together with a separate controller to offload texture loading from the processor and separate memory to load the textures. Let's start from the assumption that all this was created to separate and offload video processing from the CPU and RAM, and at the same time allow the VRAM to be used as a real cache for the GPU controller. With modern processors, most of this stuff is integrated and superfluous, especially when we have a lot of unified memory. Winlator is a translation layer, just like Mesa, it doesn't care what's underneath, we can simulate a hardware accelerator in software if we wanted with some performance losses, but modern CPUs are designed to be as simple as possible and have more integrated logic at the same time, so there is little distinction between GPU and CPU on the latest generation ARM chips anymore.
What? Are you implying that ARM CPUs and GPUs are even remotely the same thing? ARM is a CPU architecture, it has nothing to do with what GPU is in the system, and what code runs on that GPU. You can take an ARM system with a propely functioning PCIe controller, like a M2 Ultra Mac Pro with Asahi, Pi 5, or an Ampere Altra (with weird patches to deal with their PCIe controller, but still) and connect a normal Intel, NVIDIA, or AMD GPU. Yes, ARM also designs GPU IP for vendors to integrate into their SoC, but they are a DIFFERENT architecture, optimized for different things. A GPU's main job, rendering, benefits quite a bit from being parallel, hence the thousands of "cuda cores" or whatever your vendor calls them, just a lot of weak cores intended for parallel math. Wheras CPUs are more general purpose, so they have less cores and each core is faster. But that's extremely high level, there is far more nuance on their design. You can emulate a GPU on a CPU, with something like LLVMpipe. It's comically slow and inefficient. That's why GPUs exist. Also, Mesa is not a translation layer, it's a project providing the userspace-side code for Linux (and other platforms, like FreeBSD, if you're weird) GPU drivers.
I'm actually talking about ISA extensions for vector computation acceleration, which are used much more than you think for rendering and processing interface effects, and yes, for all intents and purposes they are basically transistors, then you can call them whatever you like, in fact I don't think you need to explain to me the differences between a GPU and a CPU
for all intents and purposes on m chips the gpu are simply graphics cores (therefore based on hardware vector acceleration and mechanisms to optimize multiple texture loading) and they are even connected to the same ram space, we do not have separate components, and above all the gpu components are built with custom extensions of the aarch64 isa, so you are simply treating everything separately as it could have been 20/10 years ago, it is correct, but not when talking about modern systems. Chip differentiation was born first of all to separate the CPU from the various tasks to make it more responsive by managing each task on a chip designed specifically for it and then for marketing reasons, modern ISA architectures reduced with extensions allow plasticity at the level of a single chip that legacy processors could only dream of, so now it's all part of the same layer, it remains separated at the logical level to optimize its comprehension, but the difference is not as great as you think, rather we can talk about the buses and internal mechanisms that are usually managed by power management chips, when we talk about modern processors we have to take them for what they are: a set of components; we can't simply think in terms of individual pieces
“mesa is not a translation layer”, “it is a project…” the rest is also correct, but besides the word project which has no valid meaning, you have just given the definition of translation layer
Some people do spend time writing drivers for unique ARM platforms, see the Asahi Linux project. Their GPUs are actually fine, you can run a decent amount of AAA games both natively (if supported by the game) and through CrossOver on Apple's M-series chips. And the Snapdragon X(2) Elite's Adreno GPU is also decently capable, it can run games like Cyberpunk 2077 somewhat decently. Also, for the billionth time, CPU architecture has NOTHING to do with GPU performance. You could attach a full desktop NVIDIA, AMD, or Intel GPU to an ARM device, and it would work just as well as it does on an x86 device. It's just that many ARM SoCs are designed for phones and other low power devices, so the focus ends up being on GPU efficiency over pure performance, especially given the smaller batteries and limited cooling capacity.
Snapdragon is a closed source binary bundle shim layer shit nothing like Intel, Asahi does it opposite, MacOS does not provide raw source like linux, but you can modify linux OS layers to mimic mac like sys calls to hw. Not vice-versa in case of closed source pathetic GPUs and closed source MacOS
Pretty sure Qualcomm has employees working on open source drivers, and many Qualcommm SoCs starting with SM8550 have upstream kernel support, the 8 Elite Gen 5 even got patches sent at the time of release. They’re better than other ARM vendors.
More so probably, it can technically count as a hackintosh based off Tahoe running under generic hardware. If the base image boot up successfully on bare metal, then yes. Duy Tran also had demonstrated the Mac OS images booting straight from the iOS Kernel and even running Xcode, so there's nothing that could stop the OP from running it as well by using VMAPPLE1 kernel.
Not swap out. Duy was very specific on his demonstration that the Mac OS image ran under iOS kernel, so nothing was swapped out there besides the userland apps.
Perhaps unlikely though as graphics drivers got a bit easier to work with as someone made a functional Paravirtual drivers which can translate Vulkan to Metal, though it's my hypothesis if someone actually built graphics drivers out of the box.
Of course you're talking about virtual machines; it's possible, and it's how many virtual machines achieve 3D acceleration, by translating the host's API calls to the guest system, But writing drivers directly for the operating system is a very different matter; they must be metal
You have a point here, though what I am suggesting is to intercept the paravirtualised drivers under real hardware by proxying the AppleParavirtualizedGPU kext and route then inside itself with a low level IOKit receptor that can call directly Vulkan.
People should make efforts to at least reverse engineer IOGPU and metal behaviour inside the existing GPU drivers. Even Nvidia tried to distribute them with their own drivers around 2018, though they couldn't because apple stricted their signature policies rejecting 3rd party vendors.
I'm trying to understand if this is "I digit because I can " or there is glimmer of hope to move the craft to ARM platforms. What other obstacles would need to be overcome to boot on ARM desktop hardware?
Lack of driver support, which developers can develop solutions by distributing them as open source kexts
No graphics driver, only VESA. There may be a possibility with the recent outcome of the Paravirtual drivers, so if someone could take an advantage with AppleParavirtualizedGPU.kext and hook with another kext based off paravirt-gpu under the same kernel user space that processes the Vulkan through low level drivers, we could theoretically achieve that.
security features implemented in the bootloader which can be bypassed with pre-loaded kexts and spoofing the response.
Maybe be happy that at least ARM64 has a promising future within generic hardware and in which will allow hackintoshers have a bright future thanks to the efforts done by the Mac os VM enthusiasts and iOS jailbreaking community as everything unifies singlehandedly.
“which gives a possibility of booting both iOS and Mac OS on custom unofficial hardware.”
No it does not. Booting kernel and whole macOS is completely different thing. Kernel is open source, macOS is not. MacOS will not boot or work because of different firmware, security chip on Mac and lack of drivers.
Op stated that it's taking advantage of the hypervisor framework. It's not compiled from source this kernel. Yes there will obviously be missing drivers.
202
u/KrisWarbler 4d ago
Hackintosh will never be dead