ProjectOSX

Welcome Guest!

Returning User? Login here.

Want membership privileges? Register here.

> DSDT

Differentiated System Description Table (DSDT) - DSDT is a part of the ACPI specification and it supplies configuration information about a base system. ACPI capable computers come with a preinstalled DSDT from the manufacturer. A common Linux/OS X problem is missing ACPI functionality (fans not running, laptop screens not shutting off, etc.)

This subforum is dedicated to patches/fixes able to be inserted/modified from an extracted dsdt.dsl, which is then compiled into a DSDT.aml for OS X to pick up and use (with a proper bootloader).

These fixes are not permanent, and do not damage your BIOS.

 
Start a new topic Add Reply
> Operationregion Systemmemory - Help
Noyfb
post Apr 5 2012, 07:22 AM
Post #1
Hello,

I really hope some one can answer this question.


Could someone explain to me how the OperationRegion SystemMemory hex ex"0x37F7FDBC" is calculated or point me in the right direction/docs?
Apparently is changes when you add or remove memory.

Thanks to a post from Slice, cant remember where I saw it, I now understand the other OperationRegion name significance and how to work with them.
Examples ICH9 LPCB 0xA0.

Does SystemMemory have a simular table/document like ICH9 or is programmer defined?

I have searched the net and found squat.

Thank you in advance for any help given.

This post has been edited by Noyfb: Apr 5 2012, 12:56 PM
Noyfb
post Apr 5 2012, 02:36 PM
Post #2
I thought I had found the answers but it just got more confusing.

What I found so far is that the Operationregion Systemmemory Hex Address is the location of the CMOS dump in main memory because AML is not allowed to read CMOS directly.
It's probably why it changes when you add ore remove memory.


I still need help because I am having an extremely hard time finding the links between Systemmemory offsets and ICH documentation.
I would make sense since it's CMOS (bois) and not chipset stuff. The hard part is finding the BIOS documentation of that content to prouve me right or wrong.

I still need help.

Thank you.

This post has been edited by Noyfb: Apr 5 2012, 05:42 PM
bcc9
post Apr 5 2012, 08:04 PM
Post #3
When I first noticed that the OperationRegion SystemMemory addresses could vary depending upon system memory size (or pci devices), I wrote a script to dump the memory map and identify which layout was in use. The identifying portion is specific to my model of laptop, but you can use the script as an example. The dumping of the memory map is achieved using a tweaked version of amit's showbootermemorymap dtrace script (I added 64 bit support).
Attached File  showbootermemorymap.zip ( 1004bytes ) Number of downloads: 56

Attached File  dsdt_check.pl.zip ( 822bytes ) Number of downloads: 52



This post has been edited by bcc9: Apr 5 2012, 08:06 PM
Noyfb
post Apr 14 2012, 10:19 PM
Post #4
Thanks for your reply. I read the script and can see where it would be help full. just not in this situation.sad.gif

The memory address location in question (0x37F7FDBC) is the BIOS dump and there will never be any documentation ... sad.gif


I did allot more digging and my revised questions are ...

I know how to read and find almost all of the device registers but there are a couple of addresses and situations that are baffling.


In my P5K DSDT you have within D31:F0: OperationRegion (IOID, SystemIO, 0x2E, 0x02)
IN the ICH9 docs at D31:F0 you will find offset 2Ch:2Fh.
Logically 2E is within 2Ch:2Fh.
First question is why use 2E and not just 2C?


logically 2Ch:2Fh will include 2Eh so I go to 2Ch,
In 2Ch you have bits 31:16 and bits15:0.

Looking at the following in the P5K DSDT you find

OperationRegion (IOID, SystemIO, SPIO, 0x02) //SPIO being 0x2E
Field (IOID, ByteAcc, NoLock, Preserve)
{
INDX, 8,
DATA, 8
}


Will INDEX be bit 0 and DATA bit 1?
or
INDEX is bits 15:0 and DATA bits 31:16
and if so why the hell do you need 15 bits if you only need one?



And now for some more weirdness. sleep.gif

In P5K DSDT you have:
OperationRegion (IOB2, SystemIO, 0xB2, 0x02)
OperationRegion (IORK, SystemIO, 0xB3, One)

Both are under root and not under a device or PMBase.
In the ICH9 docs I found B2h under fixed registry which is not under any Device or is PMBase which makes sense.
but If I take an other similar entry in the P5K DSDT,
OperationRegion (DEB0, SystemIO, DP80, 0x02) // DP80 is 0x80
OperationRegion (DEB4, SystemIO, 0x84, One) // 0x84

Again they are under root and not under a Device or is PMBase but this time the are no entries in the ICH9 documentation.
Yes there are 80h and 84h entries but none are without a doubt a match since they are located under devices.


I'v tried to match them by looking that the functions that use them in hops of finding hints but I did not succeed.


I'm so damn close to being able to read all DSDT code it's driving me insane when hitting a freaking wall like this one.


Please help .

This post has been edited by Noyfb: Apr 14 2012, 11:42 PM
bcc9
post Apr 16 2012, 12:04 AM
Post #5
The point of my post was to show how the SystemMemory operation region addresses found in the DSDT can be expected to be *dynamic*, allocated by the BIOS, not found in a manual. The showbootermemorymap script dumps the bios e820 memory map so that you can see what the dynamic assignments are.

In the example dsdt-check.pl script, the ACPI data address space is checked against two common dynamically allocated values for my particular platform (that depend upon what memory size and video cards one's laptop has).

It doesn't make sense for you to be expecting such dynamic hex addresses to be hard coded into an intel chipset spec.

Now you're changed the question to SystemIO memory operation regions instead of SystemMemory operation regions. With respect to that far different question:

> First question is why use 2E and not just 2C?

You're looking at disassembled DSDTs. Generally speaking, the disassembled code is free to contain optimzations, such as only declaring a region to begin at an actually *used* offset instead of at some logical start address.

QUOTE (Noyfb @ Apr 14 2012, 03:19 PM) *
OperationRegion (IOID, SystemIO, SPIO, 0x02) //SPIO being 0x2E
Field (IOID, ByteAcc, NoLock, Preserve)
{
INDX, 8,
DATA, 8
}


Will INDEX be bit 0 and DATA bit 1?
or
INDEX is bits 15:0 and DATA bits 31:16
and if so why the hell do you need 15 bits if you only need one?
Now you're just asking about the ACPI language specification. See P. 603 of the ACPI (4.0) spec for this. In this example INDX is the first 8 bit byte, and DATA is the second 8 bit byte, at offset 0 to this field.

I don't have a p5k motherboard (I RMA'd the one I briefly had thankfully smile.gif so I'm not going to get into p5k specific details.
eberts
post May 5 2012, 07:31 AM
Post #6
QUOTE (bcc9 @ Apr 16 2012, 02:04 AM) *
The point of my post was to show how the SystemMemory operation region addresses found in the DSDT can be expected to be *dynamic*, allocated by the BIOS, not found in a manual. The showbootermemorymap script dumps the bios e820 memory map so that you can see what the dynamic assignments are.

In the example dsdt-check.pl script, the ACPI data address space is checked against two common dynamically allocated values for my particular platform (that depend upon what memory size and video cards one's laptop has).

It doesn't make sense for you to be expecting such dynamic hex addresses to be hard coded into an intel chipset spec.

Now you're changed the question to SystemIO memory operation regions instead of SystemMemory operation regions. With respect to that far different question:

> First question is why use 2E and not just 2C?

You're looking at disassembled DSDTs. Generally speaking, the disassembled code is free to contain optimzations, such as only declaring a region to begin at an actually *used* offset instead of at some logical start address.

Now you're just asking about the ACPI language specification. See P. 603 of the ACPI (4.0) spec for this. In this example INDX is the first 8 bit byte, and DATA is the second 8 bit byte, at offset 0 to this field.

I don't have a p5k motherboard (I RMA'd the one I briefly had thankfully smile.gif so I'm not going to get into p5k specific details.


Hi bcc9,

I have problems to run the script (as root):
dtrace: failed to compile script ./showbootermemorymap: line 22: failed to resolve `_mh_execute_header: Unknown symbol name

Is my XCode 4.2 (Snow Leo) broken?
Thx
bcc9
post May 14 2012, 05:02 PM
Post #7
QUOTE (eberts @ May 5 2012, 12:31 AM) *
Hi bcc9,

I have problems to run the script (as root):
dtrace: failed to compile script ./showbootermemorymap: line 22: failed to resolve `_mh_execute_header: Unknown symbol name

Is my XCode 4.2 (Snow Leo) broken?
Thx

Looks like my change for showbootermemorymap doesn't work with older kernels (OSX 10.6). I had only tested against 10.7. Someone else hacked up the script to address 10.6 support:

http://www.projectosx.com/forum/index.php?...ost&p=17773
dmazar
post May 14 2012, 05:07 PM
Post #8
QUOTE (bcc9 @ May 14 2012, 07:02 PM) *
Looks like my change for showbootermemorymap doesn't work with older kernels (OSX 10.6). I had only tested against 10.7. Someone else hacked up the script to address 10.6 support:

http://www.projectosx.com/forum/index.php?...ost&p=17773
But this does not work if 64 bit kernel is loaded with 32 bit EFI. So, still not universal.
HW: Asus P8P67-M, Intel Core i5-2300, 4GB, XFX HD-567X-ZHH3 SW: SL, L, ML: Clover UEFI boot

Add Reply Start a new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members: