Jump to content

Chameleon RC4 is out!

Poco

By Poco,
in Front Page News and Rumors

 Share
1,054 posts in this topic

Recommended Posts

zef
zef
Posted
Posted
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?

Link to comment
Share on other sites
scwhar
scwhar
Posted
Posted

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!

Link to comment
Share on other sites
THe KiNG
THe KiNG
Posted
Posted

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.

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
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 (:

Link to comment
Share on other sites
rekursor
rekursor
Posted
Posted
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.

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted

@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.

Link to comment
Share on other sites
zef
zef
Posted
Posted
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.

Link to comment
Share on other sites
rekursor
rekursor
Posted
Posted
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 !

Link to comment
Share on other sites
Onixs
Onixs
Posted
Posted
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.

Link to comment
Share on other sites
tamorgen
tamorgen
Posted
Posted

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.

 

system%20profile.jpg

 

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>

Link to comment
Share on other sites
asadev
asadev
Posted
Posted

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!

Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted
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.

Link to comment
Share on other sites
Beerkex'd
Beerkex'd
Posted
Posted
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.

Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted
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...:D

 

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?

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...