Voodooprojects

Chameleon => Bug Reports => Topic started by: smith@@ on August 20, 2010, 07:52:10 PM

Title: SystemId
Post by: smith@@ on August 20, 2010, 07:52:10 PM
First of all, sorry for english and for text..

Anyway, on my little msi u100 i had always this tiny problem.

Until now, only on this pc, I was forced to use the platformuuid kext to inject the hardware uuid, because in two following cases I have an hardware uuid like this: 000000000-000 - etc. etc.
and consequent errors of "host 35" in console and so on......

Two cases: injection made by booter and injection with override SystemId in com.apple.boot etc..

 Ok, now, in some tests this evening with revisions made by azimutz, both chazileon and clean cut, the problem there isn't anymore. Only with these two rev from azi if booter inject the harware uud i have a RIGHT hardware uuid  9878979-43343-DS43 ..... and NO errors in console, obviously
The same good result if i ovverride with SystemId in com.apple etc. etc.

 So on, I have controlled the boothelp.txt from repository of all revision and for this particular case i haven't found differences.

I do not know if I was very clear but i want say that with azimutz's rev also on my little msi the booter inject the right hardwareuuid and so No errors in console and Not platformuuid kext to use. For my desktops, on my sony lappy, and so on, this "problem" does not exist from very long time  ::) 

Ok, 2 question:  what are the differences in this specific case?  And if is it possible fix this also for trunk?

I hope to be very clear but the little problem, if problem is, is real. Only on msi u100 netbook, in this specific case.



Thanks  :)
Title: Re: SystemId
Post by: Azimutz on August 21, 2010, 12:53:57 AM
Hi Smith@@,

i got you clearly :)
Explaining:
the difference on my branch on this matter, is the patch for this issue (http://forge.voodooprojects.org/p/chameleon/issues/21/).
To put it simple, the Atom processor on you notebook is 32 bit only; these processors seem to need EFI32 set
for hardware uuid to work properly (and some other stuff). The problem is that Chameleon is using only
EFI64 since RC4; the patch only does the switch between EFI 32 & 64 according to the cpu architecture.
The issue was accepted so, it's just a matter of time for this to be fixed on the trunk.
If everything is working fine, you should be getting the uuid from bios dmi, the real one that any OS
installed on that machine will see.

Still about my branch; be careful because there are other important changes, mainly on file loading.
Will add some documentation this night weekend for sure.. only needs clean up.
Hey.. and Thanks for trying the stuff and reporting :)
Besides my own tests, your's is the first feedback i get on this issue and not on purpose, from a 32 bit processor,
that i don't own. To test this i need to use -legacy kernel flag on my Pentium D 925.

See you around...
Title: Re: SystemId
Post by: smith@@ on August 21, 2010, 01:08:53 AM
Hi Smith@@,

i got you clearly :)
Explaining:
the difference on my branch on this matter, is the patch for this issue (http://forge.voodooprojects.org/p/chameleon/issues/21/).
To put it simple, the Atom processor on you notebook is 32 bit only; these processors seem to need EFI32 set
for hardware uuid to work properly (and some other stuff). The problem is that Chameleon is using only
EFI64 since RC4; the patch only does the switch between EFI 32 & 64 according to the cpu architecture.
The issue was accepted so, it's just a matter of time for this to be fixed on the trunk.
If everything is working fine, you should be getting the uuid from bios dmi, the real one that any OS
installed on that machine will see.

That discussion I had completely ignored, my mistake  :(
---
Perfect, NOW i understand.  Your chazileon works well, so also clean cut, specially for this issue.

Still about my branch; be careful because there are other important changes, mainly on file loading.
Will add some documentation this night for sure.. only needs clean up.

I hoped in this, some things aren't clear about all your changes ;)

Hey.. and Thanks for trying the stuff and reporting :)
Besides my own tests, your's is the first feedback i get on this issue and not on purpose, from a 32 bit processor,
that i don't own. To test this i need to use -legacy kernel flag on my Pentium D 925.

See you around...

You're welcome. With your rev the correct uuid automatically is shown, not with other or trunk, but now i understand why ;)

I tested chazileon on my other desktop (64) and the uuid is shown correctly, so it works really good, at least for me. I hope that the patch will be to add in trunk very early..

And i wait your new documentation about the changes of your branche  8)
Title: Re: SystemId
Post by: smith@@ on August 21, 2010, 01:23:38 AM
Azi, in cleancut about changes i read this:
   - Removed -x32 option, use arch=i386 instead

but in boothelp i read instead this:
 32 (i386 arch)

Both?

Also, about changes of chazileon, i see new "stuff" during the chameleon loading.  But i don't see nothing in changes. Like for example tha patch for efi32

Thanks ;)


...Other 2 things:  can you add back the f flag to both chazileon and clean? And update the boothelp.txt of both?
Title: Re: SystemId
Post by: smith@@ on August 21, 2010, 12:14:49 PM
Thanks Azi, for fixing the boothelp.txt finally ;)

PM..
Title: Re: SystemId
Post by: Azimutz on August 22, 2010, 03:44:41 AM
Smith@@,
i'll get back here as soon as possible... will update this post if you don't post in between :)

EDIT: man, just lost all the docks i had "almost" ready to commit >:( pissed at my self!!!
Well (grabbing a beer to calm down), i'll just have to start all over again. Maybe it's better this way..
Maybe it's destiny :P could be if i believed in it.

Smith, the BootHelp.txt has always been up to date on my branch!
This comment:
Quote
- Removed -x32 option, use arch=i386 instead
it's from the trunk (rev 377). Make sure you don't confuse this stuff.
Also, my branch (azimutz) has 2 projects, CleanCut and Chazileon.
CleanCut is meant to commit some patches, the ones i think are most useful for Chameleon,
that work properly for everyone and keep it as close as possible to the trunk.
Chazileon is a copy of my work folder as it is at the moment, the booter i use.
Same stuff but with more patches, experiments, comments, style edits, etc, etc, etc... but will be gone soon...
Keep an eye on the repo ;)
Title: Re: SystemId
Post by: smith@@ on August 22, 2010, 02:48:18 PM
Quote
EDIT: man, just lost all the docks i had "almost" ready to commit  pissed at my self!!!

AHAHAHAH     :lol: 

Quote
Well (grabbing a beer to calm down), i'll just have to start all over again. Maybe it's better this way..
Maybe it's destiny  could be if i believed in it.

Great man!

Quote
Smith, the BootHelp.txt has always been up to date on my branch!
 Removed -x32 option, use arch=i386 instead

This is my mistake, again, i war referring to CHANGES.txt, not boothelp.txt, sorry for mistake. In fact also now in that file there is still that string as in trunk obviously
BTW it's ok I see what you want say me;)  Too many hot here, really too many hot, i'm crazing :(

Quote
CleanCut is meant to commit some patches, the ones i think are most useful for Chameleon,
that work properly for everyone and keep it as close as possible to the trunk.
Chazileon is a copy of my work folder as it is at the moment, the booter i use.
Same stuff but with more patches, experiments, comments, style edits, etc, etc, etc... but will be gone soon...

I know I know, hence you confirm that clean cut soon will take with it most of the stuff of chazileon until this last 'disappear'. Right?

Quote
Same stuff but with more patches, experiments, comments, style edits, etc, etc, etc

I like it. Listen, for testing, can you try to add these two patch: the usblegacyoff from meklort boot (really work well that patch) and the code to patch to fly atom processors http://forum.voodooprojects.org/index.php/topic,1153.0.html

I mean essentially also to this part
From meklort branch:
Code: [Select]
1        Fixed lapic_init patch. Fixed _cpuid_set_info patch to work on the 10.6.0 / 10.6.1 kernel (patches cpumodel)
2 - Added USB Legacy Off patch. Modified to run immediately *before* the kernel is executed, that
3   way no files need to be loaded after the usb device is reset.
4 - Backup original dsdt to /dsdt/originaldsdt in the IORegistery
5 - Added kernel patcher, removes the CPUID check panic in the kernel. Forces _cpuid_set_info to
6   return Penryn / cpuid model 23

Sorry for English my friend ;)
Title: Re: SystemId
Post by: Azimutz on August 23, 2010, 06:26:41 PM
Hi Smith@@,

don't worry about English, i get it.. if i don't understand something i'll ask :)
Well, added some literature to CleanCut, still doing other but the main stuff i lost is done.
The CHANGES file you were reading is also the trunk one; that one will always reflect the trunk changes.
My changes and docs will be on "doc-azi" folder, to avoid confusions.

I   know I know, hence you confirm that clean cut soon will take with it   most of the stuff of chazileon until this last 'disappear'. Right?
yeah, something like that :) but there will always be a CleanCut, at least for now. Not sure about the future..

Listen, for testing, can you try to add these two patch...

1 - Fixed lapic_init patch. Fixed _cpuid_set_info patch to work on the 10.6.0 / 10.6.1 kernel (patches cpumodel)
2 - Added USB Legacy Off patch. Modified to run immediately *before* the kernel is executed,
     that way no files need to be loaded after the usb device is reset.
4 - Backup original dsdt to /dsdt/originaldsdt in the IORegistery
5 - Added kernel patcher, removes the CPUID check panic in the kernel.
     Forces _cpuid_set_info to return Penryn / cpuid model 23
USBLegacyOff is already on the trunk so, it's also on my branch too.
The others are on Chazileon (Chazi), except 4. You need to use PatchKernel=y to activate the kernel patching.
Meklort added new stuff to his branch recently related to this; i think kernel patcher is already working, judging by
his comments; still didn't had time to check it out. Will do asap ;)

Take a look at CleanCut docs, see if that helps. Need to finish FileLoad.txt to go with CHANGES.
See ya later...

p.s.: edited to correct kernel patcher key.
Title: Re: SystemId
Post by: smith@@ on August 23, 2010, 07:04:37 PM
ahahaha ok my friend, i 'm officially losting  :lol:

BTW, some caveats:

Quote
USBLegacyOff is already on the trunk so, it's also on my branch too.

Yep ;)   because also for this i hadn't seen trace in trunk's changes, but if you says that it is there anyway is there;)

Quote
Fixed lapic_init patch. Fixed _cpuid_set_info patch to work on the 10.6.0 / 10.6.1 kernel (patches cpumodel)

Can you say me if this patch works also with 10.6.3/4 and automatically for next? I think that this can be important I ask you this because maybe i can buy a hp lappy with core i7 and i wouldn't to use directly a pathced kernel. The result is the same, i know, but.. .

Quote
Added kernel patcher, removes the CPUID check panic in the kernel.
     Forces _cpuid_set_info to return Penryn / cpuid model 23

I'm a bit confuse on this. Can you show me some use example of this patch?

Also, for atom and their patching on fly?

Last:
Quote
KernelPatcher=y

This key is for patch #1, is for #5 ?

Sorry for these MANY questions, but this is the single way to clarify my ideas and not only my ;)

See ya my friend


Title: Re: SystemId
Post by: Azimutz on August 23, 2010, 08:58:32 PM
Check the BootHelp.txt, USBLegacyOff key it's there. (link (http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/trunk/doc/BootHelp.txt#L82))

Quote
Can you say me if this patch works also with 10.6.3/4 and automatically   for next? I think that this can be important I ask you this because   maybe i can buy a hp lappy with core i7 and i wouldn't to use directly a   pathced kernel. The result is the same, i know, but.. .
Not sure if it will always work.. Mek is the right person to answer that. I remember reading something about that on the topic!?

Quote
Forces _cpuid_set_info to return Penryn / cpuid model 23
This is the cpu model returned for an Atom processor.
The patch for cpu id works like this: if it's an Atom, impersonate Penryn cpu; if it's other cpu, remove just the unknown cpu panic; if it's a supported cpu, don't patch.

The key anables all, patch_commpage_stuff, patch_lapic_init and patch_cpuid_set_info.

Hey, what do you mean with this?
Quote
i 'm officially losting
:)
Title: Re: SystemId
Post by: smith@@ on August 23, 2010, 09:12:20 PM
Quote
Check the BootHelp.txt, USBLegacyOff key it's there.

D'oh! Strange, i'm searching this and never i've see it, btw thanks..

Quote
Not sure if it will always work.. Mek is the right person to answer that. I remember reading something about that on the topic!?

Good question, i'll try to ask him ;)


Quote
This is the cpu model returned for an Atom processor.
The patch for cpu id works like this: if it's an Atom, impersonate Penryn cpu; if it's other cpu, remove just the unknown cpu panic; if it's a supported cpu, don't patch.

The key anables all, patch_commpage_stuff, patch_lapic_init and patch_cpuid_set_info.

Amazing, hence with that key on yes, i can to forget to use a patched kernel for my atom,, amazing ;)
Btw, i think that now i will to use chazileon on my little msi, and not only here. Chazileon instead cleancut  :o

Only doubt now is on meklort patch by as already written, i will to ask him..

Quote
Hey, what do you mean with this?

Oh, nothing of particualr, simply i'm losing, losting in all these options, txt file, help file, etc...  It is a way of saying ironic, joke  :lol:

;)
Title: Re: SystemId
Post by: Azimutz on August 23, 2010, 11:12:00 PM
aah, lost in file confusion :) yeah, i know the feeling :P

Yep, with Chazileon you can use Vanilla kernel on the Atom. And i can boot vanilla kernel too if i use the -legacy flag ;D
I only added PatchKernel=y/n to be able to test patched kernel, i need to use one to boot with 64 Bit Mode enabled
or x86_64 kernel.
I'm thinking of adding the kernel patcher to CleanCut; in fact, the only thing i will keep out (related to patches) is the
AutoResolution, since it doesn't work properly for everyone. Anyway, i have the feeling this will end up on the trunk!?

Still about this:
Quote
Can you say me if this patch works also with 10.6.3/4 and automatically for next?
the best is really ask the man; i took a look at the topic and there's no clue.
What i read is about other stuff or was on another place i can't remember now.. maybe on his blog, yeah!?


p.s.: edited to correct kernel patcher key.
Title: Re: SystemId
Post by: meklort on August 28, 2010, 02:27:00 AM
I'm thinking of adding the kernel patcher to CleanCut; in fact, the only thing i will keep out (related to patches) is the
AutoResolution, since it doesn't work properly for everyone. Anyway, i have the feeling this will end up on the trunk!?

Still about this:
Quote
Can you say me if this patch works also with 10.6.3/4 and automatically for next?
the best is really ask the man; i took a look at the topic and there's no clue.
What i read is about other stuff or was on another place i can't remember now.. maybe on his blog, yeah!?

As far as I know, the kernel patcher will never be added to trunk. Anyways, I've been rewriting it a lot to be much cleaner, 64bit support, making it easier for others to write patches, and to changing it to a module.

The comment about the kernel_patcher and 10.6.0/1 is that is used to only work on the 10.6.2, 10.6.3, and 10.6.4 kernels, since that commit it works on all (vanilla) kernels.

As far as it fixing thing for the i7, I have no clue, it really depends on what needs fixing (I'm sure patches could be written for it though).

As far as the resolution code, it needs some cleanup / to be rewritten some, it really isn't something that should be in trunk at the moment.
Title: Re: SystemId
Post by: Azimutz on August 28, 2010, 04:29:53 AM
Hi Meklort,

thanks for the comments...

Quote
As far as I know, the kernel patcher will never be added to trunk. Anyways, I've been rewriting it a lot to be much cleaner, 64bit support, making it easier for others to write patches, and to changing it to a module.
Well, that was/is my main feeling and if you say so... need a reason to comment. Anyways... :)
I've been keeping an eye on the latest developments on your branch... nice stuff!! Need some clarification...
Will continue talking about this stuff on the other topic, about porting your patches;
just finished spamming a topic, don't want to start on another :P

Quote
The comment about the kernel_patcher and 10.6.0/1 is that is used to only work on the 10.6.2, 10.6.3, and 10.6.4 kernels, since that commit it works on all (vanilla) kernels.
yep... but the question we were talking about is, if it will work for future kernels, without code maintenance?
This can be a major reason for not adding the patch to the trunk!

Quote
As far as the resolution code, it needs some cleanup / to be rewritten some, it really isn't something that should be in trunk at the moment.
The AutoResolution code i mentioned is the one on the branch with the same name. This would be a great Chameleon addition, if it worked properly for everyone.

See ya later...
Title: Re: SystemId
Post by: meklort on August 28, 2010, 05:20:55 AM
Will continue talking about this stuff on the other topic, about porting your patches;
just finished spamming a topic, don't want to start on another :P
You said that before and it never happened...

yep... but the question we were talking about is, if it will work for future kernels, without code maintenance?
This can be a major reason for not adding the patch to the trunk!

It's depended on the kernel. If apple goes and rewrite the cpuid_set_info function, or even just renames it, the current version will break. That isn't so say it can't be fixed easily, it just depends on what Apple changes. Fortunately Apple doesn't seem to care that much. Also fortunately is that I am a registered developer with apple and I do get the prerelease software, so I can often fix the bootloader before the next update is out.
Title: Re: SystemId
Post by: Azimutz on August 30, 2010, 10:46:07 PM
It's depended on the kernel...
As i thought; i have the feeling i read a similar answer from you but can't remember were.
Well Mek, that solution maybe enough for a spin-off booter, but for Chameleon..?!We'll see; today this (kernel patcher) is mainly a solution for legacy or unsupported cpu's... in the future, who knows how many "legacy/unsupported" cpu's will exist that can benefit with this? not to mention stuff other than the kernel patcher ;)
Edit: bs! And irrelevant with modules.

You said that before and it never happened...
yeah, you're right and i'm sorry for that. But, stay assured that is just lack of time and also a bit of waiting for the right moment (priorities). I need/ed to gather some knowledge, otherwise i'll be just another noob asking you questions!
And i've been following your work steady; tried the kernel patcher module a couple of days ago and works fine for me :)
Just need some time alone with my branch and i'll get to you on that topic!

Stay safe.
Title: Re: SystemId
Post by: NetBoot on December 31, 2010, 10:29:27 PM
Sorry for bring up an old thread..  If in the future I need to start a new thread, I will.

I'm having an issue getting the Hardware UUID to update.  Did this get patch yet in the trunk?

I updated the svn checkout I have and I'm on build 698.  But still not getting UUID to change.

If I can get a diff patch that would be great.  If the patch updated on the trunk.  Then, it might be the nawcom 10.5.0 kernel I'm using.  Also, I'm wondering it I still need FakeSMC loaded and if I can remove it.

Any tips or suggestions are welcome

Net....
Title: Re: SystemId
Post by: Gringo Vermelho on January 01, 2011, 03:45:32 AM
Please explain in more detail because I don't understand what your problem is, what do you mean "getting the hardware UUID to update", it should not update, it should stay the same.

If you want to know how the hardware UUID is generated, read this:
http://www.insanelymac.com/forum/index.php?showtopic=201902&st=20&p=1359776&#entry1359776
Read further into the thread for more info.

Yes, you still need fakesmc.kext like everybody else.
Title: Re: SystemId
Post by: NetBoot on January 02, 2011, 02:05:07 AM
Sorry about the confusion.

I've read that post and I have to say I'm more confused now after reading it.

What I mean to say is how do I change the System Profile Hardware UUID to 00000000-0000-1000-8000-<MyMacAddress>

My understanding it Chameleon boot loader gets my UUID from my PC BIOS and uuidgen it to 44454c4-4a00-1036-8052-<etc>

But in my System Profile it's completely different.

Then reading the link you provided.  The System ID is not the Hardware ID.  So, in saying that, the Hardware ID gets generated by the System ID, right?

Question is how can I get my Hardware ID to use my Mac Address as the Hardware ID?  Or is that even possible?

After searching the net, I don't need to use PlatformUUID.kext?

Chameleon version used:  Chameleon v2.0-RC5 r698 from SVN
Nawcom 10.5.0 kernel

Net....
Title: Re: SystemId
Post by: Azimutz on January 02, 2011, 02:43:30 PM
NetBoot,
forget that "00000000-0000-1000-8000-<MyMacAddress>" stuff; that's obsolete!

Chameleon gets the real uuid from dmi bios. If that fails, a default uuid is used. What happens next is that the real uuid is converted to a new one, as Gringo already pointed you to the explanation. You can still check the real uuid to see if it's correct:
- it's posted by Chameleon while booting with -v; you can also check this same info from the "new" booter log with bdmesg tool.
- can also be checked on ioreg under "IODeviceTree:/efi/platform/system-id".

As you mentioned, the Legacy kernel also has a generic uuid, but that is only used if no uuid is already published by the booter.

If all this fails, then you can use the SystemId key, but use the real uuid, not the MacAddress.

Hope this helps ;)
Title: Re: SystemId
Post by: NetBoot on January 03, 2011, 02:28:20 AM
Thank you!
Title: Re: SystemId
Post by: Azimutz on January 03, 2011, 03:28:00 PM
No problem :)

One more thing; system-id, platform uuid or hardware uuid are exactly the same thing, just different names.
And if this stuff is working properly you don't need PlatformUUID.kext anymore.
Title: Re: SystemId
Post by: Slice on January 07, 2011, 05:32:59 PM
This is not so obvious. My bdmesg
Code: [Select]
Set SMUUID to 862F78AF-9B36-50AF-B67A-ABBA8C14A528  -- this value from my smbios.plist
CPU is Intel(R) Core(TM)2 Duo CPU     T8300  @ 2.40GHz, family 0x6, model 0x17
Patched DMI Table
Platform CPU Info:
 FSB=200
 MaxSpeed=0
 CurrentSpeed=2394
DMI CPU Info:
 FSB=200
 MaxSpeed=2400
 CurrentSpeed=2400
DMI CPU Info 2:
 Family=bf
 Socket=6
 Cores=2 Enabled=2 Threads=2
Overclocked CPU from 2400MHz to 2400MHz
Found SMBIOS System Information Table 1
Customizing SystemID with : 44454c4c-3900-1031-8053-c8c04f51334a  -- this value from DMI, it is written into /efi/platform...
Nontheless
Code: [Select]
Hardware Overview:

  Model Name: MacBook
  Model Identifier: MacBook4,1
  Processor Name: Intel Core 2 Duo
  Processor Speed: 2,4 GHz
  Number Of Processors: 1
  Total Number Of Cores: 2
  L2 Cache: 3 MB
  Memory: 2 GB
  Bus Speed: 800 MHz
  Boot ROM Version: MB41.006C.B05
  SMC Version (system): 1.30f3
  Serial Number (system): Wxxxxxxxxxxx
  Hardware UUID: 00000000-0000-1000-8000-00xxxxxxxxxx   -- my mac address.

But if I don't use NVRAM then I see different UUID, not same as any of these

I don't understand about EFI32/64.
I have Core2Duo that 64bit capable, but I use 32bit System because of X3100 video. What EFI I have to choose 32 or 64? Both works fine.