Chameleon RC4 is out!

[blackosx]

The information in RAM can be incorporated in the smbios.plist with all the information that is available.

I have little to do that without problem.

Hi Flashe

 

Yes the memory information has previously been in SMBIOS.plist but Asere's bootloader now contains code to automatically read it from the memory controller.

The memory parameter detecting should work with P35/X38/X48/P45 memory controllers and the builtin memory controllers of the Core i5/i7 CPU's. Reading of memory SPD (Serial Presence Detect EEPROM) data should work on P55, ICH10® and ICH9. You must remove all memory related keys from smbios.plist (SMmemmanufacter_X, SMmempart_X, SMmemserial_X, SMmemspeed & SMmemtype).

[Dr. Hurt]

I patched the chameleon 2 RC4 source with Asere's patch 1.1.2 + Master Chief's recommendations.

 

Boot loader is now silent.

Memory type is detected but not manufacturer, serial, or part number

Speed is displayed as 667Mhz which is actually what I use normally . I tried changing RAM speed in BIOS, but it did not detect them (at least in OS X).

 

Everything else is working perfectly.

Thanks everyone.

 

source and bin attached below

bin.zip

Source.zip

[Flashe]

How we use the 2 files Asere, I deleted my boot file and replace it by Asere but does not work for me, in info for the memory and the patch file to which it serves.

Possible to explain how to install.

Don't work for me.

 

 

 

 

The message is "An error occurred during the compilation of this information."

 

 

Thanks

[Asere]

Good to hear that, that mean the code will be released.

You funny, can you make a "phone call" for EDID and other stuff?

j/k

 

Hehe, not funny... but it's always good to have connections. I'm an embedded software engineer, but unfortunately do we not work with intel chips. So how to resolve the eq: dramfreq = fsbfreq * ratio? Calling someone how is working with intel chips???

 

BTW, I've looked into memtest. The relevant information is also there. Good to know

 

Memory speed detection is working fine for me, although it's not rounding up (ie. it says 666 not 667Mhz, but thats just cosmetic.)

The only issue remaining for me is memory detection (or reporting) for the second slot.

 

Also, please add Master Chief's suggestion to make the boot loader silent.

 

Open device_inject.c and change this line:

printf("efi_inject_get_devprop_string NULL trying stringdata\n");into:

verbose("efi_inject_get_devprop_string NULL trying stringdata\n"); // Used to be: printf(...

 

Thanks in advance

 

Can you explain the issue with the second slot?

 

Added Master Chiefs suggestion.

[Dr. Hurt]

Hehe, not funny... but it's always good to have connections. I'm an embedded software engineer, but unfortunately do we not work with intel chips. So how to resolve the eq: dramfreq = fsbfreq * ratio? Calling someone how is working with intel chips???

 

BTW, I've looked into memtest. The relevant information is also there. Good to know

 

 

 

Can you explain the issue with the second slot?

 

Added Master Chiefs suggestion.

 

Nothing major. Manufacturer, Serial, and Part numbers are not displayed (or detected?). I don't care as long as type and speed are detected.

 

Here's how system profiler looks:

 

Bank2/3/A1:

 

Size: 1 GB

Type: DDR2 SDRAM

Speed: 800 MHz

Status: OK

Manufacturer: N/A

Part Number: N/A

Serial Number: N/A

[Asere]

Hi, interesting work.

I also modified RC4 to add PciRoot autodetection that I injected from netkas pcefi 10.5.

I also added an option to set the system-id to a value of your choice.

My version has been recently incorporated in Dr. Hurt new unofficial RC4_V3 installer.

What would be interesting is to merge the code so that your work can be reviewed and still maintain some compatibility with what has already been done/released.

 

More precisely, it could be nice to harmonize your system-id modifications with mine, i.e: if no override is set in the com.apple.Boot.plist, then you read the bios value isntead of injecting an 0x12345678... arbitrary value as it is done in original RC4 from the IntVar original contrib.

 

I would be interested to have a look to your sources, did you reference them in this forum ?

 

I also have new ideas for chameleon that should be less than a couple of hours of work to implement but cant find the time right now, like:

Adding a 'Rename Partition' option so that we can rename some weird names like 'System Reserved' into "Windows 7' as an example.

 

I also think about developing a chameleon system preferences panel similar to the current Startup panel (that we cant use on our hacks with chameleon) but that would recognize all our boot partitions.

 

We should team up, not only you and me, but I think of the voodoo team and the chameleon team to all contribute to a SINGLE version repository (maybe in the voodoo google project ?)

 

Thanks. I would prefer to open public viewable code repository (Google Code, because of svn access, or github, or ...).

 

I've used SMUUID in smbios.plist to override system-id. If present in smbios.plist, then it's used for system-id and patched into SMBIOS.

 

And yes, we should all team up!

 

 

Hi Asere,

 

Just took a quick look at your 1.1.2 patch. It contains many interesting improvements.

Btw I think you need to re-license your currently GPL'ed files found in this APSL based project in order to bypass the GPL-APSL incompatibility issue .

 

diff -Naur Chameleon-2.0-RC4-r684-src/i386/libsaio/mem.c AsereBLN_v1.1.2_clean/i386/libsaio/mem.c
--- Chameleon-2.0-RC4-r684-src/i386/libsaio/mem.c	1970-01-01 01:00:00.000000000 +0100
+++ AsereBLN_v1.1.2_clean/i386/libsaio/mem.c	2010-01-09 13:32:57.000000000 +0100
@@ -0,0 +1,27 @@
+/*
+ * Copyright 2010 AsereBLN. All rights reserved. <aserebln@googlemail.com>
+ * Released under version 2 of the Gnu Public License (GPLv2).
+ *
+ * mem.c - obtain system memory information
+ */
+ 

 

It's still not released. So I can change this without a problem.

 

 

How we use the 2 files Asere, I deleted my boot file and replace it by Asere but does not work for me, in info for the memory and the patch file to which it serves.

Possible to explain how to install.

Don't work for me.

 

 

 

 

The message is "An error occurred during the compilation of this information."

 

 

Thanks

 

Can you run CPU-Z under Windows? If not, I must modify my Booter to dump the SPD of your memory modules.

 

Did you removed all the memory stuff from smbios.plist? What does the Booter with debugs say?

[rekursor]

Thanks. I would prefer to open public viewable code repository (Google Code, because of svn access, or github, or ...).

 

I've used SMUUID in smbios.plist to override system-id. If present in smbios.plist, then it's used for system-id and patched into SMBIOS.

 

And yes, we should all team up!

We could use both SMUUID and thenew SystemID option to be back-compatible with the numerous folks that already use my patch with iTunes and would hate to cancel their limited number of changes on their iTunes account ...

 

MasterChief suggested github, and I would be glad to have one repository here, because a good way to welcome and unify all the teams here could be to use this (neutral) site ...

 

Still, it could (and should) keep the Chameleon name project.

 

I would be interested to know if Zef (and any other other Chameleon team representative ) is OK so that one of them could hopefully initiate that

[Flashe]

Yes I deleted all the information in the smbios.plist.

At boot how can I check the problem ? boot with-v or another, to know ?

 

 

Dump Cpuz:

 

 

Memory SPD

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

 

DIMM #1

 

General

Memory type DDR2

Module format Regular UDIMM

Manufacturer (ID) Kingston (7F98000000000000)

Size 2048 MBytes

Max bandwidth PC2-6400 (400 MHz)

Part number 9905316-173.A00LF

Serial number 82CC994D

Manufacturing date Week 07/Year 09

 

Attributes

Number of banks 2

Data width 64 bits

Correction None

Nominal Voltage 1.80 Volts

EPP no

XMP no

 

Timings table

Frequency (MHz) 266 333 400

CAS# 4.0 5.0 6.0

RAS# to CAS# delay 4 5 6

RAS# Precharge 4 5 6

TRAS 12 15 18

TRC 16 20 24

 

DIMM #2

 

General

Memory type DDR2

Module format Regular UDIMM

Manufacturer (ID) Kingston (7F98000000000000)

Size 2048 MBytes

Max bandwidth PC2-6400 (400 MHz)

Part number 9905316-173.A00LF

Serial number 81CCE24C

Manufacturing date Week 07/Year 09

 

Attributes

Number of banks 2

Data width 64 bits

Correction None

Nominal Voltage 1.80 Volts

EPP no

XMP no

 

Timings table

Frequency (MHz) 266 333 400

CAS# 4.0 5.0 6.0

RAS# to CAS# delay 4 5 6

RAS# Precharge 4 5 6

TRAS 12 15 18

TRC 16 20 24

 

Dump Module #1

0 1 2 3 4 5 6 7 8 9 A B C D E F

00 80 08 08 0E 0A 61 40 00 05 25 40 00 82 08 00 00

10 0C 08 70 01 02 00 03 30 45 3D 50 3C 1E 3C 2D 01

20 17 25 05 12 3C 1E 1E 00 06 3C 7F 80 14 1E 00 00

30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 DD

40 7F 98 00 00 00 00 00 00 04 39 39 30 35 33 31 36

50 2D 31 37 33 2E 41 30 30 4C 46 00 00 00 09 07 82

60 CC 99 4D 00 00 00 00 00 00 00 00 00 00 00 00 00

70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

F0 39 39 30 35 33 31 36 2D 31 37 33 2E 41 30 30 4C

 

 

Dump Module #2

0 1 2 3 4 5 6 7 8 9 A B C D E F

00 80 08 08 0E 0A 61 40 00 05 25 40 00 82 08 00 00

10 0C 08 70 01 02 00 03 30 45 3D 50 3C 1E 3C 2D 01

20 17 25 05 12 3C 1E 1E 00 06 3C 7F 80 14 1E 00 00

30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 DD

40 7F 98 00 00 00 00 00 00 04 39 39 30 35 33 31 36

50 2D 31 37 33 2E 41 30 30 4C 46 00 00 00 09 07 81

60 CC E2 4C 00 00 00 00 00 00 00 00 00 00 00 00 00

70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

F0 39 39 30 35 33 31 36 2D 31 37 33 2E 41 30 30 4C

[Asere]

We could use both SMUUID and thenew SystemID option to be back-compatible with the numerous folks that already use my patch with iTunes and would hate to cancel their limited number of changes on their iTunes account ...

I do not prefer to be too "back-compatible". It does not help to keep the code clean and straight-forward. I like the idea of an Chameleon PrefPane for settings and updates. In the future we should clean up all this old stuff.

 

MasterChief suggested github, and I would be glad to have one repository here, because a good way to welcome and unify all the teams here could be to use this (neutral) site ...

 

Still, it could (and should) keep the Chameleon name project.

 

I would be interested to know if Zef (and any other other Chameleon team representative ) is OK so that one of them could hopefully initiate that

 

I looked at Github. It's free up to 300MB Diskspace. If we start with an active development, then we will reach the 300MB quickly. How pays then?

[rekursor]

I do not prefer to be too "back-compatible". It does not help to keep the code clean and straight-forward. I like the idea of an Chameleon PrefPane for settings and updates. In the future we should clean up all this old stuff.

Well, SMUUID has been stated in this forum as 'obsoleted' for ages now, I believe that if we must stick with one option, it should be the new SystemID which btw, denotes more precisely what it is and has been used a lot since it has been released.

I looked at Github. It's free up to 300MB Diskspace. If we start with an active development, then we will reach the 300MB quickly. How pays then?

Good point, I though about just the same thing and did a search to see what google offers:

As stated in a discussion of google groups:

A project already starts with 1GB of svn space and 2GB of space for 
'releases'.   Are you going to surpass that usage anytime soon?  And 
if so, by how much, and how fast?

So 1GB for svn and 2GB for releases is more than 9 times the capacity of github.

I have no problem with svn too.

 

Proposition:

We create a google code repository that would be named :

Chameleon Collaborative Project

 

In the project description, we would include APSL, Chameleon, Voodoo, PCEFI teams and others special thanks note.

 

How about that ?

[Onixs]

Asere

 

The source patch 1.1.2 doesn't include the Memory Fix.

 

Thank You.

[zef]

I would be interested to know if Zef (and any other other Chameleon team representative ) is OK so that one of them could hopefully initiate that

 

Actually we have an svn repo already. We also have a bug tracking and code review frontend for that (http://indefero.net) hosted on our own server, so we shouldn't face with storage and bandwidth limitations any soon. I need to discuss some questions regarding this. Let me get back to You guys

[scrax]

Proposition:

We create a google code repository that would be named :

Chameleon Collaborative Project

 

In the project description, we would include APSL, Chameleon, Voodoo, PCEFI teams and others special thanks note.

 

How about that ?

 

I think this is a very good idea.

I've found some problem with the name chameleon in searches because it's too common, so i'll suggest something like ChameleonX or ChamX86 for the name to make it a good keyword.

 

Or what about CalumMac (Calumma is the latin name of a chameleon's genus )?

[eberts]

Nothing major. Manufacturer, Serial, and Part numbers are not displayed (or detected?). I don't care as long as type and speed are detected.

 

Here's how system profiler looks:

 

Bank2/3/A1:

 

Size: 1 GB

Type: DDR2 SDRAM

Speed: 800 MHz

Status: OK

Manufacturer: N/A

Part Number: N/A

Serial Number: N/A

 

Same here:

Detection is working with first Bank(0) but not with the second one.

 

 

BANK0/DIMM0:

 

Größe: 1 GB

Typ: DDR2 SDRAM

Geschwindigkeit: 666 MHz

Status: OK

Hersteller: Corsair

Teilenummer: VS1GB667D2

Seriennummer: 0x00000000

 

BANK1/DIMM1:

 

Größe: 1 GB

Typ: DDR2 SDRAM

Geschwindigkeit: 666 MHz

Status: OK

Hersteller: N/A

Teilenummer: N/A

Seriennummer: N/A

 

Btw, I remember when I first switch to MacPro in smbios.plist (iMac9,1 before), Memory Slot Utility.app came up saying my memory configuration is wrong. I can't open that application anymore (in /S/L/CoreServices) - it says it doesn't work on this system. I think I changed something else later. Fortunately, I did a screenshot :

 

Currently installed memory module:

Bank A4: 1 GB DIMM Bank B4: -

Bank A1: 1 GB DIMM Bank B1: -

Bank A5: - Bank B5: -

...

 

Recommended configuration:

Bank A4: - Bank B4: -

Bank A1: 1 GB DIMM Bank1: 1 GB DIMM

Bank A5: - Bank B5: -

...

 

Thanks a lot

eberts

[Asere]

Yes I deleted all the information in the smbios.plist.

At boot how can I check the problem ? boot with-v or another, to know ?

 

 

Dump Cpuz:

 

 

Memory SPD

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

 

DIMM #1

 

General

Memory type DDR2

Module format Regular UDIMM

Manufacturer (ID) Kingston (7F98000000000000)

Size 2048 MBytes

Max bandwidth PC2-6400 (400 MHz)

Part number 9905316-173.A00LF

Serial number 82CC994D

Manufacturing date Week 07/Year 09

 

Dump Module #1

0 1 2 3 4 5 6 7 8 9 A B C D E F

00 80 08 08 0E 0A 61 40 00 05 25 40 00 82 08 00 00

10 0C 08 70 01 02 00 03 30 45 3D 50 3C 1E 3C 2D 01

20 17 25 05 12 3C 1E 1E 00 06 3C 7F 80 14 1E 00 00

30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 DD

40 7F 98 00 00 00 00 00 00 04 39 39 30 35 33 31 36

50 2D 31 37 33 2E 41 30 30 4C 46 00 00 00 09 07 82

60 CC 99 4D 00 00 00 00 00 00 00 00 00 00 00 00 00

70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

F0 39 39 30 35 33 31 36 2D 31 37 33 2E 41 30 30 4C

 

I've tried your SPD dump on my machine. It works

 

I had the same problem with trailing 0x20 (spaces). Apple accepts 0x20 in between, but not at the end. Maybe it's due the french localization?

[Master Chief]

Not only don't you need that much space (less than 3MB in source code / many static files) but there's also: http://github.com/plans#footnote-1

 

"[1] The 300MB is a soft limit setup to prevent abuse of the service. If your open source project needs more space, email us, we're happy to provide it."

[Beerkex'd]

Welcome back Master Chief.

 

i'll suggest something like ChameleonX or ChamX86 for the name to make it a good keyword.

 

Or what about CalumMac (Calumma is the latin name of a chameleon's genus )?

 

I think 'Gecko' would be a cool name for a Chameleon derivative.

[zef]

I think 'Gecko' would be a cool name for a Chameleon derivative.

 

I would join the forces into the existing project instead

[Beerkex'd]

That would be kickass.

 

It seems some of the talented gentlemen posting in this thread don't agree with the way things are run at voodooprojects for whatever reason.

 

To me it looks like a misunderstanding, I'm sure if you put your heads together and discuss this over a couple of drinks you could work something out.

[blackosx]

Yes. There could be some exciting developments coming soon

[THe KiNG]

I would join the forces into the existing project instead

Agree.

I have no idea why people spend time on something that is not important(The name) instead focusing on what is important....

[Asere]

Not only don't you need that much space (less than 3MB in source code / many static files) but there's also: http://github.com/plans#footnote-1

 

"[1] The 300MB is a soft limit setup to prevent abuse of the service. If your open source project needs more space, email us, we're happy to provide it."

 

Didn't noticed this little but important footnote

 

I've created a repository at Github. Link is http://github.com/aserebln/Chameleon.

 

Maybe we should discuss some rules of how to write and supply code. I suggest:

 

1.) We should name some maintainers for the repository. Only these maintainers should modify the main branch, always keepig the "big picture" in mind... assuring clean and straight forward code.

 

2.) Other coders should send a patch or open a branch to make their changes. The maintainers then will merge these patches or the branch into the main branch.

 

3.) Always use braces!!! I've seen dozens of bugs due to the laziness or "coolness" of programmers to not put braces. Especially if you are working in a team. These are real examples from Chameleon

		// check for 'PCIR' sig
	if (rom_pci_header->signature == 0x50434952)
			if (rom_pci_header->device != nvda_dev->device_id)
					// Get Model from the OpROM
					model = get_nvidia_model((rom_pci_header->vendor << 16) | rom_pci_header->device);
	else
			printf("incorrect PCI ROM sig: 0x%x\n", rom_pci_header->signature);

 

or this one:

if (*ptr>='a' && *ptr<='f')
   (t=(t<<4)|(*ptr-'a'+10)),kk++;

 

What a big pile of d***. Using the comma operator to avoid putting the braces. Such "masterpieces" does not help to write clean and understandable code. Or should Chameleon be the next winner of the "International Obfuscated C Code Contest".

 

4.) Don't put quick "extern ..." declarations into the code. Use / make a header file with a clean interface.

 

5.) And last but not least we should agree one coding style.

[WinstonAce]

Just tried your latest version (1.1.3)

works great.

I have p55 and it's recognizing my memory speed/part number/manufacturer

and also I don't need any kext's for restart.

The UUID injection is also very good.

Thank you.

[zef]

Didn't noticed this little but important footnote

 

I've created a repository at Github. Link is http://github.com/aserebln/Chameleon.

As one of the founders of Chameleon, I would still use the already existing repo for public use instead. We have all the necessary infrastructure for doing this.

 

Maybe we should discuss some rules of how to write and supply code. I suggest:

 

1.) We should name some maintainers for the repository. Only these maintainers should modify the main branch, always keepig the "big picture" in mind... assuring clean and straight forward code.

Yeah, open it readonly for everyone, read/write to maintiners for the trunk and read/write for own branches. I think we can adjust such privileges with Indefero (via mod_authz_svn).

 

2.) Other coders should send a patch or open a branch to make their changes. The maintainers then will merge these patches or the branch into the main branch.

That's how we did it in the past. Everybody had an own playground (branches/<devname>) in the repo, then merged back the changesets into the trunk. Regarding the externally supplied patches, we also committed many of them.

 

3.) Always use braces!!! I've seen dozens of bugs due to the laziness or "coolness" of programmers to not put braces. Especially if you are working in a team. These are real examples from Chameleon

		// check for 'PCIR' sig
	if (rom_pci_header->signature == 0x50434952)
			if (rom_pci_header->device != nvda_dev->device_id)
					// Get Model from the OpROM
					model = get_nvidia_model((rom_pci_header->vendor << 16) | rom_pci_header->device);
	else
			printf("incorrect PCI ROM sig: 0x%x\n", rom_pci_header->signature);

 

or this one:

if (*ptr>='a' && *ptr<='f')
   (t=(t<<4)|(*ptr-'a'+10)),kk++;

 

What a big pile of d***. Using the comma operator to avoid putting the braces. Such "masterpieces" does not help to write clean and understandable code. Or should Chameleon be the next winner of the "International Obfuscated C Code Contest".

There were discussions about what is the better option: Do something what "w0rkz" vs do it properly and clean.

The above example tells what option was chosen by the author of that part of code. More skilled/experienced developers are very welcome.

Actually this ancient old boot-132 project (many part comes from the late 80's-mid 90's) should be refactored on the long run.

 

4.) Don't put quick "extern ..." declarations into the code. Use / make a header file with a clean interface.

 

5.) And last but not least we should agree one coding style.

Many of these "coolnesses" are the heritage of the original boot-132 codebase but sure, we also added hackish things over time as well.

A strong quality assurance should be a minimum requirement from now on.

[Phoenix Wright]

Hi Asere, your modifications are great!

I only had a small issue with resume from hibernation (deep sleep): it worked with RC4 (with rekursor and Duvel's mods) but your version failed to resume with a black screen. After some tests, I figured out that the problem was the "setVideoMode( VGA_TEXT_MODE, 0 );" line in resume.c. After I deleted that, everything worked fine again.

I have an ATI 4850 video card (using GraphicsEnabler to make it work)