Chameleon > Bug Reports
SMcputype (and others) not working with SMBIOSdefaults=n on RC5
konsti:
Hello to the development team of Chameleon. I post here a new topic after being encouraged by dear Azimutz on an issue/bug we've been discussing for some time.
I think I have detected a bug with the latest builds of Chameleon RC5 (that I am getting compiled and ready from Azimutz's public folder), otherwise I am not injecting a proper value... Can you guys please check and help?
The story: I decided I want to create a full, official and complete smbios.plist for my machine so that I don't need SMBIOSdefaults=Yes. My mobo is a barebone PC with ICH7 and Q9550 declared as MacPro3,1.
However, I cannot pass in any way the CPU value for either SMbustype or SMcputype resulting to getting "unknown CPU" in About this Mac. And I see this, too, as missing in IORegistryExplorer: no cpu-type value!
Please, remember that SMcputype worked fine with older builds of Chameleon. SMbustype was introduced by Asere for his loader, also solving my CPU identification issue.
With default SMBIOS values set with RC5 v517+, I get "2.84 GHz Quad-Core Intel Xeon" for my Q9550 Core2 Quad CPU. And inside IORegistryExplorer, I also see with proper bus-frequency and clock-frequency values, the value cpu-type <01 05>. So far, so good.
But when I inject my own smbios.plist (see below) I cannot get that CPU type detected, at all, and the field CPU-type is totally missing from IORegistry.
I tried mixed SMcputype>1281 (used to work OK) no result. I tried SMbustype>0105 or SMcputype>0105 etc. Nothing. Decimal 1281 is equivalent to 0x0501...
So, allow me to recap:
Can you please please tell me what value is injected with SMBIOS defaults? It drives me mad!
Then, can you please check if it's a major bug and, when smbios.plist is present in /Extra/ without defaults enabled, there is indeed no CPU type passed to the system?!? I have reasons to believe it's NOT passed at all !
I will appreciate your time on this... perhaps it is a bug. Value 1281 used to work for the Xeon type; not with new RC's of Chameleon, anymore :(
Many thanks in advance.
Best regards and thanks to the team for your excellent work!
Konsti
--- Code: ---<dict>
<key>SMbiosdate</key>
<string>02/09/08</string>
<key>SMbiosvendor</key>
<string>Apple Computer, Inc.</string>
<key>SMbiosversion</key>
<string>MP31.88Z.00C1.B00.0802091544</string>
<key>SMboardmanufacturer</key>
<string>Apple Computer, Inc.</string>
<key>SMboardproduct</key>
<string>Mac-F4208DC8</string>
<key>SMbusspeed</key>
<string>1333</string>
<key>SMbustype</key>
<string>0105</string>
<key>SMcputype</key>
<string>1281</string>
<key>SMexternalclock</key>
<string>333</string>
<key>SMfamily</key>
<string>MacPro</string>
<key>SMmanufacter</key>
<string>Apple Computer, Inc.</string>
<key>SMmaximalclock</key>
<string>2830</string>
<key>SMmembankloc_1</key>
<string>BANK 0</string>
<key>SMmembankloc_2</key>
<string>BANK 1</string>
<key>SMmembankloc_3</key>
<string>BANK 2</string>
<key>SMmembankloc_4</key>
<string>BANK 3</string>
<key>SMmemdevloc_1</key>
<string>DIMM 1</string>
<key>SMmemdevloc_2</key>
<string>DIMM 2</string>
<key>SMmemdevloc_3</key>
<string>DIMM 3</string>
<key>SMmemdevloc_4</key>
<string>DIMM 4</string>
<key>SMmemmanufacter_1</key>
<string>OCZ Inc.</string>
<key>SMmemmanufacter_3</key>
<string>OCZ Inc.</string>
<key>SMmempart_1</key>
<string>OCZ2B800C52G</string>
<key>SMmempart_3</key>
<string>OCZ2B800C52G</string>
<key>SMmemserial_1</key>
<string>0x0000000000102001</string>
<key>SMmemserial_3</key>
<string>0x0000000000102002</string>
<key>SMmemspeed</key>
<string>800</string>
<key>SMmemtype</key>
<string>19</string>
<key>SMproductname</key>
<string>MacPro3,1</string>
<key>SMserial</key>
<string>G8829257XYL</string>
<key>SMsystemversion</key>
<string>1.0</string>
</dict>
--- End code ---
konsti:
Hello again to everyone who's read the thread; I am very impressed with the fact that no-one confirmed the bug, yet... Possibly the developers never read this thread, but on my hackintosh it happens, unfortunately, with latest r651 build too.
Just to rule out another option, I tried SMBIOS.plist and smbios.plist as filenames (case sensitive) and it doesn't work. The CPU parameter SMcputype doesn't get forwarded to the system with SMBIOSdefaults=No...
I hope this time someone can confirm it--at least, someone who has access to the code! (as I cannot build it myself, unfortunately. Lack of Xcode knowledge!)
Cheers 8)
Gringo Vermelho:
Doesn't work for me either on my old P4 hack, I have to use Chameleon 2.0 RC3.
Azimutz:
Well, i'm tired of playing with this all night... time to rest some.
Just came around to tell you guys, specially to mister Konsti, that SMcputype does work with SMBIOSdefaults enabled like i explained at first. There's is no need to disable defaults to override default values;
any value set on smbios.plist always overrides a default value!
This
--- Code: --- <key>SMcputype</key>
<string>1281</string>
--- End code ---
sets "Dual-Core Intel Xeon" instead of the default "Intel Core 2 Duo",
and
--- Code: --- <key>SMcputype</key>
<string>513</string>
--- End code ---
a "Intel Core Duo", based on the number of cores of the Pentium D.
If i try 257, "Core 2 Solo", i get Unknown (as expected) but the value is still set and correct on IOreg.
Konsti, go practice ;D i'll be back later with more info, if needed be...
Gringo Vermelho:
Hmm
Time to dust off the old P4 and install Chameleon 2.0 RC5 on it.
I bought a cheap wireless USB keyboard/mouse for it...but the keyboard is not detected by the BIOS during startup so whenever I want to boot into the OS X installation or set something in the BIOS i have to plug in another keyboard. Cheap!!
I'll try some things later.
Ah, I remember now - the Voodoo kernel sets Core Solo or Core 2 Solo (?) automatically for the P4 CPU. But Chameleon broke that somewhere along the line and I don't think there's a switch to turn this auto-CPU setting thing off for the Voodoo Kernel.
Navigation
[0] Message Index
[#] Next page
Go to full version