[HOW TO] OpenCore 0.9.1 > 0.9.2 differences

[Deleted member 188658]

My Z390 system always has had a Samsung SSD EVO 970 M.2 boot drive containing my OC EFI and Mac OS. But for the first time when booting OC 0.9.2 I have a quick boot. No more Trim slowness with the EVO 970 drive.

Is this expected?

 

[miliuco]

@Deleted member 188658
Not sure. As far as I know there is no changes related to this.
EVO 970 is known to have Monterey and Ventura issues with long boot times. But not for all users.

 

[wstrohm]

I also use Samsung M.2 drives in my Hacks. Two 1 TB 970 Pros in computer at left; one 512 GB 970 Pro in "Mini-ITX 3" listed below. On Big Sur (APFS file system) my computer at left requires about 59 seconds to boot (on previous OpenCore versions), but on Mojave running HFS+, it boots in 19 seconds. "Mini-ITX 3" has always been on High Sierra, and also boots in about 20 seconds. Although presently booting both computers using OC 0.9.2, neither has been tried on later Mac OS versions with that EFI boot loader version. Now I'm curious!

 

[5T33Z0]

DisableIoMapperMapping is unrelated to whether or not an iGPU is enabled/disabled. It's only needed to remove Reserved Memory Regions provided by a DMAR table from memory in macOS so certain Ethernet/Wifi/TB Cards which require AppleVTD can work. Z490 by Gigabyte are affected by this for example. It also works independently of DisableIoMapper. Imo, I think they should have given it a different name because people assume it is dependant on DisableIoMapper being enabled - which it's not.

 

[miliuco]

@5T33Z0
Thanks. Fixed the first post to match current OpenCore documentation.

 

[Jasonhacks]

DisableIoMapperMapping is unrelated to whether or not an iGPU is enabled/disabled. It's only needed to remove Reserved Memory Regions provided by a DMAR table from memory in macOS so certain Ethernet/Wifi/TB Cards which require AppleVTD can work. Z490 by Gigabyte are affected by this for example. It also works independently of DisableIoMapper. Imo, I think they should have given it a different name because people assume it is dependant on DisableIoMapper being enabled - which it's not.

The systems with iGPU disabled or memory of 16 GB or less were the conditions for not being affected by the changes made in 13.3. These systems simply do not need DisableIoMapperMapping quirk. Hence, Casey included that in the documentation. Also, the quirk does not make it superfluous to replace DMAR table. Replacing DMAR table is still needed for the systems that required it prior to Ventura-AppleVTD-Patch.

 

[5T33Z0]

Replacing DMAR table is still needed for the systems that required it prior to Ventura-AppleVTD-Patch.

Well, in macOS prior to 13.3, yes. But dropping DMAR table (on current systems) was done to replace it by a modified table without Reserved Memory Regions. And since the Quirk does extactly do that – removing these regions from memory – I am pretty sure, dropping and replacing that table in Ventura is pretty much superflous then.

 

[Jasonhacks]

Well, in macOS prior to 13.3, yes. But dropping DMAR table (on current systems) was done to replace it by a modified table without Reserved Memory Regions. And since the Quirk does extactly do that – removing these regions from memory – I am pretty sure, dropping and replacing that table in Ventura is pretty much superflous then.

Simply put, on my system, Wifi/Ethernet will not work if DMAR table is not replaced even with DisableIoMapperMapping on in Ventura 13.3+.

And since the Quirk does extactly do that – removing these regions from memory –

Hmm...

The systems with iGPU disabled or memory of 16 GB or less were the conditions for not being affected by the changes made in 13.3. These systems simply do not need DisableIoMapperMapping quirk.

NM on these two conditions, it looks like those were only tested on Z390 Designare and Z490 Vision-D. It may be different for other boards as mentioned here.

 

[5T33Z0]

@Jasonhacks I have a Z490 Vision G and that's where dropping/replacing DMAR is required when using the stock firmware of the I225 combined with certain wifi/ethernet cards required the presence vtd which required removng certain memory regions from DMAR table.

On the Gigabyte Z490 board, the issue is caused by incorrect Device Header/descripter on the Intel I225V. And after I flashed the modded ROM, the issue was gone. So therefore, for Gigabyte Z490 with this NIC, I think this issue is not related to the presence/absence or the iGPU nor the amount of installed RAM