Chameleon RC4 is out!

The problem is the same with last cham, restarts in a infinite loop.

The last cham downloaded from svn don't work for me; i've try it on desktop and on msiu and on both they restarted in a infinite loop.

The problem is the same with last cham, restarts in a infinite loop.

For me too r112 not working yet

Strange as it's not working for others but it does for me?

If I can help share any info about my setup then let me know.

For ref, I have attached the build I made that works for me.

RC5_prerelease_18___Build_112.zip

Blackosx's pre18b12 also works fine for me on a Gigabyte X48-DS5.

I made a r112 that worked great for me on 2 different machines, hope this works for you...

With r107, the reboot happens before I could get to the Darwin boot prompt.

With r112, regardless what I set for UseMemDetect, the reboot happens somewhere in the DMI patching code.

Maybe there is an ASUS specific issue here since both Smith@@, scrax and me are using ASUS mobos.

@iNDi: This issue reminds me your fight against a very similar instant reboot issue on ASUS boards.. Can't find the details about how You fixed that.

Strange as it's not working for others but it does for me?

If I can help share any info about my setup then let me know.

 

For ref, I have attached the build I made that works for me.

Do you have any ASUS product nearby to test this one?

Sorry Zef, No ASUS near me.

Hopefully others can submit their test reports of R112 to help build an overall picture.

BlackOSX R112 works great for me on ASUS, Seems faster.

Memory reads

BANK1/DIMM1:

Size: 2 GB

Type: DDR2 SDRAM

Speed: 800 MHz

Status: OK

Manufacturer: N/A

Part Number: N/A

Serial Number: N/A

when its 1066Mhz OCZ and Asere's booter got that and the serial number - but this doesn't matter really, fast boot much appreciated, thanks!

Works fine on my ASUS notebook or desktop, just that memory is stuck @ 800 MHZ, I tried UseMemDetect=yes no change.

Guess there is no option to enable it... or the flag is wrong.

If there is no custom DSDT to load FACP fix is not working, this should be fixed and not conditioned by DSDT.aml found

With stuff added back in Smbios.plist I got them memory info, so old way still works.

Not trying to be antagonistic here, just an honest question. The data needs to be obtained on startup, either directly from SPD, or a "cached" version in a plist file. Is SPD/SMBus access really that much slower than reading and parsing the XML in the plist file? Or are you strictly worried about boot load size?

I'm not too concerned about the boot file size [for Chameleon] but cached data is much faster yes. Even with XML data [which to me is another candidate for removal].

@Rek,

My ASUS boards are still rebooting here (:

With r107, the reboot happens before I could get to the Darwin boot prompt.

With r112, regardless what I set for UseMemDetect, the reboot happens somewhere in the DMI patching code.

Maybe there is an ASUS specific issue here since both Smith@@, scrax and me are using ASUS mobos.

 

@iNDi: This issue reminds me your fight against a very similar instant reboot issue on ASUS boards.. Can't find the details about how You fixed that.

 

 

 

Do you have any ASUS product nearby to test this one?

OK Folks, good news overall, we need to help all ASUS folks for which it does not work.

Zef, do you think you can contact iNDi on irc ?

Would be great to understand what's going on with this problem.

Also, meanwhile it would be worth it to understand which _last_ version did not cause a reboot for you folks.

@Rek,

I was reading the source code when I saw this:

struct SMBEntryPoint *getSmbios(int which)
{
   static struct SMBEntryPoint *orig = NULL; // cached
   static struct SMBEntryPoint *patched = NULL; // cached
   // whatever we are called with orig or new flag, initialize asap both structures
   if (orig == NULL) orig = getAddressOfSmbiosTable();
   if (patched == NULL) {
       [color="#FF0000"]patched = smbios_dry_run(orig);
       smbios_real_run(orig, patched);[/color]
   }

   switch (which) {
   case SMBIOS_ORIGINAL:
       return orig;
   case SMBIOS_PATCHED:
       return patched;
   default:
       printf("ERROR: invalid option for getSmbios() !!\n");
       return NULL;
   }
}

You want it to run the red lines, even when people want the original SMBIOS? Would this explain why Zef sees a reboot with the option is set to false?

Edit: Ah I see. "UseMemDetect" only prevents it from calling scan_memory and scan_spd A different kind of beast.

My ASUS boards are still rebooting here (:

same MSI NEO3F board there - since pre11 builds - restart on boot0

Asus laptop A8J boots that

Also, meanwhile it would be worth it to understand which _last_ version did not cause a reboot for you folks.

The last OK rev is r92 on my board. With r97 I get the slots dumped, but after the keypress I get the reboot.

The last OK rev is r92 on my board. With r97 I get the slots dumped, but after the keypress I get the reboot.

Thanks !

I'll analyze what changes and will come back to you,

I also had the chance to discuss with iNDi,

and this folk is simply the most knowledgeable person I had a chance to discuss with about chameleon ...

He told me that the reboot pb that he fixed was about the floating point bug, but it seems it has been fixed since,

I'll check that as well.

He also gave me tons of informations and now I have to digest all of it,

but I can tell you he has been a great help and mentor !

@Rek,

The reboot on my Asus board is triggered by getSmbiosUUID() Returning NULL at the top stops the instant reboots (preliminary finding). Have to get some sleep now.

Strange as it's not working for others but it does for me?

If I can help share any info about my setup then let me know.

 

For ref, I have attached the build I made that works for me.

Can you up the source of fdisk440. Want to make one for Leopard

Thanks.

Can you up the source of fdisk440. Want to make one for Leopard

 

Thanks.

Hi rals2007

It's already a universal binary.

More info here.

Source is on the SVN.

Hi

I tested the boot file that is in RC5 prerelease 18 - Build 112 don't work for me.

I put this file to boot the root of my drive, I guess that's how to do ?

Have you any idea what's wrong.

Thanks

Rekursor,

I just tested the build blackosx posted yesterday and it's not detecting my memory properly on my Dell Studio 14z. It does boot (good), but it does not detect the Hynix memory or the speed properly.

I had the correct settings in my smbios.plist:

<dict>

<key>SMbiosdate</key>

<string>10/27/2009</string>

<key>SMbiosversion</key>

<string>MP31.88Z.006C.B02.0801021250</string>

<key>SMfamily</key>

<string>Mac Pro</string>

<key>SMmanufacter</key>

<string>Dell</string>

<key>SMmemmanufacter_1</key>

<string>Hynix</string>

<key>SMmemmanufacter_2</key>

<string>Hynix</string>

<key>SMmempart_1</key>

<string>HMT112S6AFP8C-G7N0</string>

<key>SMmempart_2</key>

<string>HMT351S6AFR8C-G7</string>

<key>SMmemserial_1</key>

<string>00000001</string>

<key>SMmemserial_2</key>

<string>6484502C</string>

<key>SMmemspeed</key>

<string>1066</string>

<key>SMmemtype</key>

<string>24</string>

<key>SMproductname</key>

<string>MacPro3,1</string>

</dict>

Hi all,

Im very intrested in the fdisk440 method as my windows7 installation does not sleep.

Do i need fdisk440 even though my windows7 and SL installs are on separate disks?

If i do could someone post it up and the method i need to take?

Cheers!

Try this:

... went into CMD as administrator and typed "powercfg -h off" and pressed enter and closed CMD window. I now have sleep working.

If i do could someone post it up and the method i need to take?

Im very intrested in the fdisk440 method as my windows7 installation does not sleep.

Here's my interpretation and a quick overview of fdisk440...

When you download Chameleon, you will find an 'fdisk' binary in the i386 folder. I always read that this should be used when installing Chameleon, so I always did, but I never really knew why. As it turns out, this version of fdisk was a modified version of the fdisk that ships with OS X, and the modification was it only writes to the first 440 bytes of the MBR.

The modified binary being called 'fdisk' though has led to confusion in the past as the one that comes with OS X would be used instead of the modified one, so Zef has renamed the modified fdisk to fdisk440 to save future confusion. Therefore, if we all use and refer to fdisk440 from now on then we should all be singing from the same hymn sheet.

The main benefit though can be found when dual booting with Windows7 on the same HDD as Chameleon. This is because when you install Windows7 it will write to the MBR and when you boot, the code in the MBR will go off and do it's thing to load Windows7. If you then go and write Chameleon's boot0 to the MBR using the fdisk that's shipped with OS X it will overwrite the code that Windows put there, resulting in Windows being unable to boot. Where as if you write Chameleon's boot0 to the MBR with the modified fdisk440, it will co-exist with the Windows code, not destroying it, so Windows will continue to boot happily. Though for this particular example, you will want to actually write Chameleon's new boot0hfs to the MBR instead of boot0, as the new boot0hfs will load Chameleon from a non-active partition, allowing Windows 7 to remain the active partition.

Which brings us back to your sleep question, and that is Windows 7 will generally only sleep if it's on the active partition of the HDD that's used to boot it.

Windows 7 will generally only sleep if it's on the active partition of the HDD that's used to boot it.

It rarely is.

By default, the Windows 7 installer creates a 'System Recovery' partition, which is marked active, and installs itself on a second partition, which is not active.

So for the vast majority of users, Windows 7 is already installed to a non-active partition.

By default, the Windows 7 installer creates a 'System Recovery' partition, which is marked active, and installs itself on a second partition, which is not active.

 

So for the vast majority of users, Windows 7 is already installed to a non-active partition.

hmmm.. good point... that's blown my sleep theory out the window...

Thing is, when I have been doing my tests with Windows7, I haven't been installing it on the first partition of the HDD and I think that's why it hasn't been creating the System Reserved partition for me, so Windows7 in my tests has been on the active partition. So what's the correct reason that prevents Windows7 from sleeping?

EDIT: Would it be correct to say then that Windows 7 will generally only sleep if it's on the active partition of the HDD that's used to boot it providing there isn't a System Reserved partition?

@Rek,

 

The reboot on my Asus board is triggered by getSmbiosUUID() Returning NULL at the top stops the instant reboots (preliminary finding). Have to get some sleep now.

Zef and MC, please have a try to r114 and report if you get any debug message,

should permit to clarify what's going on, for sure it has to to do with smbios tables adressing, construction and init ...

@Flashe: this is work in progress, and there several issues we try to address concerning the recent new functionalities, so if it does not work for you, please be patient and wait for a new RC5pre release.

I have very few time right now and can't help you much as the little time I have, I spend it on troubleshooting booter issues.