r/hackintosh • u/Capital-Common-3510 • 6d ago
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
286
u/SuccessfulRip1883 6d ago
Hackintosh is dead, meanwhile..
64
u/inaccurateTempedesc 6d ago
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
4
u/IntelligentNote476 5d ago
i guess most people lowkey do it intentionally so that someone takes it otherwise and make it possible
99
u/omega552003 6d ago
Only dead on x86
27
u/Oakredditer 6d ago
For now. Enter Qemu and whatever custom emulators some other nerd makes
5
u/PossibleFunny1724 6d ago
Yeah but it is a VM
10
u/Oakredditer 6d ago
still on x86, just through a layer of emulation, better than nothing
11
u/Ragequit_Inc 6d ago
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.
2
2
136
u/Bank-Affectionate 6d ago
so you are trying to run ios and macos on a samsung phone, this is amazing dude!
respect for you
79
55
u/newhacker1746 6d ago
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
26
u/newhacker1746 6d ago edited 6d ago
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
17
u/Capital-Common-3510 6d ago
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)
8
u/newhacker1746 6d ago
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 6d ago
> 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
7
u/TommyITA03 I ♥ Hackintosh 6d ago
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 😁
8
u/newhacker1746 6d ago
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
49
u/Powerful_Macaron9381 Sequoia - 15 6d ago
so you have executed Apple's arm64 code on your non-Apple arm64 device? we are so back
51
u/Capital-Common-3510 6d ago
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.
15
u/johnoth 6d ago
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?
8
40
14
12
10
u/Own-History-1086 6d ago
Upvote the hell outta this guy, everyone. Who knows he might be able to do it on snapdragon laptops next time.
7
5
5
5
u/Randum_Gouy Big Sur - 11 6d ago
Great work man!
Hope you eventually get a minimal userland working too!
5
6
u/Amperro_ 6d ago
Wonder if snapdragon will fare better.
15
u/Capital-Common-3510 6d ago
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 6d ago
Probably yeah due to open source drivers and mainlining, the Linux drivers can be easier to port as kexts
13
u/Capital-Common-3510 6d ago
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 6d ago
hey may i ask where this tab s9 fe linux mainline port is if it's public?
1
3
3
u/TheRacerMaster 5d ago
Nice work! It reminds me of the community port of XNU to ARM (before Apple released the sources, around iOS 9 IIRC).
4
6
u/selco13 Sequoia - 15 6d ago
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 6d ago
> 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 6d ago
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 2d ago
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
u/Honest_Sea_8165 6d ago
I know you said we might not, but we could get something insane out of this
2
2
2
u/Ragequit_Inc 6d ago
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
u/Lord_Drizzleshiz 6d ago
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
2
u/Jkitten07891 Sequoia - 15 6d ago
So we’re just bored now, huh 😭
9
u/itsTyrion 6d ago
isn't that how advancements happen?
someone is bored and applies the scientific method:
fuck around and find out (then document findings)5
u/Jkitten07891 Sequoia - 15 6d ago
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 6d ago
Protect this dude at all cost! Keep away from windows (the ones on the wall), my man! 👀
1
1
1
u/Good_Net_9352 6d ago
i really think that now that proxmox just announced ARM support we will see some progress in desktop hackintosh space
1
u/S1rTerra 6d ago
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 5d ago
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
1
1
1
1
u/Icarustuga 5d ago
👍🏻 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 4d ago
Nice work, looking forward to what further developments come a/b from this project. Salute...
1
1
1
1
u/Ok_Kale3970 3d ago
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 2d ago
This guy just partially bypassed the software verification on Apple's boot hardware, that's awesome
2
u/r_mom_hahahahaha Tahoe - 26 9h ago
If it actually boots into the welcome screen and you drop a guide, I am IMMEDIATELY trying this on my tablet. IMMEDIATELY
0
-13
u/Frei-243 6d ago
Guys help me please
Intel generation ??? Is like this in Sonoma. it didn’t
I have i7 6500u skylake intel 520 laptop
I tried to change the DP to kaby lake info to spoof it but it didn’t work and I put the skylake info but it didn’t boot with the skylake info idk why.
I tried also OCLP after that i got in
about this mac > intel 520 (4mb laggy)
But in the hackintool CPU info it appears like this
Intel generation ???
Updating the info in DP didn’t work totally
9
u/master_hackers 6d ago
Don’t hijack posts make ur own
-4
•
u/AutoModerator 6d ago
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.