Chameleon v2.1 (Main Trunk)

[Azimutz]

Azimutz thank's once more for your explanation and patience. I found these bugs (IMHO) and wanted to report it, that's all nothing more.

Yeah, i get it... just don't go matching a Mac on everything! Many of this SMBIOS stuff are just cosmetics, other are essential to get

functionality, like the Mac model, board-id, etc...

Again, i didn't meant to be rude or offend you just expressing my indignation.

 

I know, i know but what is SystemID feature in Boot.plist for? May be i try to use it in wrong way or it doesn't work?

The key is "SystemId" (lower case "d") and it's to be used in the case that your real uuid is not detected properly;

in that case a default one is used so, the key allows to specify the correct one.

 

Why not? Anyways would be nice to have it working.

I prefer to have the correct info.. don't you? Unless we are not talking about the same...

Don't you prefer to see the info from the modules on your machine?

 

BTW. If i use UseMemDetect=No get correct info in SysProf but if UseMemDetect=Yes get different mem speeds on identical modules (tested with two different pairs of modules in all combinations)

Talk to Kabyl... can't help much on that since i still didn't had time to check his rework properly.

I use MemDetect enabled, no modules stuff on smbios.plist and everything works fine for me.

All i keep on the plist is this:

	
<key>SMproductname</key>
<string>iMac8,1</string>
<key>SMserial</key>
<string>RM629559W87</string>
<key>SMboardmanufacter</key>
<string>Apple Inc.</string>
<key>SMboardproduct</key>
<string>Mac-F227BEC8</string>

and i don't even remember what SMProductname is doing there, since it's the default for my processor...

probably forgot to remove it... getting old for this s..t

All i know is, there are problems with some laptop's mem detection...

 

I need help to get rid of error in SysProf-Diagnostics section

 

After some investigation and studying the SMBIOS Reference Specification, I've an idea to override coresponding SMBIOS (table handle: 0x002B, type: 17 ) Error Information Handle field with 0xFF value (no error), now is 0x002D.

Some people reported this issue. May be adding a patch fix this up: if field1 <> 0xFF check field2 then if field2 = OK then field1:= 0xFF (field1=Error Information Handle, field2=Type)

Same as above... you seem to know more about this than me

 

Anyone having trouble entering flags in the non-GUI...

Check issue 83... Charles Delorean ce moi

Will try to check it; thanks for tracking it back... are you sure about r752?

 

Going for lunch... will take a peek here after...

[bcc9]

Thanks for the patch! applied with a few changes (r1004).

Great, works for me. Hope that puts memory reporting issues to rest for most of us. I'm moving on to my intel GPU issues now

[digital_dreamer]

<snip>

Check issue 83... Charles Delorean ce moi

Will try to check it; thanks for tracking it back... are you sure about r752?

 

Ah! Bingo! That's the symptom.

Now, I'm not saying the problem starts after 752, but just that 752 was the only revision I had on hand to test where the symptom wasn't present.

So, thinking it's between 752 and 877. Wish I could be more specific!

 

Be glad to test anything between 752-877 to narrow it down. Is there a way I can do that? Don't know much about "svn." I only know how to download the latest updates and compile via xcode.

 

MAJ

 

P.S. I see in the svn handbook a way to fetch older snapshots:

svn checkout -r 800
svn update -r 800

 

Is this what I'm looking for and what's the difference between the two?

[Azimutz]

Ah! Bingo! That's the symptom.

Now, I'm not saying the problem starts after 752, but just that 752 was the only revision I had on hand to test where the symptom wasn't present.

So, thinking it's between 752 and 877. Wish I could be more specific!

Ok, that's what i wanted to clear out....

 

Be glad to test anything between 752-877 to narrow it down. Is there a way I can do that? Don't know much about "svn." I only know how to download the latest updates and compile via xcode.

If you can do that, would be a great help. An advice; don't compile via XCode; use Terminal instead.

The xcodeproj file is seriously outdated and using XCode, you won't be able to use the new "make config".

In my opinion, as it is, the xcodeproj file is only useful for those who use XCode's editor to code, instead of another editor.

There's no advantage on using it to build the booter since all it does is call "make", which uses the makefile's in the source code.

"make config" is not mandatory; just cd to the folder in Terminal and do "make"; it will build a default config.

To see what the default config is or to configure an alternate build, use "make config" and follow instructions.

"make clean" cleans the folder for a fresh build

 

P.S. I see in the svn handbook a way to fetch older snapshots:

svn checkout -r 800
svn update -r 800

 

Is this what I'm looking for and what's the difference between the two?

Yeah... "svn checkout -r 800" will checkout r800;

"svn update -r 801" will sync the folder to r801;

"svn update -r 799" will sync the folder to r799; note that this is not the same as "revert";

"update" tries to keep any change you've done to the code; "revert" discards any change you've done.

 

SVN is not that complicated; on Terminal type "svn help" and you'll get a nice overview of the most useful

commands. "svn help [subcommand]" will output help on the specific command. It doesn't replace the book,

but it's a nice way to recall something on the spot.

 

Does this help?

[Bungo]

Yeah, i get it... just don't go matching a Mac on everything! Many of this SMBIOS stuff are just cosmetics, other are essential to get functionality, like the Mac model, board-id, etc...

Again, i didn't meant to be rude or offend you just expressing my indignation.

 

I prefer to have the correct info.. don't you? Unless we are not talking about the same...

Don't you prefer to see the info from the modules on your machine?

Thank you for your help, you're right.

IMHO to many automated features. I need Chameleon Pro version

[blackosx]

Great, works for me. Hope that puts memory reporting issues to rest for most of us. I'm moving on to my intel GPU issues now

As Kabyl previously made a fix to the memory detection code in response to an issue I raised on Voodooprojects' forge, I thought I'd also report the memory detection with the latest trunk build is still working great for me after the recent changes. Good job guys.

[Azimutz]

IMHO to many automated features. I need Chameleon Pro version

This is as Pro as it gets kidding...

Most of the automated stuff has an override/disable/etc key... and if it doesn't, it will.

But that doesn't depend only on me...

[Gringo Vermelho]

Sorry, a little late to the table..

what is SystemID feature in Boot.plist for? May be i try to use it in wrong way or it doesn't work?

No, it works, just not in the way that you expect it to work. *puts on archaeologist hat*

Rekursor announced and explained it in this thread:

http://www.insanelymac.com/forum/index.php...t&p=1359776

Read on until post #60 for some entertaining posts and further explanation of why it works like it does.

 

In Chameleon 2.0 RC5, your Hardware UUID (AKA PlatformUUID) is generated from your System UUID, which is either 1) set by you in /Extra/com.apple.Boot.plist or 2) automatically read from your motherboard's SMBIOS. The two are not and can not be the same.

 

I believe it was Asere who introduced the automatic systemUUID code (and other cool stuff such as reading the PCI Root value from DSDT) in his own Chameleon variant - the release notes elaborate further on how it works:

http://www.insanelymac.com/forum/index.php...t&p=1379601

His code was later added/ported to Chameleon.

 

In short: If you're using RC5, it should only be necessary to use the override in /Extra/com.apple.Boot.plist if Chameleon for some reason can't read the SystemUUID from your motherboard.

 

I believe that *cough* covers it *dusts off cobwebs from self after navigating old InsanelyMac threads*

[jhrfc]

Thanks. Can you confirm the key value syntax needed in boot.plist to override using RC5. The bootloader does read my SystemUUID, but I would like to maintain the same UID i've been using via the injector PlatfromUID.kext for ages. I'm hoping this will ease porting my apps and pref when I migrate from snow lep to Lion under RC5.

Cheers

Jon

[Azimutz]

Gringo, go dust your self off some were else...

i got covered in dust and cobwebs just from taking a quick peek

 

Greetings

[Gringo Vermelho]

lol hi Azi, good to see you back.

Thanks. Can you confirm the key value syntax needed in boot.plist to override using RC5.

Read the post that I linked to above, wherein the very person who coded it is showing you the correct syntax.

The bootloader does read my SystemUUID, but I would like to maintain the same UID i've been using via the injector PlatfromUID.kext for ages.

So you have not read or not understood anything that I've posted....please, go back to the thread I linked to and read posts #22 and #60 and Asere's release post again.

 

If you want the Hardware UUID to stay the same then you cannot use the UUID that you put in PlatformUUID.kext as SystemUUID in your com.apple.Boot.plist.

 

You need to find out if there is a way to disable Chameleon reading the SystemUUID (via flag in com.apple.Boot.plist) so that you can keep using your PlatformUUID.kext. Asere mentions a flag in his release notes but I'm not sure that it will still work. Also you might be able to find something here: http://forge.voodooprojects.org/p/chameleo...86/boot2/boot.h

[digital_dreamer]

<snip>

Does this help?

 

Yeah, you betcha. Thanks!

I was getting into a issue where the revision # wouldn't change even after a make clean, so I resorted to dumping the trunk on my system and starting over. I assume the binary may have been the correct revision, but it was disconcerting doing a string search on the binary and finding a different revision number. Is there a trick around this?

 

Okay, I'm using the binary search method - half forward, half back - to search for the beginning of this non-GUI bug in 7 tries or less. However, I wasn't making progress and now realize that r900 works okay. So, I be starting my search again with 900-1000. Don't have time right now. Hope to zero in on it sometime tomorrow.

 

Gotta report another bug!

Installed on a RAID setup (striped) Lion DP4. It appears all is there as far as system files and bootloader support is concerned. However, Chameleon doesn't read the RAID correctly at the screen selection.

My RAID is called "MacRAID" and the helper partitions are the default names, "Boot OS X". But, the Chameleon (r1002) screen shows "MacRAID 1" and MacRAID 2" instead. Of course, the boot process is very, very short and nothing gets loaded.

Wrong info. Chameleon is definitely loading the 10.7 kernel, mkext file, and DSDT.aml. So, I don't know what's going on here, yet. It's the old "can’t perform kext scan/Unable to find driver for this platform" KP.

Doing more research.

 

best of wishes,

MAJ

[digital_dreamer]

Thanks to some nice work by marliwahoo and Crna Brada, they have been able to boot the Lion RAID by putting the full S/L/E boot cache in /Extra.

 

I can confirm this. Using my HackInstaller script I can use the Combo boot cache option to build both /Extra and /System cache into /Extra.

 

kind regards,

MAJ

[Azimutz]

Yeah, you betcha. Thanks!

I was getting into a issue where the revision # wouldn't change even after a make clean, so I resorted to dumping the trunk on my system and starting over. I assume the binary may have been the correct revision, but it was disconcerting doing a string search on the binary and finding a different revision number. Is there a trick around this?J

Sorry but i'm so tired right now that i can relate that stuff to any svn practice; i remember it happened some times to me in the past and i recall getting to a conclusion,

but can't really remember it now getting old... well, not old, used

These days i only resort to Terminal (when it comes to svn), if Cornerstone doesn't have a way to do it.

 

Okay, I'm using the binary search method - half forward, half back - to search for the beginning of this non-GUI bug in 7 tries or less. However, I wasn't making progress and now realize that r900 works okay. So, I be starting my search again with 900-1000. Don't have time right now. Hope to zero in on it sometime tomorrow.

Take your time; i'll get to it asap; still have a lot of lose ends to tie up before i can get to it...

 

Gotta report another bug!

Installed on a RAID setup (striped) Lion DP4. It appears all is there as far as system files and bootloader support is concerned. However, Chameleon doesn't read the RAID correctly at the screen selection.

My RAID is called "MacRAID" and the helper partitions are the default names, "Boot OS X". But, the Chameleon (r1002) screen shows "MacRAID 1" and MacRAID 2" instead. Of course, the boot process is very, very short and nothing gets loaded.

Wrong info. Chameleon is definitely loading the 10.7 kernel, mkext file, and DSDT.aml. So, I don't know what's going on here, yet. It's the old "can’t perform kext scan/Unable to find driver for this platform" KP.

I see you found a ugly workaround

Can't help with RAID atm; probably next month; thinking of buying another 500 GB Caviar Green to setup one of those.

Same applies to Lion; have to wait for kernel sources to know whether i'll be able to install it on the desktop or not.

Still got no time to try hackintosh the brand new Core i5 lappy

 

Do me a favor.. if you get to any conclusion about the boot prompt bug, pm me here or on VoodooForums;

i will not be posting in the next couple of day or so; need to get focused on the booter; i'l pm you when if get to the prompt stuff before you do...

 

Thanks... and stay safe.

[Azimutz]

I was getting into a issue where the revision # wouldn't change even after a make clean, so I resorted to dumping the trunk on my system and starting over. I assume the binary may have been the correct revision, but it was disconcerting doing a string search on the binary and finding a different revision number. Is there a trick around this?

Ok, i'm thinking a bit clearer now

First, you don't need to do a string search to verify the rev; just open the "revision" file on the root of the

working copy (wc); that file is created/updated every time you do make, with the info stored by svn

on it's hidden folders and read to "stamp" the rev on the booter.

The reason why the file is not updated in some situations, is still a mystery to me?! Usually doing

svn update -r X

on the wc, being X the revision at which the wc is supposed to be at, solves the problem.

 

Besides that, updating the wc after committing changes to the repo is usually mandatory;

meaning, you make changes to your wc, commit them to the repo and then do "svn update"

on the wc to update it to the repo rev, else it will stay stamped at a previous rev, even though the

code is indeed up to date

 

ttyl...

 

 

p.s.: completely forgot about "make clean"; when everything else fails, do it, before compiling.

Edited June 30, 2011 by Azimutz

[bmas]

Why when I boot with UseKernelCache=yes in Lion DP4, my kexts in EFI partition are not loaded .. ? Is this problem just with my system .. ?

[meklort]

Why when I boot with UseKernelCache=yes in Lion DP4, my kexts in EFI partition are not loaded .. ? Is this problem just with my system .. ?

 

XNU doesn't support loading both prelinked kernel extensions and kernel extensions loaded by the bootloader. In order to support that, XNU must be patched.

[bmas]

XNU doesn't support loading both prelinked kernel extensions and kernel extensions loaded by the bootloader. In order to support that, XNU must be patched.

So if use UseKernelCache=yes, I have to copy the kexts from EFI to S/L/E to be everything fine ..

In fact .. what is the advantage of UseKernelCache, exept that the system not scan every kext on every boot ..

[blackosx]

So if use UseKernelCache=yes, I have to copy the kexts from EFI to S/L/E to be everything fine ..

Yes

 

In fact .. what is the advantage of UseKernelCache, exept that the system not scan every kext on every boot ..

The boot time will be faster. How much depends on your hardware.

[bmas]

Thanks @blackosx & @STLVNUB, I`ll try these methods.

I prefer EFI partition, because not to wary about updates and ect .. or some delete/changes by mistake if somebody else is on the PC ..

[dantesieg]

Will there be SSDT tables loading support?

[Bungo]

Sorry, a little late to the table..

In Chameleon 2.0 RC5, your Hardware UUID (AKA PlatformUUID) is generated from your System UUID, which is either 1) set by you in /Extra/com.apple.Boot.plist or 2) automatically read from your motherboard's SMBIOS. The two are not and can not be the same.

Ok. I need to change Hardware UUID. How can I do it using Chameleon? XPC do it correctly.

[Azimutz]

Ok. I need to change Hardware UUID. How can I do it using Chameleon? XPC do it correctly.

I am very very tempted to tell you "Well, then use XPC!", but...

 

*Azi takes a deep breath, counts to ten and looks at the code very carefully to explain it to Bungo...*

 

So, to understand what the booter does, we need to look at fake_efi.c and the getSystemID() function:

// unable to determine UUID for host. Error: 35 fix
const char *sysId = getStringForKey(kSystemIDKey, &bootInfo->bootConfig);
EFI_CHAR8*  ret = getUUIDFromString(sysId);

getStringForKey() looks for SystemId="some uuid" on Boot.plist and stores it on sysId;

getUUIDFromString() takes the data stored on sysId (a string of characters), converts it into EFI_CHAR8 and stores it in ret;

if (!sysId || !ret) // try bios dmi info UUID extraction
{
ret = getSmbiosUUID();
sysId = 0;
}

if sysId or ret are null/empty, getSmbiosUUID() function is used to get the real Hardware UUID from BIOS DMI;

if the uuid is found it's stored in ret; sysId is set to 0;

if (!ret) // no bios dmi UUID available, set a fixed value for system-id
ret = getUUIDFromString((sysId = (const char*) SYSTEM_ID));

if ret is null/empty (getSmbiosUUID() was unable to retrieve uuid from dmi), getUUIDFromString() converts the default uuid

defined in SYSTEM_ID and stores it in ret;

// apply a nice formatting to the displayed output
verbose("Customizing SystemID with : %s\n", getStringFromUUID(ret));
return ret;

finally, the data stored in ret is converted back to a string of characters by getStringFromUUID() function,

printed to screen at boot time by verbose() function

and the value stored in ret is returned to be used.

 

Does this clear things for you?... (rhetorical question)

 

Now, i don't know what "XPC do it correctly." means, because i don't use it in a long time; can you explain,

like me and Gringo did to you, what's that you think XPC does so correctly?!

[kocoman]

Can anyone tell me where a reply about "how fakesmc.kext works" was in this forum? (It had a CODE wrapper IIRC) I remember seeing it, but then after I reboot I could not find the thread anymore

 

Also I tried the 899 build here, but it still hangs at the black screen, i.e.: just stuck at "executing fsck_hfs"..., is there any way to debug that?

[ApexDE]

I still use a very old, self patched, selfcompiled Chameleon Version (RC3). Is it OK to just replace the boot file with the RC5 Version?

I remember i had to "install" boot0 and boot1h when i switched to Chameleon.