Voodooprojects

Chameleon => Bug Reports => Topic started by: konsti on October 19, 2010, 02:21:00 PM

Title: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: konsti on October 19, 2010, 02:21:00 PM
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: [Select]
<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>
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: konsti on December 04, 2010, 09:02:31 PM
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)
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on December 05, 2010, 06:56:25 AM
Doesn't work for me either on my old P4 hack, I have to use Chameleon 2.0 RC3.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Azimutz on December 05, 2010, 08:34:03 AM
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: [Select]
    <key>SMcputype</key>
    <string>1281</string>
sets "Dual-Core Intel Xeon" instead of the default "Intel Core 2 Duo",
and
Code: [Select]
     <key>SMcputype</key>
     <string>513</string>
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...
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on December 05, 2010, 07:10:01 PM
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.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Azimutz on December 05, 2010, 09:23:01 PM
Yep Gringo.. i was going to mention that later... Chameleon does override the cpu-type set by the kernel, if any; i can confirm that, since i'm using the legacy kernel atm without any changes. So, as SMBIOSdefaults=n is currently disabling cpu-type setting, if we use it, the value set by the kernel will be used, which can be confusing if we forget the fact ::)

Anyway, the booter should be setting Core Solo for any cpu with just one core! If that is not working, then we have a bug.
Can't test that stuff on my Pentium D; you'll need to feedback :)

Gringo, about the keyboard all i can think of is "legacy usb"; i need it enabled on Bios for my wireless keyboard to be detected.

I'll be back... still checking some stuff...
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: konsti on December 05, 2010, 09:33:06 PM
Dear Azimutz, thanks for taking the time to reply and sorry you have to deal with us "newbies" regarding the deeper use of Chameleon  :lol:

Since there's apparently no clear documentation, I was under the impression that:

Using SMBIOSdefaults=Yes doesn't make the system need smbios.plist file, as everything is detected by Chameleon (CPU, RAM speed, RAM types/serial, CPU Bus speeds etc.). Perhaps the system (or kernel, as you say) sets the most appropriate SMproduct according to what is pushed by Chameleon.

Using SMBIOSdefaults=No make the system badly need smbios.plist file in order to have all the parts defined (again, (CPU, CPU Bus speeds, RAM speed, RAM types/serial etc. AND product-type i.e. MacPro3,1 or MacBook2,1 etc.) as Chameleon doesn't bother detecting anything.

On my ICH7 Core2Quad mobo, if I set SMBIOSdefaults=Yes the CPU is recognised and the RAM modules as well. Actually, they are reported as 802MHz rather than 800MHz.

With SMBIOSdefaults=No I get no CPU type ("unknown") so I don't know if Chameleon parses/pushes the info from smbios.plist.

I apologize if I got it all wrong; I was never able to find a good post to explain what the heck SMBIOSdefaults does, at the end of the day  8)
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on December 07, 2010, 07:02:20 PM
I installed 2.0 RC5 r647 on the P4 (10.5.8, qoopz Voodoo derivative 9.8.0) and the CPU is now correctly set as Core Solo. Someone must have fixed that somewhere during the RC5 dev cycle. :) 

I am using a MacPro1,1 smbios.plist, no SMBIOSdefaults flag in com.apple.Boot.plist.

The memory detection does not fully work with the i865PE/ICH5 though, type and speed are correct but partnumbers, manufacturer and serials are not set.

8086:2570 82865G/PE/P DRAM Controller/Host-Hub Interface ... if anybody wants to bother with something this old.

I haven't tried an SMcputype override, but at least I can confirm that the automatic override works now.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: konsti on December 08, 2010, 01:19:59 AM
So dear Gringo, to get a better understanding; you installed this RC5 build r347 and used a custom-made smbios.plist file, and the CPU is properly displayed as Core Solo? Without SMBIOSdefaults=Yes or SMBIOSdefaults=No?

Please try the very latest builds of Chameleon; get them from Azimutz's signature. In early builds, this thing as I described above works; with latest build, the SMcputype is not pushed to the system (taken from smbios.plist) when SMBIOSdefaults=No!

Cheers and good night.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on December 08, 2010, 01:38:07 AM
Sorry about the typo, I meant r647. I've edited my post. I'll upgrade to r653 but don't think it'll make any difference.
/EDIT - indeed, it still works.
I compile Chameleon from svn trunk myself, find my builds in my install guide here:
http://forum.voodooprojects.org/index.php/topic,649.0.html

I use a MacPro1,1 smbios.plist with only model data in it (no SMcputype) and no SMBIOSDefaults flag set in /Extra/c.a.B.p.

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.

And sorry about the threadjack Konsti, my issue was only slightly related to yours and turned out to be a non-issue!
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Azimutz on December 08, 2010, 09:11:26 AM
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.
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: [Select]
<?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 :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 (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/i386/libsaio/smbios_patcher.c#L438) 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.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on December 08, 2010, 04:39:30 PM
Excellent, thanks for the detailed explanation.
About the "MemDetect" stuff, does it show with Asere's booter? Just out of curiosity, is that Pentium 4 64 bit?

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.
This one "SMbustype" i can't find anywere! Not even on Asere's code! Don't know were you got that, Konsti??
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 
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: konsti on December 09, 2010, 12:41:34 AM
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.

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...
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Azimutz on December 09, 2010, 05:51:28 AM
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
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: konsti on December 09, 2010, 01:15:02 PM
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 (http://forum.voodooprojects.org/index.php?topic=1146.0)! How about that ;)
But according to your posted link on the actual used smbios.plist keys (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/i386/libsaio/smbios_patcher.c#L438), 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.

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.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on December 09, 2010, 10:39:31 PM
1. SMbustype: yes, it was referenced around the web; our dear Gringo Vermelho even makes a mention in his thread (http://forum.voodooprojects.org/index.php?topic=1146.0)! How about that ;)
But according to your posted link on the actual used smbios.plist keys (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/i386/libsaio/smbios_patcher.c#L438), indeed, SMbustype doesn't exist. Wonder who invented it...

It did exist in Chameleon 2.0 RC4 (I used it!) and was invented by DigitalDJ:
http://forum.voodooprojects.org/index.php?topic=839.0
I don't know how it became "SMbustype" when the code made it in, zef probably knows.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Azimutz on December 10, 2010, 09:40:04 AM
Yeah... i traced this "SMbustype" thing here (http://www.insanelymac.com/forum/index.php?s=&showtopic=201833&view=findpost&p=1360961), here (http://www.insanelymac.com/forum/index.php?s=&showtopic=231075&view=findpost&p=1576372), here (http://www.insanelymac.com/forum/index.php?s=&showtopic=223597&view=findpost&p=1503922), here (http://www.insanelymac.com/forum/index.php?showtopic=234420), here (http://forum.voodooprojects.org/index.php/topic,1146.msg4938.html#msg4938), here (http://forum.voodooprojects.org/index.php/topic,839.msg6593.html#msg6593) (some already mentioned) and gave up :P
Still i don't know were it came from and there's also no sign of it on RC4's code.
SMcputype and SMbusspeed are indeed from DigitalDJ's patch, which i believe is inspired by his kext (http://www.insanelymac.com/forum/index.php?showtopic=189562) work (even here, no SMbustype).
Let's just leave that one alone before it comes to life again ;D



About SMbusspeed, afaik it's cpu specific, Core i7 i believe; it's of no use for you Konsti (or me), but i did checked that stuff you mention and it does the same here. The important part is that also doesn't seem to work with SMBIOSdefaults=n.
Anyone can confirm? :)



Ok... this SMBIOS stuff can get messy to explain, simply because it interacts with several stuff, cpu detection, memory detection, Mac model setting, etc... As i mentioned, the explanation i gave is mainly based on my experience as a user and the tests i been doing the past days, to refresh my mind; i also been taking a look at the code, but getting knowledge from there is going to take time, for me.

The main problem That Konsti brought up is that, some stuff, namely SMcputype, doesn't get injected from smbios.plist when SMBIOSdefaults=n is used, which i already confirmed. It seems now that SMbusspeed can be added to the bunch!? I can also confirm that the mentioned smbios.plist keys work with SMBIOSdefaults=n on RC4.
Also, i already knew that UseMemDetect is being affected by the same problem.
These are the facts!
According to that, i changed the topic again to something more appropriate and that doesn't make us being "out of topic" so easily :P
Note: Gringo, about this topic change, can you check i did it properly? I only changed first post and i don't see the other posts updated :o which i assumed it would. Wanted to spare you guys some work, but instead...

With this said, one thing we need to keep in mind, is the possibility that this code isn't ready yet!?
Also, we are assuming these keys should work with SMBIOSdefaults=n, but there's the possibility this was done on purpose? I don't believe so on the UseMemDetect case, since it has it's own mechanism to disable it.
To many doubts i can't answer atm.

So Konsti, i already explained you don't need to use SMBIOSdefaults=n to use a smbios.plist's values...
What more can i say or help you with? :)


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.
Gringo, about the memory detection i'll take a look; maybe we can at least figure if it's a problem with the detection code or some incompatibility with the machine/Bios. There's code for ICH5 (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/i386/libsaio/spd.c#L350) on spd.c; can you check the dev id of the smbus controller against yours?
Just a silly question... do you have the missing info on Windows? :)
We're out of topic here so, feel free to pm me if you need.

About the cpu-type you're right, i did asked because of the em64t thing; Intel Core Solo/Duo don't have it.
I don't think it makes any diff; i mean, i can use Core Duo on my Pentium D and i never saw any diff. But maybe Core 2 Solo it's a better fit on these cases?! Specially on the 64 bit capable Atom's, since they belong to the same family as Core 2 cpus (6).
Our old stuff is family 15.
Anyway, i consider this stuff mostly cosmetic, since the real cpu is always detected on my system.
The "64 mode" message means you can run 64 bit apps, yes. Did you gave a try to Snow on that machine?
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on December 10, 2010, 07:17:23 PM
The SMBus controller on the P5P800SE:

00:1f.3 SMBus [0c05]: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller [8086:24d3] (rev 02)

On Windows (it's running 64-bit Windows 7 Ultimate) I can see all the SPD data for all four sticks of RAM with CPU-Z.

I agree Core 2 Solo would be a better fit for my P4 and the Atoms too, but then what about older model P4s with no 64-bit support? They would still need to be set as Core Solo. Chameleon would then have to check for EM64T capability in addition to whatever it's doing now when setting the CPU type. If that's even possible.
But I guess it would be a lot of work to support old, obsolete hardware like that and I don't know how much it matters. Maybe it would be giving me trouble if I was using a MacMini model identifier, the Mac Mini had the Core Solo right? From what I've seen so far it seems that most apps look at the model identifier instead of the CPU type.

I haven't attempted to install Snow Leopard on it, maybe I'll give it a go just to say I did it.

About the topic - let me check that, I never tried changing a topic title. I hope there's a tickbox that says 'change title for all posts'. If not, blame Rocksteady. :P

/Edit
...nope, you have to change each post title individually. Booooorring!
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Azimutz on December 11, 2010, 09:23:05 AM
Quote
The SMBus controller on the P5P800SE:

00:1f.3 SMBus [0c05]: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller [8086:24d3] (rev 02)

On Windows (it's running 64-bit Windows 7 Ultimate) I can see all the SPD data for all four sticks of RAM with CPU-Z.
The controller id matches
Code: [Select]
{0x8086, 0x24D3, "ICH5",    read_smb_intel },I'd say the booter is not being able to retrieve the info, but... will try to take a look.

Quote
I agree Core 2 Solo would be a better fit for my P4 and the Atoms too, but then what about older model P4s with no 64-bit support? They would still need to be set as Core Solo. Chameleon would then have to check for EM64T capability in addition to whatever it's doing now when setting the CPU type. If that's even possible.
But I guess it would be a lot of work to support old, obsolete hardware like that and I don't know how much it matters. Maybe it would be giving me trouble if I was using a MacMini model identifier, the Mac Mini had the Core Solo right? From what I've seen so far it seems that most apps look at the model identifier instead of the CPU type.
yep.. as i said, i believe most of this stuff is cosmetics, unless one can take advantage of it in cases like native power management.
Chameleon does detect if the cpu has em64t or not; it's how it chooses the arch to pass to the kernel. And it also detects the number of cpus/cores. It's not that hard to make changes in that direction; in fact, it seems pretty easy.
Will try to take a look too :)

Quote
I haven't attempted to install Snow Leopard on it, maybe I'll give it a go just to say I did it.
It will work Gringo! I know a mate who has it running on a machine very similar to yours; he just doesn't run it on x86_64 arch because of the graphics drivers not having support for 64 bit (nVidia 7xxx).

Quote
About the topic - let me check that, I never tried changing a topic title. I hope there's a tickbox that says 'change title for all posts'. If not, blame Rocksteady. :P

/Edit
...nope, you have to change each post title individually. Booooorring!

hum.. it seems like so :P looks like Blackosx did the same on the other change.
Will do so, while the posts aren't that many.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: konsti on December 11, 2010, 02:25:55 PM
Dear friends, my turn to reply  8)

1. Thanks for confirming the SMcputype bug of this thread, Azimutz. I am happy I am not getting crazy! So what can the next step be? I mean, how can we have Chameleon developers also poke into the code and see where this injection gets lost?

2. The above question also expands to SMbusspeed, hoping that you can also confirm my contradicting reports in System Profiler with SMBIOSdefaults=Yes or No  :)  Anyway, what kind of unit is 1.33 GT/s ?

3. And I believe you all refer to CoreSolo as processor, since there has apparently never been a Core2Solo, right? You are indeed referring to value:
   <key>SMcputype</key>
   <string>257</string>
...correct?

4. I also have a hackintosh based on Core i7-860 (2.83GHz) and will test the SMbusspeed in relation to SMBIOSdefaults, if you want (more feedback, I mean).

Cheers!
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on December 11, 2010, 03:15:23 PM
http://en.wikipedia.org/wiki/Intel_Core#Core_2_Solo

Core 2 Solo has EM64T, Core Solo doesn't. Therefore Core 2 Solo would be a better "fake" for my P4 since it has EM64T.

But I don't know if Apple has actually used the Core 2 Solo? If not, then Core Solo is the best match.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: konsti on December 11, 2010, 03:21:26 PM
I am pretty sure Apple used CoreSolo, mainly in the first generation of MacMini (http://www.everymac.com/systems/apple/mac_mini/stats/mac_mini_cs_1.5.html)'s. Never again, though... They went straight to the hoter CoreDuo's. I have never seen Core2Solo used in Apple products (http://www.everymac.com/systems/apple/mac_mini/index-macmini.html). Hence my comment (not doubted you, of course)...
So my previous value for SMcputype of 257 is for CoreSolo, mind you.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Blackosx on December 12, 2010, 09:15:42 AM
...nope, you have to change each post title individually. Booooorring!
hum.. it seems like so :P looks like Blackosx did the same on the other change.
Apologies for the OT comment but I agree in that I couldn't find an option either, though I did find this topic (http://www.simplemachines.org/community/index.php?topic=190523.0) at SMF fourms where some have had success but it didnt' work for me. So I ended up doing to manually as you've done Azimutz.

EDIT: There is the option to rename all posts when merging topics - so for speed one could create a new topic with a relevant post for this one, then merge both topics together, renaming each post in the process :)
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Azimutz on December 13, 2010, 03:46:46 PM
Blackosx, i can't make that stuff work either. Maybe we need to "blame" Rocksteady like Gringo suggested ;D

Back to the SMcputype talk and about "Intel Core 2 Solo" (dec 257, hex 0x0101, cpu-type <0101>), i'm having doubts about it's usefulness?! It looks like Apple never used it (i use Mactracker to check this kind of info) and it's a "mobile" cpu so, maybe not the best choice for a desktop Pentium 4 (or even a 64 bit Atom).
Mostly trying to collect info on this...
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on December 13, 2010, 08:22:15 PM
I've done some searching as well and I could not find any mention of a Mac with a Core 2 Solo CPU either.

If the idea is to only fake CPUs that shipped in actual Macs (which makes total sense) then Core Solo is not just the best match, it is the only match there is, even if it didn't have EM64T.

Konsti, you said "since there has apparently never been a Core2Solo, right?" which to me reads as if you meant to say that that particular model doesn't exist. That's why I posted the wikipedia link.

Again sorry about the threadjack Konsti, the thread became a bit messy which is mostly my fault. But it's kind of sort of almost related.  :-[
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Azimutz on December 14, 2010, 05:04:02 AM
If the idea is to only fake CPUs that shipped in actual Macs (which makes total sense) then Core Solo is not just the best match, it is the only match there is, even if it didn't have EM64T.
Yes, i agree. But, did you tried 257, just to see if it works with the Pentium 4?
I can confirm it doesn't work on my Pentium D (because of the number of cores, i assume), but it does work on an 64 bit Atom.
 
 
Dear friends, my turn to reply  8)
 
 1. Thanks for confirming the SMcputype bug of this thread, Azimutz. I am happy I am not getting crazy! So what can the next step be? I mean, how can we have Chameleon developers also poke into the code and see where this injection gets lost?
 
 2. The above question also expands to SMbusspeed, hoping that you can also confirm my contradicting reports in System Profiler with SMBIOSdefaults=Yes or No  :)  Anyway, what kind of unit is 1.33 GT/s ?
 
 3. And I believe you all refer to CoreSolo as processor, since there has apparently never been a Core2Solo, right? You are indeed referring to value:
    <key>SMcputype</key>
    <string>257</string>
 ...correct?
 
 4. I also have a hackintosh based on Core i7-860 (2.83GHz) and will test the SMbusspeed in relation to SMBIOSdefaults, if you want (more feedback, I mean).
 
 Cheers!
 
1. If you mean, "when will this be fixed?", you already know my opinion; this is not critical, thus not a priority.

2. & 4. http://en.wikipedia.org/wiki/Intel_QuickPath_Interconnect

3. Already explained by Gringo Vermelho.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Azimutz on December 28, 2010, 04:56:01 AM
Hey Konsti,

did you tried Kabyl's branch on this matter?
It works properly ;)
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: konsti on December 28, 2010, 10:56:50 AM
Good morning Azimutz, season's greetings everyone!
I looked into our exchanged PMs too, I could not find a source for compiled binaries for kabyl's branch.
I am not too familiar compiling with Xcode, yet but I am as happy as I am impressed that it works. That means that kabyl's code is different/improved on that matter (recently or always has been) which I hope he can merge to the main trunk, soon!
What build version did you try? Higher than your currently shared R668?
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on December 29, 2010, 02:47:29 AM
Kabyl branch r693 build attached, Merry Christmas.  :)
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Azimutz on December 29, 2010, 04:53:23 AM
Yeah, a nice Holiday season for anyone out there :)

Konsti,
compiled binaries are not an issue, as you can see ;D
I was asking because you may had already tried it from here (http://www.insanelymac.com/forum/index.php?showtopic=231768); the topic has nothing to do with smbios patching but Kabyl does mention the stuff on the first post.
That means that kabyl's code is different/improved on that matter (recently or always has been) which I hope he can merge to the main trunk, soon!
What build version did you try? Higher than your currently shared R668?
Yep, it's been there for a while. Kabyl rewrote a good deal of code related to smbios patcher on his branch; in fact, i meant to add it to my branch, but as you know Kabyl been busy and i didn't knew the status of the stuff; meanwhile i also got busy and i forgot that this matter we've been talking, could be fixed on his branch :P
I tried rev 594, which works fine as far as i could see; after that he added the ATI stuff, that breaks GraphicsEnabler on my card.
I'll be messing with this for now so, if you need something just yell...
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: NetBoot on December 31, 2010, 08:57:46 PM
Salutations!

First post by the way..  :)

ah, If you need to change the cpu type.  How about using it as a data field and not a string.

So it would be, using Properties List Editor

<key>SMcputype</key>
    <data><0101></data>

Raw format, in Text Editor

<key>SMcputype</key>
    <data>AQE=</data>


Net....
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: NetBoot on December 31, 2010, 09:33:51 PM
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)

The Bus Speed and Processor Interconnent Speed are correct.

Net....

Please don't quote whole posts, trim your quotes so that you're only quoting what's relevant. Thank you.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: konsti on December 31, 2010, 09:39:11 PM
ah, If you need to change the cpu type.  How about using it as a data field and not a string.

So it would be, using Properties List Editor

<key>SMcputype</key>
    <data><0101></data>

Raw format, in Text Editor

<key>SMcputype</key>
    <data>AQE=</data>
You have to be joking... it was so simple all this time? Just needed to insert the right value in the correct encoding? When did this change in the Chameleon main code?!? Thanks for the tip, will try it the soonest possible, together with Azimutz's suggestion for kabyl's compiled binaries...

Also, I was wondering what kind of measurement unit this GT/s is, for the interconnect speed... (giga--what?)
One get a comma [,] in the display of the unit, the other setting [.] a point.

Anyway, new year is close here. Take care, everyone! Happy new year!
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: NetBoot on December 31, 2010, 10:03:34 PM
It was alway this way.  Well, with the versions I've been using anyways.  I've only been doing this for 3 months.

The PIS in never automatic you have to insert this code if you want to use it.

About the comma and period, I'm not sure what you mean.  a snapshot would help.

I'm using an old Dell OptiPlex SX280, so my PIS is only 800 MT/s

Oh, i hope no one messed with the source code.  Since and far as I can tell it not a bug...

Happy New Year

Net....

P.S.  The only thing that I can't figure out and Fix is the Hardware UUID.  I just can't seem to get it to change.

Redundant quoting removed.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on January 01, 2011, 03:35:19 AM
This is the most mysterious part of this thread. And we've talked about some pretty mysterious things already.
NetBoot: I don't understand the way you talk, I don't know if I should ban you or worship you.

<key>SMcputype</key>
    <data><0101></data>

Raw format, in Text Editor

<key>SMcputype</key>
    <data>AQE=</data>

<data><0101></data> say what?

Does that actually work for you?

It's supposed to be (example!) <key>ClavinetD6</key> followed by <string>y</string>.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: NetBoot on January 01, 2011, 05:22:38 AM
Yes Sir, working this way for me.

Net....

/EDIT no need to quote everything when you're replying directly below.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: NetBoot on January 02, 2011, 01:49:25 AM
I guess it's working for konsti.  No news is good news.

Recap:

I went through some of the source code.  For this to work correctly it needs to be injected in Base 64 encoded data.  This needs to be in data format in the smbios.plist.  In example, Base 64 encoded data AQE= is converted into 0101.

This is a simplified explanation, but I think you get the idea.

Net....

P.S. Sorry about the quoting
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: konsti on January 02, 2011, 10:18:54 AM
Hello gentlemen, I am sorry for my delayed response, New Year's Eye and Day's family responsibilities kept me away from the computer, in general  ;D

NetBoot mate thanks for your time, your tip was very unexpected but it doesn't work. I did the changes but get "Unknown". Initially, I couldn't find an appropriate Base64 encoder for these values (please post a URL if you have one) so I used a value after searching the net (for my Core2Quad):

Intel Xeon Quad: 1281 - 0x501 - 0x0105 (little endian) - AQU= (Base64)
Intel Core 2 Duo:  769 - 0x301 - 0x0103 (little endian) - AQM= (Base64)
Intel Core Solo:     257 - 0x101 - 0x0101 (little endian) - AQE= (Base64)

resulting to:
<key>SMBIOSdefaults</key>
<string>No</string>
and
<key>SMcputype</key>
<string>AQU=</string>

I guess there's no value injected whatsoever; it wasn't a value type problem, it's the injection itself... Do not forget that at some point, it used to work with a decimal value (still referring to a Snow Leopard system, I am sure that back in the Leopard days it worked, too... I thought that perhaps the SL system required a new type of injection, compared to Leopard).

EDIT: Dear Gringo Vermelho, thanks for the compiled binaries from Kabyl's branch (r693) it works. Amazing. With either Base64 or decimal value. With SMBIOSdefaults disabled, I inject the value 1281 and CPU is properly set as Xeon QuadCore. Thanks!

Dear Azimutz, how can you merge SMBIOS code in your branch? Has Kabyl disclosed his/her changes already?
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Azimutz on January 02, 2011, 01:52:00 PM
Hi guys.. a god year to anyone.

NetBoot... are you sure that passing the values as "data" is working for you?? :o i checked that, when Konsti first talked with me about this and it didn't worked...
That was used on the "kext" DigitalDJ created before he did the booter patch and the values were all in "base64" format (check the link to the InsanelyMac topic, Gringo and i posted). Anyway, what we are discussing here is not the type of the value, but the fact that some values are not passed from smbios.plist, when SMBIOSdefaults=n is used.


Dear Azimutz, how can you merge SMBIOS code in your branch? Has Kabyl disclosed his/her changes already?
Here (http://home2.paulschou.net/tools/xlate/) is a decent translator that handles base64 ;)
About the smbios patcher code, did you missed my last post?? The code is on Kabyl's branch :P
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: NetBoot on January 03, 2011, 02:26:11 AM
Yes, it's working for me.

I tried kabyl branch but it goes into a continuous reboot.  So no luck there. May be the kernel I'm using?

Azimutz, would that kabyl branch be the one with the 450.diff patch?  Don't recall see any smbios patch?

Here's my info:

Dell Optiplex SX280
MacOS 10.6.5
nawcom 10.5.0 Legacy Kernel
Chameleon 2.0 RC5 r698 svn trunk
FakeSMC 2.7.2 - S/L/E
IOATAFamily.kext - Legacy ATA ICH6 - E/E
ElliottAppleIntelGMA950LegacyEnabler.kext - S/L/E

Everthing else is vanilla

I'm working on my daughter's pc right now.  But, I'm going to change it to a string field and then to a data field and take snapshots of the two and post my findings.

After, reading konsti last post.  I think I see what's going on.  When he uses <string>AQU=</string> it's still injecting the correct code AQU=

If I use <data><0105></data>  the raw value is AQU= which that is getting passed and injected.

We still pass the correct data to the injector, I'm just use Properties List Editor to end up with the same results..

Make sense to you?

I do see a warning when chameleon loads, non-string value for SMcputype, but seems to still pass the code.
Plus, it must still be using the smbios.plist value for it or it would return unknown cpu.


Net....

PS - See Attached smbios.plist image
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on January 03, 2011, 05:07:57 AM
would that kabyl branch be the one with the 450.diff patch?
Grab it here:
http://forum.voodooprojects.org/index.php/topic,1647.msg9176.html#msg9176

Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: NetBoot on January 03, 2011, 11:28:01 AM
Thanks, I really wasn't having an issue with SMBIOSDefault.  But, I went ahead and updated with 693.  I'm assuming this is your branch?

Did a quick test and it working either way, string or data.  Just as long as it's the correct value; i.e. AQU=

I also compiled your lastest branch 698 and that's working also as normal.  Plus, no reboot issue..

Also, no issues with GraphicsEnabler on my end.

Question thou, what do I gain by using your branch?

There is one thing I did notice on your latest branch.  In the ioreg logs I see the cpu type as 102.  Have any idea why that is?

I haven't got around to updating it back to 698 trunk to see it there's a difference.  But, just for the hell of it I set the SMcputype to AQI= (did the conversion 0102) and no issues.

Is there a way to get my ethernet working?  It's just isn't getting found in the OS.  Also, I'm not having an issues with my graphics adapter but I do notice the it's not supported by Chameleon.  MacOS log show that the display0 is not usable, but it's working fine? go figure.

Talk to yah later's

Net....
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on January 03, 2011, 04:45:31 PM
I am Gringo, Kabyl is Kabyl.

It should not matter much if Chameleon does not know the device ID of your video card, injection with GraphicsEnabler=y will work just the same. System Profiler will display "Unknown nvidia". Assuming of course your video card is nvidia, you didn't say.

Set EthernetBuiltIn=y in your com.apple.Boot.plist. Like GraphicsEnabler, this is not a driver, it's just to make sure that OS X sees your primary network adapter as built-in, which is good for compatibility. You'll still need to install or modify existing drivers to get your hardware working. However, this is off topic for this forum.

If I use <data><0105></data>  the raw value is AQU= which that is getting passed and injected.
We still pass the correct data to the injector, I'm just use Properties List Editor to end up with the same results..
Make sense to you?

No, that does not make sense to me. And you still have too many <>'s. I tried to tell you before that it's <data>xxx</data>, not <data><xxx></data>.
What do you mean "passing to the injector", and what do you mean "using Property List Editor to end up with the same result"?
As you have been told already, the correct way to override the way Chameleon handles this is to set the CPU type via smbios.plist like this:
<key>SMcputype</key>
<string>513</string> (or whatever value you wish to set. As Azi said, base64 will not work)
If you're doing this in any other way it will not work and Chameleon will set the CPU type it thinks is the most appropriate.

The CPU type setting code comes from DigitalDJ originally:
http://digitaldj.net/2009/10/06/cpu-detection-integrated-with-chameleon-rc3/
As you can see even the author tells you to use 1281, 257 etc and not base64 values.
 
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: NetBoot on January 04, 2011, 02:37:31 AM
Sorry Gringo,

I haven't been on this forum very long. So, I don't know everybody here.

About the video.  Yeah, not that it matters, but I just installed the GMA900 kext for it and it's fine.

About the ethernet.  I thought that EthernetBuiltIn setting wasn't needed to be used any longer with the latest chameleon build, but I put it in anyway.  I just need a working BCM5751 kext.   The many I found are crap.  Trying to find a good source code and build it myself.

"passing to the injector"  If that's the wrong terminology for it please correct me on that.

"using Property List Editor to end up with the same result"?   I use the MacOS's Property List Editor to modify the smbios.plist   All I'm saying is that I'm using it to modify the plist instead of editing it directly.

Quote
As you have been told already

Yes, I know that, I just posting my finding.

I made the recommended changes to the smbios.plist (SMcputype 257) and I'm using Kabyl 693.

This is what I get see attached image.

So, it must be something else.  What? I'm not sure right now

Net...

P.S.  If you want me to stop posting about this subject then fine, I'm done...

Not sure why the images are not working,, Maybe wrong format

Question?  Would having a HyperThreading CPU have any effect on how Chameleon detects cpu type?  Even thou I have HyperThreading turned off in the PC BIOS  Maybe it's still being pick up as a dual processor.  I Know Chameleon see is as two when I do verbose startup.

Edit: images
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on January 04, 2011, 02:57:06 AM
No, I don't want you to stop, I just want to make sure we are speaking the same language.

I don't know why somebody would tell you that EthernetBuiltIn=y wasn't needed with the latest Chameleon, it's needed in the same way that it always was.

If you're using Apple Dev Tools Property list editor, great. I wasn't sure what you meant, I didn't realize you were only talking about editing smbios.plist itself. As I said earlier I'm having a hard time following your style of writing.

I did not download your attached images. You should upload .png or .jpg files instead, as they will be viewable directly here in the forum.
Use command+shift+4 to select an area to screengrab, then click the mouse, or use the space bar to select the active window and then click to screengrab it. Screengrabs are saved as .jpg files on your desktop.

/EDIT thanks, that's better.

I have a Pentium 4 Hackintosh and Chameleon auto-sets the CPU to Core Solo like it's supposed to. I'm not using SMcputype in smbios.plist.
Hyperthreading is enabled and it seems to be working. It's running 10.5.8, Qoopz Voodoo 9.8.0 kernel and a fairly recent, unmodified trunk build of Chameleon 2.0 RC5. But I'm using a MacPro2,1 model identifier.

You should not need the SMmaximalclock, SMmemtype and SMmemspeed settings when using Chameleon 2.0 RC5.
Apart from that, your smbiosdate does not match your boot ROM version and the boot ROM version is not correct for a MacMini2,1. Check your sources. The best way to find reliable DMI information is to look at DMI dumps from real Macs. You can find those by googling for example "MacPro2,1 DMI" and then follow the hits that lead to Linux bug report sites.

Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: NetBoot on January 04, 2011, 04:56:29 AM
Yeah, I know about the smbios info I'm using.  I haven't finshed tweaking it.  But I made the changes that you recommended.  Thanks for the help on that.

Question about HyperThreading.  I tried enabling HyperThreading in the PC BIOS in the past and the system would lock up.

I just tried it again and now the system is up and running.  But, I don't see any changes to the System Profile. The number of Processors and cores are still 1

Should this change?

Thanks for being so patient with me.

Net....
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on January 04, 2011, 05:23:16 AM
Having hyperthreading enabled doesn't change the fact that you have 1 CPU with 1 Core, so that information should stay that way.

Try running Activity Monitor and take a look there, IIRC it *should* show two "CPU Usage" windows. Not sure, the P4 hack runs Windows 7 all the time, it's been a while since I've booted up OS X on it.

Try installing the processor prefpane, it comes with Apple Developer Tools and is buried somewhere in the /Developer folder. Once you find it, just double click on it to install it. It'll probably say 'unknown' as well but IIRC it should show two threads. Sorry but I rarely boot up OS X on the P4 anymore and I don't remember all the juicy details.

Could you add wait=y to your com.apple.Boot.plist and post a photo of the information shown on bootup here?
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: NetBoot on January 04, 2011, 06:02:44 AM
I have to disable HyperThreading.

I'm losing my USB High Speed Bus.

Net....
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: NetBoot on January 04, 2011, 10:29:27 AM
When I use Wait=yes all I get is press an key to continue

Net....
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Kabyl on January 04, 2011, 10:55:14 AM
The booter doesn't support Base64.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Azimutz on January 04, 2011, 08:53:22 PM
When I use Wait=yes all I get is press an key to continue
You need to use -v (verbose) argument too; but you can also use "bdmesg" to get the "booter-log" ;) ask if you don't know what i'm talking about.
And i think you need to slow down a bit, read and give it more time;
i'm reading for 3 years and most of the time, i still feel like a damn noob!

Ok, using Kabyl's branch or Chameleon (trunk), remove the smbios.plist you're using and check what cpu, Mac model, etc... the booter gives you by default! The booter has default values, you only need to change them via plist if they are incorrect or missing. Most probably you will only need the serial; you should get iMac1,8 and Core Solo cpu.
And 257 is the code for Core 2 Solo, which apple never used, some crazy dude found some where and i was wondering if it would work on a Pentium 4...
You would know all this stuff if you've read the topic properly ::)

By the way, does your P 4 has em64t (Intel 64)?



Gringo, you need to emend
Code: [Select]
<key>SMcputype</key>
<string>0102</string>
on post #42; it needs to be a "decimal" value :)
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on January 04, 2011, 09:04:48 PM
Azi, I don't understand?  :o
To my eyes, that's exactly what it says in post #42.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Azimutz on January 04, 2011, 10:34:22 PM
Well, in this case/example it needs to be
Code: [Select]
<key>SMcputype</key>
<string>513</string>
which is the decimal of 0x0201 (or 0x201), which ends up on IOreg byte flipped, 0102.

0x0201 - Core Solo/Duo (dec 513)
0x0301 - Core 2 Duo (dec 769)
0x0501 - Dual-Core/Quad-Core Xeon (dec 1281)
0x0601 - Core i5 (dec 1537)
0x0701 - Core i7 (dec 1793)
0x0901 - Core i3 (dec 2305)
and the bastard
0x0101 - Core 2 Solo (dec 257)

You mention correctly next...
Quote
As you can see even the author tells you to use 1281, 257 etc...
The hex values above are from Chameleon code; don't ask me why it uses hex instead of dec :P
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on January 05, 2011, 01:44:00 AM
woah, "identification through obfuscation" :-)

Thanks again.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: konsti on January 26, 2011, 09:23:20 PM
Guys, just to inform you that the latest R699 Chameleon that I am using (thanks to Azimutz's signature-binaries) does not fix the problem, compared to R693 from Kabyl's branch that works flawlessly. This, again, referring to the SMBIOSdefaults option, to properly parse/inject SMcputype variable. Just for the record 8)
Thanks again.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: konsti on January 25, 2012, 12:45:43 AM
Hello to all and happy new year. Has this been fixed in the recent versions of Chameleon RC5? Can anyone confirm, please? Thanks in advance.
Title: Re: SMcputype (and others) not working with SMBIOSdefaults=n on RC5
Post by: Gringo Vermelho on January 25, 2012, 02:31:08 AM
The RC (Release Candidate) 5 dev cycle was frozen and the last revision became Chameleon 2.0 Final.

Chameleon is presently at version 2.1 r18xx.

I don't know if your issue has been fixed.

Upgrade to Chameleon 2.1, get rid of the smbiosdefaults key/string in (was: com.apple.Boot.plist) org.chameleon.Boot.plist and place only model identifier and other Mac DMI data in smbios.plist. No memory stuff, no CPU stuff, Chameleon should auto detect all of that.

Something we didn't discuss here is that it's possible your smbios.plist is corrupt and Chameleon can't read all the values in it.
If you zip and attach your smbios.plist here, I'll make a clean one for you with Apple dev tools plist editor.