Ryzen 7000 Testing
- Thread starter PoMpIs
- Start date
I’ve been testing a number of kernel patches on IOPCIFamily, but while they seem to take effect according to OpenCore logs, they don’t actually seem to take effect. For instance, I’ve patched configRead and extendedConfigRead in IOPCIDevice to bypass the check for Inactive state, but the functions still return 0xFFFF.
So I’m thinking of exploring other options…
Has anyone been able to compile the macOS Monterey kernel using the source code on GitHub?
I’ve made some progress, but running into some virtual function override errors that may be due to a mismatch between header files and source files.
UPDATE: I only need to build IOPCIFamily.kext, not the entire XNU kernel. Will work on that shortly.
The idea is to add a number of debug logs to IOPCIFamily to find the point at which PCI devices get detached (marked Inactive).
Another option is to use lldb for two-computer debugging -- as long as a supported Ethernet port remains active (USB Ethernet is not supported). The ‘development’ kernel boots up, but screen stays black. Will check the AMD-OSX kernel patches. On the other hand, it’s not strictly necessary to fix the black screen issue because PCI activation problem occurs much before screen initialization. I can trigger a NMI interrupt or enable Thunderbolt to trigger a kernel panic, at which point the target kernel will wait for host debugger to attach. I don’t think this method will be as effective as compiling a custom kernel.
So I’m thinking of exploring other options…
Has anyone been able to compile the macOS Monterey kernel using the source code on GitHub?
I’ve made some progress, but running into some virtual function override errors that may be due to a mismatch between header files and source files.
UPDATE: I only need to build IOPCIFamily.kext, not the entire XNU kernel. Will work on that shortly.
The idea is to add a number of debug logs to IOPCIFamily to find the point at which PCI devices get detached (marked Inactive).
Another option is to use lldb for two-computer debugging -- as long as a supported Ethernet port remains active (USB Ethernet is not supported). The ‘development’ kernel boots up, but screen stays black. Will check the AMD-OSX kernel patches. On the other hand, it’s not strictly necessary to fix the black screen issue because PCI activation problem occurs much before screen initialization. I can trigger a NMI interrupt or enable Thunderbolt to trigger a kernel panic, at which point the target kernel will wait for host debugger to attach. I don’t think this method will be as effective as compiling a custom kernel.
Last edited:
As far as I know, building IOPCIFamily against XNU requires building XNU, no? I could be wrong.
ExtremeXT told me on the Discord server that you were having trouble building XNU, so I wrote up a little tutorial.
https://forum.amd-osx.com/threads/how-to-build-xnu-from-source.3561/
This is still awaiting approval as of writing, but it should open up soon.
I wasn't able to build KCs, but that's there if you need it.
This is great! I'll wait for the guide to become available. I've been able to resolve nearly all XNU build errors by adding a bunch of compiler flags in
makedefs/MakeInc.def. The first 13 or 14 flags after $(WERROR) are mine:
C:
# Shared C/C++ warning flags
# NOTE: order matters here. -Wno-xxx goes before opt-in of ones we want
WARNFLAGS_STD := \
-Weverything \
-Wundef-prefix=TARGET_OS_ \
-Wno-pedantic \
$(WERROR) \
-Wno-suggest-override \
-Wno-suggest-destructor-override \
-Wno-unused-but-set-variable \
-Wno-unused-but-set-parameter \
-Wno-pragma-pack \
-Wno-four-char-constants \
-Wno-null-pointer-subtraction \
-Wno-void-pointer-to-int-cast \
-Wno-pointer-to-int-cast \
-Wno-tautological-value-range-compare \
-Wno-implicit-int-conversion \
-Wno-implicit-function-declaration \
-Wno-int-conversion \
-Wno-bad-function-cast \
-Wno-c++-compat \
-Wno-c++98-compat \
-Wno-conditional-uninitialized \
-Wno-covered-switch-default \
-Wno-disabled-macro-expansion \
-Wno-documentation-unknown-command \
-Wno-extra-semi-stmt \
-Wno-format-non-iso \
-Wno-format-nonliteral \
-Wno-language-extension-token \
-Wno-missing-variable-declarations \
-Wno-packed \
-Wno-padded \
-Wno-partial-availability \
-Wno-reserved-id-macro \
-Wno-shift-sign-overflow \
-Wno-switch-enum \
-Wno-undef \
-Wno-unused-macros \
-Wno-used-but-marked-unused \
-Wno-variadic-macros \
-Wno-vla \
-Wno-zero-length-arrayI'll just post the
This took me ages lol
make command I used to make it easier on you.$ make SDKROOT=macosx ARCH_CONFIGS=X86_64 KERNEL_CONFIGS=RELEASE CFLAGS_RELEASEX86_64="-Wno-error=unused-but-set-variable -Wno-error=four-char-constants -Wno-error=suggest-destructor-override -Wno-error=suggest-override -Wno-error=null-pointer-subtraction -Wno-error=void-pointer-to-int-cast -Wno-error=tautological-value-range-compare -Wno-error=unused-but-set-parameter -Wno-error=shorten-64-to-32 -Wno-error=undef-prefix -Wno-error=implicit-int-conversion -Wno-error=pointer-to-int-cast" CXXFLAGS_RELEASEX86_64="-Wno-error=unused-but-set-variable -Wno-error=four-char-constants -Wno-error=suggest-destructor-override -Wno-error=suggest-override -Wno-error=null-pointer-subtraction -Wno-error=void-pointer-to-int-cast -Wno-error=tautological-value-range-compare -Wno-error=unused-but-set-parameter -Wno-error=shorten-64-to-32 -Wno-error=undef-prefix -Wno-error=implicit-int-conversion -Wno-error=pointer-to-int-cast"This took me ages lol
Last edited:
It’s available from the first post in this thread, but the version is up to 0805:
X670 / X870 resource thread
ill use this thread to collect some new test bioses for the boards, maybe also to explain some less understood options to disable cores ccd go here and choose ccd xx bit map down core. each ones stand for an enabled core best to disable from the back, ie: 110000 instead of 0011000 after...
Did you have to compile firehose_kernel?
In my case, the compile phase completes successfully, but the linker complains about a missing firehose_kernel lib. Firehose is part of libdispatch, which is running into compile issues. Will post compiler error messages soon. (Update: I downloaded the wrong version.)
As for IOPCIFamily, that’s just full of compiler errors. There is a user post on developer.apple.com claiming that XNU needs to be compiled first. Not sure about that, but given the spate of problems with IOPCIFamily, I’m inclined to believe that post.
UPDATE: Aarg, now why didn’t I see libdispatch and dtrace on the Apple open source site? They are both there.
UPDATE 2: Ventura 13.0 kernel source code is available now!
Last edited:
It’s available from the first post in this thread, but the version is up to 0805:
X670 / X870 resource thread
ill use this thread to collect some new test bioses for the boards, maybe also to explain some less understood options to disable cores ccd go here and choose ccd xx bit map down core. each ones stand for an enabled core best to disable from the back, ie: 110000 instead of 0011000 after...rog.asus.com
I read thru the post and saw they included the 0805 bios for my X670 Creator too.. thanks for the link.
i've been lazy to build this system I have all the parts sitting on my test bench collecting dust. also I don't have a GPU.. i'm waiting on the 7000 series...
I think i'm going to go full-on XTXH like I did with my X570 Creator.
it's funny how the people at OC say STAY AWAY from PowerColor.. I love my RDU.. although it did require an SSDT to work in Monterey. it works flawlessly tho.
happy to hear 0805 helps immensely.
one of these days i'll pick your brain about installing Monterey (or FrankenMon) on an external NVME on my X570 via thunderbolt and then inserting same into the X670 Creators NVME slot.
it sounds kind of like a daunting undertaking for a noob like me.. so i've been putting it off.
Last edited:
Interim Update #5:
Thanks to the XNU guide posted by @alyxferrari, I was able to compile the macOS 13.0 (Ventura) kernel. Why not Monterey kernel? Because I updated Xcode a few days ago, which only contains the SDK for Ventura. Instead of downloading and installing an older version, I wanted to see if the kernel would build -- and it did. I should also mention that this was done on my AM5 platform with Ryzen 7 7700X. The compiler just tore through the project, finishing it more quickly than I expected!
XNU Guide by @alyxferrari is located here:
forum.amd-osx.com
My experience building Ventura is located here:
forum.amd-osx.com
So where do we go from here? We know that our PCI problem disappears simply by importing Big Sur's version of IOPCIFamily and AppleACPIPlatform into Monterey. This means the Monterey kernel is most likely not the issue. Adding debug statements to IOKit in the kernel won't necessarily help, although we have that option now.
Instead, now we can try to build IOPCIFamily itself. This may be more difficult than it seems. But if we can do that, we can add a bunch of extra logging in hopes of identifying where exactly the PCI device configuration failure occurs.
Thanks to the XNU guide posted by @alyxferrari, I was able to compile the macOS 13.0 (Ventura) kernel. Why not Monterey kernel? Because I updated Xcode a few days ago, which only contains the SDK for Ventura. Instead of downloading and installing an older version, I wanted to see if the kernel would build -- and it did. I should also mention that this was done on my AM5 platform with Ryzen 7 7700X. The compiler just tore through the project, finishing it more quickly than I expected!
XNU Guide by @alyxferrari is located here:
Tutorial - How to build XNU from source
This was posted because apparently someone's trying to figure out the IOPCIFamily issues on MSI 500 series boards and AM5 socket boards and they're having trouble with building XNU. Here's what I wrote in the Discord server: Grab the version of Xcode with the correct SDK for the kernel you're...
forum.amd-osx.com
Tutorial - How to build XNU from source
This was posted because apparently someone's trying to figure out the IOPCIFamily issues on MSI 500 series boards and AM5 socket boards and they're having trouble with building XNU. Here's what I wrote in the Discord server: Grab the version of Xcode with the correct SDK for the kernel you're...
forum.amd-osx.com
So where do we go from here? We know that our PCI problem disappears simply by importing Big Sur's version of IOPCIFamily and AppleACPIPlatform into Monterey. This means the Monterey kernel is most likely not the issue. Adding debug statements to IOKit in the kernel won't necessarily help, although we have that option now.
Instead, now we can try to build IOPCIFamily itself. This may be more difficult than it seems. But if we can do that, we can add a bunch of extra logging in hopes of identifying where exactly the PCI device configuration failure occurs.
** IOPCIFamily for macOS 13.0 Compiled Successfully **
I guess we're on a roll now...
The Montera version of IOPCIFamily is too much of a problem to compile, but the Ventura version was a snap! Details here:
Tutorial - How to build XNU from source
This was posted because apparently someone's trying to figure out the IOPCIFamily issues on MSI 500 series boards and AM5 socket boards and they're having trouble with building XNU. Here's what I wrote in the Discord server: Grab the version of Xcode with the correct SDK for the kernel you're...
forum.amd-osx.com
Code:
$ pwd
/Users/casey/Downloads/Ventura/IOPCIFamily-IOPCIFamily-583.40.1/dst/System/Library/Extensions/IOPCIFamily.kext/Contents/MacOS
% ls -l
total 3768
-rwxr-xr-x 1 casey staff 395848 Nov 5 10:40 IOPCIFamily
-rwxr-xr-x 1 casey staff 402680 Nov 5 10:40 IOPCIFamily_development
-rwxr-xr-x 1 casey staff 1124528 Nov 5 10:40 IOPCIFamily_kasanNice! Can you upload the working source code to GitHub? Now it should be just a matter of re-adding code from Big Sur, compiling and testing.** IOPCIFamily for macOS 13.0 Compiled Successfully **
I guess we're on a roll now...
The Montera version of IOPCIFamily is too much of a problem to compile, but the Ventura version was a snap! Details here:
Tutorial - How to build XNU from source
This was posted because apparently someone's trying to figure out the IOPCIFamily issues on MSI 500 series boards and AM5 socket boards and they're having trouble with building XNU. Here's what I wrote in the Discord server: Grab the version of Xcode with the correct SDK for the kernel you're...Code:$ pwd /Users/casey/Downloads/Ventura/IOPCIFamily-IOPCIFamily-583.40.1/dst/System/Library/Extensions/IOPCIFamily.kext/Contents/MacOS % ls -l total 3768 -rwxr-xr-x 1 casey staff 395848 Nov 5 10:40 IOPCIFamily -rwxr-xr-x 1 casey staff 402680 Nov 5 10:40 IOPCIFamily_development -rwxr-xr-x 1 casey staff 1124528 Nov 5 10:40 IOPCIFamily_kasan
I can upload the modified IOPCIFamily source code to my GitHub repo soon (have to step out for an appointment).
However, wouldn't it be better to find the cause of the problem and develop a patch? On the other hand, maybe IOPCIFamily cannot be patched by OpenCore. My previous attempts did not seem to work.
Some options:
- First identify the problem
- Then see if IOPCIFamily or kernel needs to be patched
- Kernel patching works fine, but if IOPCIFamily cannot be patched then we may need to compile a new version
- Can OpenCore replace IOPCIFamily by dropping the existing version? I have some doubts about this
- If we have to insert a new IOPCIFamily using the KDK/livemount technique, that would be troublesome because macOS updates will undo the change, so we'll need to install our IOPCIFamily every time
My suggestion is to first change some code with Big Sur's IOPCIFamilly until we get it working, then try turning it into a kernel patch which would be the optimal option. Sadly, OpenCore cannot replace IOPCIFamilly.
I've uploaded the Ventura IOPCIFamily source, including the build products:
GitHub - CaseySJ/IOPCIFamily-583.40.1: A test and debug vehicle
A test and debug vehicle. Contribute to CaseySJ/IOPCIFamily-583.40.1 development by creating an account on GitHub.
github.com
I think we should try rolling back IOPCIMessagedInterruptController, since it's the most likely culprit IMO. Try replacing the code with Big Sur's version and compiling it.I've uploaded the Ventura IOPCIFamily source, including the build products:
GitHub - CaseySJ/IOPCIFamily-583.40.1: A test and debug vehicle
A test and debug vehicle. Contribute to CaseySJ/IOPCIFamily-583.40.1 development by creating an account on GitHub.
Interim Update #6: Some quick notes to keep everyone informed...
- The newly compiled IOPCIFamily.kext can indeed be incorporated into a new system snapshot. This means
kmutil --installsucceeds and we can boot the new FrankenTura up to a point where PCIe devices are scanned, but cause the system to crash. This is still good news because our IOPCIFamily is working -- otherwise it would crash the system immediately. - Instead, the crash happens at roughly the same place in the boot sequence as with the original IOPCIFamily.
- I have just bumped up the version number of our IOPCIFamily. Will see if OpenCore will inject it.
- I tried a moment ago (without changing version), but macOS errors out right away, saying that a prelinked version already exists in system cache.
- Cannot inject new IOPCIFamily via OpenCore despite changing version number
Last edited:
I was able to build IOPCIFamily after replacing just IOPCIMessagedInterruptController.cpp with that from Big Sur. It was necessary to make one minor change to parameter list of allocateDeviceInterrupts:
It's going to take about an hour to test this. I have to try and boot Ventura with the snapshot kernel. If it refuses, I have a full backup that can be restored.