OpenCore General Discussion

[Awesome Donkey]

26 minutes ago, Andrey1970 said:

.contentDetails without _

https://www.insanelymac.com/forum/topic/338516-opencore-discussion/?do=findComment&comment=2675278

 

 

Thank you very much kind sir, got it all sorted out.

[Cass67]

On 5/15/2020 at 12:04 AM, Tiem said:

No it’s false. But you’re right. Windows will forcibly install its boot loader to the most primary drive. It’s actually pretty trivial to move that thing. But that’s besides the point.

 

the point is in UEFI mode Windows will install itself anywhere you tell it to. You don’t need to disconnect drives and doing that to m.2s is lunacy. It’s totally possible to install W10 anywhere, you just need to workaround the BL issue which again, is trivial.

 

theres lot of things Windows does forcibly but that doesn’t mean you can’t wrangle it in.

To be fair, i had to pull the power on all my sata drives recently to get W10 to install to a sata ssd, it just would not pass the stage on install after selecting the disk to install to, Just errored out.  Nothing i could do to get around it, spent hours trying to fix it.  Funny thing is, W10 would not install either if i have EFI partition on slice 1... Needed for me to delete all partitions on the install drive and allow it to set the disk up itself.  It made EFI slice 5 or something funky like that.  Only then with all sata drives removed (and a pci-e m.2) and an putting an efi on slice 5 would it install. Even then the arsehole put the BL on the m.2 drive i had left installed as i could not be bothered taking the gpu and m.2 out.. SO... It could be specific to some hardware but there is indeed cases where disks need to be removed to install W10.   I can also remember a time with 18.09 or something it would not allow me to upgrade to 19.03 without removing drives as there was a bug with the installer where the device id's got shuffled around during install time.  This problem may still be in play ..  Its not a blanket true or false scenario..

 

Edited May 16, 2020 by Cass67
few more words

[arsradu]

On 5/16/2020 at 3:08 AM, Cass67 said:

To be fair, i had to pull the power on all my sata drives recently to get W10 to install to a sata ssd, it just would not pass the stage on install after selecting the disk to install to, Just errored out.  Nothing i could do to get around it, spent hours trying to fix it.  Funny thing is, W10 would not install either if i have EFI partition on slice 1... Needed for me to delete all partitions on the install drive and allow it to set the disk up itself.  It made EFI slice 5 or something funky like that.  Only then with all sata drives removed (and a pci-e m.2) and an putting an efi on slice 5 would it install. Even then the arsehole put the BL on the m.2 drive i had left installed as i could not be bothered taking the gpu and m.2 out.. SO... It could be specific to some hardware but there is indeed cases where disks need to be removed to install W10.   I can also remember a time with 18.09 or something it would not allow me to upgrade to 19.03 without removing drives as there was a bug with the installer where the device id's got shuffled around during install time.  This problem may still be in play ..  Its not a blanket true or false scenario..

 

 

It does happen. And you are not alone. Whether or not this is a general issue, that's another story. But it's definitely affecting SOME users. 

I'm just gonna say this. Yesterday I installed Windows TWICE, just to confirm this issue. And I found out that, aside from not letting you install on a specific partition when multiple drives are connected, if you have multiple USB drives, it will also give you another error! 

 

For example, this is what's gonna be created with multiple drives, and below is what's gonna be created with only one drive. Again, after removing, recreating partitions etc etc etc. And personally, I couldn't convince Windows either to install its bootloader on a specific location as it was suggested to be possible before (I'd love to know how), nor start the installation in the first place.

 

This error/warning/whatever the hell it is that prevents going any further with the installation doesn't make any sense to me. I mean, the partition is already created (it created it itself, for God's sake!)...so I don't know about that, and "locate" it?? What do you need, a flashlight?

 

After unplugging the second drive (some motherboards don't have the option to disable the drive in BIOS) and re-deleting and repartitioning... All good!

 

Notice that, in the first case (multiple drives), it added (aside from EFI which was previously created): Recovery, System, MSR. 

With only one drive, it only added MSR. Could that be the cause of the issue? I don't know. I don't really care much about Windows (that's why I'm using MacOS, duh).

 

 

Aaand installing.

 

 

So...is it really so "trivial" to install Windows 10 on a different/separate HDD (cause you do want to have Windows put its things on its dedicated HDD rather than overwriting everything) when you have multiple drives connected at the same time? In my experience, I'd say no. But maybe I'm just too stupid to install Windows. I don't know.

I'm not any kind of guru when it comes to Windows. So it could be indeed specific to some hardwares or hardware setups. But starting with the premise that everyone should know something, or something is "trivial" cause it probably is, FOR YOU, doesn't really help anyone.

 

We're all here to share our knowledge with each other and in the process, learn something new. That means, we start with the premise that we DON'T know everything, we were NOT born with this knowledge, and we're OPEN to learning something new. Also, that we COULD be wrong in our assumptions. So...my opinion is that, if you can help someone, do it. If you can't, don't just insult people to satisfy your arrogant ego.

Edited May 17, 2020 by arsradu

[Synapsis]

I know that I don't know {censored} - after my late 3x something birthday I realised

that this is a very fair assumption to go by. I suggest to try it. Lifts a lot of daily burden

[arsradu]

On 5/14/2020 at 11:05 AM, familygw said:

 

Well, why? Just to 'test' and to say later: real-mac-alike full covered. hahaha --- my idea with the assistant were to download the 'windows support package' to install bootcamp helper in Window; finally I downloaded the software using the tool 'brigadier' https://github.com/timsutton/brigadier, but the doubt remained in my mind.

On my Windows disk I've installed bootcamp and have the same option to 'select startup disk', and that doesn't give me any improvement, just 'fancy' things xD.

 

Hey!

 

So...it took me a while. But I think now I can answer your question. With a few screenshots.  

 

So...is it easy and straight forward to get this done? No. Maybe there are easier ways to do it (it's definitely the first time I'm trying it, and there might be still a few things I didn't completely understand regarding BootCamp's functionality), but the way I did it, I wouldn't call that neither easy, nor straight forward.  So there is plenty of room for improvement there. :))

 

But is it possible to use BootCamp on a hackintosh? Yes, yes it is. And without Brigadier.

 

Should you use it? Hell no. :)) It's just too much work and the outcome is not really worth it. I mean, yes, at this point, you can say you got the most "real-mac-alike" experience you could get on a hackintosh. And if you were on real Apple hardware, I'm pretty sure you would get the same pain in the rear trying to get BCA and Windows to work.

 

I tried to use as few "external" tools as possible. Unfortunately a very straight forward approach was not possible, and I think that could be due to some really annoying bugs with BootCamp Assistant and Disk Utility on MacOS side. 

 

Now, depending on which hardware you're using, things might be different and you might need to search for some drivers online to get some of your hardware working. I didn't have to, since pretty much everything I use is supported in some way on both Windows and MacOS. But your mileage may vary.

 

One thing I couldn't get to work (and if you know how to get this fixed, please, let me know), is the boot back into MacOS. And that seems to be because there is no APFS driver for Windows. So...if you're booting an HFS+ volume, that might work fine. But for APFS...I didn't have much luck. You can still reboot your computer normally and select MacOS from the OC boot picker.

So, maybe with future versions of BootCamp utility this will be added, but right now, at least the version I got, doesn't seem to have that implemented.

 

So...as a proof of concept, I think this turned out very well. Will I continue to use it in the future? No. Most likely not. :)) But it was a fun challenge nonetheless. So I hope I fulfilled your curiosity (and mine).

 

See you around.  

 

 

Edited May 16, 2020 by arsradu

[Andrey1970]

1 hour ago, arsradu said:

One thing I couldn't get to work (and if you know how to get this fixed, please, let me know), is the boot back into MacOS.

Need v6.1+, for example from iMac19,1

[arsradu]

1 hour ago, Andrey1970 said:

Need v6.1+, for example from iMac19,1

 

If you already have an older version installed, the easiest way seems to be using Apple's own Updater tool, directly from Windows.

 

 

Aaand sure enough, that fixed it right up! 

 

 

Thank you very much, Andrey!

Edited May 16, 2020 by arsradu

[Guest]

Hi, I am using latest Opencore 0.59 debug commit on my rig in signature with Proxmox/HighSierra

I have some problems related to internal audio (TRX40 Realtek USB 2.0 audio), sometimes it is scratchy , sometimes it misses sync.

Instead Nvidia DP audio is perfect

I would like to understand if it could be related to this debug lines and if there is a way to debug better this problem (I set on bold type to better evidence )

 

00:000 00:000 OC: OpenCore DBG-059-2020-05-17 is loading in Optional mode (0/0)...
00:002 00:002 OC: Boot timestamp - 2020.05.17 07:21:19
00:006 00:003 OCCPU: MP services threads 64 (enabled 64) - Success
00:008 00:002 OCCPU: MP services Pkg 1 Cores 64 Threads 1 - Success
00:011 00:002 OCCPU: Found AMD Ryzen Threadripper 3970X 32-Core Processor 
00:014 00:002 OCCPU: Signature 830F10 Stepping 0 Model 31 Family F Type 0 ExtModel 3 ExtFamily 8 uCode 0
00:017 00:002 OCCPU: Hypervisor detected

00:020 00:002 OCCPU: VMWare TSC:  3699993000Hz,  3699MHz; FSB:  1000000000Hz,  1000MHz; BusRatio: 3

00:022 00:002 OCCPU: Detected Apple Processor Type: 02 -> 0605
00:025 00:002 OCCPU: EIST CFG Lock 0

00:028 00:002 OCCPU: CPUFrequencyFromTSC           0Hz     0MHz
00:031 00:002 OCCPU: CPUFrequency  3699993000Hz  3699MHz

00:033 00:002 OCCPU: FSBFrequency  1000000000Hz  1000MHz
00:036 00:002 OCCPU: Pkg 1 Cores 64 Threads 64

I would like also say that Internal audio in a Proxmox/windows environment is perfect.

Thank you in advance for any advice you can give

 

Edited May 17, 2020 by Guest

[polkaholga]

On 5/5/2020 at 8:41 AM, polkaholga said:

 

I still can't figure it out what is wrong here.

This error does not happen with CLOVER

 

My actual config added... if someone could take a look i really would appreciate it.

Thanks

config.plist

 

With 0.5.9 the error is gone !

 

 

[Paksman]

If anyone is interested, I wrote MaciASL patch for @vit9696 SSDT-PLUG.dsl Acpi sample: https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/SSDT-PLUG.dsl that injects frequency vector from MP 7,1 to enable HWP/Speedshift on HWP unaware SMBIOS, i.e. iMac 17,1. It is intended to use on desktop configurations, it drops lowest frequency to 800 mHz and EPP is set to 20 (0x20). Remember to enable Speedshift in your BIOS/UEFI and use with CPUFriend kext.

SSDT-PLUG_patch.txt

[hardcorehenry]

1 hour ago, Paksman said:

If anyone is interested, I wrote MaciASL patch for @vit9696 SSDT-PLUG.dsl Acpi sample: https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/SSDT-PLUG.dsl that injects frequency vector from MP 7,1 to enable HWP/Speedshift on HWP unaware SMBIOS, i.e. iMac 17,1. It is intended to use on desktop configurations, it drops lowest frequency to 800 mHz and EPP is set to 20 (0x20). Remember to enable Speedshift in your BIOS/UEFI and use with CPUFriend kext.

SSDT-PLUG_patch.txt

I've tested similarly modified SSDT-PLUG.aml for over a year and confirm that method works.

Edited May 17, 2020 by hardcorehenry

[insanefrancis]

1 hour ago, Paksman said:

If anyone is interested, I wrote MaciASL patch for @vit9696 SSDT-PLUG.dsl Acpi sample: https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/SSDT-PLUG.dsl that injects frequency vector from MP 7,1 to enable HWP/Speedshift on HWP unaware SMBIOS, i.e. iMac 17,1. It is intended to use on desktop configurations, it drops lowest frequency to 800 mHz and EPP is set to 20 (0x20). Remember to enable Speedshift in your BIOS/UEFI and use with CPUFriend kext.

SSDT-PLUG_patch.txt

 

How does this work and how to do it?

My current system's lowest freq is 1.2GHz with iMac19,2 SMBIOS. It would be sweet to drop it to 800 if possible.

[Paksman]

1 minute ago, insanefrancis said:

 

How does this work and how to do it?

My current system's lowest freq is 1.2GHz with iMac19,2 SMBIOS. It would be sweet to drop it to 800 if possible.

Just download SSDT-PLUG.dsl from opencore acpi samples, download MaciASL app from here: https://github.com/acidanthera/MaciASL/releases, open dsl file with downloaded app, copy all content from my previously attached SSDT-PLUG_patch.txt, paste in MaciASL patch window, apply patch, compile to SSDT-PLUG.aml, put the compiled aml to Acpi folder in your bootloader EFI, enable aml in config.plist, install CpuFriend, reboot, done. I tested it on iMac 17,1 SMBIOS but i think it should work on 19,2 too.

[Andrey1970]

1 hour ago, Paksman said:

If anyone is interested, I wrote MaciASL patch for @vit9696 SSDT-PLUG.dsl Acpi sample: https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/SSDT-PLUG.dsl that injects frequency vector from MP 7,1 to enable HWP/Speedshift on HWP unaware SMBIOS, i.e. iMac 17,1. It is intended to use on desktop configurations, it drops lowest frequency to 800 mHz and EPP is set to 20 (0x20). Remember to enable Speedshift in your BIOS/UEFI and use with CPUFriend kext.

SSDT-PLUG_patch.txt

The upper frequencies at different processors different, it too it is necessary to consider in vectors.

[hardcorehenry]

The best solution would be to generate cf-frequency-data
 corresponding to your platform then paste it to SSDT-PLUG_patch.txt. or directly to decompiled SSDT-PLUG.dsl.(then recompile as *.aml) Instruction how to generate ssdt_data.dsl

Edited May 17, 2020 by hardcorehenry

[Paksman]

8 minutes ago, Andrey1970 said:

The upper frequencies at different processors different, it too it is necessary to consider in vectors.

Thanks, i didnt't know that, will have to look at different freqvectors and try to compare data.

[arsradu]

Hi guys,

 

Are the OpenCore errors/warning themselves documented anywhere? I tried to look for them on Github but couldn't find anything. But I probably missed it.

 

There is some very useful document on Dortania here. So that helped a lot.

 

However, it doesn't seem to explain some things. Like: what is "CS:", "OCS:", "OCB:", "OCABC:"? I assume OC prefix probably comes from OpenCore. But what does the S in "OCS" stand for? Also, what about CS?

 

For example, yesterday I was trying to debug this: "OCS: Failed to parse string field of type 1".

Now, while I don't know exactly what type 1 is, I know what a string is. So that helped.

 

So I tried to look through the various scenarios described in the documentation above. And I found something similar.

"Receiving "Failed to parse real field of type 1" "

 

Now, my error was not about a "real" field, it was about a "string" field. But it was enough to get me on the right track.

 

This turned out to be a mistake on my side when trying to use a value set as string instead of integer (human error when editing the config basically). But the only way I found to know which exact line was wrong, was to compare side by side, the sample.plist with my own. Is there an easier way to do that?

 

Also, this made me think: would it be possible, in the case of config related issues, to include the line in the xml where the issue resides? Or some pointers towards it? So that the user can find it and fix it easier? Cause, when it comes to "real" fields, I guess the options are pretty limited. But if it's a string...that can be many things.

 

If this is stupid (which it probably is), please, ignore my question and I apologise for wasting your time reading this.

 

Update: I just realised there is no "CS". Just OCS. But apparently, when it's on the first line, the "O" is pushed all the way to the right. Initially I thought that's a 0 (zero). But it's just the font. :))

 

So it's like:

                                                                                          O
CS: failed to parse... 

So, nevermind.

 

The question still remains though.  

Edited May 17, 2020 by arsradu

[vit9696]

OCS is a short form of OpenCore serialisation module. We will document this. As for the errors themselves, they are documented at the moment, but we gradually improve them to be more clear.

[arsradu]

17 minutes ago, vit9696 said:

OCS is a short form of OpenCore serialisation module. We will document this. As for the errors themselves, they are documented at the moment, but we gradually improve them to be more clear.

 

Awesome, thank you very much!  

[Matgen84]

Hi @vit9696

 

I build latest OpenCore's commit. 2962fbf  on Mojave: disabling 32bits build by default seems not working for me. The script build 32bits version but don't save it.

 

I don't understand this in Terminal windows: ./build_oc.tool: line 472: 60536 Terminated: 15          pingme $! build "$@"  (wd: ~/OC/OpenCorepkg/UDK)

 

Thanks
 

Spoiler

Ran 282 tests in 1.996s

 

OK

Building...

Building OpenCorePkg/OpenCorePkg.dsc for X64 in DEBUG with XCODE5...

.. - OK

Building OpenCorePkg/OpenCorePkg.dsc for X64 in RELEASE with XCODE5...

.. - OK

Building OpenCorePkg/OpenCorePkg.dsc for X64 in NOOPT with XCODE5...

.. - OK

Building OpenCorePkg/OpenCorePkg.dsc for IA32 in DEBUG with XCODE5...

.. - OK

Building OpenCorePkg/OpenCorePkg.dsc for IA32 in RELEASE with XCODE5...

.. - OK

Building OpenCorePkg/OpenCorePkg.dsc for IA32 in NOOPT with XCODE5...

.. - OK

./build_oc.tool: line 472: 60536 Terminated: 15          pingme $! build "$@"  (wd: ~/OC/OpenCorepkg/UDK)

Packaging...

~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/DEBUG_XCODE5/X64 ~/OC/OpenCorepkg

64+0 records in

64+0 records out

64 bytes transferred in 0.024091 secs (2657 bytes/sec)

64+0 records in

64+0 records out

64 bytes transferred in 0.000327 secs (195795 bytes/sec)

~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/DEBUG_XCODE5/X64/tmp ~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/DEBUG_XCODE5/X64 ~/OC/OpenCorepkg

~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/DEBUG_XCODE5/X64 ~/OC/OpenCorepkg

~/OC/OpenCorepkg

~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/RELEASE_XCODE5/X64 ~/OC/OpenCorepkg

64+0 records in

64+0 records out

64 bytes transferred in 0.000322 secs (198694 bytes/sec)

64+0 records in

64+0 records out

64 bytes transferred in 0.000309 secs (207126 bytes/sec)

~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/RELEASE_XCODE5/X64/tmp ~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/RELEASE_XCODE5/X64 ~/OC/OpenCorepkg

~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/RELEASE_XCODE5/X64 ~/OC/OpenCorepkg

~/OC/OpenCorepkg

 

 

Edited May 17, 2020 by Matgen84

[arsradu]

@vit9696 Thank you so much for these two commits!  Awesome!

 

https://github.com/acidanthera/OpenCorePkg/commit/74cc771bac9a74f33a264dbea698b71a16defeda

https://github.com/acidanthera/OpenCorePkg/commit/570a537fc2a3839893a097de7046349b8f747277

[jsl2000]

10 hours ago, vit9696 said:

OCS is a short form of OpenCore serialisation module. We will document this. As for the errors themselves, they are documented at the moment, but we gradually improve them to be more clear.

Thanks for your attention for this issue.

For example what does "OCS: Failed to parse data field of type 1" mean and how to fix it ? Because almost all my OpenCore booting hackintoshs had the same error, but all can boot without other errors. Is it due to my config.plist was edited by PlistEdit Pro ?

Edited May 17, 2020 by jsl2000

[arsradu]

I think you're using "data" tags when you should be using something else (probably integer?). Try to compare the sample plist (or sampleFull.plist) to your own. See what's different.

 

You can try one of these for an easier side-by-side comparison.

 

Also, I don't think it's due to PlistEdit Pro. It could be though due to other editors, such as the OpenCore Configurator.

Edited May 18, 2020 by arsradu

[markl18]

hi I have this is one of my ssd 

 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
            {
                Return GPRW { 0x09 , 0x04 }
            }

339, 6126, syntax error, unexpected '{'

Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
            {
                Return ((GPRW , 0x09) ,
                        (GPRW , 0x04))
            }
251, 6126, syntax error, unexpected ','

 

how do I resolve this

Edited May 18, 2020 by markl18

[Matgen84]

Hi again @vit9696

 

I build latest OpenCore's commit d09762e on Mojave: disabling 32bits build by default don't work for me. The script build 32bits version but package only 64bits.

 

I don't understand this in Terminal windows: ./build_oc.tool: line 490: 21136 Terminated: 15          pingme $! build "$@"  (wd: ~/OC/OpenCorepkg/UDK) 

 

Thanks
 

Spoiler

Building...

Building OpenCorePkg/OpenCorePkg.dsc for X64 in DEBUG with XCODE5...

. - OK

Building OpenCorePkg/OpenCorePkg.dsc for X64 in RELEASE with XCODE5...

.. - OK

Building OpenCorePkg/OpenCorePkg.dsc for X64 in NOOPT with XCODE5...

. - OK

Building OpenCorePkg/OpenCorePkg.dsc for IA32 in DEBUG with XCODE5...

.. - OK

Building OpenCorePkg/OpenCorePkg.dsc for IA32 in RELEASE with XCODE5...

.. - OK

Building OpenCorePkg/OpenCorePkg.dsc for IA32 in NOOPT with XCODE5...

. - OK

./build_oc.tool: line 490: 21136 Terminated: 15          pingme $! build "$@"  (wd: ~/OC/OpenCorepkg/UDK)

Packaging...

~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/DEBUG_XCODE5/X64 ~/OC/OpenCorepkg

64+0 records in

64+0 records out

64 bytes transferred in 0.013454 secs (4757 bytes/sec)

64+0 records in

64+0 records out

64 bytes transferred in 0.000310 secs (206489 bytes/sec)

~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/DEBUG_XCODE5/X64/tmp ~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/DEBUG_XCODE5/X64 ~/OC/OpenCorepkg

~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/DEBUG_XCODE5/X64 ~/OC/OpenCorepkg

~/OC/OpenCorepkg

~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/RELEASE_XCODE5/X64 ~/OC/OpenCorepkg

64+0 records in

64+0 records out

64 bytes transferred in 0.000321 secs (199432 bytes/sec)

64+0 records in

64+0 records out

64 bytes transferred in 0.000313 secs (204444 bytes/sec)

~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/RELEASE_XCODE5/X64/tmp ~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/RELEASE_XCODE5/X64 ~/OC/OpenCorepkg

~/OC/OpenCorepkg/UDK/Build/OpenCorePkg/RELEASE_XCODE5/X64 ~/OC/OpenCorepkg

~/OC/OpenCorepkg