Asus-X505ZA-Ryzen-Hackintosh
Asus-X505ZA-Ryzen-Hackintosh copied to clipboard
mvaisakh
Hardware Graphics Acceleration on Vega 8
Vega 8 Graphics is not supported by Apple, but most of the init code and code needed to get acceleration working is already present in their kexts. Also being an integrated GPU and new kind of architechture it makes it a challenge to get this working.
Since this laptop is not shipped with a dedicated GPU (if there was one, it would have been a lot easier to hackintosh!), it lags and becomes unusable for day to day tasks. To get it to work, I first need to fix HW Acceleration on Radeon Vega 8. This thread can be used for discussing about other Ryzen APUs as well.
Any help is appreciated!
I need the full EFI, but I'm almost sure that Radeon 8 is not compatible. Your audio will work normal, touchpad I still want to see about, I also need an AIDA64 report.
Edit1: yes, radeon 8 is not compatible, switch to RX560, 570 or 580 Touchpad probably is i2c ELAN or Synaptics.
Edit2: ohhh, is notebook. sorry. I'm sad for you.
Edit3: Remember that ryzen notebooks also do not work. Desktops only. My recommendation is that you mount full intel. Ryzentosh also has its problems. Intel are easier to fix.
Edit4: my notebook is i3-7020U and 16gb RAM, full working on HD Graphics 620. She is not good at playing. But for work it is efficient (apart from video processing). But it is interesting to build cheaper machines.
Well, I've been working on this since the past week. I know Ryzen Laptops aren't supported, I'm trying to break the taboo.
Why do I say so?
Here's the proof!
There's GPU init code for Raven Ridge (Commonly known as the Vega Integrated GPUs) in AMDRadeonX5000HWLibs Kext:
Even has the SMU code loading feature
I've tried spoofing the GPU IDs from Vega 10, 12 and 20 (Because they use these kexts), but either it goes into endless verbose loop (which I was able to fix with injecting VBIOS and FB Limit) or it doesn't work at all. WEG manages to load them but they don't seem to load after the boot finishes (No clue as to why).
The only new line that I could find on verbose after spoofing the GPU to GCN 5 GPU ID was
AGDCC: Unauthorized client 'PerfPowerService' ( IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/GP17@8,1/IOPP/GFX0@0/AMD10000ControllerWrangler)
Now I'm not sure as to how I'd be able to init AMDRadeonX5000 kexts, but if it does, I'm pretty sure HW Acceleration would work.
Update: So I managed to get a log about why the Kext wouldn't load, and guess what! It's only missing VRAM config. Guess I'm one more step closer to achieving acceleration, though I'm unsure how many more steps I'd need
As you can see it can't find the VRAM size (because it's shared from the system memory and does not have a dedicated VRAM)!....
I was reading on how VRAM can be increased on MacOS. I stumbled upon this page. https://apple.stackexchange.com/questions/79452/how-to-increase-graphics-memory-in-mac-os-running-as-a-client-in-vmware
Take a look at the file they are talking about. It might be helpful. I don't really have experience with Mac code.
I was reading on how VRAM can be increased on MacOS. I stumbled upon this page. https://apple.stackexchange.com/questions/79452/how-to-increase-graphics-memory-in-mac-os-running-as-a-client-in-vmware
Take a look at the file they are talking about. It might be helpful. I don't really have experience with Mac code.
Thanks for your reply! I really appreciate you joining this conversation! That looks like a Virtual Machine only restricted thing, since we're running it natively, this won't work for us. I saw a commit on Whatevergreen for calculating intel VRAM, so I'll be checking that out to see, how it's done on intel. Might as well check on Linux Kernel too.
We might have a lead on this issue. I was just searching the web for whatevergreen and vram allocation. I found these links with some code as well.
https://www.iatkos.in/2020/05/whatevergreen-igpu-vram-allocation-via.html https://www.reddit.com/r/hackintosh/comments/gp07ko/whatevergreen_igpu_vram_allocation_via/
We might have a lead on this issue. I was just searching the web for whatevergreen and vram allocation. I found these links with some code as well.
https://www.iatkos.in/2020/05/whatevergreen-igpu-vram-allocation-via.html https://www.reddit.com/r/hackintosh/comments/gp07ko/whatevergreen_igpu_vram_allocation_via/
The WEG method for iGPU vram allocation only works for Intel integrated. Well it can work on ours too, but I'm not sure how it'd enable Acceleration since it's void of all the init code (I'm referring to AppleIntelFB kexts). Unlike Intel processors, AMD APUs have different method of reserving a certain amount of vram from ram. As far as my research has gone, Intel uses dynamic memory allocation (accoriding to the need) and hence does not need fixed reserved value (which is why one can spoof over 2GB of vram on Intel integrated). Sadly, AMD hasn't done it that way making it difficult for us.
I have an idea though, I'll have to write up a kext (which I have no idea how) that'll patch a few functions namely _ttlIsApuDevice, _ttlIsRavenDevice (these are in AMDRadeonX5000HWLibs kext) and return them to true for actual HW initialisation.
These functions are major characters for our GPU initialisation. I'm guessing spoofing with Vega 10/12/20 PCI ID leads to these functions being returned as false, making laptop not boot on the Vega GPU (also considering the fact that VRAM is missing too).
So my guess here is that if those functions are returned true, it could solve both our VRAM and Graphics Acceleration problem (hopefully!)
Any help with this would be highly appreciated!
You should use X-Code for this. The Apple website offers a guide on how kexts are made. I can't exactly find a link but X-Code makes everything quite easy. You will also need to have a basic knowledge of C language programming as that is the language you have to write in.
Another Update!
On further investigation on how the code is called (where the init code for raven is etc.,), I found some interesting code. There's switch case which determines what device to initialise. I need to dig a bit more further so see what cases it's looking for (it's probably related to PCI ID, which is why Raven won't initialise). Here's the code piece according to Ghidra Decompiler:
switch(iVar6) { case 0x82: uVar10 = *(uint *)(pplVar1 + 2); if (uVar10 < 0x14) { ........additional code........... } break; default: return 10; case 0x87: local_58 = _PP_Tables_BackEnd_Initialize; local_40 = _PhwCz_Initialize; break; case 0x8d: uVar10 = *(uint *)(pplVar1 + 2); if (uVar10 < 0x14) { local_58 = _PPT_Vega10_BackEnd_Initialize; local_40 = _PhwVega10_Initialize; } else { if (uVar10 < 0x28) { local_58 = _PPT_Vega12_BackEnd_Initialize; local_40 = _PhwVega12_Initialize; } else { if (0x31 < uVar10) { plVar10 = *pplVar1; pcVar11 = "Unsupported ASIC for AI family"; pcVar14 = "0"; pcVar13 = "PHM_Initialize"; uVar12 = 0x3cb; goto LAB_0009c6d1; } local_58 = _PPT_Vega20_BackEnd_Initialize; local_40 = _PhwVega20_Initialize; } } break; case 0x8e: bVar17 = *(int *)(pplVar1 + 2) - 0x91U < 0x6e; local_40 = _PhwRaven_Initialize; if (bVar17) { local_40 = (code *)PTR__PhwRenoir_Initialize_00505068; } local_58 = _PPT_Raven_BackEnd_Initialize; if (bVar17) { local_58 = (code )PTR__PPT_Renoir_BackEnd_Initialize_00505010; } break; case 0x8f: local_58 = _PhwSoc15_PPTables_Initialize; LAB_0009bbbb: local_48 = _Phw_SwSmu_BackEnd_Initialize; local_40 = _PhwSoc15_Initialize; goto LAB_0009bcd3; case 0x90: if ((int *)(pplVar1 + 2) - 1U < 0xfe) { local_58 = _PP_Tables_BackEnd_Initialize; goto LAB_0009bbbb; ........additional code......... LAB_0009bcd3: _PHM_RegAccessInitialize(pplVar1); }
This might seem gibberish, but it seems like the key to what we're supposed to do next. What we need to focus is on this particular case:
case 0x8e: bVar17 = *(int *)(pplVar1 + 2) - 0x91U < 0x6e; local_40 = _PhwRaven_Initialize; if (bVar17) { local_40 = (code *)PTR__PhwRenoir_Initialize_00505068; } local_58 = _PPT_Raven_BackEnd_Initialize; if (bVar17) { local_58 = (code *)PTR__PPT_Renoir_BackEnd_Initialize_00505010; } break;
So what my guess here is, the case defaults to Vega10 switch case (because we spoof using that device id).
We have two options here:
- Hex edit to change our raven switch case to vega10 switch case
- Find this specific
iVar6(i.e., possibly the variable name) &case 0x8eand provide the proper return type for it.
I still ask for help from much more experienced developers than me on this regard (if they're interested to help) and it will be much appreciated.
P.S.: I was able to patch the previous function that I had mention (i.e., _ttlIsApuDevice), but to no avail.
Yet another update
So, after digging through an ocean of logs, I finally saw something that is actually related to our GPU not init-ing.
Fault 0x0 0 0 kernel: (IOAcceleratorFamily2) virtual bool IOGraphicsAccelerator2::start(IOService *): configureDevice failed
Fault 0x0 0 0 kernel: (IOAcceleratorFamily2) IOGraphicsAccelerator::start: Failure exit
So the kext isn't able to configure the GPU device (probably because we spoof with vega10 id [?])
So what we have to do is to find a way to get this device configured. I'm still thinking how..(?) Also algrey pointed out that it could probably mean that the controller is failing to load.
Any ideas on how we can move forward from here?
Yet another update
So I think I was looking in the wrong direction.
For proper VCN intitialisation, we should move to the Navi GPU kexts (AMDRadeonX6000), because they're VCN 2.0 based GPU, which is basically an extension to the existing VCN 1.0 extension. They share most of required HW code (atleast on the Linux Kernel)
The init code for Raven also exists on their HWLibs plugin kexts.
They share a lot of hardware similarities (based on VCN, shaders obviously differ) :
But, spoofing using the Navi10/14 PCI IDs leads to kernel panic, which I guess is because of Controller failing to load.
This is what the log says (not the clearest log I could get).
We have to somehow make the controller init and then move ahead with further debugging. If anyone has any ideas on how we could approach it, would be highly appreciated, because the more people are involved, more effectively we can tackle this!
For AMD CPU kernel patches I noticed the Penryn naming. Did you check with Algrey to see if this may be an issue? The Penryn doesn’t have IGpU that is useable in OSX. Is it possible to use a different CPU spoof? Skylake.
For AMD CPU kernel patches I noticed the Penryn naming. Did you check with Algrey to see if this may be an issue? The Penryn doesn’t have IGpU that is useable in OSX. Is it possible to use a different CPU spoof? Skylake.
Welcome Gigamaxx! Glad to have you in conversation here!
We can spoof to skylake (some amdosx users are already doing that because it gives a cpu perf boost according to some, not sure of it though) I'll check the skylake spoof in a bit.
I asked osy if he could take a look, guess he's not interested (probably he doesn't have the time/laptop/pc).
The NUC case was different because Vega M there was dGPU (even though it's claimed to be iGPU). They have dedicated VRAM. In our case we'll need to reserve it from the RAM and allocate it to the VRAM. I looked at Linux kernel documentation, and it says, "VRAM for APUs is carved from the BIOS", Now I'm really not sure if they're referring to Video BIOS or Motherboard BIOS (as some APUs can allocate vram from there, unfortunately most of the laptops can't). Needs insights from there too.
Yes those NUCs have HbM2 built in. I was able to spoof using the old Kernel in Mojave to KabyLake. It would load the Framebuffer but if I spoofed the ID into both kexts to get accelerators it would panic. So I was able to get the KabyLake Framebuffer loaded. For the NUCs they are using Polaris ID to spoof.
Very nice work you are doing this could be a major breakthrough if you can get it figured out.
Yes those NUCs have HbM2 built in. I was able to spoof using the old Kernel in Mojave to KabyLake. It would load the Framebuffer but if I spoofed the ID into both kexts to get accelerators it would panic. So I was able to get the KabyLake Framebuffer loaded. For the NUCs they are using Polaris ID to spoof. Very nice work you are doing this could be a major breakthrough if you can get it figured out.
Do you still have the panic log? Might help me breakdown my issue. Spoofing here doesn't panic (unless I'm using Navi IDs, which I thought would be the possible route to take, but nope, those kexts are majorly written for GFX10, while raven is GFX9, will have to fallback to vega10). The polaris and vega10 controllers have no verbose. Tried merging a lot of properties to get one.
I'm on Catalina though. Haven't tried Mojave.
No panic logs, I did this years ago. Unfortunately, work is very busy and my wife has me in remodel mode at home but if I get some time I will try to reproduce the spoofing on Mojave. I do no that it didn’t work in Catalina, just Mojave.
No panic logs, I did this years ago. Unfortunately, work is very busy and my wife has me in remodel mode at home but if I get some time I will try to reproduce the spoofing on Mojave. I do no that it didn’t work in Catalina, just Mojave.
Take your time man, no hurries. Thanks
So, after digging through an ocean of logs, I finally saw something that is actually related to our GPU not init-ing.
Fault 0x0 0 0 kernel: (IOAcceleratorFamily2) virtual bool IOGraphicsAccelerator2::start(IOService *): configureDevice failedFault 0x0 0 0 kernel: (IOAcceleratorFamily2) IOGraphicsAccelerator::start: Failure exitSo the kext isn't able to configure the GPU device (probably because we spoof with vega10 id [?])
After merging in a few properties through the ACPI, I don't seem to find this in the logs anymore. But, I don't find anything else either. I've seen many logs out there with actual kext debug (dmesg), but ig the boot verbose isn't very verbose after all. Dmesg could have the reason why the GPU won't init, if anyone has a clue to export dmesg after a certain amount of time after boot would be helpful. Or if we could view dmesg of a previous boot would help too.
I've searched for it, but couldn't find a possible way to do it. Everything points to log show command.
Also the vbios injection works fine and it is detected by the system, well atleast the first 3 digits (113) of the name are proper (my vbios has 113-RAVEN-<some number that I don't remember>), which means once the kexts load, connectors should be fine and hopefully VRAM (that's a big hope) too.
@mvaisakh : Can you please elaborate which properties you added through ACPI. I am seeing similar errors for my GPU which is completely irrelevant to this one but might help me fix. Thanks
Hi Team, this looks promising... and is the only thing stopping me from attempting a Ryzentosh laptop. Would the above be applicable for the Vega 6 family? I've got an ASUS ZenBook 14 with AMD Ryzen 5 4500U with Vega 6 graphics so keeping a close eye on this thread - happy to help out with testing where possible.
@mvaisakh : Can you please elaborate which properties you added through ACPI. I am seeing similar errors for my GPU which is completely irrelevant to this one but might help me fix. Thanks
Hi, sorry for the really late reply, I'll be uploading my ACPI decompiled files soon, you might want to wait until then, a I'm bit busy. Also the properties I merged were from WhateverGreen and AMD Kexts, setting a certain value that seemed proper to me. I don't know how it'd help you though.
Hi Team, this looks promising... and is the only thing stopping me from attempting a Ryzentosh laptop. Would the above be applicable for the Vega 6 family? I've got an ASUS ZenBook 14 with AMD Ryzen 5 4500U with Vega 6 graphics so keeping a close eye on this thread - happy to help out with testing where possible.
Since your APU is Renoir, I'm really not sure if it'd work, but I've seen similar symbols as Raven in the Kexts. So the chances are, let's say if Raven works, Renoir should too. But I'm not really sure about the CPU.
If you can, then try Dortania Guide for setting up for Mojave and try fetching a log for spoofed Kext.
So I think I was looking in the wrong direction. For proper VCN intitialisation, we should move to the Navi GPU kexts (AMDRadeonX6000), because they're VCN 2.0 based GPU, which is basically an extension to the existing VCN 1.0 extension. They share most of required HW code (atleast on the Linux Kernel) ....... https://github.com/mvaisakh/Asus-X505ZA-Ryzen-Hackintosh/issues/1#issuecomment-702274076
I wanted to clarify this, X6000 Kexts are not the direction that we should move forward to. Because the needed kexts don't have vcn specific symbols. The VCN specific symbols are present in the X5000 kexts, so X6000 Kexts are a no go.
@onlyhalfchinese here are the properties I merged, https://gist.github.com/mvaisakh/61e193b3319dc9a797d7c41045583947 As I said before, not sure how these will help you.
P.S.: I'm Spoofing Vega 10 in those properties.
@mvaisakh your work is revolutionary, do you have or planning to set up crowd funding for this project?
@mvaisakh your work is revolutionary, do you have or planning to set up crowd funding for this project?
As good as it sounds, I'm not doing this for money, nor do I need any. It's a side hobby and will be continuing as such. All I want from others is to join in the conversation and share their ideas!
@mvaisakh Got it! Well you certainly have my backing... I am not a techo, but keen to help where possible
Agreed.
Cheers Adam
Sent from my iPhone
On 28/10/2020, at 4:36 PM, jjz660 [email protected] wrote:
@mvaisakhhttps://github.com/mvaisakh Got it! Well you certainly have my backing... I am not a techo, but keen to help where possible
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/mvaisakh/Asus-X505ZA-Ryzen-Hackintosh/issues/1#issuecomment-717674560, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARQCB3IRYOSWYQCK624YWNDSM6GS5ANCNFSM4ROLGVCQ.
@mvaisakh good luck man. i hope that somehow gonna work, heh. That's will be more steps for futher investigations on AMD graphics (and maybe CPU too) side. At least, experimenting with that stuff was fun, heh :)
