Chameleon with SMBIOS patching

[Azimutz]

Hy.. just want to say that it works fine for me.

Can't wait for new Chameleon

Thanks

[avian]

Mackerintel this is brilliant. Thanks so much for your work here, definitely my favourite solution. I've tested this on 10.5.1, 10.5.2, 10.5.3, 10.5.5, and 10.5.6 vanilla smbios.kext's and it never missed a beat (dont ask). Thanks!

[filosofem]

I have Quad Q6600 processor and SystemProfiler did not showed cpu instructions etc. I founded systemprofilerfix.pkg in XXX_10.5.X installdisc. I installed that and now SystemProfiler shows everything correct cpu name,Instructions etc.

SySProfilerFix.zip

[jeff4760]

I have Quad Q6600 processor and SystemProfiler did not showed cpu instructions etc. I founded systemprofilerfix.pkg in XXX_10.5.X installdisc. I installed that and now SystemProfiler shows everything correct cpu name,Instructions etc.

 

 

You are the {censored}! That fixed it! This and along with the About the Mac fix from eddie11c has everything listed perfectly for my CPU.

 

Thank you so much for finding and posting that. I havent looked at the XXX disc so I would have never found it.

[tuxianer]

Hi,

geekbensh says:

Motherboard: Gigabyte Technology Co., Ltd. EP35-DS3

BIOS: Award Software International, Inc. MP11.88Z.005D.B00.0709141354

 

how can I change this?

[MacUser2525]

Hi,

geekbensh says:

Motherboard: Gigabyte Technology Co., Ltd. EP35-DS3

BIOS: Award Software International, Inc. MP11.88Z.005D.B00.0709141354

 

how can I change this?

 

You install the chameleonsm as your new /boot file then make sure you have no other SMBIOS EFI enablers running and put the proper settings in your com.apple.Boot.plist reboot and the new settings should be used. Since your sig says q6600 for processor using my file as a templte for your new one could be helpful you want to change the bus/cpu/ram speeds to match what your running at and remove the timeout/kernel flags -v if you do not want to wait 5 seconds for a verbose (text) boot.

 

 cat /Library/Preferences/SystemConfiguration/com.apple.Boot.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
<string>-v</string>
<key>Timeout</key>
<string>5</string>
<key>SMbiosversion</key>
<string>MP31.88Z.00C1.B00.080209154</string>
<key>SMmanufacter</key>
<string>Apple Inc.</string>
<key>SMproductname</key>
<string>MacPro3,1</string>
<key>SMexternalclock</key>
<string>375</string>
<key>SMmaximalclock</key>
<string>3150</string>
<key>SMmemmanufacter</key>
<string>Kingston</string>
<key>SMmempart</key>
<string>0x0000FFFF</string>
<key>SMmemserial</key>
<string>0x48092D503537345336304350362D09352020</string>
<key>SMmemspeed</key>
<string>700</string>
<key>SMmemtype</key>
<string>19</string>
<key>SMsystemversion</key>
<string>1.0</string>
<key>SMserial</key>
<string>W88261E7YP4</string>
</dict>

[tuxianer]

yes i have done this already. But the Motherboardname and the BIOS Company is not overwritten.

[Kaydis]

We've just integrated SMBIOS patching (including SMboardmanufacter, SMboardproduct and SMUUID) and basic SM autodetecting into upcoming Chameleon. On my system I no longer need to specify SMBIOS values manualy. DSDT patch is already integrated onloy difference is that default location of DSDT.aml is /Extra/DSDT.aml. Wait for the next release.

@pharillion: Any luck with Applenvramefi?

I take it that it is not in PC_EFI v9 then?

[Beerkex'd]

yes i have done this already. But the Motherboardname and the BIOS Company is not overwritten.

 

You must use SMboardmanufacter and SMboardproduct.

But I don't think those are available in the version that Mackerintel has uploaded. I'm just about to reboot and find out.

 

/edit

 

No, ioreg -l |grep board-id still says I have a P5Q-E...can't blame it.

 

If you want to change board-id you'll have to use another SMBIOS solution for now.

 

I recommend Chun-Nan's AppleSMBIOSEFI.

You can set the board-id with that but you have to edit the source code and compile it yourself. It's really easy, there are instructions in the original thread. You need to have Apple XCode installed.

 

Or we can try begging Mackerintel to release a new ChameleonSM with the board strings added...

[artofware]

Guys, help me out here. I'm not seeing any strings under the boot.plist file? Any help.? thanks

[Beerkex'd]

You're supposed to put the strings and keys there yourself!

 

Use a tool called EFI Studio (google it) to conveniently edit the com.apple.boot.plist.

 

There's nothing there either because the bootloader is incorrectly installed, you have no strings in boot.plist or there is a conflict because you left an SMBIOS Injector in your extensions folder. It should show something there or at least crash..

 

Go to the Chameleon website, download the Chameleon 1.0.11 installer and install it on your system.

 

Then replace the file 'boot' (maybe a hidden file, I don't remember. If you use the finder to replace it you have to unhide it first) at the root of your system file with the file ChameleonSM from the archive in the first post. It must be named 'boot'.

 

Make sure you have an original, unpatched AppleSMBIOS.kext taken from the same version of Leopard as you are running, and none of the usual SMBIOS injectors in your extensions folder already, such as AppleSMBIOSEFI.kext etc etc.

 

Always delete the kext caches before you replace or remove something in the extensions folder.

[Beerkex'd]

Great news;

 

SMboardmanufacter and SMboardproduct are implemented in Chameleon 2.0.

 

ioreg -l |grep board-id

"board-id" = <"Mac-F2218EC8">

 

Tested working. My P4 Hackintosh is an iMac9,1 for now.

[Arial]

I just knew how powerful Chameleon2. http://www.insanelymac.com/forum/index.php...t&p=1156867

AMAZING! This is the first time my OSx86 identify proper Mac Model using Vanilla Kernel.

 

 

 

 

with original AppleSMBIOS.kext and modded smbios.plist:

- Proper Hardware Overview on System Profiler

- Mac Model Identifier (iMac, MBP, MBA,…)

- Safe update to current latest OSX 10.5.7

 

~2.22 MB

http://rapidshare.com/files/237815997/Chameleon2_SMBIOS_man_rev2.dmg
http://www.mediafire.com/?zydjnzr3mgg

- Manual rev.1 (pdf) and some pics.

- Chameleon-2.0-r431-core.pkg

- smbios.plist some Mac Idenftifier

- SysProfiler_Fix_rev1.mpkg

- AboutThisMac_Fix.pkg

- Original AppleSMBIOS.kext for 10.5.6 & 10.5.7

 

VoodooLabs, you all are genius people! many many thanks for your excelent work and generosity.

[Jingu]

I have an Acer Aspire 9525 Intel Core 2 Duo 2Gghz 667MHz FSB

 

I have successfully upgraded to retail 10.5.7 with Chameleon 2.0, smbios.plist and com.apple.Boot.plist in /Extra.

 

I have set my machine ID to MacBookPro 2,1

 

Everything is vanilla and no kext in S/L/E has been removed.

 

But, when I follow exactly the Chameleon SMBIOS patching instructions, I get for System Profiler: "there was an error while gathering this information", even when I use the System Profiler fix from the previous post.

 

Curiously, when I put back AppleSMBIOSEFI in /Extra/Extensions/, Everything shows up correctly in System Profiler:

 

Hardware Overview:

 

Model Name: MacBook Pro 17"

Model Identifier: MacBookPro2,1

Processor Name: Intel Core 2 Duo

Processor Speed: 2 GHz

Number Of Processors: 1

Total Number Of Cores: 2

L2 Cache: 4 MB

Memory: 4 GB

Bus Speed: 667 MHz

Boot ROM Version: MBP21.00A5.B08

 

For some weird reason in my case, I need to use BOTH the smbios.plist and the AppleSMBIOSEFI for everything to show up correctly. Even XBench sees my machine as MacBookPro2,1

 

EDIT: Now everything shows up perfectly in System Profiler without the AppleSMBIOSEFI. The com.apple.Boot.plist in /Extra was the original unedited. I simply added these lines in that Boot.plist:

 

<key>SMbiosversion</key>

<string>MBP21.88Z.00A5.B08.0802291403</string>

<key>SMmanufacter</key>

<string>Apple Inc.</string>

<key>SMproductname</key>

<string>MacBookPro2,1</string>

<key>SMsystemversion</key>

<string>1.0</string>

<key>SMserial</key>

<string>W123456W0M</string>

 

Added bonus is that now all the memory info I manually entered shows up.

 

Memory Slots:

 

ECC: Disabled

 

Bank 0/M1:

 

Size: 2 GB

Type: DDR2 SDRAM

Speed: 667 MHz

Status: OK

Manufacturer: Micron Technology

Part Number: 16HTF25664HY-667G1

Serial Number: DF284798

 

Bank 1/M2:

 

Size: 2 GB

Type: DDR2 SDRAM

Speed: 667 MHz

Status: OK

Manufacturer: Micron Technology

Part Number: 16HTF25664HY-667G1

Serial Number: DF284785

[Beerkex'd]

I just knew how powerful Chameleon2.

 

Just FYI, the smbios-table data you are using is not parsed by Chameleon 2.0.

[Master Chief]

- SysProfiler_Fix_rev1.mpkg

I installed this package (not Chameleon v2/I am using ChameleonSM) on my 10.5.7 hack, but I keep getting this error: "There was an error while gathering this information" with the vanilla AppleSMBIOS.kext (the EFI variant has been removed). Even after checking permissions with Disk Utility (and boot cache rebuild). Is that because of the installed Intel Q9300 CPU, which is never used by Apple?

 

Also, do I really need to insert every single key/string combo in com.apple.Boot.plist or just the ones I need to change?

 

Memory overview is fine. Well almost because I don't like this:

Part Number: PartNum1

Serial Number: SerNum1

 

Which could as well have been blanked out. No?

 

EDIT: It works now – I just had to add a few more key/string combinations.

 

p.s. This thread is still about ChameleonSM, and not Chameleon v2, right?

[Beerkex'd]

p.s. This thread is still about ChameleonSM, and not Chameleon v2, right?

 

It seems to have naturally evolved into being about Chameleon 2.0.

 

The syntax for the two is the same, but Chameleon 2.0 RC 1 can inject more stuff, like motherboard ID and manufacturer for example.

[Master Chief]

It seems to have naturally evolved into being about Chameleon 2.0.

 

The syntax for the two is the same, but Chameleon 2.0 RC 1 can inject more stuff, like motherboard ID and manufacturer for example.

Yeah, so I noticed. That is why I want the source code. And the complete source, not just a diff.

 

I don't want to be rude, but I have no need for a fat boot loader with stuff I don't need. What I do is to use dedicated harddrives for Ubuntu Linux, and I don't even have a Windows installation on any of my partitions – I am a happy camper using Parallels Desktop for it. So tell me something; why would people like me want it? To slow down our boot process? I tell you this: opening more files will slow down the boot process.

 

Adding injectors? No thanks. I don't want them anywhere on my hard drives. At least not for stuff that can be done in a better way... like DSDT/EFI patching.

 

Don't get me wrong: Chameleon V2 is great, for certain people (probably ex-Windows users) but I fell off that boat a long time ago – I started to use (SCO) Unix back in 1987 (yeah, I am that old already) and switched to Ubuntu Linux since its first Beta (mainly because I know Mark) and my children love it ever since. In fact the only Windows versions I used were Windows NT 4.0 and Windows XP for work. I also used OS/2 for a while, but we all know what happened with it...

[Kabyl]

Yeah, so I noticed. That is why I want the source code. And the complete source, not just a diff.

You know that applying the patch/diff gets you the complete source?

 

Adding injectors? No thanks. I don't want them anywhere on my hard drives. At least not for stuff that can be done in a better way... like DSDT/EFI patching.

Many people now think that "injecting" data by editing the DSDT or using the so called EFI-strings is a better way, just because someone claimed so. Can you tell me why is that better than doing it in a kext or in the booter? I mean really, you're using kexts for other things anyway, you have them in your HDD, even on real Macs you install drivers (kexts) which go into their real intended path (/System/Library/Extensions/).

 

IMO, people should look for and promote the use of better, automated and universal solutions either in kexts or in the booter (if that is possible), instead of "hacking" around with DSDTs (SSDTs.. etc), I'm not talking about fixing bugs in the ACPI tables, fixing bugs wherever found is something needed and wanted, no doubt.

 

Using a given tool for/in something that is not intended to be used for/in is called a "hack", and that will never be the best way to solve problems.

[Master Chief]

You know that applying the patch/diff gets you the complete source?

I know diff and patch, me being OSS (Mozilla Application Developer) but it all depends on the source file to start with. Not to mention that people here keep assuming that everyone uses the same source code, which I can assure you is simply not the case. Not to mention that this way of doing things isn't covered by the license.

 

Many people now think that "injecting" data by editing the DSDT or using the so called EFI-strings is a better way, just because someone claimed so.

To each his own of course, but patching via DSDT/EFI is in my view a much cleaner way.

 

Can you tell me why is that better than doing it in a kext or in the booter? I mean really, you're using kexts for other things anyway, you have them in your HDD, even on real Macs you install drivers (kexts) which go into their real intended path (/System/Library/Extensions/).

First, opening more files at boot time will slow down the boot process. Secondly, I no longer need to think about replaced/lost/overwritten kext files with the next upgrade. Third, all modification can be done in one single spot, be it with help of DSDT and/or EFI patching. Fourth, why would I use a graphics interface, or a rather fat boot loader, when I don't have any use for it?

 

How many of you need to copy kext files out of /S*/L*/E* to /Extra (or whatever you use) to get audio going?

 

IMO, people should look for and promote the use of better, automated and universal solutions either in kexts or in the booter (if that is possible), instead of "hacking" around with DSDTs (SSDTs.. etc)...

But is that because it fits Chameleon V2 better, or because it can really do better? I fail to see why to be honest.

 

To me Chameleon is just a boot loader, and IMHO should stay that way. The only reason to swap boot loaders for me would be a more EFI based one, or a Chameleon based one without the reboot/shutdown bugs.

 

Note: I am fully aware of the fact that my use might be different, but I will get what I want either way sooner or later. With or without help from this community, simply because it fits me better.

[Kabyl]

Not to mention that this way of doing things isn't covered by the license.

Not sure I understand what you mean by that, but I believe there are levels of "openness" in projects, projects where anyone can have read access to the source repository, is definitely more open than Apple's way of doing things, but that doesn't go against their license, and neither does Chameleon.

 

To each his own of course, but patching via DSDT/EFI is in my view a much cleaner way.

Very true, and for people to agree they need a common reference.

 

First, opening more files at boot time will slow down the boot process.

If you use "many" files, and if a file is relatively big, there are also other things that should be considered here like the BIOS (drivers) HDD, the code in the booter.. etc

 

You can have your kexts packed in an mkext, which solves the "more files" thing.

 

Secondly, I no longer need to think about replaced/lost/overwritten kext files with the next upgrade.

That's why methods like munky's are used, but again that is caused by the way things were done in the past, you should never replace stock kexts when that is possible, and it usually is possible only in cases like with few Family kexts.

 

Also, Apple isn't perfect, they have bugs too, sometimes serious ones, in which case you need to replace the stock files.

 

Third, all modification can be done in one single spot, be it with help of DSDT and/or EFI patching.

And you have to deal with the drawbacks of go that way, like not having your DSDT updated (the BIOS does some patching when things in the HW or settings in the Setup change) and it usually needs a lot of testing before you get a good working DSDT this is hard for the average user (but probably not you ).

 

EFI patching... I'm sure you mean EFI-strings which is also another bad naming, I prefer calling it device-properties (plist) like Apple does, well in this case the things you can do are still limited.

 

In both methods you're editing files and modifying it to for your own system, software should be multi-platform and automated as much as possible.

 

Fourth, why would I use a graphics interface, or a rather fat boot loader, when I don't have any use for it?

You don't. Others do because they "Think Different™".

 

How many of you need to copy kext files out of /S*/L*/E* to /Extra (or whatever you use) to get audio going?

Not me, I always recommend against it. Unfortunately, many consider /S/L/E to be a sacred place.

 

But is that because it fits Chameleon V2 better, or because it can really do better? I fail to see why to be honest.

How would it fit Chameleon better?? What would be the benefit if that is the case, in your opinion?

 

Things can always be done better, that's how software is and will always be. Products die when a better one is released, and this isn't tied to software.

 

To me Chameleon is just a boot loader, and IMHO should stay that way. The only reason to swap boot loaders for me would be a more EFI based one, or a Chameleon based one without the reboot/shutdown bugs.

Once the OS is loaded, there is a lot involved in the reboot/shutdown process, and solving that isn't the job of the booter (if it even can be done there).

 

I understand that people update or change software when that fixes bugs for them or provides features they need, what would an "EFI based" booter provide for you?

 

Note: I am fully aware of the fact that my use might be different, but I will get what I want either way sooner or later. With or without help from this community, simply because it fits me better.

Sure, if you know your stuff, you don't need the help of others, but you can't do everything alone.

[Master Chief]

Not sure I understand what you mean by that, but I believe there are levels of "openness" in projects, projects where anyone can have read access to the source repository, is definitely more open than Apple's way of doing things, but that doesn't go against their license, and neither does Chameleon.

Please, don't forget that you talk to a real OSS expert here, someone with many years on his resume so trust me; the Chameleon project is violating the Apple license (just read the license) and once you tag it with that license, there is no way back.

 

EFI patching... I'm sure you mean EFI-strings which is also another bad naming, I prefer calling it device-properties (plist) like Apple does, well in this case the things you can do are still limited.

Correct.

 

In both methods you're editing files and modifying it to for your own system, software should be multi-platform and automated as much as possible.

Oh but don't get me wrong, that would be nice. Of course, but it should be a separate project. Not included with the booter.

 

You don't. Others do because they "Think Different™".

Yes I do, and that is why you use certain features in your browser that were introduced by me, simply because I think different

 

How would it fit Chameleon better?? What would be the benefit if that is the case, in your opinion?

Again, I just don't think that a booter fits this part of the project. But feel free to convince me otherwise.

 

Things can always be done better, that's how software is and will always be. Products die when a better one is released, and this isn't tied to software.

But of course, but with a real Open Source project you can take over, fix things yourself, but that won't work when people hold back with source code, basically violating the Apple license.

 

Once the OS is loaded, there is a lot involved in the reboot/shutdown process, and solving that isn't the job of the booter (if it even can be done there).

A single leak can prevent shutdown and/or restart from working, and ChameleonSM isn't clean so guess what. I got to freaking fix it simply because I cannot shutdown when I use it.

 

I understand that people update or change software when that fixes bugs for them or provides features they need, what would an "EFI based" booter provide for you?

Answer this: "Why do people need Chameleon?" and "What problems do they face when they use it?" and you know what I mean. Or not of course

 

Note: I left the obvious remarks unanswered – I have more work to do.

[iPhoneTom]

Please, don't forget that you talk to a real OSS expert here

 

LOL, yeah, as like your an main developer on UEFI project? And as an OSS expert you need to upset ppl by PM trying to force them to stop development?

 

Nice try, better luck next time.

[Kabyl]

Please, don't forget that you talk to a real OSS expert here,

Great!

 

someone with many years on his resume so trust me;

I've learned not to trust but proofs and my own experience and research, in our case it's a very simple subject (I guess)

 

the Chameleon project is violating the Apple license (just read the license) and once you tag it with that license, there is no way back.

We would be glad to be proven wrong, and we'll fix our mistakes. And so, we are either blind or we didn't understand the license, maybe you can point out the exact thing that Chameleon is violating by quoting from the APSL?

 

Oh but don't get me wrong, that would be nice. Of course, but it should be a separate project. Not included with the booter.

Which leaves a second option (or maybe the first); in KEXTs. But also don't get me wrong here, my main motivation here is to highlight that things are done not in their intended and best place; the DSDT is very specific to the HW, and the way people are modifying it is hard-coding values and adding methods they don't even know what they are for, sometimes unnecessary, and that is still nothing close to a real solution and is far from being automated.

 

I've done this, and I'm probably the first person who did it for OSX and release the fixes, but I knew it could be done better,and I did find better automated ways which save me time and effort, obviously, I'm using them.

 

I want to note that we work on complete solutions, the booter is just a part (an important one).

 

Yes I do, and that is why you use certain features in your browser that were introduced by me, simply because I think different

I'm a FireFox user because I have use for it, thanks for your work :pirate2:

 

Again, I just don't think that a booter fits this part of the project. But feel free to convince me otherwise.

The solutions you talked about are not user-friendly, not automated, limited, and have serious issues in the case of the DSDT (both the DSDT modifications and the device-properties need support in the booter).

 

An EFI-based booter (calling it DUET-based is probably more accurate) is "fat" and people have use for just like they do have use for "the fat" Chameleon. The EFI environment is almost a tiny OS, and I'm very fine with that.

 

But of course, but with a real Open Source project you can take over, fix things yourself, but that won't work when people hold back with source code, basically violating the Apple license.

I'm not an Open Source purist, I think it doesn't work for all projects; there are closed projects/apps that are more succeful then their Open Source alternatives. And closed worked and still works for many; M$ , Apple, Games.. etc.

 

But again, I prefer OSS for the reasons you mentioned.

 

Note that we have released the sources for previous versions of Chameleon, and we talked about v2 in our site if anyone wants to check.

 

A single leak can prevent shutdown and/or restart from working, and ChameleonSM isn't clean so guess what. I got to freaking fix it simply because I cannot shutdown when I use it.

Isn't that the case of every (Open Source/) software?

 

The reboot/shutdown issues are in most cases OS issues; in your case it's not because of issues in ChameleonSM (why would an OS depend on SMBIOS data for reboot/shutdown?) but because of the assumptions OS X makes and the way Apple made it. Mac OS X is written for Macs, for that specific HW.

 

Answer this: "Why do people need Chameleon?"

Obvious reasons?

 

and "What problems do they face when they use it?"

We have bug reports and we try to fix them, it's just about time, will and motivation.

 

and you know what I mean. Or not of course

I'm going to guess the DUET-based booter doesn't have the issues Chameleon have? That doesn't mean DUET doesn't have issues, and it doesn't mean issues can't be fixed (for both).

 

The only DUET-based booter known till now (at least for me) is iPhoneTom's (we both discuess about (U)EFI/edk(2) stuff) XPC, and that is closed source (so far).

 

Note: I left the obvious remarks unanswered – I have more work to do.

Good luck with your work

[incabulos]

I'm not an Open Source purist, I think it doesn't work for all projects; there are closed projects/apps that are more succeful then their Open Source alternatives. And closed worked and still works for many; M$ , Apple, Games.. etc.

 

But again, I prefer OSS for the reasons you mentioned.

 

Note that we have released the sources for previous versions of Chameleon, and we talked about v2 in our site if anyone wants to check.

 

The reboot/shutdown issues are in most cases OS issues; in your case it's not because of issues in ChameleonSM (why would an OS depend on SMBIOS data for reboot/shutdown?) but because of the assumptions OS X makes and the way Apple made it. Mac OS X is written for Macs, for that specific HW.

 

 

We have bug reports and we try to fix them, it's just about time, will and motivation.

I would just like to second Master Chief's sentiments on the OSS purity of Chameleon. Chameleon has built enough momentum to maintain an open access source repository with public todo lists and whatever without diluting their mission or user base. In a sense, as part of the community that generally benefits from Chameleon, I'd like the opportunity to give back in terms of relevant code and not have to worry about duplicating progress or making irrelevant patches. Allow us to help you guys shoulder the burden as you get piled under bug reports, as your time invariably gets sucked away in other aspects of life.

 

Cheers!