Gringo,
At this point I can't say if it's Chameleon or the Voodoo Kernel that's responsible for the correct CPU override, but it works.
It's the booter, checked here on Snow & Leo, it always overrides the kernel setting; i found a diff... the booter injects the cpu model into IOreg e.g. /AppleACPIPlatformExpert/CPU0@0/cpu-type, while the kernel doesn't seem to store this info there.
We really should stop doing this on the kernel, but that's another story...
About the "MemDetect" stuff, does it show with Asere's booter?
Just out of curiosity, is that Pentium 4 64 bit?
Now to clear the doubts about this SMcputype thing...
Mr Konsti
first we need to change the topic to something like "SMcputype not working with SMBIOSdefaults=n on RC5 r653"... can you do that?
The key is indeed failing in this situation and ONLY in this situation. And i think it's the only key that fails.. didn't tested all but from the example below, the only failing is SMcputype:
<?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>SMbiosdate</key>
<string>04/01/2008</string>
<key>SMbiosversion</key>
<string>MP21.88Z.005C.B01.0608221120</string>
<key>SMfamily</key>
<string>Mac Pro</string>
<key>SMmanufacter</key>
<string>Apple Inc.</string>
<key>SMmemmanufacter_1</key>
<string>Kingston</string>
<key>SMmemmanufacter_2</key>
<string>Qimonda</string>
<key>SMmemmanufacter_3</key>
<string>Kingston</string>
<key>SMmemmanufacter_4</key>
<string>Qimonda</string>
<key>SMmempart_1</key>
<string>9905429-002.A00LF</string>
<key>SMmempart_2</key>
<string>64T64000HU3SB</string>
<key>SMmempart_3</key>
<string>9905429-002.A00LF</string>
<key>SMmempart_4</key>
<string>64T64000HU3SB</string>
<key>SMmemserial_1</key>
<string>80CCC94D</string>
<key>SMmemserial_2</key>
<string>0416AB24</string>
<key>SMmemserial_3</key>
<string>ACCCBF51</string>
<key>SMmemserial_4</key>
<string>0416AC26</string>
<key>SMproductname</key>
<string>MacPro2,1</string>
<key>SMserial</key>
<string>CZX702KPJ</string>
<key>SMsystemversion</key>
<string>1.0</string>
<key>SMcputype</key>
<string>1281</string>
<key>SMmaximalclock</key>
<string>3000</string>
<key>SMserial</key>
<string>RM629559W87</string>
</dict>
</plist>
Besides this detail, all works as usual when it comes to
smbios patching; explaining:
EDIT: some restructure due to
monumental lapse of reason
- the booter ALWAYS looks for a smbios.plist and that can't be disabled.
- SMBIOSdefaults, are the default values stored on the booter's code, "injected" using the keys
present on
this bit of code, the same keys we can use on smbios.plist. They are used when all else fails.
As far as i understand, SMBIOSdefaults=n "is" used to disable the USE of these default values, only.
- if a smbios.plist is found, the values in it are ALWAYS used, OVERRIDING the default ones,
either with SMBIOSdefaults enabled or not. Same applies to values typed at boot prompt.
- based on the above, the only way to "disable" any smbios patching is by using SMBIOSdefaults=n
and remove any smbios.plist out of Chameleon's way
This one "SMbustype" i can't find anywere! Not even on Asere's code! Don't know were you got that, Konsti??
SMcputype and SMbusspeed were the last keys added on RC4.
So, if you leave that SMBIOSdefaults=n "thing" alone, the default values should be ok for both your Q9550 and Atom (i have that one confirmed too!). If you want to tweak something just add a smbios.plist with only what you need to change; if you want to throw in a ton of stuff, that's up to you... it will work the same.