If you experienced a problem patching your DSDT/SSDT to enable Mac OS X native power management, or you don't know how to do this - the new bootloader is for you! Should work on most modern systems/processors.
Bootloader based on latest Chameleon RC5 rev184. Mem detection is enabled and slightly modified: fixed system profiler returns error while reading memory info in some cases. P-States & C-States are exported to the system via additional SSDTs, so if you have native SSDTs with _CST methods you should use "DropSSDT" = "Yes" option in boot.plist. If you have modded DSDT with _CST methods you should remove them or it'll be kernel panic on system start. The bootloader also supports multiple SSDT loading (names should be SSDT.aml, SSDT-1.aml ... SSDT-29.aml). Bootloader also supports latest graphic cards (code was obtained from here)
To enable native power management you should use proper mac model + HPET enabled. To enable C-States you must have LPC working on your system. It could be enabled via DSDT mod or injector.
To activate P-States generation add "GeneratePStates"="Yes" option into boot.plist. To activate C-States generation add "GenerateCStates"="Yes" option into boot.plist. Those features are not activated by default!
Sources available here. The name of the project is Chameleon-Mozodojo.
P-States generation algo based on original superhai's algo from VoodooPower project.
Click to view attachment
Full Version: Chameleon Rc5 Mode With Mem Detection Enabled And Automatic P-states & C-states Generation For Native Power Managment
Nice work, I would like to see more of this, using SSDTs is a better way than patching the original DSDT in such cases, you probably already have seen this one, but I'll post the link anyway: ACPI Generator from the coreboot project.
One thing I would really like to see is patching-on-the-fly a few things in the DSDT like the GNVS/BIOS starting address, this seems to change when you add/remove DIMMs.
Excerpts:
from my laptop:
from a MBP6,2:
One thing I would really like to see is patching-on-the-fly a few things in the DSDT like the GNVS/BIOS starting address, this seems to change when you add/remove DIMMs.
Excerpts:
from my laptop:
CODE
OperationRegion (BIOS, SystemMemory, 0x7DFAE064, 0xFF)
from a MBP6,2:
CODE
OperationRegion (GNVS, SystemMemory, 0x8B6E6E18, 0x0161)
QUOTE (Kabyl @ Jul 20 2010, 01:00 PM) 
Nice work, I would like to see more of this, using SSDTs is a better way than patching the original DSDT in such cases, you probably already have seen this one, but I'll post the link anyway: ACPI Generator from the coreboot project.
One thing I would really like to see is patching-on-the-fly a few things in the DSDT like the GNVS/BIOS starting address, this seems to change when you add/remove DIMMs.
Excerpts:
from my laptop:
from a MBP6,2:
One thing I would really like to see is patching-on-the-fly a few things in the DSDT like the GNVS/BIOS starting address, this seems to change when you add/remove DIMMs.
Excerpts:
from my laptop:
CODE
OperationRegion (BIOS, SystemMemory, 0x7DFAE064, 0xFF)
from a MBP6,2:
CODE
OperationRegion (GNVS, SystemMemory, 0x8B6E6E18, 0x0161)
The simple solution: parse those values from the original dsdt before any patching or/and ovverride. After this, patch new dsdt with parsed values?
QUOTE (Kabyl @ Jul 20 2010, 02:00 PM)
from my laptop:
from a MBP6,2:
CODE
OperationRegion (BIOS, SystemMemory, 0x7DFAE064, 0xFF)
from a MBP6,2:
CODE
OperationRegion (GNVS, SystemMemory, 0x8B6E6E18, 0x0161)
+1
CODE
OperationRegion (OSTY, SystemMemory, 0x37F7FF4C, 0x00000001)
OperationRegion (SMI1, SystemMemory, 0x37F7FDBC, 0x00000190)
OperationRegion (SMI1, SystemMemory, 0x37F7FDBC, 0x00000190)
After numerous patching of my DSDT I increased RAM and encounter non-working function. I had to find these values in DSDT.
But I have no idea how to correct it automatically... Compare BIOS DSDT with loaded from file? What names to check?
We can parse and patch OperationRegions with well known names like: BIOS, GNVS, OSTY, SMI1. Make an array of these names, and patch differences automatically.
All OperationRegions with SystemMemory and patch all differencies.
QUOTE (Mojodojo @ Jul 20 2010, 12:09 PM)
The simple solution: parse those values from the original dsdt before any patching or/and ovverride. After this, patch new dsdt with parsed values?
Besides GNVS/BIOS/<whatever> everything else can be read from registers, so one needs to make a good DSDT with these OperationRegions set dynamically, or what do you think?
QUOTE (Kabyl @ Jul 20 2010, 04:04 PM)
Besides GNVS/BIOS/<whatever> everything else can be read from registers, so one needs to make a good DSDT with these OperationRegions set dynamically, or what do you think?
I think it wouldn't be a big difference from parsing and patching some or whole OperationRegions found. We don't know where is the next OperationRegion appears so we need to check a whole DSDT, original one and a custom. Make an array with OperationRegion names and offsets. Compare differences and patch custom DSDT.
If I understand you correctly, you want to read values for some of OperationRegions from the specific registers? If it so, I tnink it's difficult, and I love simple solutions
CODE
for(i=0; i<endOfDSDT;i++){
if((BIOSDSDTopCode[i]=OperationRegion) && (BIOSDSDTopCode[i+L]=SystemMemory)){
name=BIOSDSDTopCode[i+K];
addr=BIOSDSDTopCode[i+N];
for(j=0; i<endOfNewDSDT;i++){
if((newDSDTopCode[i]=OperationRegion) && (newDSDTopCode[i+L]=SystemMemory)
&&(name==newDSDTopCode[j+K])){
newDSDTopCode[j+N] = addr;
}
}
}
if((BIOSDSDTopCode[i]=OperationRegion) && (BIOSDSDTopCode[i+L]=SystemMemory)){
name=BIOSDSDTopCode[i+K];
addr=BIOSDSDTopCode[i+N];
for(j=0; i<endOfNewDSDT;i++){
if((newDSDTopCode[i]=OperationRegion) && (newDSDTopCode[i+L]=SystemMemory)
&&(name==newDSDTopCode[j+K])){
newDSDTopCode[j+N] = addr;
}
}
}
QUOTE (Slice @ Jul 20 2010, 05:00 PM)
CODE
for(i=0; i<endOfDSDT;i++){
if((BIOSDSDTopCode[i]=OperationRegion) && (BIOSDSDTopCode[i+L]=SystemMemory)){
name=BIOSDSDTopCode[i+K];
addr=BIOSDSDTopCode[i+N];
for(j=0; i<endOfNewDSDT;i++){
if((newDSDTopCode[i]=OperationRegion) && (newDSDTopCode[i+L]=SystemMemory)
&&(name==newDSDTopCode[j+K])){
newDSDTopCode[j+N] = addr;
}
}
}
if((BIOSDSDTopCode[i]=OperationRegion) && (BIOSDSDTopCode[i+L]=SystemMemory)){
name=BIOSDSDTopCode[i+K];
addr=BIOSDSDTopCode[i+N];
for(j=0; i<endOfNewDSDT;i++){
if((newDSDTopCode[i]=OperationRegion) && (newDSDTopCode[i+L]=SystemMemory)
&&(name==newDSDTopCode[j+K])){
newDSDTopCode[j+N] = addr;
}
}
}
it's need some optimization. In this algo you parse custom DSDT every time you found OperationRegion in original DSDT
QUOTE (Mojodojo @ Jul 20 2010, 02:49 PM)
If I understand you correctly, you want to read values for some of OperationRegions from the specific registers? If it so, I tnink it's difficult, and I love simple solutions
No, what I meant is, if someone is going to edit his DSDT, he could make it so that the OperationRegions are set by reading registers; RCBA addr, SMBus I/O port.. etc. Not to be done by the booter, but in the DSDT itself.
I hope it's clear now (?)
QUOTE (Mojodojo @ Jul 20 2010, 06:13 PM)
it's need some optimization. In this algo you parse custom DSDT every time you found OperationRegion in original DSDT
It is not a problem for real programmers as we are, isn't it?
First scan byte by byte to find all regions. Second scan by table entries. Faster 10 times.
But I think my double cycle 20000x20000 will perform in L2 cache during 1sec.
QUOTE (Kabyl @ Jul 20 2010, 07:33 PM)
No, what I meant is, if someone is going to edit his DSDT, he could make it so that the OperationRegions are set by reading registers; RCBA addr, SMBus I/O port.. etc. Not to be done by the booter, but in the DSDT itself.
I hope it's clear now (?)
I hope it's clear now (?)
It's very hard task for almost all users except roots.
We are making an automatic solution for lamers.
QUOTE (Kabyl @ Jul 20 2010, 06:33 PM)
No, what I meant is, if someone is going to edit his DSDT, he could make it so that the OperationRegions are set by reading registers; RCBA addr, SMBus I/O port.. etc. Not to be done by the booter, but in the DSDT itself.
I hope it's clear now (?)
I hope it's clear now (?)
I understand, I hope ^)
It's like a sections for SuperIO registers on some mobos.
Ooops! Impossible! We need to know Names before search.
Quickly looking I see C1-C3 support, does this build support C4? I know most boards don't support four C-states but what about C1, C2 and C4.
Revision 346 doesn't give me CStates with DropSSDT either yes or no with a GA-EX58 MB's DSDT with a standard PR scope.
However, when clocked over a certain point (148x20 or 2.96 GHz for a i7 920 or Xeon W3520 CPU), the OS doesn't see the CStates available to it anyways.
Memory detection didn't work either, but does work with AsereBLN's version.
However, when clocked over a certain point (148x20 or 2.96 GHz for a i7 920 or Xeon W3520 CPU), the OS doesn't see the CStates available to it anyways.
Memory detection didn't work either, but does work with AsereBLN's version.
I have not played around with compiling sources in OSX yet only Linux. Is it kinda the same?
Anyhow does anyone have a link to the i386 binary?
Anyhow does anyone have a link to the i386 binary?
QUOTE (Slice @ Jul 20 2010, 10:21 PM)
Ooops! Impossible! We need to know Names before search.
it' not required to know a name. We can search for OperationalRegionOp (0x830b) and parse the name.
The way I see it could be done is, parsing both the original and modified DSDT and building 2 arrays of a type with 2 pointers; each pointing to the OperationRegion's name and address, then we go over the 2 arrays, compare and patch...
CODE
typedef struct {
char *name;
void *addr;
} operationRegion;
#define OP_REG_MAX_NUM 20 // enough?
operationRegion orgOperationRegions[OP_REG_MAX_NUM];
operationRegion modOperationRegions[OP_REG_MAX_NUM];
int buildOperationRegionsFromTable(operationRegion opRegs[], void *table);
int fixOperationRegions(operationRegion orgOpRegs[], operationRegion modOpRegs[]);
char *name;
void *addr;
} operationRegion;
#define OP_REG_MAX_NUM 20 // enough?
operationRegion orgOperationRegions[OP_REG_MAX_NUM];
operationRegion modOperationRegions[OP_REG_MAX_NUM];
int buildOperationRegionsFromTable(operationRegion opRegs[], void *table);
int fixOperationRegions(operationRegion orgOpRegs[], operationRegion modOpRegs[]);
QUOTE (Kabyl @ Jul 21 2010, 10:26 AM)
The way I see it could be done is, parsing both the original and modified DSDT and building 2 arrays of a type with 2 pointers; each pointing to the OperationRegion's name and address, then we go over the 2 arrays, compare and patch...
CODE
typedef struct {
char *name;
void *addr;
} operationRegion;
#define OP_REG_MAX_NUM 20 // enough?
operationRegion orgOperationRegions[OP_REG_MAX_NUM];
operationRegion modOperationRegions[OP_REG_MAX_NUM];
int buildOperationRegionsFromTable(operationRegion opRegs[], void *table);
int fixOperationRegions(operationRegion orgOpRegs[], operationRegion modOpRegs[]);
char *name;
void *addr;
} operationRegion;
#define OP_REG_MAX_NUM 20 // enough?
operationRegion orgOperationRegions[OP_REG_MAX_NUM];
operationRegion modOperationRegions[OP_REG_MAX_NUM];
int buildOperationRegionsFromTable(operationRegion opRegs[], void *table);
int fixOperationRegions(operationRegion orgOpRegs[], operationRegion modOpRegs[]);
Yes, something like this. Is it really necessary? It may increase system startup time.
QUOTE (Mojodojo @ Jul 21 2010, 08:37 AM)
Yes, something like this. Is it really necessary? It may increase system startup time.
About increased startup time, reading the SPD data seems to take a bit.. I'm sure this can be made better.
That's why the best way, although risky in most cases, is flashing the BIOS with edited tables.
QUOTE (Kabyl @ Jul 21 2010, 10:52 AM)
That's why the best way, although risky in most cases, is flashing the BIOS with a modified DSDT.
Why don't you implemented it yet? What are you waiting for?
QUOTE (Mojodojo @ Jul 21 2010, 08:57 AM)
Why don't you implemented it yet? What are you waiting for?
Maybe I should "Strike while the iron is hot"...
QUOTE (Kabyl @ Jul 21 2010, 11:03 AM)
Maybe I should "Strike while the iron is hot"...
Ok. I can implement such a thing. Maybe will help for someone. Although it would help to get custom fixed DSDT dump to use after adding more memory etc in case and chameleon loading will be to slow...
QUOTE (Mojodojo @ Jul 21 2010, 09:14 AM)
Maybe will help for someone.
What I was thinking, I personally don't have that much issues in OS X to make me need a DSDT edit.
Another thing I noticed (I've posted about it above) is the booter taking a bit of time when it tries to read the DIMMs SPD.
QUOTE (Mojodojo @ Jul 21 2010, 09:07 AM)
it' not required to know a name. We can search for OperationalRegionOp (0x830b) and parse the name.
I mean that the combination 0x830b may occur as an address. How to exclude it?
And code 0x830b...
take
CODE
DefinitionBlock ("SSDT.4.aml", "SSDT", 1, "INTEL ", "CPUCSTC4", 0x06040000)
{
Scope (\_SB)
{
Name (OSTB, Ones)
OperationRegion (OSTY, SystemMemory, 0x47F7FF4C, 0x00000001)
Field (OSTY, AnyAcc, NoLock, Preserve)
{
TPOS, 8
}
OperationRegion (OSTZ, SystemIO, 0x00000F4B, 0x00000161)
Field (OSTZ, AnyAcc, NoLock, Preserve)
{
TPOT, 8
}
}
}
{
Scope (\_SB)
{
Name (OSTB, Ones)
OperationRegion (OSTY, SystemMemory, 0x47F7FF4C, 0x00000001)
Field (OSTY, AnyAcc, NoLock, Preserve)
{
TPOS, 8
}
OperationRegion (OSTZ, SystemIO, 0x00000F4B, 0x00000161)
Field (OSTZ, AnyAcc, NoLock, Preserve)
{
TPOT, 8
}
}
}
And compile
CODE
; Intel ACPI Component Architecture
; ASL Optimizing Compiler version 20100528 [Jul 12 2010]
; Copyright (c) 2000 - 2010 Intel Corporation
; Supports ACPI Specification Revision 4.0a
;
; Compilation of "SSDT.4.dsl" - Tue Jul 20 17:47:56 2010
;
; Assembly code source output
; AML code block contains 0x66 bytes
;
db 053h,053h,044h,054h,066h,000h,000h,000h ; 00000000 "SSDTf..."
db 001h,0CDh,049h,04Eh,054h,045h,04Ch,020h ; 00000008 "..INTEL "
db 043h,050h,055h,043h,053h,054h,043h,034h ; 00000010 "CPUCSTC4"
db 000h,000h,004h,006h,049h,04Eh,054h,04Ch ; 00000018 "....INTL"
db 028h,005h,010h,020h,010h,041h,004h,05Ch ; 00000020 "(.. .A.\"
db 05Fh,053h,042h,05Fh,008h,04Fh,053h,054h ; 00000028 "_SB_.OST"
db 042h,0FFh,05Bh,080h,04Fh,053h,054h,059h ; 00000030 "B.[.OSTY"
db 000h,00Ch,04Ch,0FFh,0F7h,047h,001h,05Bh ; 00000038 "..L..G.["
db 081h,00Bh,04Fh,053h,054h,059h,000h,054h ; 00000040 "..OSTY.T"
db 050h,04Fh,053h,008h,05Bh,080h,04Fh,053h ; 00000048 "POS.[.OS"
db 054h,05Ah,001h,00Bh,04Bh,00Fh,00Bh,061h ; 00000050 "TZ..K..a"
db 001h,05Bh,081h,00Bh,04Fh,053h,054h,05Ah ; 00000058 ".[..OSTZ"
db 000h,054h,050h,04Fh,054h,008h ; 00000060 ".TPOT."
; ASL Optimizing Compiler version 20100528 [Jul 12 2010]
; Copyright (c) 2000 - 2010 Intel Corporation
; Supports ACPI Specification Revision 4.0a
;
; Compilation of "SSDT.4.dsl" - Tue Jul 20 17:47:56 2010
;
; Assembly code source output
; AML code block contains 0x66 bytes
;
db 053h,053h,044h,054h,066h,000h,000h,000h ; 00000000 "SSDTf..."
db 001h,0CDh,049h,04Eh,054h,045h,04Ch,020h ; 00000008 "..INTEL "
db 043h,050h,055h,043h,053h,054h,043h,034h ; 00000010 "CPUCSTC4"
db 000h,000h,004h,006h,049h,04Eh,054h,04Ch ; 00000018 "....INTL"
db 028h,005h,010h,020h,010h,041h,004h,05Ch ; 00000020 "(.. .A.\"
db 05Fh,053h,042h,05Fh,008h,04Fh,053h,054h ; 00000028 "_SB_.OST"
db 042h,0FFh,05Bh,080h,04Fh,053h,054h,059h ; 00000030 "B.[.OSTY"
db 000h,00Ch,04Ch,0FFh,0F7h,047h,001h,05Bh ; 00000038 "..L..G.["
db 081h,00Bh,04Fh,053h,054h,059h,000h,054h ; 00000040 "..OSTY.T"
db 050h,04Fh,053h,008h,05Bh,080h,04Fh,053h ; 00000048 "POS.[.OS"
db 054h,05Ah,001h,00Bh,04Bh,00Fh,00Bh,061h ; 00000050 "TZ..K..a"
db 001h,05Bh,081h,00Bh,04Fh,053h,054h,05Ah ; 00000058 ".[..OSTZ"
db 000h,054h,050h,04Fh,054h,008h ; 00000060 ".TPOT."
I see 0x805B.
All the OP codes are described in ACPI xx standard. You can check the values, maybe a made a mistake.
QUOTE (osxfr33k @ Jul 21 2010, 05:45 AM)
I have not played around with compiling sources in OSX yet only Linux. Is it kinda the same?
Anyhow does anyone have a link to the i386 binary?
Just cd to path/to/Chameleon-Mozodojo/ and type `make' or `make embedtheme', compiled files are in sym.Anyhow does anyone have a link to the i386 binary?
I have a non specific CPU DSDT.aml made by Brett Whinnen for a Dell XPS M1530. Knowing this do I still need to DropSSDT=Yes in the com.apple.Boot.plist?
I have SSDT.aml files Extracted from Ubuntu. Just rename them as SSDT-1.aml, SSDT-2.aml etc etc and use all 5? The Pm one to? I put them into the HFS EFI Partition /Extra along with the DSDT.aml.
These are names of the 5 that got extracted:
SSDT_r1-PmRef-Cpu0Cst-3001-INTL-20050624.aml
SSDT_r1-PmRef-Cpu0Ist-3000-INTL-20050624.aml
SSDT_r1-PmRef-Cpu1Cst-3000-INTL-20050624.aml
SSDT_r1-PmRef-Cpu1Ist-3000-INTL-20050624.aml
SSDT_r1-PmRef-CpuPm-3000-INTL-20050624.aml
If I need all 5 what order is it? SSDT-1 would be CPU0Cst, SSDT-2 would be CPU0lst, SSDT-3 would be Cpu1Cst, SSDT-4 would be Cpu1lst and SSDT-5 would be CpuPm?
I am not seeing them get loaded in Verbose mode as I saw in the prior Chameleon I had installed?
Is there a Test I can do or look in the Ioreg to see if C State is enabled and functioning correctly?
I am also using this New FakeSMC with SuperIO and wonder if I should remove them or just leave them?
http://www.projectosx.com/forum/index.php?showtopic=1206
Thanks
I have SSDT.aml files Extracted from Ubuntu. Just rename them as SSDT-1.aml, SSDT-2.aml etc etc and use all 5? The Pm one to? I put them into the HFS EFI Partition /Extra along with the DSDT.aml.
These are names of the 5 that got extracted:
SSDT_r1-PmRef-Cpu0Cst-3001-INTL-20050624.aml
SSDT_r1-PmRef-Cpu0Ist-3000-INTL-20050624.aml
SSDT_r1-PmRef-Cpu1Cst-3000-INTL-20050624.aml
SSDT_r1-PmRef-Cpu1Ist-3000-INTL-20050624.aml
SSDT_r1-PmRef-CpuPm-3000-INTL-20050624.aml
If I need all 5 what order is it? SSDT-1 would be CPU0Cst, SSDT-2 would be CPU0lst, SSDT-3 would be Cpu1Cst, SSDT-4 would be Cpu1lst and SSDT-5 would be CpuPm?
I am not seeing them get loaded in Verbose mode as I saw in the prior Chameleon I had installed?
Is there a Test I can do or look in the Ioreg to see if C State is enabled and functioning correctly?
I am also using this New FakeSMC with SuperIO and wonder if I should remove them or just leave them?
http://www.projectosx.com/forum/index.php?showtopic=1206
Thanks
SSDT file name stating from SSDT.aml, second SSDT-1.aml and so on.
Thanks for the clarification.
The Memory Allocation Error is still there. I grabbed your latest update released a couple of hours ago and still get the error.
Addr=0xc0a000, Size=0xbfe000, File=free, Line=0
The Memory Allocation Error is still there. I grabbed your latest update released a couple of hours ago and still get the error.
Addr=0xc0a000, Size=0xbfe000, File=free, Line=0
QUOTE (osxfr33k @ Jul 22 2010, 06:19 AM)
I am also using this New FakeSMC with SuperIO and wonder if I should remove them or just leave them?
Don't remove. They are different projects.
forget to say about required boot options, to activate _PSS and _CST SSDT generation. Read the first post.
Hi guys,
Mojodojo, i have some stuff related to getDDRPartNum() to share; first thing i noticed when looking to the code was this comment:
i know that's not true because both Chameleon and Asere's showed me 9905429-002.A00LF for my Kingston modules. The other 2 Qimonda modules only showed Part Number on Asere's booter, 64T64000HU3SB. These match what Everest/CPU-z show on windows.
So to cut it short, what i figured out is there's more characters on Part Number besides this first group of "continuous" ones, but at least in my case there's always at least one "space" between the first and second group; so i decided to try add ispunct, break at the first space found and it works fine.
If this proves to be the case for all part serials, i think it's nailed if not, maybe it points somewer.
EDIT: seems it's really the case.
I'm just an apprentice so, feel free to improve this anyway possible. This is what System Profiler shows atm:
Click to view attachment
Everything is correct except for the Serials; can't comment much on this, need to investigate but i get the feeling that there's some hex involved in here?! EDIT: yeah, lot's of it
Everest shows the serials like this 80CCC94Dh and Asere's booter also seems to return a hex value:
Click to view attachment
That's all i can point for now. This one is probably over my knowledge!? I can always help testing.
Hey.. congrats and thanks on the nice work.. already committed to the trunk and everything
Very nice indeed!
EDIT: i should have refreshed my memory reading SPD spec first; bytes on SPD store hex values, which are used to represented ascii encoded characters.
Mojodojo, i have some stuff related to getDDRPartNum() to share; first thing i noticed when looking to the code was this comment:
QUOTE
// It seems that System Profiler likes only letters and digits...
i know that's not true because both Chameleon and Asere's showed me 9905429-002.A00LF for my Kingston modules. The other 2 Qimonda modules only showed Part Number on Asere's booter, 64T64000HU3SB. These match what Everest/CPU-z show on windows.
So to cut it short, what i figured out is there's more characters on Part Number besides this first group of "continuous" ones, but at least in my case there's always at least one "space" between the first and second group; so i decided to try add ispunct, break at the first space found and it works fine.
CODE
libsa.h -> ctype stuff
//Azi: TODO - add more ponctuation characters as needed; at least these two, i need for PartNo.
static inline int ispunct(char c)
{
return (c == '.' || c == '-');
}
spd.c
/** Get DDR3 or DDR2 Part Number, always return a valid ptr */
const char * getDDRPartNum(const char* spd) //Azi:mozo
{
static char asciiPartNo[18];
const char * sPart = NULL;
int i, index = 0;
if (spd[SPD_MEMORY_TYPE] == SPD_MEMORY_TYPE_SDRAM_DDR3)
{
sPart = &spd[128];
}
else if (spd[SPD_MEMORY_TYPE] == SPD_MEMORY_TYPE_SDRAM_DDR2)
{
sPart = &spd[73];
}
memset(asciiPartNo, 0, 18);
// 17 bytes for serial, byte 73(MSB) to 90 on ddr2, byte 128(MSB) to 145 on ddr3.
for (i = 0; i < 17; i++)
{
if (isalpha(sPart[i]) || isdigit(sPart[i]) || ispunct(sPart[i]))
asciiPartNo[index++] = sPart[i];
// break when first space is found.
if (isspace(sPart[i]))
break;
}
return strdup(asciiPartNo);
}
//Azi: TODO - add more ponctuation characters as needed; at least these two, i need for PartNo.
static inline int ispunct(char c)
{
return (c == '.' || c == '-');
}
spd.c
/** Get DDR3 or DDR2 Part Number, always return a valid ptr */
const char * getDDRPartNum(const char* spd) //Azi:mozo
{
static char asciiPartNo[18];
const char * sPart = NULL;
int i, index = 0;
if (spd[SPD_MEMORY_TYPE] == SPD_MEMORY_TYPE_SDRAM_DDR3)
{
sPart = &spd[128];
}
else if (spd[SPD_MEMORY_TYPE] == SPD_MEMORY_TYPE_SDRAM_DDR2)
{
sPart = &spd[73];
}
memset(asciiPartNo, 0, 18);
// 17 bytes for serial, byte 73(MSB) to 90 on ddr2, byte 128(MSB) to 145 on ddr3.
for (i = 0; i < 17; i++)
{
if (isalpha(sPart[i]) || isdigit(sPart[i]) || ispunct(sPart[i]))
asciiPartNo[index++] = sPart[i];
// break when first space is found.
if (isspace(sPart[i]))
break;
}
return strdup(asciiPartNo);
}
If this proves to be the case for all part serials, i think it's nailed
EDIT: seems it's really the case.
I'm just an apprentice so, feel free to improve this anyway possible. This is what System Profiler shows atm:
Click to view attachment
Everything is correct except for the Serials; can't comment much on this, need to investigate but i get the feeling that there's some hex involved in here?! EDIT: yeah, lot's of it
Everest shows the serials like this 80CCC94Dh and Asere's booter also seems to return a hex value:
Click to view attachment
That's all i can point for now. This one is probably over my knowledge!? I can always help testing.
Hey.. congrats and thanks on the nice work.. already committed to the trunk and everything
Very nice indeed!
EDIT: i should have refreshed my memory reading SPD spec first; bytes on SPD store hex values, which are used to represented ascii encoded characters.
Thank you for reporting this! Will try to fix it.
QUOTE (osxfr33k @ Jul 22 2010, 08:41 AM)
Thanks for the clarification.
The Memory Allocation Error is still there. I grabbed your latest update released a couple of hours ago and still get the error.
Addr=0xc0a000, Size=0xbfe000, File=free, Line=0
The Memory Allocation Error is still there. I grabbed your latest update released a couple of hours ago and still get the error.
Addr=0xc0a000, Size=0xbfe000, File=free, Line=0
This is a known bug from now. I've just found why it's happens. Need to fix it, then I'll come back at home. Because I allocate memory with AllocateKernelMemory and after try to free it with free() instead of ... Don't remember.
QUOTE (Mojodojo @ Jul 22 2010, 10:13 AM)
This is a known bug from now. I've just found why it's happens. Need to fix it, then I'll come back at home. Because I allocate memory with AllocateKernelMemory and after try to free it with free() instead of ... Don't remember.
I've the same problem with latest build
Click to view attachment
Mojodojo,
i like to start from the end so, i did the stuff first and checked SPD spec after
Edited my previous post and code. For me makes sense like this.
Will take a look at the Serial; the problem seems to be that there's no MSBbyte defined, like on Part Number...
i like to start from the end so, i did the stuff first and checked SPD spec after
Edited my previous post and code. For me makes sense like this.
Will take a look at the Serial; the problem seems to be that there's no MSB
QUOTE (Azimutz @ Jul 22 2010, 02:37 PM)
Mojodojo,
i like to start from the end so, i did the stuff first and checked SPD spec after
Edited my previous post and code. For me makes sense like this.
Will take a look at the Serial; the problem seems to be that there's no MSB byte defined, like on Part Number...
i like to start from the end so, i did the stuff first and checked SPD spec after
Edited my previous post and code. For me makes sense like this.
Will take a look at the Serial; the problem seems to be that there's no MSB byte defined, like on Part Number...
I thought about this. Will add your changes later. What is MSB byte?
Sorry about bit/byte confusion.. MSB = Most Significant Bit. On Part Number is always on byte 73 for ddr2 and 128 for ddr3.
For Serial ddr2 i'm reading this on one of the specification documents i have around:
It's better than my explaining.
For Serial ddr2 i'm reading this on one of the specification documents i have around:
QUOTE
Byte 95-98
Module Serial Number
Optional manufacturer assigned number. On the serial number setting, JEDEC has no specification on the data format nor dictates the location of Most Significant Bit. Therefore, it's up to individual manufacturer to assign his numbering system. All CST testers and EZ-SPD programmers have the option for user to select either byte 95 or byte 98 as the MSB (most significant bit). The testers assume the use of ASCII format; which is the most commonly used. The CST testers also have the function to automatically increment the serial number on each module tested.
Module Serial Number
Optional manufacturer assigned number. On the serial number setting, JEDEC has no specification on the data format nor dictates the location of Most Significant Bit. Therefore, it's up to individual manufacturer to assign his numbering system. All CST testers and EZ-SPD programmers have the option for user to select either byte 95 or byte 98 as the MSB (most significant bit). The testers assume the use of ASCII format; which is the most commonly used. The CST testers also have the function to automatically increment the serial number on each module tested.
It's better than my explaining.
Check rev198 on forge.chameleon.org. I have fixed all known bugs, if not forget something
Just came from some rest and 
you guys been busy... going to check. Will keep in touch
you guys been busy... going to check. Will keep in touch
QUOTE (Mojodojo @ Jul 22 2010, 06:04 PM)
Check rev198 on forge.chameleon.org. I have fixed all known bugs, if not forget something
Thx No KP, and finaly i see details about my RAM in system profiler
.Any chance to add shutdown fix to your bootloader.
Great work
Thank you
Memory Allocation Error gone on Rev204 but Unfortunately I still have this issue with System Memory Profiler, error while gathering this info.
Is there a Tool(s) or Ioreg where I can confirm C and P states working? It seems to be running cooler at idle.
My shutdown and restart works with script in my DSDT
EDITED RIGHT AFTER SCRAX POST BELOW:
I am seeing the same ProcessorOP message. I though it was because of the NON CPU SPECIFIC DSDT I use. Is there some Modifications we need to make to our SSDT or DSDT tables for this to work?
DELL LAPTOP XPS M1530 2.6 GHZ (T9500) 4GB 667MHZ System Ram.
Is there a Tool(s) or Ioreg where I can confirm C and P states working? It seems to be running cooler at idle.
My shutdown and restart works with script in my DSDT
EDITED RIGHT AFTER SCRAX POST BELOW:
I am seeing the same ProcessorOP message. I though it was because of the NON CPU SPECIFIC DSDT I use. Is there some Modifications we need to make to our SSDT or DSDT tables for this to work?
DELL LAPTOP XPS M1530 2.6 GHZ (T9500) 4GB 667MHZ System Ram.
Hi all,
I'm testing the rev204 from chameleon.
It works with an old dsdt i was using,but with the attached dsdt (an original DSDT from MacMini3,1 patched with some id for my mobo that's the same chipset) it gives me this error:
Invalid characters found in ProcessorOP!
Invalid characters found in ProcessorOP!
Invalid characters found in ProcessorOP!
Invalid characters found in ProcessorOP!
DSDT CPUs not found: C-States not generated !!!
Invalid characters found in ProcessorOP!
Invalid characters found in ProcessorOP!
Invalid characters found in ProcessorOP!
Invalid characters found in ProcessorOP!
DSDT CPUs not found: P-States not generated !!!
SOLVED!(see down)
Click to view attachment
Like all the older versions of chameleon Ram is still not recognized.
Hardware:
zotac gf9300 wifi itx, intel q9300@2,5
2x2GB TeamElite DDR2 800
@osxfr33k I use MSR tools to check speed step, but it's limited to 2 cores
I'm testing the rev204 from chameleon.
It works with an old dsdt i was using,
Invalid characters found in ProcessorOP!
Invalid characters found in ProcessorOP!
Invalid characters found in ProcessorOP!
Invalid characters found in ProcessorOP!
DSDT CPUs not found: C-States not generated !!!
Invalid characters found in ProcessorOP!
Invalid characters found in ProcessorOP!
Invalid characters found in ProcessorOP!
Invalid characters found in ProcessorOP!
DSDT CPUs not found: P-States not generated !!!
SOLVED!(see down)
Click to view attachment
Like all the older versions of chameleon Ram is still not recognized.
Hardware:
zotac gf9300 wifi itx, intel q9300@2,5
2x2GB TeamElite DDR2 800
@osxfr33k I use MSR tools to check speed step, but it's limited to 2 cores
Mojodojo,
this is what i get now with a trunk build on memory pane:
Click to view attachment
we can't use
on Part Number to break, because the space we are looking for is also an ascii character (0x20); This way i get one more "B" on the Qimonda modules (64T64000HU3SBB) and i know there is a space between those last 2 B's.
About the Serial, still investigating; i had tried "%x" before but the value seemed insane at the time.
About cpu id, works fine as before; i get "Core 2 Duo" for my "Pentium D 925" (family 15, model 6), because of the 2 cores.
this is what i get now with a trunk build on memory pane:
Click to view attachment
we can't use
CODE
else if (!isascii(c))
on Part Number to break, because the space we are looking for is also an ascii character (0x20); This way i get one more "B" on the Qimonda modules (64T64000HU3SBB) and i know there is a space between those last 2 B's.
About the Serial, still investigating; i had tried "%x" before but the value seemed insane at the time.
About cpu id, works fine as before; i get "Core 2 Duo" for my "Pentium D 925" (family 15, model 6), because of the 2 cores.
I've solved the problem with the macmini derivated dsdt.
Scope (_PR) need to be the first part of code.
I've just moved it from the old position to the top of the dsdt and now it works all as expected!
thanks to yall for this new mod
Scope (_PR) need to be the first part of code.
I've just moved it from the old position to the top of the dsdt and now it works all as expected!
thanks to yall for this new mod
QUOTE (Azimutz @ Jul 23 2010, 11:23 AM)
Mojodojo,
this is what i get now with a trunk build on memory pane:
Click to view attachment
we can't use
on Part Number to break, because the space we are looking for is also an ascii character (0x20); This way i get one more "B" on the Qimonda modules (64T64000HU3SBB) and i know there is a space between those last 2 B's.
About the Serial, still investigating; i had tried "%x" before but the value seemed insane at the time.
About cpu id, works fine as before; i get "Core 2 Duo" for my "Pentium D 925" (family 15, model 6), because of the 2 cores.
this is what i get now with a trunk build on memory pane:
Click to view attachment
we can't use
CODE
else if (!isascii(c))
on Part Number to break, because the space we are looking for is also an ascii character (0x20); This way i get one more "B" on the Qimonda modules (64T64000HU3SBB) and i know there is a space between those last 2 B's.
About the Serial, still investigating; i had tried "%x" before but the value seemed insane at the time.
About cpu id, works fine as before; i get "Core 2 Duo" for my "Pentium D 925" (family 15, model 6), because of the 2 cores.
Yes, still need to fix that algo. Just to add like ASCII codes.
P.S. Compiled new code, need to test on memory with serial number different then 00000:
QUOTE (scrax @ Jul 23 2010, 10:14 AM)
I've solved the problem with the macmini derivated dsdt.
Scope (_PR) need to be the first part of code.
I've just moved it from the old position to the top of the dsdt and now it works all as expected!
thanks to yall for this new mod
Scope (_PR) need to be the first part of code.
I've just moved it from the old position to the top of the dsdt and now it works all as expected!
thanks to yall for this new mod
You used a Macmini DSDT and did the other usual Mods to it? HPET etc.
Do you think if I move my current DSDT _PR to the top it may work?
Where exactly did you place it? Can you put a snippit of the code so we can see? Is it right before the start of any Scope or somewhere right after the definition block?
I thought this problem had something to do with the Scope (_PR) address?
MacBook Pro _PR:
Processor (CPU0, 0x00, 0x00000410, 0x06) {}
Dell XPS M1530 _PR:
Processor (CPU0, 0x00, 0x00001010, 0x06) {}
I have to find one for the Dell Laptop XPS M1530 and try it.
Would a modified smbios.plist do the job instead of replacing the DSDT?
Thanks
QUOTE (osxfr33k @ Jul 23 2010, 05:58 PM)
You used a Macmini DSDT and did the other usual Mods to it? HPET etc.
Thanks
Thanks
The dsdt of my board, and the macmini3,1 dsdt are wery similar so instead of shrink the original dsdt to make it like the one of the mac mini i've added to the one of the mac mini HDEF for audio, GFX for GF9300 (id of 9400 like the macmini because my 9300 is OC like a 9400) RTC for cmos reset fix, SATA id inj for a correct sata driver, removed FRWR because there is no firewire on my mobo and removed ARPT beacuse i've no airport in that mobo, I use a usb wifi card with his driver for osx. also removed HUB1 and 2 but this last one is experimental to avoid smoe problem because the usb of this board has some bug like no wake from sleep...
Inthis dsdt "Scope (_PR)" and all it's contents are near line 300, after moving it up near the beginning of the dsdt the problem is gone:
CODE
/*
* Intel ACPI Component Architecture
* AML Disassembler version 20091112
*
* Disassembly of /dsdt.aml, Sat Jul 24 02:54:06 2010
*
*
* Original Table Header:
* Signature "DSDT"
* Length 0x00004AF4 (19188)
* Revision 0x01 **** ACPI 1.0, no 64-bit math support
* Checksum 0x9B
* OEM ID "APPLE "
* OEM Table ID "Macmini"
* OEM Revision 0x00030001 (196609)
* Compiler ID "INTL"
* Compiler Version 0x20091112 (537465106)
*/
DefinitionBlock ("/dsdt.aml", "DSDT", 1, "APPLE ", "Macmini", 0x00030001)
{
External (PDC1)
External (PDC0)
External (\_SB_.PCI0.SATA.PRT1)
// BEGIN MOVED PART
Scope (_PR)
{
Processor (CPU0, 0x00, 0x00000810, 0x06) {}
Processor (CPU1, 0x01, 0x00000810, 0x06) {}
Processor (CPU2, 0x02, 0x00000810, 0x06) {}
Processor (CPU3, 0x03, 0x00000810, 0x06) {}
}
//END MOVED PART
OperationRegion (PRT0, SystemIO, 0x80, 0x02)
Field (PRT0, WordAcc, Lock, Preserve)
{
P80H, 16
}
Oper...etc, etc.
* Intel ACPI Component Architecture
* AML Disassembler version 20091112
*
* Disassembly of /dsdt.aml, Sat Jul 24 02:54:06 2010
*
*
* Original Table Header:
* Signature "DSDT"
* Length 0x00004AF4 (19188)
* Revision 0x01 **** ACPI 1.0, no 64-bit math support
* Checksum 0x9B
* OEM ID "APPLE "
* OEM Table ID "Macmini"
* OEM Revision 0x00030001 (196609)
* Compiler ID "INTL"
* Compiler Version 0x20091112 (537465106)
*/
DefinitionBlock ("/dsdt.aml", "DSDT", 1, "APPLE ", "Macmini", 0x00030001)
{
External (PDC1)
External (PDC0)
External (\_SB_.PCI0.SATA.PRT1)
// BEGIN MOVED PART
Scope (_PR)
{
Processor (CPU0, 0x00, 0x00000810, 0x06) {}
Processor (CPU1, 0x01, 0x00000810, 0x06) {}
Processor (CPU2, 0x02, 0x00000810, 0x06) {}
Processor (CPU3, 0x03, 0x00000810, 0x06) {}
}
//END MOVED PART
OperationRegion (PRT0, SystemIO, 0x80, 0x02)
Field (PRT0, WordAcc, Lock, Preserve)
{
P80H, 16
}
Oper...etc, etc.
So check the Scope (_PR) in your dsdt and try to move it at the top os the dsdt to see if it works also for you.
Please note that I don't think it's a good idea to use a dsdt from another machine in general, my case is a particular one (and i'm using this only for test).
Hope this help with your problem
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.