OpenCore General Discussion

[Septendre]

9 minutes ago, miliuco said:

No, see @antuneddu post, it's the extra space at the end of the PCI path.

I was answering the second part, the one mentioning the motherboard and board name. I know as a fact that the first part is due to the space before efi/ubuntu and since @antuneddu had already kindly answered that part, I offered my knowledge for the second part, cause it happened to me and support assist program from dell was not happy with it, but Ubunt will be just fine.

Edited September 24, 2021 by Septendre
adding info

[miliuco]

2 hours ago, Septendre said:

I was answering the second part, the one mentioning the motherboard and board name. I know as a fact that the first part is due to the space before efi/ubuntu and since @antuneddu had already kindly answered that part, I offered my knowledge for the second part, cause it happened to me and support assist program from dell was not happy with it, but Ubunt will be just fine.

Sorry, my mistake. Then you're right. @rajkhand must set 2 keys in config.plist:

• Kernel > Quirks > CustomSMBIOSGuid > True (default False)
• PlatformInfo > UpdateSMBIOSMode > Custom (default Create).

So OpenCore doesn't pass SMBIOS data to other operating systems.

 

[rajkhand]

@antuneddu @Septendre @miliuco 

Thanks 🙏🏼 

[ghost8282]

Hi, I just see recent commits in opencore; I saw vit changed in sample.plist AdviseFeatures from false to true with this description:

Quote

Without this bit, it is not possible to install macOS versions with large BaseSystem images, such as macOS 12.

 

Andrey changed it back from true to false.

 

Can anybody give some suggestions?

Is that true that setting AdviseFeatures to false will prevent us to install monterey from BaseSystem?

What's the drawback of setting it to true if not running monterey (let's say big sur), so different than the current default setting in sample.plist?

 

Was that changed again to false because of the change of the last characters from AAAAA= to gAAAA= in FirmwareFeatures and FirmwareFeaturesMask?

Edited September 25, 2021 by ghost8282

[Andrey1970]

8 hours ago, ghost8282 said:

Was that changed again to false because of the change of the last characters from AAAAA= to gAAAA=

Yes

[Andrey1970]

8 hours ago, ghost8282 said:

Is that true that setting AdviseFeatures to false will prevent us to install monterey from BaseSystem?

Not truly, because this bit is already included in database for all compatible models.

Edited September 25, 2021 by Andrey1970

[deeveedee]

On 9/21/2021 at 2:19 PM, Hervé said:

1. "hex swapped"-> incorrect term which does not mean much, it should be "byte reverse(d) order"

 

Many of us adopted "hex swapped" because of the terminology used in the Dortania guide (see use of "hexswap" here).  Maybe this needs to be corrected in the Dortania guide?

[mhaeuser]

Neither "hex swapped" nor "byte reverse order" are technical terms, please do not replace things with "equally bad" things for no reason. People understand it, so let it live.

[Henties]

For those that are keen and have time to refresh their understanding of "Endianness" I suggest you dive into the link below:

https://en.wikipedia.org/wiki/Endianness

Edited September 28, 2021 by Henties

[deeveedee]

Wanted to share a lesson learned after misinterpreting Dortania documentation here.  Bottom line is that framebuffer-stolenmem and framebuffer-fbmem were unnecessary on my rig and actually caused problems (my fault, not the documentation).  I ended up removing these parms from my config.plist with much better performance/stability.  See details below...

 

My HP Envy x360 15 / HackBookPro15,2 (i5-8250U / UHD620) does not allow any VRAM configuration in BIOS.  This was my first laptop hack since my Dell Latitude E6410.  After seeing similar hacks that defined framebuffer-stolenmem and framebuffer-fbmem in OC's config.plist DeviceProperties and after misinterpreting this Dortania guide, I assumed that I had to define framebuffer-stolenmem and framebuffer-fbmem because I couldn't configure VRAM in my BIOS config.  I chose the values 19MB and 9MB respectively as per the example in the guide.  After upgrading to BS 11.6, I started experiencing com.apple.driver.AppleIntelKBLGraphics kernel panics when streaming video in firefox and when establishing remote desktop via Tunnelblick OpenVPN.  After some experimentation, I increased framebuffer-stolenmem and framebuffer-fbmem to 39MB and 21MB respectively (based on my framebuffer memory utilization specified here) and found that the kernel panics stopped.  This lead me to realize that I did not need to constrain framebuffer-stolenmem and framebuffer-fbmem, so I deleted them from my config.plist.  My rig is now rock solid.  My lesson learned is that I should first test without framebuffer-stolenmem and framebuffer-fbmem before unnecessarily (and wrongly) defining these.  I suspect that if I booted Windows (not installed on my rig) and examined video memory, I would see that my rig has plenty of allocated VRAM for my chosen framebuffer (AAPL,ig-platform-id) and there is no need to constrain framebuffer-stolenmem and framebuffer-fbmem.

Edited September 29, 2021 by tonyx86
Fixed typo

[deeveedee]

Developers - at the risk of receiving your constructive criticism for this comment, I think it would be a good idea to add an example here where adding framebuffer-stolenmem and framebuffer-fbmem is determined to be unnecessary.  After reviewing many sample EFIs posted in InsanelyMac, it appears to me that the addition of framebuffer-stolenmem and framebuffer-fbmem has become somewhat "automatic" if VRAM can't be configured in BIOS.  Further, the automatic entry of these parms uses the 19MB and 9MB values from the Dortania example.  As I mentioned here, adding framebuffer-stolenmem and framebuffer-fbmem created problems for me in 11.6.  Advising people that these parms are unnecessary if there's enough allocated VRAM (and how to determine whether there's enough allocated VRAM even if not configurable in BIOS) might be helpful.  Thank you and thank you for all the great work you have done and continue to do.

[pkdesign]

Question about SIP. I updated my csr-active-config to FF070000 as suggested in the OpenCore guide. I used to have it set to 67000000.

 

But now I find the following when I run csrutil status I get the following:

Apple Internal: enabled
Kext Signing: disabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: disabled
NVRAM Protections: disabled
BaseSystem Verification: disabled

Shouldn't Apple Internal be disabled? According to OC Guide:

Quote

Enabling CSR_ALLOW_UNAUTHENTICATED_ROOT and CSR_ALLOW_APPLE_INTERNAL are common options that can break OS updates for users

 

With 67000000 I would just get "System Integrity Protection status: disabled"

 

Using CsrDecode; 67000000, FF070000, FF0F0000 all come up with the same values.

 

I'm confused. What is correct or suggested?

[pkdesign]

The issue @Hervé is that you get conflicting information from all over the place. Yes I searched here and elsewhere, and other that your own posts, found different suggestions everywhere. And considering that the official OpenCore guide seems to contradict your advice is not helpful. That is what I was trying to get clarification for.

Edited October 1, 2021 by pkdesign

[MacNB]

Hmmm....interesting

On my Legacy Dell Inspiron 530 running Big Sur 11.6 booted via OC 0.7.3, I have csr-active-config set to 0FFF :

macnb@iMac-530 ~ % nvram -p | grep csr
csr-active-config	%ff%0f%00%00
macnb@iMac-530 ~ % 

and I get :

macnb@iMac-530 ~ % csrutil status
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: disabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: disabled
	NVRAM Protections: disabled
	BaseSystem Verification: disabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Thus CSR_ALLOW_APPLE_INTERNAL bit is SET in my case but the status command returns disabled. 

 

OTA update worked today as I received a minor supplemental update for Device Support Update for newer iOS & iPad devices syncing with macOS.

 

 

Edited October 2, 2021 by MacNB

[joevt]

8 hours ago, tonyx86 said:

Wanted to share a lesson learned after misinterpreting Dortania documentation here.  Bottom line is that framebuffer-stolenmem and framebuffer-fbmem were unnecessary on my rig and actually caused problems (my fault, not the documentation).  I ended up removing these parms from my config.plist with much better performance/stability.  See details below...

 

My HP Envy x360 15 / HackBookPro15,2 (i5-8250U / UHD620) does not allow any VRAM configuration in BIOS.  This was my first laptop hack since my Dell Latitude E6410.  After seeing similar hacks that defined framebuffer-stolenmem and framebuffer-fbmem in OC's config.plist DeviceProperties and after misinterpreting this Dortania guide, I assumed that I had to define framebuffer-stolenmem and framebuffer-fbmem because I couldn't configure VRAM in my BIOS config.  I chose the values 19MB and 9MB respectively as per the example in the guide.  After upgrading to BS 11.6, I started experiencing com.apple.driver.AppleIntelKBLGraphics kernel panics when streaming video in firefox and when establishing remote desktop via Tunnelblick OpenVPN.  After some experimentation, I increased framebuffer-stolenmem and framebuffer-fbmem to 39MB and 21MB respectively (based on my framebuffer memory utilization specified here) and found that the kernel panics stopped.  This lead me to realize that I did not need to constrain framebuffer-stolenmem and framebuffer-fbmem, so I deleted them from my config.plist.  My rig is now rock solid.  My lesson learned is that I should first test without framebuffer-stolenmem and framebuffer-fbmem before unnecessarily (and wrongly) defining these.  I suspect that if I booted Windows (not installed on my rig) and examined video memory, I would see that my rig has plenty of allocated VRAM for my chosen framebuffer (AAPL,ig-platform-id) and there is no need to constrain framebuffer-stolenmem and framebuffer-fbmem.

 

Documentation is unclear.

 

Quote

Here the main entries we care about:

Entry	Value	Comment
STOLEN	32MB	Memory reserved for the iGPU
FBMEM	19MB	Memory reserved for the framebuffer
TOTAL CURSOR	1 MB	Memory reserved for cursor
TOTAL STOLEN	52 MB	Combination of the above

Now let's say for example your motherboard only allocates 32MB for the iGPU, this will be too little for what the framebuffer expects and so will most likely kernel panic when it tries to write into an area of memory that does not exist.

That's where WhateverGreen's patching capabilities come in, here we're able to set the exact amount of iGPU memory the framebuffer expects with the following properties:

Value	Comment
framebuffer-patch-enable	This enables WhateverGreen's patching capabilities
framebuffer-stolenmem	This sets the value used by STOLEN entry
framebuffer-fbmem	This sets the value used by FBMEM entry

#Creating our patch

So to lower this VRAM requirement, we'll want to set STOLEN to 19MB and FBMEM to 9MB. This will get us underneath the 32MB limit.

 

 

 

It doesn't say where the the "32MB for the iGPU" comes from (maybe it's the STOLEN number but the last line infers something else) or what the framebuffer expects (maybe that's TOTAL STOLEN?).

It doesn't say why the solution is to reduce STOLEN and FBMEM instead of increasing something else (like what the motherboard allocates to the iGPU).

 

[ghost8282]

Hi, sorry if this is a stupid question, probably it is..

From monterey beta 7 we lost native compatibility for nvidia kepler gpus: it's a shame, because my gtx titan black is still capable of running monterey, but hey we know that apple likes to drop "old" hardware, sometimes with no reasons (at least this is what I think).

If one wants to still use its kepler he/she needs to copy old files in /System/Library/Extensions and make a new snapshot disk.

However, as you know, this means disabling secure boot, authenticated-root and disable/enable sip to perform all the steps.

Moreover, I'm worried about os updates, most probably they will show as full installers instead of deltas.

 

To be able to have back a kepler gpu we need: GeForce.kext, GeForceAIRPlugin.bundle, GeForceGLDriver.bundle, GeForceMTLDriver.bundle, GeForceVADriver.bundle, NVDAGF100Hal.kext, NVDAGK100Hal.kext, NVDAResman.kext and NVDAStartup.kext

 

So, kexts and bundles files: is it possible to inject these with opencore? I think bundles cannot be injected?

 

Thank you

[MacNB]

6 hours ago, Hervé said:

@MacNB 

Nope; as shown by your own SIP status check, AppleInternal bit is NOT set and therefore shown as disabled. It's your csr-active-config parameter which is clearly ineffective.

 

I'd say there is something incorrect in your config or with your (emulated?) NVRAM or an unreported bug with OC 0.7.3 because, under normal/full operational conditions, setting csr-active-config to 0xFFF cannot leave AppleInternal set to disabled. It's a plain binary matter and therefore an absolute impossibility if the csr-active-config parameter is properly applied.

 

 

@Hervé

Yes I know SIP status is showing AppleInternal bit as disabled but clearly nvram command is clearly showing that bit is & was set.

Checking the OC log now shows that macOS (or boot.efi) is changing that bit (for whatever reason):

 

...

22:433 00:002 AAPL: [EB|#CSR:IN] 0x00000FFF
22:436 00:002 AAPL: [EB|#CSR:OUT] 0x00000FEF
...

That is the log output from Apple and proves that csr-active-config was properly set to 0x00000FFF but changed to 0x00000FEF.

So, "It's a plain binary matter and therefore an absolute impossibility if the csr-active-config parameter is properly applied" is not true as "something" is flipping that bit.

 

Thanks for checking your various systems.

I downgraded my OC back to 0.7.0 like yours just incase it's an issue in latest OC 0.7.3 Release but that's clearly that's not the case as I get the same result.

 

With emulated NVRAM, there's not reset NVRAM capability in OC from Bootpicker (though the feature function has been requested).

The only thing you can do is to delete the csr-active-config variable in macOS nvram via nvram command and delete the nvram.plist file before you reboot. Which I did but made no difference.

 

Not sure setting csr-active-config via Recovery OS would work for emulated nvram as it has no LogoutHook.command mechanism to save the nvram to the emulated nvram.plist.

 

So why is the AppleInternal bit being changed from 1 to 0 in some cases ?

Plot thickens.

Edited October 2, 2021 by MacNB

[ghost8282]

3 hours ago, Hervé said:

why don't you try & cache them from /E/E?

thank you, it seems it doesn't work.

no prompt to enable any of the kexts/bundles from security.

 

Edited October 2, 2021 by ghost8282

[ghost8282]

yes, thank you, I looked before posting at the script (chris1111) and also made my gtx working, but it creates a new snapshot with all the drawbacks I listed; also oclp does a root patch, I have not looked at the code, but it seems it does the same thing as the script by looking at the oclp warning.

Anyway, thank you for your suggestions.

Edited October 2, 2021 by ghost8282

[MacNB]

1 hour ago, Hervé said:

Ok, so csr-active-config changing value to 0xFEF -for whatever unidentified reason- does explain why AppleInternal is shown as disabled, the bit being actually unset. At least there's a consistency from the binary point of view.

 

As you said, the mystery to resolve is why the parameter value you specify in your config gets changed as shown in the log. But at least, we've confirmed that setting it to 0xFFF does not keep AppleInternal set to disabled. Which is re-assuring.

 

One thing bothers me though when you say:

I must disagree. Emulated NVRAM does work as expected on my Dell Vostro 200 which, as you know, is 99% identical to the Inspiron 530 (100% if you have the G33M02 motherboard rather than the G33M03 one). I use an older OC version on that old C2D desktop computer (v0.6.8 or v0.6.9, I can't remember) but it does offer the "Reset NVRAM" option in the Picker and the feature is fully functional as far as I'm concerned.

 

If you cannot Reset NVRAM, then it's as I suspected: you most probably have an emulated NVRAM-related issue.

 

Do you have a file called nvram.plist at the root of your EFI partition (next to boot file and OPenCore's EFI folder) ? If you do, do you see it updated (contents & date) after you make changes to NVRAM parameters and reboot? The timestamp should be that off the reboot. You may look at the contents of the file with a plist editor and check the value of csr-active-config stored in there.

 

Might have to raise a bug report on Acidathera's bug tracker as why macOS is not honouring csr-active-config value.

 

Regarding my NVRAM. It is working perfectly across High Sierra, Catalina and Big Sur (all three OS's have LogoutHook.command installed).

So yes of course I have nvram.plist file where it should be on the EFI.

I know a bit about the working of the emulated NVRAM as worked with the Devs to solve a few issues in the early days.

 

I know about the Reset NVRAM tool in the bootlicker; here's mine:

 

(BTW, that screenshot was done with hitting Function F10 with the OC CrScreenshotDxe.efi driver installed so that one does not have to take photos of the bootpicker with a camera 😉)

 

My motherboard is G33M03 running Quad Core Xeon E540 but regarding NVRAM, the motherboards are irrelevant as they both do not have native hardware NVRAM.

 

Have you actually tested it by clicking it and checking that your nvram variables were cleared ?

That is, what do mean "as expected" ? What did you expect it to do ?

BootPicker offers the Reset NVRAM tool but for emulated NVRAM it can't do much since I checked las time. There's an open related issue here.

 

 

 

Edited October 2, 2021 by MacNB

[MacNB]

1 minute ago, Hervé said:

Yes I know about the module that supports screenshot but it's not installed. I switch from Clover/High Sierra to OC/Big Sur on that old PC. If I don't Reset NVRAM when booting OC/Big sur, I have leftover from Clover/High Sierra, that's how I know that Reset NVRAM works.

Ah OK. Clover emulated NVRAM implementation is not the same as OC.

[MacNB]

1 hour ago, Hervé said:

Yes I know about the module that supports taking screenshots but it's not installed.

 

I switch from Clover/High Sierra to OC/Big Sur on that old PC. If I don't Reset NVRAM when switching from former to latter, I have leftover from Clover/High Sierra that can prevent booting OC/Big Sur, that's how I know that Reset NVRAM works as expected.

 

The reference I made to motherboards was to highlight the closeness between our 2 x systems and therefore the expected similar behaviour with regards to emulated NVRAM. Nothing else and no mention was made to hardware/native NVRAM.

 

Maybe you can post your OC config or its NVRAM section.

 

When switching Clover to OC, you have to clear out left over Clover stuff from your system...especially NVRAM scripts. See this guide

Sure. Here is my OC config.plist.

 

MacNB-Dell-530-config.plist

Edited October 2, 2021 by MacNB

[MacNB]

13 minutes ago, Hervé said:

That's right and Clover is better suited to our old Penryn/Wolfdale/Yorkfield/Harpertown systems than OC. 

 

Well that is very debatable.

I am quite impressed with OC on the Legacy PC's.

Makes my Hack more like a Mac (bootpicker function, startup disk, bootcamp, etc).

Mine boots faster.

Properly documented throughout its development and importantly, still being developed even though we're coming to an end of Hacks.

NVRAM issue is a non-issue for me as it works as I expect (mainly for proper startup boot disk selection and controlling the default boot disk). 

 

Like you, I grew up with Clover but having switched, there's no going back - even on Legacy PC's.

I even use OC on my ageing real MacPro5,1 like many real Mac users with unsupported Macs.

Lol real Mac have now become Hackingtosh's thanks to OC 🤣

 

[deeveedee]

17 hours ago, joevt said:

Documentation is unclear.

 

It doesn't say where the the "32MB for the iGPU" comes from ...

 

@joevt Thank you for expressing interest in this topic and for continuing the discussion.  I think that the Dortania doc does "say where the 32MB" comes from.  My interpretation of the documentation was that the motherboard allocates this 32MB.  I believe this is an allocation that is easily confirmed when running Windows, but I'm not sure how to view the allocation in macOS.  Further, I believe the Dortania docs imply that the 32MB is an allocation that is not configurable by the end user.

 

17 hours ago, joevt said:

It doesn't say why the solution is to reduce STOLEN and FBMEM instead of increasing something else (like what the motherboard allocates to the iGPU).

 

Maybe this is unclear.  I assumed that the Dortania doc implied that "increasing the motherboard allocation" was not possible, thus the need to constrain STOLEN and FBMEM.

 

Regardless, if the two of us have different interpretations of the Dortania docs and numerous others appear to be using framebuffer-stolenmem=19MB and framebuffer-fbmem=9MB without knowing why, whether it's even necessary and whether 19MB and 9MB are the correct values if it is necessary (as evidenced by their posted EFIs), I agree that the documentation is unclear.

[deeveedee]

@Hervé Great explanation.  Thank you.  I referenced the term VRAM and not DVMT to remain consistent with this guide.  If they are not the same thing, should the guide have stated DVMT instead of VRAM?

 

P.S. I wasn't sure, but I think there's a math error in the calcs you provided here unless I'm not following this example: "In that case, FBmem + Cursormem = 21MB + 9MB = 25MB which remains lower than Stolenmem at 32MB. All is therefore well. " Herve has fixed this math mistake in his post.

Edited October 3, 2021 by tonyx86
Noted that Herve fixed his mistake