BlueToolFixup and Bluetooth-Spoof enabled in the config?Yes. I've never had a problem before. I used to have Big Sur and it worked. I looked in the ktexts folder (EFI) and saw there were files that referenced bluetooth. I can not think of anything.
BlueToolFixup and Bluetooth-Spoof enabled in the config?Yes. I've never had a problem before. I used to have Big Sur and it worked. I looked in the ktexts folder (EFI) and saw there were files that referenced bluetooth. I can not think of anything.
Thank you very much Martin for your quick support. Both were false and I changed it to true. Now the problem is different. Before, I could enter the Bluetooh preference panel although I couldn't activate the slider but now it doesn't let me enter the Blueetooh section. When trying to enter, it gives an error in the preferences. The Bluetooh preferences panel could not be loaded.BlueToolFixup and Bluetooth-Spoof enabled in the config?
I just checked my Firmware version under High Sierra, it is 9144.0.8.6.0. Is this correct? Should I downgrade, and then upgrade again? How do I verify/check my bootrom "healthyness?
I suspect the bootrom may be from the OC EFI boot.
I'll check the system options tomorrow as I'm getting ready to go nighty night.
Thanks for all you help in advance!
Blitz-d
So, how do I check the "healthyness" of the BootRom?
I just checked my Firmware version under High Sierra, it is 9144.0.8.6.0. Is this correct? Should I downgrade, and then upgrade again? How do I verify/check my bootrom "healthyness?
So, how do I check the "healthyness" of the BootRom? I downloaded the tool and images for 4.1 and 5.1 from the House of Moth. So, downgrade, then upgrade using those?
Having OpenCore show 9144.0.8.6.0 doesn't mean at all that the current Mac Pro firmware is really 144.0.0.0.0 - you can have any previous Mac Pro EFI firmware and @h9826790 OC config will still show 9144.0.8.6.0, see below:It's perfect :
– you have the correct up to date BootROM : 144.0.0.0.0, which is displayed 9144.x.x.x.x if you use Martin Lo OpenCore files.
– xxxx.0.8.6.0 : is the version of Martin Lo OC package![]()
<key>BIOSReleaseDate</key>
<string></string>
<key>BIOSVendor</key>
<string></string>
<key>BIOSVersion</key>
<string>9144.0.8.6.0</string>
<key>BoardAssetTag</key>
<string></string>
<key>BoardLocationInChassis</key>
<string></string>
<key>BoardManufacturer</key>
<string></string>
<key>BoardProduct</key>
OKHaving OpenCore show 9144.0.8.6.0 doesn't mean at all that the current Mac Pro firmware is really 144.0.0.0.0 - you can have any previous Mac Pro EFI firmware and @h9826790 OC config will still show 9144.0.8.6.0, see below:
Code:<key>BIOSReleaseDate</key> <string></string> <key>BIOSVendor</key> <string></string> <key>BIOSVersion</key> <string>9144.0.8.6.0</string> <key>BoardAssetTag</key> <string></string> <key>BoardLocationInChassis</key> <string></string> <key>BoardManufacturer</key> <string></string> <key>BoardProduct</key>
You did an off-topic here, no? This is a topic for the BootROM thread, not here.So, I ordered a bunch of the MXIC MX25L3206E from Digikey, and was thinking about using this on the MB instead of soldering a new chip on:
![]()
SMT Socket - Wide SOIC-8 (200mil)
This socket is good for any SOIC/SOP Wide-body 8 pin chip in a 200mil wide body. Simply flip open the latch, insert the chip, and flip down the latch to secure it in place.The chip is held ...www.adafruit.com
So, my next question is what do you reconstruction ROM fellas need to create a new ROM image? I read the link above from tsialex, and am not sure what all the "intermediate" files are.
Let me know or PM me if you can do this with details.
Thanks in advance!
I believe there is no H264 acceleration for AMD7000 at all. Otherwise, the nMP (D700) should has that working natively.Or is H.264 acceleration just not present in AMD7000 at all on Mac?
*Mac doesn't boot anymore after OpenCore installation.*
I installed OC ver. 0.8.6 and after that the boot is stucked with Apple Logo. I tried to remove the main HD including OC and then do NVRAM reset. Doesn't help. I wonder if it happened because I totally forgot to delete previous Lilu from System/Library.
Is there any anyway to fix this? If the problem is Lilu, can I somehow remove it with Terminal? Or my only choice is just to make clean install right now :/
I was on OS 10.14.6. Mac Pro mid 2010. Pulse RX580 installed.
Thank you in advance. I feel so desperate now..
EDIT: Fixed. I took the HD to another computer and removed the Lilu file. Now everything okay.
AFAIK, TRIM is an OS level function that perform from time to time (assume hardware support it).
MacOS perform a manual TRIM during boot. This turn all remaining empty space on the SSD into over provision effectively. Therefore, the SSD should able to perform as expected right after boot to desktop.
However, this is not enough. If you rarely reboot the machine (most Mac user only use sleep indeed), then those TRIMed empty space will still run out eventually.
And the OS will actually TRIM the SSD from time to time. Ideally, this only perform when the system is idle.
I rarely monitor TRIM activity. But one of my net friend did that a few months back. What he found is that MacOS seems only perform TRIM once every few days.
I don’t know if his data is 100% correct. Or if that result only applicable for his SSD, or even his setup. But if that’s true, then if we don’t perform TRIM during boot, macOS should still TRIM the SSD later on, but may need to wait for few days. And in between, the SSD may not perform as expected.
Back to your situation. I don’t know if the system will be locked during TRIM. As I said, it seems that only happen once every few days, and most likely when the system is at idle. Therefore, the user may never notice when TRIM happen.
So, unless every time after lock up, you can find the TRIM record. Then we may safely assume that lock up is TRIM related. Otherwise, that may because something else.
On the other hand, I am not surprised if the system is locked when waiting for storage IO return, that sounds very normal to me indeed.
So, why this lock up only happen on some SSD but not others? I think that may depends on how the controller determine “idle”.
Assume the Samsung SSD controller is very conservative, and only report “idle” (or more precise, “ready for TRIM”) when the disk is at long idle. Then most likely the user is not using the computer, and won’t notice the lock up.
But if the WD controller reports idle more aggressively. Then it may active TRIM inadvertently, which causing a system lock up when the user actually still using the computer.
Anyway, all these are just a theory, I have no prove for that. But this theory fit what I know so far.
Can, but I believe either set 4294967295 or 0 is better. That standard timeout will cause the TRIM stopped at the middle of nowhere. If your SSD is one of those drive which need way more than 10s to finish this APFS startup TRIM thing. Then 10s highly like will still at the scanning phase, which means, end up just spend 10 more seconds on boot, but achieved nothing.Is it OK to set the SetApfsTrimTimeout value to -1 with your package? From what I understand, this will do a standard length TRIM during boot.
If SetApfsTrimTimeout is an unsigned 32 bit value, then -1 = 4294967295Can, but I believe either set 4294967295 or 0 is better. That standard timeout will cause the TRIM stopped at the middle of nowhere. If your SSD is one of those drive which need way more than 10s to finish this APFS startup TRIM thing. Then 10s highly like will still at the scanning phase, which means, end up just spend 10 more seconds on boot, but achieved nothing.
If SetApfsTrimTimeout is an unsigned 32 bit value, then -1 = 4294967295
-1 works as a flag that switches the item off for this particular setting.They are not interchangeable andIf 4294967295 and -1 are interchangeable, I'll use -1 as it's neater
-1 is