Access width of Field Unit extends beyond region limit

[need.discipline]

Hi

I am trying to compile my SSDT-1.dsl, which is unmodified from being decompiled with iasl and I am getting the following error: Access width of Field Unit extends beyond region limit



I understand that the region NVHM has size 0x01FA (= 506), and the field list has 28 fields, but I haven't figured out the the size of which field and how can I fix this error.

Could you please shed some light on this subject? I found a related post in a german forum, with someone with the same error on a different SSDT, but someone just fixed the file and uploaded without giving a small explanation of needed to be done.

Would be great to know

1. How to workout the size of each field
2. How to choose which field to reduce the size or remove.

The I did look around in ACPI specification, but it was a little overwhelming...

The decompiled DSLs are also attached: View attachment patched_dsl.zip.

Thanks in advance

 

[RehabMan]

Hi

I am trying to compile my SSDT-1.dsl, which is unmodified from being decompiled with iasl and I am getting the following error: Access width of Field Unit extends beyond region limit

View attachment 171386

I understand that the region NVHM has size 0x01FA (= 506), and the field list has 28 fields, but I haven't figured out the the size of which field and how can I fix this error.

Could you please shed some light on this subject? I found a related post in a german forum, with someone with the same error on a different SSDT, but someone just fixed the file and uploaded without giving a small explanation of needed to be done.

Would be great to know

1. How to workout the size of each field
2. How to choose which field to reduce the size or remove.

The I did look around in ACPI specification, but it was a little overwhelming...

The decompiled DSLs are also attached: View attachment 171387.

Thanks in advance

Just to make sure we are looking at unpatched files... Post all native DSDT and SSDTs (eg. Clover F4 extract).

OperationRegion size is specified in bytes. Each field size is specified in bits.

Total size of the declared fields in bytes: (16*4+32*2+16*3+8*8+16*3+32*3+1600+32+1600+32+400)/8=506

506=0x1fa

So... the field sizes add up to the exact size as declared.

I suspect it is an alignment issue.

It is declared as DwordAcc, if you change to AnyAcc or ByteAcc, no error. Also, if you change 0x1fa to 0x1fc (two bytes larger), no error. I suspect GTTP is being aligned to the next 32-bit boundary with DwordAcc.

What the right solution is may require further reading of the ACPI spec (does DwordAcc affect the alignment of identifiers within a Field?) and perhaps even insider knowledge of this specific SystemMemory region.

 

[need.discipline]

Thank you so much RehabMan! The division by eight at the end is what I was not clear

AML dumped by Clover F4: View attachment origin.zip

I take the files:

DSDT.aml     SSDT-1.aml   SSDT-2.aml   SSDT-4x.aml  SSDT-6x.aml  SSDT-8x.aml
SSDT-0.aml   SSDT-10x.aml SSDT-3.aml   SSDT-5x.aml  SSDT-7x.aml  SSDT-9x.aml

To a separate directory and decompile with:

iasl -da -dl *.aml

iasl version:

Intel ACPI Component Architecture
ASL+ Optimizing Compiler version 20150515-64
Copyright (c) 2000 - 2015 Intel Corporation


Supports ACPI Specification Revision 6.0

Upon decompilation and trying to compile the original DSDT, the following errors show:



To solve this I just deleted the Arg0 after the return



To solve this I just deleted the Arg0, Arg1, Arg2, Arg3 after the return

I got the iasl from: http://www.insanelymac.com/forum/files/file/408-acpica-iasl-intel-acpi-tools/ but the same error shows on the iasl you host on bitbucket

Thanks once again!

 

[RehabMan]

Thank you so much RehabMan! The division by eight at the end is what I was not clear

AML dumped by Clover F4: View attachment 171449

It is an error in the original files... The correct fix is hard to know as we don't have complete technical specs regarding the intention of the original programmer.

Two possibilities:
- change to AnyAcc or ByteAcc
- change 0x1fa to 0x1fc

I guess you could test both and see what happens.

It would affect all fields defined from GTTP onwards. A misaligned field would cause read/write of bad data.

These fields appear to be accessed only in various _DSM methods, which are usually expendable for OS X purposes. So... It is likely the code accessing these fields is unreachable when running OS X, so it probably doesn't matter at all.

Note: With a quick look, I couldn't find any information regarding DwordAcc specification and its relationship to alignment. So it is also possible it is a bug in iasl. Most likely though it was a bug in an older iasl, now fixed.

 

[katza]

Hello "need.discipline"
Is it possible for you to share your EFI as I have the same machine as you and I can't configure my 980m to work.
Thank you

 

[need.discipline]

Hello "need.discipline"
Is it possible for you to share your EFI as I have the same machine as you and I can't configure my 980m to work.
Thank you

Hi katza, I answered you at http://www.tonymacx86.com/el-capita...-6700k-intel-z170-nvidia-980m-4k-display.html . If the information there is not enough, please open a dedicated topic to your problem with descriptive title so it can be searched later.


Hi RehabMan,

Two possibilities:
- change to AnyAcc or ByteAcc
- change 0x1fa to 0x1fc


I guess you could test both and see what happens.

Thanks for the input, I was able to compile with the 3 variants that you suggested, AnyAcc, ByteAcc and using 0x1fc. It produces code that seems to run, where I added your Debug methods and see them on the Console.app.

If I ever encounter any anomalies, I will report back.

So it is also possible it is a bug in iasl. Most likely though it was a bug in an older iasl, now fixed.

For what it is worth, I am using the latest iasl, 20160108, with Intel license, from https://www.acpica.org/downloads to Decompile and Compile the DSDT and SSDT-xx. It still results in the same error without your suggested fix.

 

[RehabMan]

For what it is worth, I am using the latest iasl, 20160108, with Intel license, from https://www.acpica.org/downloads to Decompile and Compile the DSDT and SSDT-xx. It still results in the same error without your suggested fix.

The suggestion is it could be a bug/error in the compiler, not the disassembler. Perhaps a misinterpretation of the ACPI spec. But the spec is not clear on it.

But like I said, more than likely the error/bug was in a previous compiler (one that was used to compile the OEM file), in that case you would expect the result you have... original code without error when compiled with old compiler, but new/more correct compiler producing an error with the disassembled code.