MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro

[205Maxi]

Also the backup as well.
[automerge]1572907402[/automerge]


do you mind Zip the ROM, and send them to me via PM?

Ok i will...

 

[205Maxi]

Ok i will...

I am on the phone and can't find where to send you a pm...
[automerge]1572913491[/automerge]

Thanks for keep testing even though you know the risk.

Hopefully that won’t happen again, but if really brick again, please remember to hardware dump the corrupted ROM image.

Anyway, my config file is more complicated than that. To mix 5,1 and 7,1’s info “correctly”, I use manual mode, but not auto mode.

That’s why I didn’t post it yet, awant to do that with a proper keyboard.

Even may be you only want the config file. I
still prefer to explain what I changed and why.

My config file only work for my hardware setup. Definitely won’t work for everyone automatically.

I may also need to explain more about how to edit that config to fit your own hardware.

please try to send me a PM and i will reply. Thanks...

 

[jackluke]

To those who want to test a Sidecar patched file that I made, it's correctly working on any supported Catalina Mac and any iPadOS devices (at least in wired usb-lightning cable mode) if the Mac has the Wifi ac then also in wireless mode, consider that for iPad Air 2, mini 4 , iPad 5th and 6th gen only wired, and you can't have the HEVC quality, but only some kind of H264 video streaming compression:

Sidecar - Has anyone got it working?

Even if the previous beta9 patch still worked, here is the updated Sidecar patch. Steps: - disable SIP, at power-on CMD+R, then from Recovery Terminal: csrutil disable ; reboot - from a Catalina Terminal make temporary writeable the System folder: sudo mount -uw / ; killall Finder - open...

forums.macrumors.com

 

[205Maxi]

You tried all the ports on the graphic card?

There should be only one port works with that config file.

Sorry well this time i lost everything my dumped rom, i had to reinstall everything from scratch as my nvme got somehow corrupted too.
So i am sorry.

if you by PM provide or with Mega.nz provide a link where i can download your files maybe since my machine is 12 cores maybe we will have a bricked firmware again.

lets try at this point i do not really care i have installed everything from scratch and i do not plan to reinstall all apps yet.
Thank you for your understanding.

Maxi

 

[tsialex]

@h9826790 This is the time that we need to stop and take some steps back. You provided enough info to reproduce your findings and we confirmed it. Now people without the necessary knowledge are trying to the same and consequently more people will brick backplanes.

Like I said before, #673, #678, #680 I'm inclined to say that spoofing another Mac is not safe and for sure is a blunt solution to achieve HEVC hardware encoding.

We now need to work in two different ways, the first one is to determine what is triggering the binary blobs inside the NVRAM and work with OpenCore developers to prevent it since we still need OC for the VMM flag spoofing, the second one is to investigate what Apple test inside AppleGVA for HEVC to be activated and implement it without SMBIOS spoofing.

SMBIOS spoofing is a Pandora’s box. It’s very useful for investigate and develop, but I bet that now people will use it as a easy way to fake 2012 Mac Pros, for example.

 

[205Maxi]

@h9826790 This is the time that we need to stop and take some steps back. You provided enough info to reproduce your findings and we confirmed it. Now people without the necessary knowledge are trying to the same and consequently more people will brick backplanes.

Like I said before, #673, #678, #680 I'm inclined to say that spoofing another Mac is not safe and for sure is a blunt solution to achieve HEVC hardware encoding.

We now need to work in two different ways, the first one is to determine what is triggering the binary blobs inside the NVRAM and work with OpenCore developers to prevent it since we still need OC for the VMM flag spoofing, the second one is to investigate what Apple test inside AppleGVA for HEVC to be activated and implement it without SMBIOS spoofing.

SMBIOS spoofing is a Pandora’s box. It’s very useful for investigate and develop, but I bet that now people will use it as a easy way to fake 2012 Mac Pros, for example.
[/QUOTE

i think that i can still go on with the testing as i now have a bed testing machine, so i really don't mind testing with the files H9826790 has and report . I also think its up to me to decide wether or not i want to brick my own machine and do testing to also contribute with this, with all my due respect. As far i know i did not complain but rather even laugh about. So i asked him if it could share the files so we could see where the problem would be eventually or reproduce if problem there is with OC or SMBIOS ...

I want to say thank you for the hard work and i am confident we together can do great.

 

[tsialex]

@205Maxi For sure, you are free to do as you please, but you are not helping since you didn’t save the bricked dump and for some weird motive you can’t provide the backup/dump it again for us to check if you already had problems that could cause the brick.

Anyway, I already told what I had to say about SMBIOS spoofing and I’m going back to investigate the binary blobs.

 

[205Maxi]

@205Maxi For sure, you are free to do as you please, but you are not helping since you didn’t save the bricked dump and for some weird motive you can’t provide the backup/dump it again for us to check if you already had problems that could cause the brick.

Anyway, I already told what I had to say about SMBIOS spoofing and I’m going back to investigate the binary blobs.

That is why i asked the files, with i can try to reproduce. And it could happen again. I was going to give the corrupted one when my nvme ssd got corrupted or something i could not access the ssd and lost everything that was on. Sorry.

 

[tsialex]

That is why i asked the files, with i can try to reproduce. And it could happen again. I was going to give the corrupted one when my nvme ssd got corrupted or something i could not access the ssd and lost everything that was on. Sorry.

If you really want to help, stop what you are doing and dump your BootROM immediately and let @h9826790 check it before anything (since Martin is out of town, I can check it when I have free time).

It’s stupid to continue acting this way, you will brick again and this time without a backup dump.

 

[joevt]

Anyway, brick means won’t POST. You can’t hear the “Don”.

You can disable the startup chime by turning down the Internal Speakers volume before restarting (might need to disconnect headphones and line out to see the Internal Speakers option).

 

[jackluke]

You can disable the startup chime by turning down the Internal Speakers volume before restarting (might need to disconnect headphones and line out to see the Internal Speakers option).

This is true, but I guess @205Maxi after bricked the first thing tried for recovering was a PRAM reset that resets also to default the power-on chime volume, that's why needed to SPI flash the firmware back, surely wasn't an EFI (disk0s1 partition) mismatch.

 

[h9826790]

That is why i asked the files, with i can try to reproduce. And it could happen again. I was going to give the corrupted one when my nvme ssd got corrupted or something i could not access the ssd and lost everything that was on. Sorry.

You don’t need my file to reproduce that firmware corruption.

You did that without my config file. If you want to help, want to reproduce that, You should try everything you did but not with my config.

Anyway, you can still send me your current dump if you lost the backup. I am sure the very first thing you need to do now is make another BootROM backup. Otherwise, if you brick your logicboard again, it will be extremely hard (or even impossible) for you to recover it properly.

I will PM you now, and you can simply zip your current dump, and send that to me via PM. Thanks in advance.

 

[Fairdinkem]

Boot from recovery and you should be able to bless the partition or disable SIP if you want to execute it from within macOS

Edit: Another option is to bless the BOOTx64.efi file:

sudo bless --mount /Volumes/EFI --setBoot --file /Volumes/EFI/EFI/BOOT/BOOTx64.efi

I keep getting the following error with or without following your suggestion. I don't get it I have followed the guide in post one implicitly I don't know what I am missing

I get this error as follows.

Can't load /Volumes/EFI/usr/standalone/i386/apfs.efi

Could not load apfs.efi data from /Volumes/EFI/usr/standalone/i386/apfs.efi

 

[w1z]

I keep getting the following error with or without following your suggestion. I don't get it I have followed the guide in post one implicitly I don't know what I am missing

I get this error as follows.

Can't load /Volumes/EFI/usr/standalone/i386/apfs.efi

Could not load apfs.efi data from /Volumes/EFI/usr/standalone/i386/apfs.efi

Why are you blessing apfs.efi when you be should be blessing BOOTx64.efi as per my suggestion? Also why is /usr/standalone/i386/apfs.efi in the EFI folder? What's your mac pro's model?

Edit: Sorry, just noticed that it was an error you were receiving and not a command you were entering. Are you using a cMP 2,1 or 3,1?

 

[h9826790]

You can disable the startup chime by turning down the Internal Speakers volume before restarting (might need to disconnect headphones and line out to see the Internal Speakers option).

I know that speaker volume thing, but still thanks for eliminating some possible unnecessary confusion.

Anyway, line out or headphone won’t stop that chime. I tested it on my cMP.

 

[startergo]

I know that speaker volume thing, but still that’s for eliminating some possible unnecessary confusion.

Anyway, line out or headphone won’t stop that chime. I tested it on my cMP.

I stopped the chime on my Mac mini 3.1 with NVRAM variable.

 

[jackluke]

@cdf does your config file works too if using the latest OpenCore 0.5.2 and AppleSupportPkg 2.1.2 ?

Another question about your "4b" point:

4b) Enable the VMM flag: Find the Cpuid1Mask entry, and carefully change AAAAAAAAAAAAAAAAAAAAAA== to AAAAAAAAAAAAAACAAAAAAA==. The value should now be the same as for Cpuid1Data.

To revert to a non-VMM-flag , without a PRAM reset, is suffice to remove that entire XML "Emulate" string <dict></dict> , or the cpuid1mask entry should be reverted first to its default value to "A*==" rebooting from OC bootloader ?

 

[startergo]

does your config file works too if using the latest OpenCore 0.5.2 and AppleSupportPkg 2.1.2 ?

I am using 0.5.2 version. On the top of my head the second field for the cpuid equal to 0 in hex removes the VMM flag. I believe this is how the config file in the post is because I had to make second field the same as the first one using the config file.

 

[cdf]

@cdf does your config file works too if using the latest OpenCore 0.5.2 and AppleSupportPkg 2.1.2 ?

The configuration file has been updated for these versions.

To revert to a non-VMM-flag , without a PRAM reset, is suffice to remove that entire XML "Emulate" string <dict></dict> , or the cpuid1mask entry should be reverted first to its default value to "A*==" rebooting from OC bootloader ?

The easiest thing to do is to change the C back to an A in the Cpuid1Mask (effectively, zeroing the mask).

 

[startergo]

@h9826790 This is the time that we need to stop and take some steps back. You provided enough info to reproduce your findings and we confirmed it. Now people without the necessary knowledge are trying to the same and consequently more people will brick backplanes.

Like I said before, #673, #678, #680 I'm inclined to say that spoofing another Mac is not safe and for sure is a blunt solution to achieve HEVC hardware encoding.

We now need to work in two different ways, the first one is to determine what is triggering the binary blobs inside the NVRAM and work with OpenCore developers to prevent it since we still need OC for the VMM flag spoofing, the second one is to investigate what Apple test inside AppleGVA for HEVC to be activated and implement it without SMBIOS spoofing.

SMBIOS spoofing is a Pandora’s box. It’s very useful for investigate and develop, but I bet that now people will use it as a easy way to fake 2012 Mac Pros, for example.

This may be a solution to prevent NVRAM write:

Emulated NVRAM | Opencore Vanilla Desktop Guide

khronokernel-2.gitbook.io

 

[Ludacrisvp]

This may be a solution to prevent NVRAM write:

Emulated NVRAM | Opencore Vanilla Desktop Guide

khronokernel-2.gitbook.io

I too suggested this path, but ideally we want to keep it as non-hackintosh as possible, was the essential answer.

 

[tsialex]

I too suggested this path, but ideally we want to keep it as non-hackintosh as possible, was the essential answer.

The end goal is to enable hardware encoding and the less we hackintosh our MP5,1s, the better. Maybe we will need to enable NVRAM emulation for investigating what is needed in a safe way for people that don't have MATT cards or a way to easily reflash the SPI, so I'll take a look at it.

Let's not forget that the hackintosh community did not investigate the hardware encoding problem since they obligatory have to use SMBIOS spoofing and live/work around it's problems. We don't need to and will be better for everyone if we find what's really need to enable it. Maybe we find a way to remove the soft block and implement it just via Lilu/WTG.

 

[jackluke]

@cdf I tried your OpenCore config on a MacBook7,1 mid 2010 , and I can boot using OpenCore from that machine on Catalina, after from its Terminal typing this: "nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102: opencore-version"

I get this output:

4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version REL-052-2019-10-30

But if send "sysctl machdep.cpu.features" I get this:

machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 XSAVE

I can't notice the VMM flag, maybe the "cpuidmask" for "mobile cpus" is different ?

 

[cdf]

I can't notice the VMM flag, maybe the "cpuidmask" for "mobile cpus" is different ?

Out of curiosity: can you check the output of the following command?

sysctl kern.hv_support

 

[jackluke]

Out of curiosity: can you check the output of the following command?

sysctl kern.hv_support

Here is the output: kern.hv_support: 0

It should be "1" ? But I can use virtualization software on that machine and it worked, also you can notice the "VMX" Cpuid flag previously posted.