Chameleon > Bug Reports
SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Azimutz:
Gringo,
--- Quote ---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.
--- End quote ---
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:
--- Code: ---<?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>
--- End code ---
Besides this detail, all works as usual when it comes to smbios patching; explaining:
EDIT: some restructure due to monumental lapse of reason :P
- 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.
Gringo Vermelho:
Excellent, thanks for the detailed explanation.
--- Quote from: Azimutz on December 08, 2010, 09:11:26 AM ---About the "MemDetect" stuff, does it show with Asere's booter? Just out of curiosity, is that Pentium 4 64 bit?
--- End quote ---
Yes it's a late model 651 with EM64T. There's a message about 64-bit being enabled at the beginning of the boot process. IIRC you could use chess.app to see if 64-bit addressing was working? I'll check later, the P4 is occupied running Windows 7 during the day.
I think I know why you're asking, the Core Solo didn't have EM64T right? I wonder if that could cause problems.
Memory detection didn't fully work with Asere's booter either. Speed and type was correctly detected but the rest was missing, like with RC5. It would be cool if it was working but I can understand if nobody wants to put in the work to support something as old as i865/ICH5.
--- Quote from: Azimutz on December 08, 2010, 09:11:26 AM ---This one "SMbustype" i can't find anywere! Not even on Asere's code! Don't know were you got that, Konsti??
--- End quote ---
Yeah that's a weird one...I just remembered something from a while back..Look:
http://www.insanelymac.com/forum/index.php?showtopic=201833&st=40&start=40
konsti:
First of all, guys, thanks for taking time to respond and especially Azimutz who is so patient with me :lol:
I tried to read your last big post 3 times to get what you write. So to clear this out:
The loader detects stuff (CPU, RAM etc.) and sets these as default values, right?
With SMBIOSdefaults=Yes setting, these detected values are passed to the system, correct?
Basically, no need for smbios.plist file for "normal" operation!
Additionally, if the loader finds smbios.plist file, it also uses these values (e.g. SMproductname or SMserialnumber etc.) yes?
So, with the above true, my Q9550/ICH7 the CPU is properly detected/set as Xeon Quadcore, and memories as OCZ 802 MHz :)
Question: if in smbios.plist I have conflicting values, say RAM type or RAM speed, which one prevails with SMBIOSdefaults=Yes? The loader's, right?
Now then, with SMBIOSdefaults=No you say that the detected/default values of loader are obviously not used, and instead the loader seeks to find smbios.plist file to apply those "custom" values, right? (unless the motherboard/BIOS are so Mac friendly, I guess)
In this case, my Q9550 CPU is "unknown" (although set in SMcputype) but all other values are detected/injected from smbios.plist.
--- Quote ---if a smbios.plist is found, the values in it are used, overriding the default ones, either with SMBIOSdefaults enabled or not.
--- End quote ---
Well that's not entirely true; CPU doesn't work for sure (i.e. SMcputype value). That's what I am trying to say... JUST this darn value :lol no:
Just discovered: with SMbusspeed=1333 funnily enought, I get in 10.6.5 System Profiler (with R651):
SMBIOSdefaults=No - Bus Speed: 1,33GHz (SMbusspeed set)
SMBIOSdefaults=Yes - Processor Interconnect Speed: 1.33 GT/s (SMbusspeed set)
SMBIOSdefaults=Yes - Bus Speed: 1,33GHz (SMbusspeed NOT set)
Try it too! Put the proper value in SMbusspeed and you will see! I tried with and without it!
Finally: Please just ignore my request/comment about SMbustype, I probably got it from somewhere else wrong and I apologize for the confusion...
Azimutz:
Hi Konsti... that explanation was all messed up. I'm redoing it atm so, feel free to edit your previous post if you feel like so.
I will not comment the post until i read fresh writing or editing from you :)
Sorry for the inconvenience.
p.s.: and thanks for taking care of the topic :)
Edit: done.. i think...
Please note that, this explanation is mostly based on experience and tests. I didn't got deep into the code so,
there is the possibility that i'm still missing something and thus, saying some bs :P
konsti:
Dear Azimutz thanks for your edit and making things a little more clear. Let's put it all in perspective.
1. SMbustype: yes, it was referenced around the web; our dear Gringo Vermelho even makes a mention in his thread! How about that ;)
But according to your posted link on the actual used smbios.plist keys, indeed, SMbustype doesn't exist. Wonder who invented it...
--- Quote ---- 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.
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.
--- End quote ---
2. My findings with your latest R651 build, using the same untouched smbios.plist:
SMBIOSdefaults=Yes recognizes my CPU as Xeon QuadCore (present in IORegistryExplorer, too)
Values from valid smbios.plist are also properly injected (e.g. SMserialnumber etc.). It appears that the bootloader injects SMcputype into the system.
SMBIOSdefaults=No has no CPU detected (as 'Unknown') and no reference in IORegistryExplorer either.
Again, all other values in my valid smbios.plist are injected properly; what's missing is SMcputype injection.
3. In my smbios.plist I have the value SMbusspeed=1333 but in 10.6.5 System Profiler, I get:
SMBIOSdefaults=No - Bus Speed: 1,33GHz (SMbusspeed=1333)
SMBIOSdefaults=Yes - Processor Interconnect Speed: 1.33 GT/s (SMbusspeed=1333)
SMBIOSdefaults=Yes - Bus Speed: 1,33GHz (SMbusspeed removed completely from smbios.plist)
I know #3 is slightly off-topic, but I wanted to share my finding with you...
So, to get back to #2 and your opinion/findings, I hope this is more clear as to what's happening in my ICH7/Q9550 system ;D We're repeating a lot but now know more! Cheers.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version