Chameleon RC5 mode with mem detection enabled and automatic P-States & C-States generation for native power managment

[Time2Retire]

I know.

/*
* Default path to kernel cache file
*/
//Slice - first one for Leopard
#define kDefaultCachePath "/System/Library/Caches/com.apple.kernelcaches/kernelcache"
#define kDefaultCachePathSnow "/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache"
#define kDefaultCachePathTiger "/System/Library/Extensions.kextcache"

I just wonder why Chameleon team do not want to take this into account for a half a year.

Presumably because it is a little more complicated; you first need to amend "/kernelcache" to the new path and then, based on the architecture "_i386." before the adler.

 

Yah. My three week fun period (Christmas holidays) started today

[Slice]

Thank for note. Yes, the code must be revised

sprintf(gBootKernelCacheFile, "%s.%08lX", kDefaultCachePathSnow, adler32);

But I don't know about 32 and 64 bits. Is this a difference?

[valv]

That's why I am not there.

There is no Team.

Welcome in the Team Slice More seriously Kabyl has just added a branch for you.

[rednous]

I know that this thread isn't for hacking Snow Leopard but I stumbled on a very interesting document - MAC OS X Hacking, Snow Leopard Edition written by Charlie Miller, attached below. I think it will be of interest for the Chameleon dev team and all the programmers here

 

Here's the document overview (more inside the attached document):

• Background
  
• Fun with 64-bit applications
  
• Sandboxing
  
• Topics in Heap overflows
  
• ASLR
  
• DEP
  

MAC OS X Hacking, Snow Leopard Edition, PDF, 81 pages, 11MB

[valv]

@rednous,

that's so kind, thank u

[rednous]

@rednous,

that's so kind, thank u

 

valv, you're welcome, but i have to thank you for your never ending energy, enthusiasm and helpfulness

[cparm]

Thank for note. Yes, the code must be revised

sprintf(gBootKernelCacheFile, "%s.%08lX", kDefaultCachePathSnow, adler32);

But I don't know about 32 and 64 bits. Is this a difference?

for 64 bit it should be :

		sprintf(gBootKernelCacheFile, "%s_x86_64.%08lX", kDefaultCachePath, adler32);

i also noticed that adler32 give me a wrong cache name

 

in my case it should be: S/L/C/c/S/kernelcache_x86_64.86****1D.

but adler32 give me : S/L/C/c/S/kernelcache_x86_64.87****1D.

[Slice]

Hmmm...

As I see adler32 in chameleon differs from Apple's.

unsigned long AppleFlashNVRAM::adler32( unsigned char* buffer, long length )

Dunno if it influents.

[Time2Retire]

Hmmm...

As I see adler32 in chameleon differs from Apple's.

unsigned long AppleFlashNVRAM::adler32( unsigned char* buffer, long length )

Dunno if it influents.

Hi Slice,

 

There are two Adler32 functions. One at the bottom of boot.c and one at the top of drivers.c And the latter is used by DecodeKernel... and since we can boot

 

What about moving it (see below) into boot.h and delete the one at the bottom of boot.c?

static unsigned long Alder32( unsigned char * buffer, long length )
{
   long          cnt;
   unsigned long result, lowHalf, highHalf;

   lowHalf  = 1;
   highHalf = 0;

for ( cnt = 0; cnt < length; cnt++ )
   {
       if ((cnt % 5000) == 0)
       {
           lowHalf  %= 65521L;
           highHalf %= 65521L;
       }

       lowHalf  += buffer[cnt];
       highHalf += lowHalf;
   }

lowHalf  %= 65521L;
highHalf %= 65521L;

result = (highHalf << 16) | lowHalf;

return result;
}

[Slice]

Moreover

boot.c

unsigned long Adler32(unsigned char *buf, long len)
{

adler32.c

uLong ZEXPORT adler32(adler, buf, len)
uLong adler;
const Bytef *buf;
uInt len;
{

drivers.c

unsigned long
Mkext_Alder32( unsigned char * buffer, long length )
{

[Azimutz]

Hi people...

 

been following this kernel cache talk with interest... it always puzzled me why it's not used.

Have you noticed that there's "adler32" and "alder32"!?... notice the diff? i only noticed it now

 

--------------------

 

For Slice; on your booter, the path for Tiger kernel cache doesn't seem correct to me!?

As far as i understand, Tiger uses the same path as Leo for "kernelcache" file; "Extensions.kextcache" is just a Gzip'ed plist.

Am i missing something here? i don't have much experience with Tiger...

 

Sorry for posting this here, but since the discussion is going on here...

Will check some more things with you later on the ProjectOSX topic.

 

Stay safe...

[sw170]

Hi everybody,

 

Just want to ask here:

With every chameleon version (Slice - also with yours) sometimes when I'm getting KP and forced to do hard reset I'm getting following error message:

 

Memory allocation error ! Addr = 0x0, Size = 0x8000, File = cache.c, line = 94

This is a non recoverable error

SYSTEM HALTED !

 

System starts with no errors when I reset again.

Only bootloader I tried and has this fixed (?) is Conti's myHack version

anybody familiar with this error ?

appreciate any input on that

cheers

s

[Gringo Vermelho]

This is just a guess, I don't know if this could cause what you describe, but have you changed the amount of RAM installed in your PC without changing your DSDT.aml?

 

If you have, extract your DSDT on Windows or Linux and compare it with the DSDT you're using with OS X. Search both DSDTs for "OperationRegion" and compare the numbers. Replace the numbers in the old DSDT with those from the new one.

[sw170]

This is just a guess, I don't know if this could cause what you describe, but have you changed the amount of RAM installed in your PC without changing your DSDT.aml?

 

If you have, extract your DSDT on Windows or Linux and compare it with the DSDT you're using with OS X. Search both DSDTs for "OperationRegion" and compare the numbers. Replace the numbers in the old DSDT with those from the new one.

 

Hi Gringo Vermelho,

Sorry I should say that - this happens on my HP Pavilion laptop, I did some speed tests with Apple ram before, can't remember when now, but that may be at the time when I was fiddling with DSDT too, hmm, never thought about that, thanks a lot mate, will check this.

Regards

Swavek

 

Edit on 08.01.11:

Problem solved, thanks Gringo ! DSDT difference was in my HPET Device:

						Memory32Fixed (ReadOnly,
						0xFED00000,		 // Address Base
						0x00000400,		 // Address Length
						_Y17)  //changed from Y0F TO Y17

cheers.

s

[Time2Retire]

...

As far as i understand, Tiger uses the same path as Leo for "kernelcache" file; "Extensions.kextcache" is just a Gzip'ed plist.

Am i missing something here?

I might read this wrong, or you are talking about something else, but the kernel cache includes both the kernel and kernel extensions, linked at their final load addresses: man com.apple.Boot.plist

 

Kernel Cache

This option specifies the prelinked kernel file to be loaded, which contains both the kernel and kernel extensions, linked at their final load addresses. The path uses backslash ("\ ") path delimeters. The default value is calculated programmatically using System\ Library\ Caches\ com.apple.kext.caches\ Startup\kernelcache_${ARCH}.${CHECKSUM} as the template, where ${ARCH} is the architecture of the kernel ("i386" or "x86_64") and ${CHECKSUM} is a 32-bit hash of characteristics of the boot volume and machine hardware.

BTW: Fixing the path error was the easy part because now I keep ending here:

		if (uncompressed_size != size)
	{
		error("size mismatch from lzss: %x\n", size);
		return -1;
	}

[Azimutz]

Dutchhockeypro, what i mean is that the path for Tiger (10.4) kernel cache is pointing to "Extensions.kextcache",

/*
* Default path to kernel cache file
*/
//Slice - first one for Leopard
#define kDefaultCachePath "/System/Library/Caches/com.apple.kernelcaches/kernelcache"
#define kDefaultCachePathSnow "/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache"
#define kDefaultCachePathTiger "/System/Library/Extensions.kextcache"
//file://localhost/System/Library/Extensions.kextcache

which afaik is no kernel cache. "kernelcache" (the kernel cache) is at the same path as in Leo (10.5).

Hope this makes the question more clear...

[Slice]

Yes, Azimutz, you are right, Tiger and Leo is similar. It's my mistake.

Strange, but the booter works even though wrong kernelcache path.

 

@swavek

Have no any proposition why you have KP.

[Time2Retire]

Dutchhockeypro, what i mean is that the path for Tiger (10.4) kernel cache is pointing to "Extensions.kextcache",

 

...

 

which afaik is no kernel cache. "kernelcache" (the kernel cache) is at the same path as in Leo (10.5).

Hope this makes the question more clear...

I see. Never used Tiger myself. In fact I haven't even seen it. Thank you for clearing that up.

[Time2Retire]

...

i also noticed that adler32 give me a wrong cache name

 

in my case it should be: S/L/C/c/S/kernelcache_x86_64.86****1D.

but adler32 give me : S/L/C/c/S/kernelcache_x86_64.87****1D.

Cparm,

 

Are you booting in 32 bit mode? I ask this because what you see here happens to be the 64-bit ABI mask. It's defined in: mach/machine.h as:

#define CPU_ARCH_ABI64	0x01000000		/* 64 bit ABI */

Note: Chameleon sets this despite booting in 32 bit mode:

bootArgs->efiMode = kBootArgsEfiMode64;

p.s. Yep. That's in fake_efi.c Please try / confirm with: kBootArgsEfiMode32

[Pluskat5000Schiffe]

Hey guys. I have something really weird at my HP8710W mobile workstation (laptop 17inch).

 

I have my system setup almost 100% perfect now instead of one stupid thing.

 

To be short the FSB settings are incorrect detected of CPU (T7700) and memory DD2 666MHz.

 

If I use any of the Valv's bootloaders all FSB settings are detected correct but if I use that bootloader the sound is cracky. With the Chameleon RC5 bootloader the sound is perfect clear but system isn't running at full potential because of lower FSB frequency.

 

I need to use VooDooHDA for the ADI1981 audio chip.

 

The FSB is detected as 184Mhz instead of 200Mhz. The memory is detected incorrect:

 

DSDT is corrected and speed stepping is working perfect with wrong frequencies of course and no errors from Apple Power kexts.

 

Can somebody help me to get my system even more work flawless OSX ? THX!

 

bsmesg output:

 

Intel GM965/GL960 DRAM Controller [8086:2a00] at 00:00.0
Frequency detected: 306 MHz (613) Dual Channel 
CAS:5 tRC:5 tRP:5 RAS:15 (5-5-5-15)
Slot: 0 Type 19 2048MB (DDR2 SDRAM) 613MHz Vendor=Nanya Technology
  PartNo=NT2GT64U8HD0BN-3C SerialNo=44EB4813
Slot: 2 Type 19 2048MB (DDR2 SDRAM) 613MHz Vendor=Nanya Technology
  PartNo=M2N2G64TU8HD5B-3C SerialNo=46761856

 

below max frequency should be 2600 GHz (13X200) instead of 2392 (12 X 183)

 

Note that 2,6GHz is impossible to run on both. This CPU T7700 has dynamic acceleration and maybe thats causing the problem because one core will be at 11X multiply when the first core can reach 13X

 

Maybe the problem can be fixed by limiting the max multiply to 12 and so disabling dynamic acceleration but thats just my noob thinking :-)

[valv]

@hannibal1969,

regarding cracky sound on anval, did u try latest version.

also instead of FixFSB key, try ForceFSB with (186,...) as value. That's if u still want to give it a try. I not I fully understand

[Pluskat5000Schiffe]

Yep I tried all version from 5.06 lowering as low to version 4 all versions good detection but cracky sound. If I force the FSB to 184 the sounds is back to normal. If I adjust it to lets say 190MHz its starting to be cracky.

 

The detection o the FSB in the standard Chameleon version is detected wrong with 184MHz as FSB but it seems to know that it should settle at 184 to get the sound good.

 

The memory is FSB 166MHZ X4 and the CPU is FSB 200 X 13 max so memory / PCI / CPU are running with different FSB and maybe thats going wrong with the audio chip. Maybe it wants to force a FSB of 200MHz to the PCI bus but it should be 166MHz ?

[valv]

The detection o the FSB in the standard Chameleon version is detected wrong with 184MHz as FSB but it seems to know that it should settle at 184 to get the sound good.

No, chameleon is detecting it right. My version is forcing it.

It is fully an messy Bios version. That is from where the fault came.

Look if you can make a bios update.

If I adjust it to lets say 190MHz its starting to be cracky.

You better stick with a value below 190 then.

[Pluskat5000Schiffe]

No, chameleon is detecting it right. My version is forcing it.

It is fully an messy Bios version. That is from where the fault came.

Look if you can make a bios update.

You better stick with a value below 190 then.

 

 

mmm there is one newer .. F0:F im now using F0:E the DSDT made for my laptop (not by myself) was done to F0:E so Im afraid that the DSDT is not working correctly anymore with F0:F

 

Just upgraded the bios to F0F no difference also upgarded to the newest chameleon auto detection still incorrect.

[Azimutz]

Yes, Azimutz, you are right, Tiger and Leo is similar. It's my mistake.

Strange, but the booter works even though wrong kernelcache path.

Thanks for confirming, Slice.

I've been taking a look at this stuff, but i need to look more before making comments.

 

I see. Never used Tiger myself. In fact I haven't even seen it. Thank you for clearing that up.

Well, to be honest, Tiger was the first OS X i installed, on a virtual machine; i had it installed long enough to like OS X a lot

and fetch another distro to try, which translates to a few hours 10.5.4 was the deal at the time.

Now i just got it from the vault to take a better look at...