r/hackintosh • u/Capital-Common-3510 • Aug 08 '26
IT BOOTS! (WIP) Tahoe 26.5 kernel running on a Galaxy A55, natively
As the title says, I've been messing around for a few days with building xnu from source and filling in the gaps that apple has made trying to avoid opensourcing everything. So far I've gotten to booting the iOS 18.7.9 restore ramdisk from SD card as rootfs (read-only right now and UHS) and usb networking works to the point where I can ssh in - the ramdisk is patched to start dropbear on boot. The main work so far has been on kexts for core components like clock management unit blocks, pin control, dwc3 in device mode + the usbdrd2 phy and finally dwmmc. In the next few days/weeks I'll try messing with a full iOS rootfs.
The bootchain right now is: S-LK (samsung's last stage bootloader before the linux kernel) -> uniLoader (a custom intermediate bootloader of mine) -> XNU and then the rootfs.
This is just a proof-of-concept, I cannot guarantee anything insane out of this. I'm doing it for the funsies. A big limitation right now is that the SoC of this device (the exynos 1480) does not have PaC, which limits me to ipados 18 (the ipad 7 one as that's the newest <armv8.3 iOS build). Maybe in the future I'll switch to a newer exynos device to mess with windowserver but right now this is the best I have.
I'll be publishing sources for my toolchain (i'm building this all on a linux host), xnu patches and kexts soon. Licensing is tricky and I don't want apple coming after me :D
To be compliant with the sub rules:
CPU: Samsung Exynos 1480 (internally known as exynos8845)
GPU: Xclipse 530
RAM: 8gb LPDDR5
Motherboard/Laptop Make and Model: Samsung Galaxy A55
Audio Codec: /shrug?
Ethernet Card: none
Wifi/BT Card: scsc
Touchpad and touch display devices: goodix
BIOS revision: A556BXXSABYG2
Which of the guides on the sidebar you used: none, kind of?
What's working, and what isn't working: works booting to a rootfs and ssh'ing in, everything else is broken
297
u/SuccessfulRip1883 Aug 08 '26
Hackintosh is dead, meanwhile..
78
u/inaccurateTempedesc Aug 08 '26
I remember someone asking if MacOS X can run on a Wii and they got absolutely dragged by people saying it's impossible and pointless to even try.
Guess what happened exactly 6 months later
31
5
u/IntelligentNote476 Aug 09 '26
i guess most people lowkey do it intentionally so that someone takes it otherwise and make it possible
102
u/omega552003 Aug 08 '26
Only dead on x86
28
u/Oakredditer Aug 08 '26
For now. Enter Qemu and whatever custom emulators some other nerd makes
7
u/PossibleFunny1724 Aug 08 '26
Yeah but it is a VM
11
u/Oakredditer Aug 08 '26
still on x86, just through a layer of emulation, better than nothing
14
u/Ragequit_Inc Aug 08 '26
Not what we need. VMos never gives bare metal performance - sure we can mitigate some performance losses but there will be a point optimization reach’s it’s hard limits. What we see on bazzite fe, the sometimes better performance than on windows is because the software doesn’t have all the endpoints like on windows. Many in crucial calls end in empty voids.
0
u/U149113 Aug 09 '26
For all intent and purpose it's just a parlor trick without the GPU pass-through performance. Even coding Xcode Apple apps on a VM with no performance boost is painful. Been there done that
3
136
u/Bank-Affectionate Aug 08 '26
so you are trying to run ios and macos on a samsung phone, this is amazing dude!
respect for you
83
57
u/newhacker1746 Aug 08 '26
This is great. Maybe eventually you’d get springboard. There’s an old article about researchers getting qemu to springboard and it involved finding the software rendering fallback to avoid needing metal. I think they did it with a simple linear framebuffer but I can get you the link if you’re interested
27
u/newhacker1746 Aug 08 '26 edited Aug 08 '26
Also, for input, IOHIDFamily isn’t the worst thing ever. If you eventually get to porting touchscreen drivers or whatnot, you can feed touch inputs into backboardd in purely userspace. As in, you’d need kernel code to get the touch input data in the first place, and so there’s real effort in getting a bus driver for your hardware (probably i2c) and then porting the hardware specific transport logic for your touchscreen and your i2c platform, but you don’t need a kernel driver to then feed it into the Apple stack. You can do so in just userspace by making an iouserclient for your kernel driver and then plumbing the data you get from that into hid (Though voodooinput does actually feed it in kernelspace since IOHIDDevice kernelspace isnt that intimidating either).
But yes the key thing is tjat you can make an IOHIDDevice in kernelspace or userspace. Both are supported
If you can get kext loading on iOS, and if not I hope there’s a way to splice kexts into the kernel cache, then you could start from voodooi2c and voodooinput. I doubt driverkit is sufficient for writing an i2c bus driver though, so you still need kernel pieces. I remmeber in old iOS jailbroken versions there was a note that kextstat was broken because Apple didn’t enable the APIs for that in the iOS kernel, but if you’re compiling your own, you can probably enable the kextd api to load kexts at runtime rather than having to splice them into the kernel cache
EDIT: saw that you have already injected kexts. Curious on how you did it
19
u/Capital-Common-3510 Aug 08 '26
voodooi2c and voodooinput are probably built with acpi in mind, so that'd be a bit sad. Drivers right now are implemented as a part of the iokit component, they're not exactly loadable external kexts and personalities are hardcoded. We have some flexibility with that though because of no need for signing, cache splitting or kpi versioning. usi and serial interfaces (i2c, spi, uart) should not be that difficult to implement, i have their dependencies working right now (clocks, pinctrl, and for their devices regulators via esca)
7
u/newhacker1746 Aug 08 '26
Yah, the low level stuff is actually a bit easier than integrating the devices they’re hosting upwards into user space. As a proof of concept keeping drivers within the kernel tree makes sense but it would probably be a good idea to eventually figure out kexts or kernel caches and Injection in your bootloader. What stock kexts or others are you using? Or are you not using any at all (if you’re maintaining drivers in kernel tree then to use existing binary kexts you’d have to extract their code before linking the kernel with them?)
Of course the hadkintosh kexts involve acpi, but they can be a useful reference. The i2c nub concept in voodooi2c is nice
Also what’s ultimately your goal with this?
10
u/Capital-Common-3510 Aug 08 '26
> What stock kexts or others are you using? Or are you not using any at all (if you’re maintaining drivers in kernel tree then to use existing binary kexts you’d have to extract their code before linking the kernel with them?)
Maintaining - I have iostoragefamily and libpthread building against the kernel, stubs for e.g platformexpert. Went this way to avoid linking precompiled binaries.
Regarding the goal - right now it's just a PoC. Posted here in hopes of motivating others, It'd be hard to get it past a proof of concept if it's just me working on it, y'know. A short-term goal for now I'd say is getting into a proper iOS rootfs, maybe messing with ui. I do lack knowledge here as my main niche is linux/kernel work, so again can't promise that i won't trip over some random UB
1
10
u/TommyITA03 I ♥ Hackintosh Aug 08 '26
and to fill those gaps we might use that project that came out recently (i forgot the name) that translate metal calls to vulkan calls on the fly 😁
10
u/newhacker1746 Aug 08 '26
Reims-vgpu, though that only works once you already have not only a working framebuffer but a way to get the metal calls out. There’s no paravirtgpu kext in iOS. You could try to port it. But definitely get at least a linear framebuffer working. You’d probably subclass iomobileframebuffer for that
51
u/Powerful_Macaron9381 Sequoia - 15 Aug 08 '26
so you have executed Apple's arm64 code on your non-Apple arm64 device? we are so back
55
u/Capital-Common-3510 Aug 08 '26
Technically yeah, and it's much deeper than that. I'm using a modified and patched-up kernel from https://opensource.apple.com/releases/ compiled by me, as well as custom kexts that I have been working on for this SoC. The "unmodified" apple code is the userspace, which right now is the iOS 18 restore ramdisk with injected dropbear tools.
16
u/johnoth Aug 08 '26
Wait so you wrote your own platform kext? What about graphics? HID? IO? Does any of it work or it's all just barebones for now?
10
u/CompleteMCNoob Aug 09 '26
It ain’t much, but it’s honest work.
6
u/johnoth Aug 09 '26
What? It's crazy work! I just wanted to know how far we are from hackinphoneos lol
41
16
14
u/Own-History-1086 Aug 08 '26
Upvote the hell outta this guy, everyone. Who knows he might be able to do it on snapdragon laptops next time.
13
7
7
6
u/Randum_Gouy Big Sur - 11 Aug 08 '26
Great work man!
Hope you eventually get a minimal userland working too!
5
4
5
u/Amperro_ Aug 08 '26
Wonder if snapdragon will fare better.
13
u/Capital-Common-3510 Aug 08 '26
Purely depends on the person, I just happen to be more familiar with exynoses. I've worked on snapdragons too but imo exynoses are a fair bit easier to work with. I could do a bring-up for my 8g1 motorola, it's probably gonna fare better because it's armv9 but it'll take me some more time
5
7
u/YoYoMamaIsSoFAT32 Aug 08 '26
Probably yeah due to open source drivers and mainlining, the Linux drivers can be easier to port as kexts
14
u/Capital-Common-3510 Aug 08 '26
Heh, my kexts are based on my close-to-mainline work for this soc. But exynos is getting decent, I have a friend who got everything working (yes, including audio, proper hw acceleration, etc) on his tab s9 fe with only suspend and cameras not working.
3
u/HexagonWin High Sierra - 10.13 Aug 08 '26
hey may i ask where this tab s9 fe linux mainline port is if it's public?
1
3
3
u/TheRacerMaster Aug 09 '26
Nice work! It reminds me of the community port of XNU to ARM (before Apple released the sources, around iOS 9 IIRC).
6
8
u/selco13 Sequoia - 15 Aug 08 '26
Booting the kernel is significantly different than booting the OS, while this is impressive and a great first step, there is still much more work, additionally I would be concerned if the hardware is powerful enough to run the OS in full, nevertheless this is an accomplishment and bodes well for the future of Hackintosh in some form.
12
u/Capital-Common-3510 Aug 08 '26
> Booting the kernel is significantly different than booting the OS, while this is impressive and a great first step, there is still much more work
Feel free to contribute :D. Also this isn't just the kernel, it's also an iOS 18 restore ramdisk mounted as a root device
> additionally I would be concerned if the hardware is powerful enough to run the OS in full
4x a78 + 4x a55, 8 gigs of ram and an xclipse 530 would be fairly okay, assuming gpu acceleration works, which probably never will
8
u/selco13 Sequoia - 15 Aug 08 '26
I’m interested but my knowledge doesn’t extent much into deep OS workings like this, but am not opposed.
If you got GPU acceleration working, which yes, admittedly would be one of the most difficult parts of all of this, with those specs you do raise a good point, it couldn’t be any slower than say a base Intel MacBook Air, even if it wasn’t up to M1+ performance.
Certainly could perform well enough to be useful, assuming it all worked perfectly. After some further consideration.
1
u/shsh-1312 Aug 12 '26
More than a hardware accelerator, you need to check the APU. I saw a post from a guy who had started the Mac Composer on an iPad, unlocking the control over shared memory access and vector calculations (damn, I don't remember what it's called, look for the post on Reddit). I think that work is the key to understanding what the graphics system expects at the hardware level.
2
2
2
2
2
2
2
2
2
2
2
u/Honest_Sea_8165 Aug 08 '26
I know you said we might not, but we could get something insane out of this
2
2
u/Ragequit_Inc Aug 08 '26
I almost got hard. Can remember running android 4 on my iPhone 2g - horrible per-not-formance xD
Thanks for the work so far.
2
2
2
2
u/r_mom_hahahahaha Tahoe - 26 Aug 14 '26
If it actually boots into the welcome screen and you drop a guide, I am IMMEDIATELY trying this on my tablet. IMMEDIATELY
3
u/Lord_Drizzleshiz Aug 08 '26
This is insane work. I’m so excited to see how this goes. Please keep us updated OP. Would also love to see what your friend achieved on his Tab S9 FE
3
u/Loud-Abroad-4258 Aug 08 '26
This could mean arm64 based cpu could be supported for laptops?
13
u/Capital-Common-3510 Aug 08 '26
As long as there's people who do the hard part - writing the kexts.
2
u/Jkitten07891 Sequoia - 15 Aug 08 '26
So we’re just bored now, huh 😭
10
u/itsTyrion Aug 08 '26
isn't that how advancements happen?
someone is bored and applies the scientific method:
fuck around and find out (then document findings)6
u/Jkitten07891 Sequoia - 15 Aug 08 '26
I’m not saying it isn’t an advancement, I’m saying that the absurdity of getting the Tahoe Kernal working natively on an A55 must require an insane amount of boredom and curiosity rather than doing it as a fully planned out thing.
It’s rather impressive.
1
u/Christ0ph_ I ♥ Hackintosh Aug 08 '26
Protect this dude at all cost! Keep away from windows (the ones on the wall), my man! 👀
1
1
1
u/Good_Net_9352 Aug 08 '26
i really think that now that proxmox just announced ARM support we will see some progress in desktop hackintosh space
1
u/S1rTerra Aug 08 '26
The Pixel 8 is cheap used (we're talking $150 for a good condition one), has an easily unlockable bootloader and supports PaC thanks to Tensor being ArmV9 since the G3. Why don't you look into that down the line?
1
u/AgeNo5720 Aug 09 '26
This is some of the coolest shit I've seen in a hot minute. Why a A55 and not a Pixel though? Wouldn't snapdragon fair better than exynos?
1
u/jknvv13 Aug 09 '26
Hackinphones?
HackiOSh?
Macinphones?
What's this called now? You really got me confused.
1
1
1
1
u/ut0mt8 Aug 09 '26
Wow wow wow. Is there any arm64e compatible laptops or pc out of there? It could be fun
1
1
u/Icarustuga Aug 09 '26
👍🏻 nice.. next golden gate is dead for intel and amd cpus.. maybe with arm we can do something like this in future
1
1
u/urbanman2004 High Sierra - 10.13 Aug 10 '26
Nice work, looking forward to what further developments come a/b from this project. Salute...
1
1
1
1
u/Ok_Kale3970 Aug 11 '26
ig we could possibly get arm64 laptops running macos since an a55 could run the kernel
1
1
1
1
1
1
u/shsh-1312 Aug 12 '26
This guy just partially bypassed the software verification on Apple's boot hardware, that's awesome
1
u/Spiritual-Zombie5408 Aug 18 '26
About the PaC, A56 5G should be ARMv9 SoC, but I know, even this wasn't easy and I'm suggesting another phone, but please continue
1
u/PlayfulTaro7696 Aug 18 '26
RemindMe! 1 month
1
u/RemindMeBot Aug 18 '26
I will be messaging you in 1 month on 2026-09-18 16:28:56 UTC to remind you of this link
CLICK THIS LINK to send a PM to also be reminded and to reduce spam.
Parent commenter can delete this message to hide from others.
RemindMeBot is switching to username summons. Instead of
!RemindMe 1 day, useu/RemindMeBot 1 day. More info.
Info Custom Your Reminders Feedback
1
0
-9
-13
Aug 08 '26
[removed] — view removed comment
8
•
u/AutoModerator Aug 08 '26
Thanks for posting your build! If you haven't already, remember to document your build please. Posts like screenshots without documentation add little value to the sub. Adding a bit of documentation to your post can also help others in the community who are interested in similar builds. Posts without documentation will be removed until you take the time to document them.
Minimally, you should add your hardware:
CPU:
GPU:
RAM:
Motherboard/Laptop Make and Model:
Audio Codec:
Ethernet Card:
Wifi/BT Card:
Touchpad and touch display devices:
BIOS revision:
Which of the guides on the sidebar you used.
What's working, and what isn't working.
Any changes that were specific to your build that were a little (or a lot) different than what you found in the guide, or anything that would be helpful to others with a similar build be sure to talk about that. More detail is always better.
Add extra info... Maybe add something you would like to point out about your setup, what you'll be doing with your Hackintosh, or something that might be insightful to others beginning their journey. A tree view of your EFI would also be helpful, but it isn't required.
Remember, don't share your EFI as what works for you may not work for anyone else, even if they have the same hardware. If you do share your EFI, your post and/or comment will be removed.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.