OpenCore General Discussion

[thefat32]

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!

[vit9696]

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.

 

 

[hardcorehenry]

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 April 3, 2021 by hardcorehenry

[iGPU]

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 April 3, 2021 by iGPU

[deeveedee]

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 April 5, 2021 by tonyx86

[pkdesign]

So question. Now that Shutdown and Restart are part of the 0.6.8 ethos, I assume I no longer need to keep ResetSystem.efi in my Tools folder? Is that now redundant?

[vit9696]

On 4/3/2021 at 6:29 PM, iGPU said:

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 2.13 kB · 3 downloads AMD-3970X-dmidecode-result.txt 1.72 kB · 3 downloads

32C CPUs are unsupported by macOS.

[deeveedee]

2 hours ago, miliuco said:

Not.

 

I was referring to two Quirks specifically: In the final release of the OC 0.6.8 sample.plist, Quirks KeyInitialDelay and KeySubsequentDelay moved from UEFI > Input to UEFI > AppleInput.  

[Anto65]

[eSaF]

1 hour ago, 5T33Z0 said:

CAUTION: Just a quick note on 0.6.8 and 0.6.9 config.plist: don't open it with OpenCore Configurator!

 

It adds back in all the removed entries and changes `AppleEvent" Settings from `Builtin` to `OEM`. And after that, you won't even be able to get in the bootloader.

 

Trust me on this one, 'OC Auxiliary Tools' app is the better option and far superior to the one you're referring to. OCAT now has a builtin updater that adds all new OC entries not only to the config.plist but to the major components i.e Drivers, plus a builtin auto OC Validate as soon as you open your config.plist.

[AudioGod]

@eSaF @5T33Z0 That’s just plain old lazy and risky to use apps like that to update and edit your config with plus you learn nothing from getting something to do it all for you. Use XCODE or PlistEditPro and make the changes yourself and you can learn the changes you’re making as you make them. 

Edited April 6, 2021 by AudioGod

[deeveedee]

@AudioGod I have created/edited all of my OC config.plists (currently through OC 0.6.8) with XCode (currently version 12.4).  I still feel that 'configurators' add uncertaintly as I'm debugging the configurator AND my configuration. However, This OC configurator does look very promising.  While I'm still using XCode to perform the editing, I just loaded my config.plist in the configurator and, using the built-in validator, found a few issues that I might need to correct.  It's not lazy - it's a tool: just know how to use it.

Edited April 6, 2021 by tonyx86

[AudioGod]

What’s wrong with ocvalidate to check for errors?

Yes it is a tool but everything I said stands.

 

@5T33Z0 Calm yourself down mate. Yes it is lazy and risky. Does not mean I’m calling you a lazy person and sorry if I struck a nerve... 

Also there’s something called freedom of speech and I can say what I like to who I like and if you don’t like it then you know what you can do fella. 
 

DSDT free laptop...yeah and? Am I meant to be star struck by that or something or does it mean you’re some sort of god? Sorry man I didn’t realise I was in the presence of Hackintosh royalty.....What A Big Man You Are (not) 

 

Edited April 6, 2021 by AudioGod

[deeveedee]

It's lazy to use OCValidate.  Use diff against the sample.plist

[AudioGod]

14 minutes ago, tonyx86 said:

It's lazy to use OCValidate.  Use diff against the sample.plist

No it’s not, that’s just how to double check your work is correct if need be, It’s not like it’s making any changes for you is it bud?

Edited April 6, 2021 by AudioGod

[AudioGod]

Just now, 5T33Z0 said:

 

What is it that makes you think OpenCore Configurator automates? It does nothing on it's own in terms of configuration… so your your argument isn't even valid… it's just a stereotype, like I said.

 

But hey, I bet you managed to configure your Ryzen built all on your own, without the pre-built patch collection for AMD Ryzen CPUs, because you are so god-like with OpenCore…

no it doesn’t Oc auxiliary tools does. 
Anyway now you’re just talking pure rubbish mate. I never claimed to be anything big man. Stop being a 5 year old and showing off with you’re big words and small you know what and stop spamming this thread. If you want to have a problem with me then take it up with me private and il be happy to wind you up some more...lol

 

[pkdesign]

Can we get back on topic people. Enough.

[eSaF]

@5T33Z0- If I may interject, check out the OCAT app it has if not all, most OC automation you'll need without adding useless or obsolete data unlike the other one I won't bother mentioning.

[miliuco]

@eSaF
OC Auxiliary Tools is an excellent and very complete app and I use it thanks to you. But don't forget corpnewt's ProperTree, a simple yet effective app with the ability to snapshot EFI/OC folders.

 

@eSaF @AudioGod @5T33Z0 @tonyx86

The big problem that OC Configurator has is that it must be updated for the exact version of config.plist because, if not, there will be missing or excess keys or even keys whose name, type or position have changed.
But if OC Configurator match config.plist version, it can be a tool that makes certain tasks more comfortable, although I am also in favor of plist editors (ProperTree, PlistEdit Pro, OC auxiliary Tool).

 

As audiogod says, what’s wrong with ocvalidate? It is not a config.plist editor, but in my opinion there is no better tool to check if config.plist is well formed. Provided that both are of the same version of OpenCore, exactly the same. Both elements are created by the same people, OpenCore developers. And ocvalidate is better than diff on sample.plist (imo, of course).

 

Edited April 8, 2021 by miliuco

[eSaF]

@miliuco - I totally agree Bro, if the config.plist is not up to date then you will get a conflicting data read out. I do have Proper Tree, PlistEdit Pro and OCAT on my system and believe use all three to cross reference everything is as should be. I have used the other one (the one that begins with M) and found each time it would add useless data i.e CPU type, instead of the entry '0' for auto it would place something completely different so I removed from my system and would not go near it again. To be fair I do not know if it has been improved since as OCAT is my goto plus it has an unofficial endorsement by Vit9696 the Man himself.

3 minutes ago, Hervé said:

Guys (you know who you are), the flaming stops here. We've taken measure to control behaviour and content moderation will be implemented. Whilst everyone is entitled to his/her opinion on everything, there's absolutely no reason to become overly sensitive/upset on one hand and pour oil on fire on the other.

 

All OpenCore tools have their own benefits and disadvantages and each deserve credits to their respective authors. No need to make statements that are bound to hurt to people who use them and insist on the matter.

 

MATTER CLOSED.

Sorry Have - just saw the notice.

[joevt]

Can the schema defined in OcConfigurationLib be transformed into an .xsd, then the "xmllint --noout --schema config.xsd config.plist" command can be used to verify a config file? The .xsd could be included with the config.plist file so third party utilities can use it to verify the plist.

 

The names of fields for the config schema are in OcConfigurationLib.h and OcConfigurationLib.c. The fields are in a different order in each file though. Is there a reason the fields in OcConfigurationLib.h can't be alphabetical like in OcConfigurationLib.c?

 

It seems redundant to have the fields in more than one file. Can the redundancy be removed by using some preprocessor magic? Basically, put the schema in a separate file - make it contain only comments and invocations of macros, no other C code or #defines. When you need to do the declarations or code for the fields in a .h or .c file, do the #defines for the macros, #include the schema file, then #undef the #defines (maybe the #undefs can be at the end of the schema file). The schema file can be #included multiple times in the same source file using different #defines each time.

 

Maybe the schema macros can include the documentation for the fields. A tool can have #defines to printf the documentation from the schema file, then #include the schema to do the printfs. Then the .tex and .pdf can be built from the result of using the tool. This way the documentation will automatically match the source (at least for the fields part of the documentation). Maybe a similar tool can build an .xsd...

 

[mitch_de]

Yep here also,  newest OC Configurator displays an already existing  Buildin right  but changes the Event to OEM if you save it. 

 

Question ( a bit off OC topic but may be interesting) : I am now on OC 0.68 ,all OK.

But i used first time the Tool OC Auxiliary Tools which can validate (as OC Tool) and sjow Systeminfo.

Here i seen first time ever (i use same generated serial since a few years!) an Warning about Serial which contains an "I". Google for that gives info "I" is wrong.

Can i run in probs  with OC using that serial? Apple ID, App Store working (since a few years with that bad serial).

 

[mhaeuser]

@joevt Your idea is interesting but expensive. What would be the big advantage of the new verifying over ocvalidate?

Config options are "rarely" changed, we never released with out-of-sync scheme and docs as far as I am aware.

 

Don't get me wrong, I'm sure it'd be a nice idea if we were at the very beginning again. But we have a solution I'm not sure what kind of problem you're trying to fix of.

[joevt]

1 hour ago, Download-Fritz said:

@joevt Your idea is interesting but expensive. What would be the big advantage of the new verifying over ocvalidate?

Config options are "rarely" changed, we never released with out-of-sync scheme and docs as far as I am aware.

 

Don't get me wrong, I'm sure it'd be a nice idea if we were at the very beginning again. But we have a solution I'm not sure what kind of problem you're trying to fix of.

xsd's are a standard method for validating xml documents but the xsd verifying method probably would not have much benefit over ocvalidate. With an xsd, a field can have facets for validating length, ranges, enumerations, and patterns. ocvalidate does some of that already and other things.

 

The point of the changes is to increase information localization and density. If the info is in a single file then only one file needs to be edited (instead of two) to change the information for a field. The macros can be used to remove parts that are common to a majority of fields of the same type to improve readability. OC already uses many macros - so adding a few more won't make it much more difficult to follow (besides, you can make the compiler output the preprocessed result to see what's actually happening).

 

I was thinking about the problem of OC Configurator messing up the config. Is there a way for it to know that the config file is a different version than it expects?

 

[Andrey1970]

4 hours ago, mitch_de said:

Yep here also, 

 newest OC Configurator displays an already existing  Buildin right  but changes the Event to OEM if you save it. 

 

Question ( a bit off OC topic but may be interesting) : I am now on OC 0.68 ,all OK.

But i used first time the Tool OC Auxiliary Tools which can validate (as OC Tool) and sjow Systeminfo.

Here i seen first time ever (i use same generated serial since a few years!) an Warning about Serial which contains an "I". Google for that gives info "I" is wrong.

Can i run in probs  with OC using that serial? Apple ID, App Store working (since a few years with that bad serial).

 

 

Letters I and O aren't admissible because are similar to digits 1 and 0.

https://github.com/acidanthera/OpenCorePkg/blob/master/Utilities/macserial/FORMAT.md