Jump to content
8755 posts in this topic

Recommended Posts

Multiple Opencore configurations?

Is this possible?

My laptop has a Mojave supported dGPU, but Catalina/BS can't recognize it (bad drivers) and boot stalls, so I need to have different Opencore EFI folders and switch between them using refind.

Is it or would it be possible to just be able to select a different config file on the fly like on Clover? This would also help when trying new things.

3 hours ago, Download-Fritz said:

All you do with that is losing the flexibility of leaving at least some of the upper memory accessible to e.g. hibernation.

 

Thanks for confirming.  The RTC memory size patch (0x02) will be my OC baseline now.  It is working perfectly.  Also, thanks @theroadw ;)

Edited by tonyx86
  • Like 1

@tonyx86 Confirming what? I said that the SSDT approach is a real subset (as in the SSDT can do nothing more than the kext can do, but the kext can do upper subranges which the SSDT can't do). You basically break parts of hibernation and FV2 unattended restart, and call it a day.

You confirmed that RtcMemoryFixup isn't fixing anything that concerns me.  That's not a criticism or complaint - it just is.  Setting RTC memory size to 0x02 does everything I need for the way I operate my hack - no hibernation, no FV2 unattended start.

 

EDIT: I have been running with the RTC patch (instead of RtcMemoryFixup.kext) for a week now and all is perfect.  My latest conclusions are here.

Edited by tonyx86
Added note after running with RTC patch for a week
  • Like 1

Hi! I have this machine: HP DC7800 (Core2 Duo E7200, HD7750, 8GB DDR2 SDRAM). I started to install OpenCore BS few months ago. It was a process, but finally I had a full functional BS computer (no quirks need it for boot). After a while I started to have problems booting and now I can't pass [EB|#LOG:EXITBS:START]. I tried everything (OpenCore guid troubleshooting, all quirks and combinations, hardware change) but not avail. Maybe somebody can help me. 

OC.zip

Edited by Stefanalmare
9 minutes ago, Hervé said:

 @Stefanalmare this thread is actually related to OpenCore development/behaviour/bugs/features and that sort of things; hence it's presence in the Developers section. It's not a general support thread so please open up a dedicated thread for your system in the relevant desktop section.

I thought it may be interesting that a legacy computer worked very well using OpenCore and upgrading (OpenCore) boot process is degrading until stop booting.

Edited by Stefanalmare

@5T33Z0 - Looks like that translation / formatting was a lot of work.  Very informative.  Thanks!

 

EDIT: This CMOS patch is working perfectly for me here.

Edited by tonyx86
Fixed link to patch
On 3/29/2021 at 11:43 PM, 5T33Z0 said:

I took some time to translate Daliansky's OC Little Github with its impressive colletion of ACPI Hotpatches and Guides from chinese to englsh using deepl and google translate. Then I re-wrote and re-structured a lot of the guides to make them more readable and to fix some of the formatting. Maybe this might be helpful to other users.

 

https://github.com/5T33Z0/OC-Little-Translated

 

Thank you for your work!!!

16 hours ago, 5T33Z0 said:

I am not quite done yet. I probably will relocate it into the CMOS Fix section.

Glad to see it's no longer "Obsolete."  A very useful patch. :)

  • Like 1
On 3/31/2021 at 10:47 PM, 5T33Z0 said:

I am wondering: now that we can specify in which exact location renames shall be applied via the "base" parameter, shouldn't it be  possible to convert over patches from Clover that utilized the TGT Bridge?

 

I've got this issue with my Lenovo T530 where hibernate on Lid close is not working. Clam shell mode is also not working. The main display is not transferred over to the external monitor. Been trying to fix this for months. In Clover it's working fine.

Not all renames can be applied via “base”. Easy to find out with ACPIe(to test it I needed to rename DSDT.aml to DSDT.bin). If result is: “EXIT: ACPI table is incorrect or not supported by parser!” instead of “Returned offset: “something”” Base and BaseSkip need to be empty(old fashioned;) count, skip "way" have to be used).
ACPIe can be found in Utilities.

Edited by hardcorehenry
  • Like 1

I'm getting ready for OC 0.6.8.  Am I correct in understanding that if my ACPI patches are working in OC 0.6.7, that I simply need to prepend each patch with the following (for OC 0.6.8)?

				<key>Base</key>
				<string></string>
				<key>BaseSkip</key>
				<integer>0</integer>

EDIT: In addition to the Base/BaseSkip additions for ACPI patches, it looks like my OC 0.6.7 config.plist will have the following additions for OC 0.6.8:

  • Add Booter > Quirks>ForceBooterSignature (Boolean, false)
  • Add UEFI > Input > KeyInitialDelay (Integer, 0)
  • Add UEFI > Input > KeySubsequentDelay (Integer, 0)
  • Add UEFI > Output > GopPassThrough (Boolean, false)

 

EDIT2: It appears that some of the UEFI > Input properties have moved to UEFI > AppleInput.  See here.

Edited by tonyx86
Added note about UEFI > AppleInput
  • Like 1
29 minutes ago, tonyx86 said:

Готовлюсь к OC 0.6.8. Правильно ли я понимаю, что если мои патчи ACPI работают в OC 0.6.7, мне просто нужно добавлять к каждому патчу следующее (для OC 0.6.8)?


				
				
				
				

 

Yes2104222417_2021-04-0119_33_23.png.75054f39c2df0535623127a4f99a5278.png

  • Thanks 1
11 minutes ago, Антико said:

Yes

 

Thank you.  I modified my previous post to include all of the config.plist changes that I think I need to migrate from OC 0.6.7 to OC 0.6.8.

  • Like 1
1 hour ago, tonyx86 said:

 

 

Add Booter > Quirks>ForceBooterSignature (Boolean, false)

  • Add UEFI > Input > KeyInitialDelay (Integer, 0)
  • Add UEFI > Input > KeySubsequentDelay (Integer, 0)
  • Add UEFI > Output > GopPassThrough (Boolean, false)

I do not use them, although they are present in my config. plist. You may need them.

Снимок экрана 2021-04-01 в 20.22.04.png

Снимок экрана 2021-04-01 в 20.23.04.png

  • Thanks 1

Hi there. I'm having trouble finding info about ExtendBTFeatureFlags quirk. I know it is a replacement for BT4LEContinuityFixup kext. I'm currently using an USB Bluetooth dongle on my hack and it does not work when ExtendBTFeatureFlags quirk is on. Anyone knows if this quirk should work with USB dongles? in that case how to debug it?

OC Developers,

 

I frequently review your github repo and each time I finish my review, I'm blown away by the volume of work and attention to configuration management.  Just when I think your work load will diminish in a subsequent release, I see that your work load has actually increased, yet you relentlessly persist.   Your work is impeccable. In addition to the challenge and reward of hacking my own rigs, the thing I will miss most when I switch to Apple silicon is watching you all work your magic.  You have and continue to do an incredible job.  Thank you!

  • Like 11
29 minutes ago, tonyx86 said:

OC Developers,

 

I frequently review your github repo and each time I finish my review I'm blown away by the volume of work and attention to configuration management. Just when I think your work load will diminish in a subsequent release, I see that your work load has actually increased, yet you relentlessly persist. Your work is impeccable...  

Thank you!


I think the same!!!

  • Like 4
4 hours ago, tonyx86 said:

OC Developers,

 

I frequently review your github repo and each time I finish my review, I'm blown away by the volume of work and attention to configuration management.  Just when I think your work load will diminish in a subsequent release, I see that your work load has actually increased, yet you relentlessly persist.   Your work is impeccable. In addition to the challenge and reward of hacking my own rigs, the thing I will miss most when I switch to Apple silicon is watching you all work your magic.  You have and continue to do an incredible job.  Thank you!

I think you find the exact word to describe their work, it's really impeccable!

  • Like 2
On 4/1/2021 at 9:48 AM, hardcorehenry said:

Not all renames can be applied via “base”. Easy to find out with ACPIe(to test it I needed to rename DSDT.aml to DSDT.bin). If result is: “EXIT: ACPI table is incorrect or not supported by parser!” instead of “Returned offset: “something”” Base and BaseSkip need to be empty(old fashioned;) count, skip "way" have to be used).
ACPIe can be found in Utilities.

Filing an issue and submitting a table, and a search path may help. Will not promise immediate fixes, but will at least look eventually.

 

 

  • Like 3
5 hours ago, vit9696 said:

Filing an issue and submitting a table, and a search path may help. Will not promise immediate fixes, but will at least look eventually.

 

 

I’m afraid I didn’t precisely write what I meant, I’ll try to rephrase my previous post. Very few SSDT-hotpatches from Daliansky repository require renames that “have no base”(for example _PTS and probably few more), in that case Base and SkipBase need to be empty and count, skip values might need additional attention. Sorry if my previous post sounded like an issue, but there aren’t any(at least not that I'm aware of). Everything works perfectly for me.


Thank you and other Acidanthera members for your efforts.

Edited by hardcorehenry
  • Like 1

vit9696,

 

Thank you (and others) for all of your amazing work.

 

I'm using the latest OC releases (now v068 d3be085) under Big Sur 11.2.3. When ProcessorType is set to 0, I do not see recognition of the processor (AMD Threadripper 3970X). So according to the OC docs request, I'm attaching the results from sysctl machdep.cpu and dmidecode for this set up.

AMD-3970X-sysctl-machdep-cpu-results.txt AMD-3970X-dmidecode-result.txt

Edited by iGPU

EDIT: A new UEFI > AppleInput properties block has indeed been added to the config.plist for OC 0.6.8.  My complete list of EFI changes (including those required for OC 0.6.8 and some not required for OC 0.6.8) is here.

 

---------------------------------------

 

I think I'm seeing things...  Did a new UEFI properties block called AppleInput get added to config.list for OC 0.6.8?  Does this new UEFI > AppleInput properties block now include some properties that used to be in the UEFI > Input block?

 

		<key>AppleInput</key>
		<dict>
			<key>AppleEvent</key>
			<string>Builtin</string>
			<key>CustomDelays</key>
			<string>Auto</string>
			<key>KeyInitialDelay</key>
			<integer>0</integer>
			<key>KeySubsequentDelay</key>
			<integer>5</integer>
			<key>PointerSpeedDiv</key>
			<integer>1</integer>
			<key>PointerSpeedMul</key>
			<integer>1</integer>
		</dict>

 

Edited by tonyx86
  • Like 1
×
×
  • Create New...