osy / polaris22fixup Goto Github PK
View Code? Open in Web Editor NEWMetal driver patches for Vega M
License: MIT License
Metal driver patches for Vega M
License: MIT License
With 11.0 macOS no longer has frameworks and the dyld shared cache now resides in /System without the descriptions of the address ranges in a textual format like before. There will be updates needed to get things working for both this kext and Lilu itself, with likely changes in the entire userspace APIs for Lilu on 11.0 and newer.
I still do not have a good idea what is the best approach here. Since various issues were reported with dyld shared cache patching in the past and since Polaris22Fixup uses an entirely separate way of patching, I wonder if you could suggest something for 11.0? That would benefit all the sides and integrate them better.
My primary concern is doing symbolic patching as I believe doing memory searching for hex-patching is rather slow and error-prone. However, the changes in 11.0 allowed us to avoid reading files from rootfs effectively improving the overall performance. I wonder if it is possible to keep that with userspace patching too.
Following Xcode update to 11.4 the kext compiles fine but produces an immediate kernel panic on Catalina 10.15.4 running on a NUC8i7HNK. Here is the report:
`panic(cpu 6 caller 0xffffff8010a4c32a): Kernel trap at 0xffffff7f95c79759, type 13=general protection, registers:
CR0: 0x000000008001003b, CR2: 0xffffff83ae7c6000, CR3: 0x00000001e22a0001, CR4: 0x00000000003626e0
RAX: 0x00e3a791903d00e6, RBX: 0xffffff8050753d00, RCX: 0xffffff80507c2000, RDX: 0x0000000000000000
RSP: 0xffffff83c201b148, RBP: 0xffffff83c201b5d0, RSI: 0x0000000000000000, RDI: 0xffffff8050753d00
R8: 0x0000000000001000, R9: 0xffffff83c201b720, R10: 0x0000000000000480, R11: 0xffffff804b155000
R12: 0xffffff80507c2000, R13: 0x0000000000000000, R14: 0xffffff80507c1360, R15: 0x0000000000001000
RFL: 0x0000000000010286, RIP: 0xffffff7f95c79759, CS: 0x0000000000000008, SS: 0x0000000000000000
Fault CR2: 0xffffff83ae7c6000, Error code: 0x0000000000000000, Fault CPU: 0x6, PL: 0, VF: 0
Backtrace (CPU 6), Frame : Return Address
0xffffff8010754220 : 0xffffff80109215cd mach_kernel : _handle_debugger_trap + 0x49d
0xffffff8010754270 : 0xffffff8010a5a3c5 mach_kernel : _kdp_i386_trap + 0x155
0xffffff80107542b0 : 0xffffff8010a4bf7e mach_kernel : _kernel_trap + 0x4ee
0xffffff8010754300 : 0xffffff80108c7a40 mach_kernel : _return_from_trap + 0xe0
0xffffff8010754320 : 0xffffff8010920c97 mach_kernel : _DebuggerTrapWithState + 0x17
0xffffff8010754420 : 0xffffff8010921087 mach_kernel : _panic_trap_to_debugger + 0x227
0xffffff8010754470 : 0xffffff80110c2c7c mach_kernel : _panic + 0x54
0xffffff80107544e0 : 0xffffff8010a4c32a mach_kernel : _sync_iss_to_iks + 0x2aa
0xffffff8010754660 : 0xffffff8010a4c028 mach_kernel : _kernel_trap + 0x598
0xffffff80107546b0 : 0xffffff80108c7a40 mach_kernel : _return_from_trap + 0xe0
0xffffff80107546d0 : 0xffffff7f95c79759 com.osy86.Polaris22MetalFixup : __ZL17gTrampolineToOrig
0xffffff83c201b5d0 : 0xffffff8010ef77f7 mach_kernel : _load_machfile + 0x1ae7
0xffffff83c201b900 : 0xffffff8010ef5fb9 mach_kernel : _load_machfile + 0x2a9
0xffffff83c201b9c0 : 0xffffff8010e60e03 mach_kernel : _kctl_fill_socketinfo + 0xd03
0xffffff83c201bd70 : 0xffffff8010e68c4e mach_kernel : _posix_spawn + 0x3efe
0xffffff83c201bdf0 : 0xffffff8010e69de2 mach_kernel : ___mac_execve + 0x372
0xffffff83c201be90 : 0xffffff8010e6a37b mach_kernel : _load_init_program + 0x1db
0xffffff83c201bf00 : 0xffffff8010e2f10d mach_kernel : _bsdinit_task + 0x6d
0xffffff83c201bf20 : 0xffffff8010918f29 mach_kernel : _ast_taken_user + 0x119
0xffffff83c201bf60 : 0xffffff80108c7a0c mach_kernel : _return_from_trap + 0xac
Kernel Extensions in backtrace:
com.osy86.Polaris22MetalFixup(1.0)[0E6AF29A-E5AA-39F2-97C8-17BAB86085D9]@0xffffff7f95c78000->0xffffff7f95c7ffff
BSD process name corresponding to current thread: init
Boot args: mbasd=1 alcid=11 shikigva=80 keepsyms=1
Mac OS version:
Not yet set
Kernel version:
Darwin Kernel Version 19.4.0: Wed Mar 4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64
Kernel UUID: AB0AA7EE-3D03-3C21-91AD-5719D79D7AF6
Kernel slide: 0x0000000010600000
Kernel text base: 0xffffff8010800000
__HIB text base: 0xffffff8010700000
System model name: Macmini8,1 (Mac-7BA5B2DFE22DDD8C)
System shutdown begun: NO
Panic diags file available: NO (0xe00002d8)
System uptime in nanoseconds: 825855433`
Happy to help with testing etc.
(NUC8i7HVK, Vega M GH)
The Kernel-Extension seems to be not working with the first Developer Beta of macOS Ventura and needs to be updated.
I was successful to install Ventura on the Hades Canyon with a pre-Alpha OpenCore 0.8.2 build and AvoidRuntimeDefrag
enabled but I discovered that it initially went to a black screen after IOConsoleUsers
(last line of verbose, related to graphics).
After disabling the Kext and GpuSpoof I could boot at least without graphics acceleration (meaning VESA, 7 MB VRAM).
I'm up for everything if you need a tester.
Hi Osy,
Thanks for all the great work you have done over the last 2 years to enable macOS to run on the Hades Canyon NUC. I have been trying to get graphics acceleration working in Monterey Beta 4 using my fork of Polaris22Fixup which can be found here:
https://github.com/dgsga/Polaris22Fixup
All I have done with the fork is to update the code to remove legacy OS support and use the new Lilu API's introduced in version 1.5.1. In Monterey the dyld cache is split into four parts, hence the need to update the repo.
This fork works fine in BigSur 11.5.1 but in Monterey I get a glitch-free desktop but no graphics acceleration. All relevant kexts show as loaded. I have attached a full Lilu log showing the failure (highlighted in red) to patch PECI_IsEarlySAMUInitEnabled.
Lilu_1.5.6_21.0.rtf.zip.
In the ioreg device tree:
IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/PEG0@1/IOPP/GFX0@0/AMDRadeonX4000_AMDEllesmereGraphicsAccelerator is missing.
Lilu 1.5.1 introduces lots of methods and apis that have been adopted in this patch:
So I guess there's no need to maintain those implementations in this repo?
Because we hook cs_validate_range
as well as Lilu (when user patches are used), this would cause issues including the order of the hooks and when one plugin decides to remove the hooks.
An ideal solution would be to detect if Lilu is available, make sure to always load after Lilu, and then patch using Lilu when detected.
We require a hacked-up version of Lilu that skips the memcmp for the patcher storage to get around an annoying bug that prevents the shared cache from being patched.
This issue is also tracked: acidanthera/bugtracker#390
is this lilu.kext update need or 10.15 only work?
Currently, we do not disassemble the original function. We hard code a "safe" length of code to save ("safe" as in we do not copy half an instruction) and then we copy that code elsewhere and execute it before jumping to the original implementation when attempting to call back into the original function.
This will fail if, in the future, the function changes and the hard coded length is no longer safe. Additionally, if a relative jmp is added to the first couple of bytes in the future, it will also fail.
The likelihood for either case is slim but still a possibility. Ideally we use something like libsubstitute and disassemble the instruction and optionally rewrite relative jumps into absolute jumps.
IDK if it has something to do with the kext in this issue. My device is beelinks’s turbo g7 with 8709g. The device works properly at Big Sur 11.2 so I tried to install Monterey b4. I used to successfully install monterey on another laptop(uhd630) but this time it fails after all procedures finished. I can open the install disk, the installation goes well, but after the last reboot and the progress bar runs full, it turns out black screen and only the mouse pointer can move.
Edit: I was able to get it to boot in safe-mode once with no wallpaper or acceleration but normal mode just says "Check device power" on my monitor or is blank
Not sure if it's this or something else but it seems to be an issue for the NUC8I7HVK with PolarisFixUp 🤔
I'm running macos via kvm on a hades canyon 8i7hvk
with the VegaM passed through to Osx via vfio,
I can fake the PID and inject ATI and get the Card to display
But I can't get the card to display with just the simple
4GcAAA==
patch...
I try to apply it to PciRoot(0x0)\Pci(0x2,0x0)\Pci(0x0,0x0)
which is the PCID of the Card inside the VM but I can't get it to work.
Also Polaris is the issue I really have, since Faking the ID and injecting ATI seems to work
(with no audio atm, also don't really know why...)
please see my bootlog here:
https://paste.ubuntu.com/p/pT6wR5HK6C/
and the bootlog without injection:
https://paste.ubuntu.com/p/WJHfTjc68Y/
I hope you can give me some insight to this
edit: I got the video patch working now but polaris doesn't seem to get patched, I still see artefacts
edit2: hdmi with audio works fine, had the wrong pci bus set for vfio
everything runs fine, except for the polarisfix :/
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.