Jump to content
27 posts in this topic

Recommended Posts

A quick question regarding "DropForAllOS." I've not found a lot of info on it, but I have found a couple places where it suggests I have it set correctly, though Slice informs me it is not;

 

This suggests it has no effect on MacOS;

https://github.com/CloverHackyColor/CloverBootloader/issues/145

 

This also seems to imply that I had it set correctly;

https://elitemacx86.com/threads/how-to-fix-dmar-table-on-macos-memory-mapping.964/

 

So what is the impact of this setting and what is its correct usage?

OK, I've tested all this out, here are the results;

 

1)  I do not drop the DMAR table in Clover, machine panics early in the boot process.

 

 

2) I do drop the DMAR table

image.png.7431f25229eb2dfd4bbef5acd8162c70.png

 

Machine boots fine, but loads the DMAR table anyway. If I try to use a patched DMAR I end up with 2 DMAR tables

 

 

3) I drop the DMAR table and enable DropForAllOS

image.png.f5c6ab79432e49867f1f592b7109d607.png

 

Results are the same as 2. The DMAR table still loads. If I have a patched table I end up with 2 DMAR tables in ACPI

 

 

4)  (THE WINNER!!!) AutoMerge;

image.png.8e30b525e3c2e8221c3aad1911d62dc2.png

 

With this enabled I get only 1 DMAR table in MacOS (my patched one) and in Windows the only original DMAR table with the Reserved Memory Regions gets loaded. This is exactly the result I was hoping for.

 

I realize that @Slice has not been able to replicate this, though from the posts it seems I'm not the only one encountering this. I don't know if there is a common ACPI issue that I and @cankiulascmnfye have that is causing this. Obviously setting Clover to drop the DMAR table is doing something, otherwise my system won't boot, but I still do end up with the table loaded.

 

@miliuco thanks for the tip. That finally got things sorted out.

 

 

  • Like 2
×
×
  • Create New...