When is RebaseRegions necessary?

[deeveedee]

The more I hack, the more I realize that there are ACPI patching practices I use that are habits carried-over from when I first started learning to hack a PC (sometimes learned incorrectly).  I continue to employ these practices without knowing why and am certain that some of the practices are unnecessary.  One such practice is the use of RebaseRegions (first in CLOVER and now in OC).  In my latest hack, I can enable or disable ACPI > Quirks > RebaseRegions  with no noticeable difference in system behavior.

 

When is RebaseRegions necessary?  Is the determination of its necessity simply by trial and error, or is there something else about a system that determines whether the quirk should be enabled?

 

Thank you.

[Guest ricoc90]

As far as I believe it is only necessary in a few odd cases and is only necessary if you're making use of a modified DSDT and/or are dropping tables.

 

Edit:

From the OpenCore docs:

 

Quote

RebaseRegions
Type: plist boolean
Failsafe: false
Description: Attempt to heuristically relocate ACPI memory regions. Not recommended.
 

ACPI tables are often generated dynamically by the underlying firmware implementation. Among the position-independent code, ACPI tables may contain the physical addresses of MMIO areas used for device configuration, typically grouped by region (e.g. OperationRegion). Changing firmware settings or hardware configuration, upgrading or patching the firmware inevitably leads to changes in dynamically generated ACPI code, which sometimes results in the shift of the addresses in the aforementioned OperationRegion constructions.

For this reason, the application of modifications to ACPI tables is extremely risky. The best approach is to make as few changes as possible to ACPI tables and to avoid replacing any tables, particularly DSDT tables. When this cannot be avoided, ensure that any custom DSDT tables are based on the most recent DSDT tables or attempt to remove reads and writes for the affected areas.

When nothing else helps, this option could be tried to avoid stalls at PCI Configuration Begin phase of macOS booting by attempting to fix the ACPI addresses. It is not a magic bullet however, and only works with the most typical cases. Do not use unless absolutely required as it can have the opposite effect on certain platforms and result in boot failures.

 

Edited August 5, 2022 by ricoc90

[deeveedee]

@ricoc90 Thank you for the quick reply.  Your immediate responsiveness to posts across all forums continues to amaze me.

Edited August 5, 2022 by deeveedee

[Slice]

The problem and the solution was developed early in Clover and been very useful was implemented in OpenCore.

There are no faults and false application at least in Clover. It is needed when you are using custom DSDT with OperationRegions from old time. New time DSDT can has other OperationRegions addresses that should be applied to custom DSDT.

If you are not using Custom DSDT then the quirk is no use for you.

On my computer it is quite needed and I have good working computer that can sleep and wake without issues.

[rafale77]

To customize or not to customize the DSDT... that is the question. Looking at my ioreg and finding 19 devices a real mac doesn't is creating an itch but it can become a hefty undertaking with very little return since these devices don't appear to do anything... 😶

 

@deeveedee, as I am spending more time hacking, I feel exactly the way you do. There is a lot of case specific or obsolete code in the hacks which got passed down over the ages and may not be that useful anymore.

[Guest ricoc90]

1 hour ago, deeveedee said:

Your immediate responsiveness to posts across all forums continues to amaze me.

Yeah, I really should get a hobby or something 

[deeveedee]

@ricoc90 I think that full-time hobbies are underrated.

[MaLd0n]

This quirk is very useful for those who like to play. Clover FixRegions / OpenCore RebaseRegions.

I classify in two categories:

Don't need this quirk = Porno Amateur

Need this quirk = Porno Pro

People with premade things like a bunch SSDT's don't need it

For those who like inject, remove, etc patches direct into DSDT for one full solution need it. We need remember some things: Apple have a very custom ACPI tables with same chipset.

Example: 

Real Mac iMac19,1 tables, Chipset Serie 300 (8816 lines) DSDT.Real iMac CoffeLake serie 300.zip

Mobo Chipset Serie 300 non-apple (59775 lines) DSDT.Mobo serie 300.zip

 

My last hack Alder Lake i have this

Unpatch

Patched

[deeveedee]

@MaLd0n  Your use of RebaseRegions isn't clear to me in the example you provided and you lost me on the Pro vs. Amateur Porn analogy - does this have something to do with whether or not I'm paid for my services?  If I am a Pro, would I accept VISA?  What is clear to me is that I'm an amateur - my performance is far too brief to generate any income as a professional.

[MaLd0n]

4 minutes ago, deeveedee said:

@MaLd0n 

😆

this is just a joke

i remember some topics here about OperationRegions in old times, but i think is gone in some update. 

with ssdt don't need it, this way just inject little things to good boot and system work.

with dsdt need it, this way we can inject devices, remove devices, etc, etc. This is a full solution and if u used override table need this quirk.

about Visa idk, money is not easy for now, but hackintosh is free, donations is option not mandatory...at least that's how it has to be. 

[Slice]

One example about DSDT patching.

This codes have a mistake

    Method (_PTS, 1, NotSerialized)  // _PTS: Prepare To Sleep
    {
        P80D = Zero
        P8XH (Zero, Arg0)
        PTS (Arg0)
        If (AOAC & One) {}
        If (Arg0 == 0x03)
        {
            If (PWRS == Zero)
            {
                \_SB.PCI0.XHC.PMEB = Zero
                \_SB.PCI0.EHC1.PMEB = Zero
                \_SB.PCI0.EHC2.PMEB = Zero
                If (\_SB.PCI0.XHC.PMST == One)
                {
                    \_SB.PCI0.XHC.PMST = One
                }

                If (\_SB.PCI0.EHC1.PMST == One)
                {
                    \_SB.PCI0.EHC1.PMST = One
                }

                If (\_SB.PCI0.EHC2.PMST == One)
                {
                    \_SB.PCI0.EHC2.PMST = One
                }
            }

The condition if (PWRS == Zero) should be commented out.

How this change Acidanthera proposed to replace by SSDT?

There are also many other places which is better and simpler to edit in DSDT and then use custom DSDT. 

[deeveedee]

@Slice I used to perform all of my ACPI patching with DSDT edits.  With my latest rig, I'm using only SSDT patches.  For your example, I would rename _PTS to XPTS and then define a new _PTS.  Some might say this is more complex.  I think it's a personal preference.

 

EDIT: I'd have to look at the rest of the ACPI, but It's also possible that you could create an _INI and set PWRS = 0.

Edited August 5, 2022 by deeveedee

[rafale77]

These too guys are just stimulating my itch to go custom DSDT... must resist... must resist... 😅

I don't have that much time to spare...

[1Revenger1]

6 hours ago, Slice said:

One example about DSDT patching.

This codes have a mistake

    Method (_PTS, 1, NotSerialized)  // _PTS: Prepare To Sleep
    {
        P80D = Zero
        P8XH (Zero, Arg0)
        PTS (Arg0)
        If (AOAC & One) {}
        If (Arg0 == 0x03)
        {
            If (PWRS == Zero)
            {
                \_SB.PCI0.XHC.PMEB = Zero
                \_SB.PCI0.EHC1.PMEB = Zero
                \_SB.PCI0.EHC2.PMEB = Zero
                If (\_SB.PCI0.XHC.PMST == One)
                {
                    \_SB.PCI0.XHC.PMST = One
                }

                If (\_SB.PCI0.EHC1.PMST == One)
                {
                    \_SB.PCI0.EHC1.PMST = One
                }

                If (\_SB.PCI0.EHC2.PMST == One)
                {
                    \_SB.PCI0.EHC2.PMST = One
                }
            }

The condition if (PWRS == Zero) should be commented out.

How this change Acidanthera proposed to replace by SSDT?

There are also many other places which is better and simpler to edit in DSDT and then use custom DSDT. 

Likely possible to set PWRS to zero if you replaced _WAK with ZWAK, then defined your own _WAK. Something similar to
 

Method (_WAK, 1, NotSerialized)
{
	/PWRS = Zero
	ZWAK(Arg0)
}

Looking further at some other DSDTs, it seems like a common value used to represent if the device is plugged in or not on a laptop. If it's not being updated, then it may be worth setting it to AC._PSR() on wake and sleep (AC being the power adapter device). That may completely fix the behavior if the firmware doesn't expect the USB values to be set while plugged in.

Edited August 6, 2022 by 1Revenger1

[theroadw]

Or you can zero out the option using a config find replace patch.

[Slice]

OK, so you get a set of useful SSDT's from the repository and you have to set in your config some set of find/replace ACPI patches. Agree, it is possible. One SSDT -> one patch.

My way is no SSDT -> one patch.

[mhaeuser]

17 hours ago, rafale77 said:

To customize or not to customize the DSDT... that is the question.

I am really not positive this is the question. As the OC docs say, changes to DSDT are inherently unsafe and anyone who tells you otherwise demonstrates nothing but their cluelessness about firmware internals. This does not mean this never works, but the point is you unlikely verified your systems behaviour for all edge cases (resuming from all sleep states, resetting CMOS, potential recovery procedures from failed boots, etc etc). There are way too many variables, really. You also restrain yourself from updating your firmware or performing any configuration changes (hardware or software) without risking having to re-do your DSDT. If that is what is considered Pro, maybe you should switch to Gentoo Linux.

 

@MaLd0n‘s implications that you need a custom DSDT to add and remove (well, remove yes, but disabling is good enough in virtually all cases) devices is incorrect. Aside from those claims, most device rename changes (probably also things you considered „missing“) are also not needed, as they are performed by Lilu and its plug-ins. This approach is a lot safer than previous ACPI renames as dumb find-replace patches can yield false positives, the kext approach cannot.

 

Finally, for those devices that are actually missing from your ACPI stack compared to Macs - sorry, but do you even know what they are? Declaring a SMC or a Thunderbolt bridge where there are none will not improve your experience. Clueless „perfectionism“ (it really isn’t) will at best downgrade your overall experience.

 

The Acidanthera team spent a lot of time and thought designing the ecosystem with great focus on functionality, simplicity, and safety. I don’t think you have to worry much you are „missing out“.

[rafale77]

@Download-Fritz, I read all of that from Dortania and understand the risks... and to some degree disagree with them as it really depends on what one does with the custom DSDT. If you are content with using the original one and make only minor changes with a conditional on _OSI, I would argue that it is actually a much safer and resilient solution than the kext approach. The risks you are stating likely applies to starting a DSDT from scratch. I don't see how they apply to consciously patching the OEM DSDT by removing old irrelevant code and disabling devices based on the OS used.

The find and replace is infallible if you know how to use it and have inspected your DSDT. Did you know that you can limit the find and replace to a single device and allow it to do only as many replacement as you want it to?  But using this patching method is actually a way not to run a custom DSDT.

 

Within a few weeks of playing with SSDTs I am now comfortable enough with the iASL language to know what I would be doing with the DSDT. It is a lot of work because my OEM DSDT like many is full of garbage code irrelevant to my machine. I for example have a bunch of disable H_EC code related to battery monitoring on my desktop. ioreg shows 19 unused devices and I found a couple having conflicting memory allocation with real devices. Luckily they are unused but I would prefer disabling or deleting them. Sure it can be done with another find and replace but it's 19 of them...

 

There are many ways to get to the same goal and no the custom DSDT is not the only way but it can be a very attractive and simple path to get a cleaner configuration to satisfy those with an elevated level of OCD. The acidenthara work is amazing and even with the custom DSDT, the missing macOS drivers are needed from them.

 

That being said, it's not a approach for newbs and there are easier ways to get to the same functional result. It all comes down to how paranoid/OCD/Masochistic one is. I would not consider doing this if I was not comfortable and had not carefully analyzed and studied my DSDT. I still am debating the return on investment of such an undertaking.

Now I see what @deeveedee was referring to as the vanilla debate...

[mhaeuser]

12 hours ago, rafale77 said:

If you are content with using the original one and make only minor changes with a conditional on _OSI, I would argue that it is actually a much safer and resilient solution than the kext approach.

Well, then I am afraid you also do not have in-depth knowledge about firmware internals. If you have the mental image that DSDT is a static table that just exists somewhere as a blob - no. It and other ACPI tables can be and are patched dynamically during firmware execution. Changing various factors, hardware and software, thus may yield a DSDT different from the one you used as your template, and thus your patched DSDT will "rollback" exactly those differences. There is no amount of "knowledge" and "language comfortability" you can gain to make this safe, this is inherently unsafe. I do not understand your hints towards the kext approach, there are no risks there. There is full knowledge of macOS IOKit and friends, while there can never realistically be full knowledge about the vendor firmware, not your personal one, and definitely not everyone's devices' out there.

 

12 hours ago, rafale77 said:

The risks you are stating likely applies to starting a DSDT from scratch.

Not in the slightest. If you understood it that way, you either misunderstood firmware stacks and ACPI, or you misunderstood what I said.

 

12 hours ago, rafale77 said:

The find and replace is infallible if you know how to use it and have inspected your DSDT.

You inspected the DSDT of this specific boot run. As said above, it may change depending on various variables. There is not the one "your DSDT".

 

12 hours ago, rafale77 said:

But using this patching method is actually a way not to run a custom DSDT.

DSDT is not the only ACPI table and outside references need to be fixed as well. This is why some use global find+replace even with a custom DSDT. And yes, some don't, but for completeness' sake, this is relevant.

 

12 hours ago, rafale77 said:

Luckily they are unused but I would prefer disabling or deleting them.

They likely can be disabled via SSDT without messing with DSDT. Of course needs concrete examples to tell.

 

12 hours ago, rafale77 said:

There are many ways to get to the same goal and no the custom DSDT is not the only way but it can be a very attractive and simple path to get a cleaner configuration to satisfy those with an elevated level of OCD.

[...]

That being said, it's not a approach for newbs and there are easier ways to get to the same functional result. It all comes down to how paranoid/OCD/Masochistic one is

You yet again imply this is somehow magically "cleaner" than other approaches and that it is just harder and meant for the elite. No, it is not. It is risky unless you constantly monitor the firmware-generated tables. Do you? There is no level of mastery you can achieve to not be constantly paranoid about your patched DSDT breaking something when doing even slight configuration changes. I'd be paranoid if each firmware update or hardware swap risked the functionality of my setup. If you believe that you are much smarter than vit9696, me, and the rest of Acidanthera, and this is why we recommend and personally use the "noob approach", I am sorry to have wasted your time.

 

https://github.com/tianocore/edk2-platforms/blob/aa3f6fd542e99dde4206537b095f1a2201275e75/Platform/Intel/MinPlatformPkg/Acpi/Library/DxeAslUpdateLib/DxeAslUpdateLib.c

 

https://github.com/tianocore/edk2-platforms/blob/aa3f6fd542e99dde4206537b095f1a2201275e75/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/UpdateDsdt.c

[MaLd0n]

We cannot judge a case based on a few fables. I use both ways and I can't say that with SSDT it doesn't work, I've never said that, but it's far from what I and many many others expect, that's a fact, with or without your knowledge of the matter sitting on your sovereign throne my great master.

 

I see some people with no knowledge of the subject saying that with DSDT the boot is slower, etc. This is bizarre, if that doesn't work better it's time to stop and read about it again meanwhile. I see some folks inject different device properties into other devices, etc. and people believe this is the best.

 

I have all the chipsets on my mind. I read a lot and my hands are in the dough, 30 patches or more per day. You can't confuse things, not writing tutorials on the subject, for example, doesn't mean anything, but I don't judge anyone for using A or B, Olarila folders are there for that with SSDT`s and basic solution for boot system with some extra things to inject missing devices(no difference), use copy/paste folder and change what you need.

 

Many people like solution A and many people like solution B and both work, but I only use an "elite" full patch(wow).

 

Unlike most that use pre-made SSDT's, I don't force anyone to do anything as I told you via PM about some links in ur work.

 

El coniglio with oldnapalm and me created DSDT patcher for that, easy and fast way to one full patch. I just need 2 minutes to patch one. This way started with us on Olarila in this topic HERE and DSDT Auto Patcher HERE so I will always use this form, even with bios update.

 

@Download-FritzI understand this point of view, ur knowledge, you are the ones who run the boat and I respect and I also use the same procedure since it started right here on InsanelyMac. 2011, 2012? but those pointed fingers didn't start with me or you but I really don't care what you say on this subject. This book is only for noobs with no knowledge on the subject.

 

This subject ends as follows: Do you like it and do you know how to do it? Use it!

 

Peace ✌️

 

[Slice]

On 8/6/2022 at 12:10 AM, deeveedee said:

@Slice I used to perform all of my ACPI patching with DSDT edits.  With my latest rig, I'm using only SSDT patches.  For your example, I would rename _PTS to XPTS and then define a new _PTS.  Some might say this is more complex.  I think it's a personal preference.

 

EDIT: I'd have to look at the rest of the ACPI, but It's also possible that you could create an _INI and set PWRS = 0.

Don't make a logical mistake. PWRS will not be always zero.