As far as I know, building IOPCIFamily against XNU requires building XNU, no? I could be wrong.UPDATE: I only need to build IOPCIFamily.kext, not the entire XNU kernel. Will work on that shortly.
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 inAs 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.
makedefs/MakeInc.def
. The first 13 or 14 flags after $(WERROR) are mine:# 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-array
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"
** Audio Update: Line Out Miracle **
BIOS 0801 (pre-release) has made a ginormous improvement to audio from the rear Line Out and front panel audio jacks. With iGPU enabled or disabled in BIOS, or with iGPU enabled or disabled via SSDT, Line Out is now performing just as well as HDMI/DP.
It’s available from the first post in this thread, but the version is up to 0805:Where can I get the 0801 pre-release BIOS?
Did you have to compile firehose_kernel?I'll just post themake
command I used to make it easier on you.
…
This took me ages lol
Can you send a few of those compiler issues for IOPCIFamilly?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!
Will do shortly.Can you send a few of those compiler issues for IOPCIFamilly?
It’s available from the first post in this thread, but the version is up to 0805:
X670 resource
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
$ 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
Nice! 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...forum.amd-osx.comCode:$ 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).Nice! 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.
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 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
I've uploaded the Ventura IOPCIFamily source, including the build products:Nice! 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.
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.github.com
kmutil --install
succeeds 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.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: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.