So, only bricks mine thenYou can still test it for bricking without the NVMe drive. If it doesn't brick, I'm not averse to testing NVMe performance. Just make sure it doest brick the MP51.
So, only bricks mine thenYou can still test it for bricking without the NVMe drive. If it doesn't brick, I'm not averse to testing NVMe performance. Just make sure it doest brick the MP51.
So, only bricks mine then
No, it didn't fix it here, and it has increased my boot times dramatically. It now takes a VERY long time (over a minute) to boot into either OS. Both SATA and NVMe. Seriously degraded boot performance for me so far. Still going to try a hunch I have about something though.
ON MY SYSTEM (net necessary anyone else)....
Double boot 2-step is caused or affected by SIP enable/disable.
If I fully enable SIP, I get an 80 sec. boot time into HS after fully shutting down Mojave. But it doesn't double boot any more. I get EXACTLY the same times when switching OS's in the other directions as will. Also no double booting.
Subsequent boots into the same OS (HS) have increased from 27 seconds from chime, to 34 seconds. I didn't time Mojave but it's in the same ball park.
Turning SIP back off triggers double boot 2-step again, and 80 second boot times regardless. The longer boot times did not exist prior to this latest NVMe test.
[doublepost=1536007104][/doublepost]
You can still test it for bricking without the NVMe drive. If it doesn't brick, I'm not averse to testing NVMe performance. Just make sure it doest brick the MP51.
Also, going to send you my DUMP with this new update to see if any anomalies may have appeared that could be causing ancillary booting issues.
No sure if it's related. But APFS + TRIM enable may hit a slow boot bug. If you are using APFS, you may try disable TRIM to see if boot time back to normal.
Anyway, tsialex also help me to reconstruct my BootROM. NVMe DXE is injected, no change on boot time.
Since my cMP has no NVMe onboard yet, so, it's quite clear that the NVMe DXE injection alone shound't affect the boot time. It should be something else in your case.
[doublepost=1536019846][/doublepost]
Just see this post, so, your boot time issue is SIP related for BOTH OS?
Is your 10.14 upgrade from a 10.13 clone? Or it's a clean installation?
Slow boot / double boot is related to SIP. It boots fine when enabled.
I put together a reconstructed BootRom and injected/flashed. I was comparing the performance with a previous version of the NVMe driver when I noticed the affect SIP had on booting.
We have tested several BootRom versions and only testing. Machine boots fine.
Both 10.13.6 installs and the 10.14 install are clean/fresh unmolested for testing.
Yes, slow-ER boot/double boot occurs when changing from Drive A to B, or B to A.
I see, I am still wondering if this is related to APFS.
Maybe a good idea to specify whether one does a COLD BOOT. . or .. a HOT RESTART boot.
Sorry, I should have been more specific.
I meant cold boot = starting after a shut down.
warm boot = restart after cold boot.
I understand that, but was there a specific post in question? I posted that information in 805 above.
I thought you were referring to something in that post.
Well you edited that post after MIKX posted his. I'm not sure if you added the info about cold boot vs. restart or not, but that is what I think he was asking everyone to make clear in their reports of boot time--does it vary based on whether it was a cold boot or a reboot? If you indeed did have that info in your post originally then maybe he missed it.
Actually no I didn't, not for the 2nd post. After he posted the 1st time, I immediately updated it for clarity but it was there all night before the 2nd post. So I'm trying to understand if there was another post that needed clarity.
Yes it does vary whether cold or warm booting. I wasn't giving a benchmark of booting. Just reporting it was slower for me on a magnitude.
Is there some other point that needs clarification on this? It was simply to say that on MY machine, booting performance was much degraded.
My apologies for confusing anyone or failing to include enough information on the first post.
I don't think any offense was intended
Ok, thx.Same 138 firmware in build 18A384a. Just checked with iHex.
Same 138 firmware in build 18A384a. Just checked with iHex.
If anyone here is installing the new build with RX580, please check for HEVC encoding support.Ahhhh good news, at least the same for now! thanks
Where is the firmware file located?