OpenCore General Discussion

[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]

[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.

[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

[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

[mitch_de]

4 hours ago, 5T33Z0 said:

@mitch_de I think Illegal characters can only mean  special characters like the vertical seperator "|" (Alt+7), not regular like letters like "l" (lower case L) or "I" (Upper case i). It could just be a bug in the App.

 

You could run GenSMBIOS and list your current SMBIOS to verify it.

No, its an I like IPHONE. And Andrey1970 posted reason why its illegal (not used in serial). Thanks for help. I will let it until i run in probs - then i know i must generate new serial.

[deeveedee]

19 hours ago, miliuco said:

You say "In the final release of the OC 0.6.8 sample.plist, Quirks KeyInitialDelay and KeySubsequentDelay moved from UEFI> Input to UEFI> AppleInput" and I say no, UEFI > Input hasn't changed from 0.6.7 to 0.6.8, KeyInitialDelay and KeySubsequentDelay have not moved from UEFI > Input to UEFI > AppleInput because they were never in UEFI > Input, at least in final versions.

 

I stand corrected.  Forgive me - I thought this was a developer thread where we were testing Beta versions.  I will refrain from Beta comments and post only comments relevant to final releases.  Thank you for moderating this thread.

[mhaeuser]

8 hours ago, joevt said:

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?

No reliable way, no. Configurators have a habit of borking configs no matter whether the version is supported or not, I don't think we see the benefit.

 

For the rest, yes, I see it is a nice thing, but I do not see what it makes it worth days of implementation and validation. ocvalidate shares most of the code with OC for value validation by the way, so it is not like we maintain a "separate" utility we'd fully control.

[wiliplasen]

When i use the buton shutdonw after press tab buton my sistem reboot, not shutdonw

 

Someone know why?

 

Opencore 068

[mhaeuser]

@wiliplasen Some systems do not support shutdown from UEFI

[Derty]

 

Sorry for bothering with this simplicity, but I don't quite understand what data is wrong .. thank you ..

 

config.plist

<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 7, 2021 by Derty

[deeveedee]

@Derty If you were testing a late Beta version of 0.6.8 (or following late Beta 0.6.8 documentation), you'll see that properties KeyInitialDelay, KeySubsequentDelay and AppleEvent moved to property block UEFI > AppleInput.  Edit your config.plist and remove KeyInitialDelay from UEFI > Input, remove KeySubsequentDelay from UEFI > Input and remove AppleEvent from UEFI > ProtocolOverrides.  Leave your UEFI > AppleInput properties.

 

I had the same problem when I configured my 0.6.8 config.plist using Final Beta documentation.  This late change happened just before the 0.6.8 Final Release.

Edited April 7, 2021 by tonyx86

[miliuco]

39 minutes ago, Derty said:

 

Sorry for bothering with this simplicity, but I don't quite understand what data is wrong...

 

Hola, Derty! I hope you're well.

Remove KeyInitialDelay and KeySubsequentDelay from UEFI > Input and remove AppleEvent from UEFI > ProtocolOverrrides. With that it should work.

 

Edited April 7, 2021 by miliuco

[Derty]

Thank you very much, yes correct, I misunderstood in the guide and do not delete the three items.

thanks guys, now is the start without errors.

Edited April 7, 2021 by Derty