Just a purist's nitpik: For the built-in property, Apple uses <data>AA==</data>, which appears as <00> in the I/O Registry. On the other hand, <integer>1</integer> corresponds to <010000>. Of course, there should be no difference functionally as the presence of the variable is what matters.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro
- Thread starter cdf
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Speaking of which, and sorry for being slightly off-topic, is there a way to declare a property as a string that doesn't get converted to data once injected in the I/O registry? It's usually not a problem, but with very specific applications like Native Access, it crashes if it sees data instead of a string as it's not expecting anything else for the "name" property. See the discussion here, and how to get around it, but if you absolutely need to set a specific "name" property, you can't, unless maybe you use a DSDT patch?
Problem with Native Access
I have thought the same about NI ;) However i messaged them, maybe its a easy fix for them to ignore none string ionames. Ive got the EFI folder now, do u need the config.plist or everything? Is sensitive information in the EFI partition? Btw. i dont want to steal any of your time, if it is...
www.tonymacx86.com
As far as I knowSpeaking of which, and sorry for being slightly off-topic, is there a way to declare a property as a string that doesn't get converted to data once injected in the I/O registry? It's usually not a problem, but with very specific applications like Native Access, it crashes if it sees data instead of a string as it's not expecting anything else for the "name" property. See the discussion here, and how to get around it, but if you absolutely need to set a specific "name" property, you can't, unless maybe you use a DSDT patch?
Problem with Native Access
I have thought the same about NI ;) However i messaged them, maybe its a easy fix for them to ignore none string ionames. Ive got the EFI folder now, do u need the config.plist or everything? Is sensitive information in the EFI partition? Btw. i dont want to steal any of your time, if it is...
1) Device Properties is always Data.
2) DSDT/SSDT properties (_DSM -> DTGP) cannot always be recreated by Device Properties. SSDT properties can be Number, Data, or String.
3) kext properties cannot always be recreated by Device Properties or SSDT properties. Kext properties can be anything: Number, Data, String, Dictionary, Array, etc.
DSDT supports String property so an SSDT patch should work but only if the device is in ACPI.
To define a string for a property named "name", the _DSM method has a package like this:
Code:
Local0 = Package (#size#) {
"name",
"MySpecialName"
}Since kext properties is most closely related to ioreg (has the most data types), I think a method to add properties at the kext level would be the best way to go.
I wonder if a kext could be added for OpenCore to take as input the config.plist (maybe stored as a UEFI configuration table), find the device properties, and update the type in the ioreg for any items that are not Data in the config. In that case, we wouldn't need the Device Properties mechanism (unless you want to use that mechanism because the property involved uses that method on real Macs).
Instead of using a string, perhaps try adding the property as data, making sure not to forget the null termination. Alternatively, there's always the kext solution with IOKit:
IORegistryEntry | Apple Developer Documentation
The base class for all objects in the registry.
I guess esthetics are in the eye of the beholder! Try
ioreg -l -p IODeviceTree | grep built-in in Terminal.
I do not have that problem.
Not an OpenCore config issue.
Not sure what you are asking or what you are trying to achieve with Scaling.
Seems more like an issue with your GPU and/or Monitor.
XFX based 580's have had issues in the past with macOS drivers as they never implemented "reference" designs or reference UEFI firmware. Not sure if your GPU falls in that camp.
Try different connectors and different monitor (if you have another).
Last edited:
First -- thanks for acknowledgment!
But I had no such issues under HS or Mojave.... This didn't start happening/appear until I put OC on my machine, that's why I am convinced it IS an OC issue
What I'm trying to achieve with scaling is being in 1080p @ 144Hz refresh rate at boot, without having to constantly power off/power on my monitor everytime I boot in, the machine instead comes in @ 720p @ 60Hz, sometimes scaled to 1080i @ 60Hz.
It's probably just a way I coded my config.plist -- guess I will play around with it
Last edited:
You had no issues with HS or Mojave. I missed which OS are you having problem with (Catalina, Big Sur or a another ?)
If you can boot HS via OpenCore, do you still have this problem ?
Each version of macOS will have different drivers for the same type of GPU so stating it worked with HS & Mojave but not now (current OS ??) does not necessarily mean it is an OpenCore issue.
Sorry about that -- I am having this issue under Catalina 10.15.7
I didn't think HS worked with OC?
If it does, I'll install it on another SSD and try that out -- thanks for the suggestion!
OpenCore can boot all the way back to OS X 10.4 !!
I always keep a legacy OS (Snow Leopard) handy on a separate drive as a backup boot OS.
Legacy OS's don't/can't take advantage of newer GPU's but they will boot (graphics will be sluggish).
Catalina drivers for RX 580 are different from HS which have different drivers compared to Mojave, etc
Wow, excellent. This did work for my NVMe, looks mean and clean. However I am a bit puzzled in regards of my RX570.
It shows up in System Profiler as two devices (audio and video) with following names and IDs:
pci1002,aaf0 (Audio Device), VID: 0x1002 DevID: 0xaaf0
Radeon RX570 (Display Controller), VID: 0x1002 DevID: 0x67df
Now I probe them using gfxutil and:
Code:
sudo ./gfxutil | grep 1002
05:00.0 1002:67df /PCI0@0/IOU0@3/GFX0@0 = PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)
05:00.1 1002:aaf0 /PCI0@0/IOU0@3/HDAU@0,1 = PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x1)And this is all OK until I look into my config.plist, which looks like:
XML:
<key>DeviceProperties</key>
<dict>
<key>Add</key>
<dict>
<key>PciRoot(0x0)/Pci(0x1c,0x5)/Pci(0x0,0x0)</key>
<dict>
<key>brcmfx-country</key>
<string>PL</string>
</dict>
<key>PciRoot(0x0)/Pci(0x1f,0x2)</key>
<dict>
<key>built-in</key>
<integer>1</integer>
</dict>
<key>PciRoot(0x0)/Pci(0x7,0x0)</key>
<dict>
<key>pci-aspm-default</key>
<integer>2</integer>
</dict>
<key>PciRoot(0x0)/Pci(0x7,0x0)/Pci(0x0,0x0)</key>
<dict>
<key>built-in</key>
<integer>1</integer>
<key>name</key>
<string>Adata NVMe controller</string>
<key>pci-aspm-default</key>
<integer>2</integer>
</dict>
</dict>Looks like my config takes the USB3 and NVME controllers into account and also lists my (upgraded) Broadcom bt/wifi combo that sits in the stock mini-pcie socket (I have no idea why actually since it is not the factory item but and upgraded AC one, it works great so I don't bother).
But where is the GPU (and corresponding audio device)? There is no mention of
Pci(0x3) throughout config.plist and yet I get GPU-accelerated encoding in VideoProc...Those
DeviceProperties entries did not magically appear in your config.plist.Someone or some App has added them for you (dare I say it....OCLP?)
None of these entries get added automatically but have to be added.
The example I gave a few posts back regarding the AMD GPU name has to be added manually.
That is, after your Adata NVMe
<dict> and </dict>.Once, you add that, System Profiler will display your GPU video and audio names correctly.
The fact that GPU naming entry is not in the
DeviceProperties is nothing to do with GPU-accelerated encoding...that gets done by Board ID spoofing in the PlatformInfo. That is, GPU acceleration framework s/w within macOS checks the board-id of the Mac and not the Mac's Model ID. And via OpenCore, we inject either iMacPro1,1 or MacPro7,1 board-id and thus spoofing macOS into believing that we are running on one of those models that's capable of using the GPU for H/W acceleration.
Last edited:
Which was going to be one of my questions to you, @MacNB2, on what would happen if I changed my board ID in config from Mac-7BA5B2D9E42DDD94 to Mac-27AD2F918AE68F61 to see if that fixes my displays issue. Would I need to change anything else in config, or is that enough to inject MacPro 7,1?
Last edited:
You can try changing the board-id to that of a MacPro7,1 and it will do no harm but that will not change what you are observing. The macOS FrameBuffer driver is responsible for video port outputs and so is not related to board-id.
There's nothing else to change, just the board-id. Try it to confirm it.
You are damn right, I am stepping on thin ice here
I used to do it by hand since OC started to gain traction but once OCLP took off I am just too easy.OK, that explains it nicely, I was under impression (from my past 'pure OC' times and gfxutil searches when I tried to run my R9 280X to the maximum) that BoardID spoofing makes the OS boot and that's it, injecting data into respective PCI devices makes them 'supported'. Now I see the bigger picture of the spoofing idea. Great insight and a revelation for me, I should probably try to understand more of the under the bonnet stuff. Thanks again.
(BTW - device names aside, is there really a point in enumerating the GPU in
DeviceProperties if it just works? Perhaps I fail to see a bigger point here)
That's a Python dictionary, probably related to https://github.com/axivo/opencore/blob/master/examples/setup.py
Windows 11 build 22000.318 is running too nicely on my machine for me to even boot back into MacOS, but I will give the MacPro 7,1 injection script a shot to see if that does anything else. I know, as you've mentioned it won't, but i'm curious to try it anyway.
Actually the board ID is used for checking which system is supported for installing, booting and OTA updates. That's the primary function of spoofing the board ID.
There's no real point (from a functional point of view) to add the device name ...it's just cosmetic.
"enumerating the GPU" ???
What does that mean ?
As far as I got into making my R9 fully supported I had to identify the PCI id („enumerarte”) put them into the DeviceProperties and add the („<add>” section, after all) various parameters. As far as I follow your thinking this is unnecessary in moder incarnations of OC (some tinkering with boot-args, shiki etc notwithstanding).
I know this thread is not the OC learning book but I am getting a lot here.
Hi,
I've got a 2012 MP 5,1 (2x2.66 GHz, 12 core)
144.0.0.0.0 Boot ROM
24 GB 1333 MHz DDR3
Sapphire RX 580 8 GB (doesn't have a boot screen)
Have 10.14.6 Mojave running on a Samsung SSD 860 EVO
Trying to get to Big Sur on a new/separate Samsung SSD 860 EVO
Working through the instructions in the original post
My intended "game plan" was to –
bless --mount /Volumes/EFI --setBoot --file /Volumes/EFI/EFI/BOOT/BOOTx64.efi
As soon as I did so, got the following response (see photo), which leads me to believe I'm missing something.
Any thoughts?
EDIT – I should add that after the "first boot" step, when attempting to restart into Recovery mode with the following command, the computer booted into Installer mode. It didn't reboot into the actual desktop.
I've got a 2012 MP 5,1 (2x2.66 GHz, 12 core)
144.0.0.0.0 Boot ROM
24 GB 1333 MHz DDR3
Sapphire RX 580 8 GB (doesn't have a boot screen)
Have 10.14.6 Mojave running on a Samsung SSD 860 EVO
Trying to get to Big Sur on a new/separate Samsung SSD 860 EVO
Working through the instructions in the original post
My intended "game plan" was to –
- Install a clean copy of Mojave on this new SSD (completed)
- Install OpenCore on this SSD after completing the Mojave install (this is where I'm getting stuck)
- After installing OpenCore to the SSD, update the OS with a copy of Big Sur
bless --mount /Volumes/EFI --setBoot --file /Volumes/EFI/EFI/BOOT/BOOTx64.efi
As soon as I did so, got the following response (see photo), which leads me to believe I'm missing something.
Any thoughts?
EDIT – I should add that after the "first boot" step, when attempting to restart into Recovery mode with the following command, the computer booted into Installer mode. It didn't reboot into the actual desktop.
| sudo nvram "recovery-boot-mode=unused" && sudo reboot recovery |
Attachments
Last edited: