Jump to content

Chameleon v2.1 (Main Trunk)

ErmaC

By ErmaC,
in Chameleon

 Share
595 posts in this topic

Recommended Posts

^Andy^
^Andy^
Posted
Posted
The case is not unique to your situation as I have had problem booting 444d after the sequential upgrades, no matter what version of Chameleon I tried–except the old v753. I just happened to have saved it before and by chance got it to boot.

For a while after 444d, I had to resort to XPC or [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url], both of which do a very decent job.

 

I see the trunk build is now up to v800, there is some serious movement in this code now which is very good news.

I'm very impressed with the recent spurt of activity around chameleon development although have to admit I was hoping to see the sandybridge support make it into the trunk build - I guess I have to wait a while longer for that.

Link to comment
Share on other sites
Hugo_bee
Hugo_bee
Posted
Posted
I see the trunk build is now up to v800, there is some serious movement in this code now which is very good news.

I'm very impressed with the recent spurt of activity around chameleon development although have to admit I was hoping to see the sandybridge support make it into the trunk build - I guess I have to wait a while longer for that.

 

 

Agree..but not at all

i'm scared of those tons of uncontrolled injections

 

Restart..dmi..sata..video

no i'm one of those prefer to control and load os withous mess or concatenations of injections.

i mean: if i have a patched bios or a mobo ootb.. I don't need a bootloader newer that alter my acpi.

and..consequent..having strange and unwanted behavior due to merging of good mod (those in bios or dsdt) and generic standars mod (those in a bootloader)..because the second are based on rules..and a lot of system (i.e. Zotac mobo or most laptops) are farther to the standard and from those rules

and when i clean my e/e and leave s/l/e totally vanilla.. Is really strange when i see my snow so different simoly changung the bootloader

 

Really,is iportant to follow upgrades..but i hope that next releases will be made with brain and method, infact actually the chameleon deficients in:

-publishing/man (the rev grows but not the man that is still a poor txt)

-managing of changes (not a standard gpl publication and non easy to read)

-managing of flags (every develop miss a complete package or someone puts it..but is random and due to the vault of the person that is providing it)

 

The amount of brains and the run must be always paired with a good method/documentation..

Link to comment
Share on other sites
cosmo1t
cosmo1t
Posted
Posted
I see the trunk build is now up to v800, there is some serious movement in this code now which is very good news.

I'm very impressed with the recent spurt of activity around chameleon development although have to admit I was hoping to see the sandybridge support make it into the trunk build - I guess I have to wait a while longer for that.

 

 

As there are about 10 branches, what are the required patches for sandy bridge support?

 

As I don't own any ofthat hardware, i won't be able to test..

 

Please provide a diff against the current trunk for sandy bridge support..

 

thanks

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

What is Sandy Bridge support?

cpuid for extended model calculation? You can just add here

							case CPU_MODEL_NEHALEM: 
						case CPU_MODEL_NEHALEM_EX:
						case CPU_MODEL_WESTMERE: 
						case CPU_MODEL_WESTMERE_EX:
							sm_defaults=sm_macpro_core_defaults; 
							break;
...............
				case CPU_MODEL_WESTMERE: // Intel Core i7 LGA1366 (32nm) 6 Core (Gulftown, Westmere-EP, Westmere-WS)
				case CPU_MODEL_WESTMERE_EX: // Intel Core i7 LGA1366 (45nm) 6 Core ???
					return 0x0701; // Core i7

two sandy bridge models: 0x2a and 0x2d.

But about correct FSBFrequency and CPUFrequency the trunk is wrong in many cases, for example, in case of overclock. I proposed other algo in my branch if anyone wants to look.

Link to comment
Share on other sites
asapreta
asapreta
Posted
Posted

yes, I also got lost with this TONS of changes and branches.

Someone could do a 'clean up' and prepare a solid release for the upcoming needs (Oficial Lion Launch / support).

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted

I sync'd sandy bridge support from the valv branch into a chameleon rc5 tree about a week ago once the mainline had lion support. The result has been working nicely for my sandy bridge system (with an extra msr_flex_ratio fix for my gigabyte motherboard).

I could clean it up and post the diffs if nobody else is working on it (andy & valv??)

Link to comment
Share on other sites
Kabyl
Kabyl
Posted
Posted
I sync'd sandy bridge support from the valv branch into a chameleon rc5 tree about a week ago once the mainline had lion support. The result has been working nicely for my sandy bridge system (with an extra msr_flex_ratio fix for my gigabyte motherboard).

I could clean it up and post the diffs if nobody else is working on it (andy & valv??)

Hey bcc9,

 

If you'd like to commit it yourself, I can add you to the project members (write access). If you prefer to post the diffs, that would be nice too.

 

Thanks.

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
If you'd like to commit it yourself, I can add you to the project members (write access). If you prefer to post the diffs, that would be nice too.

Thanks. Even if I was to commit, the diffs should be reviewed first, so here they are. These diffs are against the chameleon rc5 trunk v767.

 

These diffs include sandy bridge support as seen via svn diff -r 702:707 from the valv branch, throwing out:

nvidia changes, amd changes, atom changes, whitespace changes, some added kernel patch support (not applicable to sandy bridge), ssdt changes.

and adding some r665 changes (for conflict resolution & legacy kernel busratio support for sandy bridge)

 

I also added my sandybridge h67 msr_flex_ratio fix, as this was a critical piece for booting osx on my gigabyte sandy bridge motherboard.

 

Diffs and compiled /boot binary attached.

 

Tested on my nvidia chipset laptop and sandy bridge desktop. Tested with 10.6, 10.7 install, 10.7 DP2 install usb drive, with&without 10.7 kernel cache, 32&64 bit modes.

sandybridge_diffs.rc5v767.txt

boot.zip

Link to comment
Share on other sites
ea dd
ea dd
Posted
Posted

"the patch is obsolete for 760 and above." Does it mean just compile latest chameleon and it can boot lion?

also to compile chameleon for lion boot, should i compile it in xcode 4.1 for lion or xcode 4.0.2 for sl?

if its neccessary to compile chameleon in xcode 4.1 for lion, could you upload compiled binaries of latest trunk?

Link to comment
Share on other sites
Kabyl
Kabyl
Posted
Posted
Thanks. Even if I was to commit, the diffs should be reviewed first, so here they are. These diffs are against the chameleon rc5 trunk v767.

 

These diffs include sandy bridge support as seen via svn diff -r 702:707 from the valv branch, throwing out:

nvidia changes, amd changes, atom changes, whitespace changes, some added kernel patch support (not applicable to sandy bridge), ssdt changes.

and adding some r665 changes (for conflict resolution & legacy kernel busratio support for sandy bridge)

 

I also added my sandybridge h67 msr_flex_ratio fix, as this was a critical piece for booting osx on my gigabyte sandy bridge motherboard.

 

Diffs and compiled /boot binary attached.

 

Tested on my nvidia chipset laptop and sandy bridge desktop. Tested with 10.6, 10.7 install, 10.7 DP2 install usb drive, with&without 10.7 kernel cache, 32&64 bit modes.

Seeing how long valv's thread is and knowing how extensively his code was tested, and since I can't test this myself, I'm assuming it's safe to apply the patch.

 

The changes in cpu.c should apply fine, but not the SMBIOS ones, since we now have a new code for that, still, it should be easily done in smbios_getters.c

 

Waiting (?) for at least another tester's feedback, and either of us can commit the patch.

 

Regards.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

@bcc9

Look this line

DBG("msr(%d): flex_ratio %08x\n", __LINE__, msr & 0xffffffff);

What did you expected to see here? msr number or line number?

 

And more

-				currcoef = (msr >> 8) & 0xff;
+				bus_ratio_max = (msr >> 8) & 0xff;

From this moment currcoef is not inintialized but used

+						if (currcoef > flex_ratio) {

Link to comment
Share on other sites
Motawa
Motawa
Posted
Posted

i installed the pkg file on a blank HDD. First in MBR an then GUID. But the bootloaer does not load when i restart the pc an choose the HDD in the boot menu.

 

Im running 10.6.7 on a other HDD right now.

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
@bcc9

Look this line

DBG("msr(%d): flex_ratio %08x\n", __LINE__, msr & 0xffffffff);

What did you expected to see here? msr number or line number?

First, that code is in the rc5 mainline, not part of the diffs I posted from the valv branch.

%d is replaced by the line number, and %08x is replaced with the lower 32 bits of the msr variable. So it works as expected from what I can see.

 

Personally I prefer __FUNCTION__ to __LINE__, but I resisted any urge to reorganize or cleanup the code here, in order to keep the patch verifiable.

And more

-				currcoef = (msr >> 8) & 0xff;
+				bus_ratio_max = (msr >> 8) & 0xff;

From this moment currcoef is not inintialized but used

+						if (currcoef > flex_ratio) {

Since I wanted to keep the patch contained, I simply added a:

#define bus_ratio_max currcoef

to reconcile the mainline with the valv branch.

I can see this went to far and added confusion (the variable is in fact initialized in all cases). I can revise the patch with currcoef completely replaced with bus_ratio_max. It would be clearer. Normally I would have done this, in fact I started to, but I stopped in order to keep the patch size down for verifiability.

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
The changes in cpu.c should apply fine, but not the SMBIOS ones, since we now have a new code for that, still, it should be easily done in smbios_getters.c

Ok, I synced up my tree with the latest rc5. (Very nice having working ATI radeon hd injection in the mainline along with everything else).

 

I re-did the smbios patch, mapping sandy bridge to imac12,1 which I in turn added, using a genuine imac12,1 bios rev. that I picked up from an apple store :P

I also replaced currcoef to bus_ratio_max within the scope of nehalem/sandy/et. all.

Lastly I fixed the BCLK verbose() message. For reference, my bdmesg output now looks like:

msr(212): platform_info 60012200
msr(216): flex_ratio 000f0000
Unusable flex ratio detected.  Patched MSR now 000e0000
Sticking with [BCLK: 99Mhz, Bus-Ratio: 340]
CPU: Vendor/Model/ExtModel: 0x756e6547/0x2a/0x2
CPU: Family/ExtFamily:	  0x6/0x0
CPU: MaxCoef/CurrCoef:	  0x0/0x22
CPU: MaxDiv/CurrDiv:		0x0/0x0
CPU: TSCFreq:			   3395MHz
CPU: FSBFreq:			   99MHz
CPU: CPUFreq:			   3395MHz
CPU: NoCores/NoThreads:	 8/16
CPU: Features:			  0x000002ff

Oh, and the current rc5 mainline now has a new SMBIOS.h file that needs to be renamed to smbios.h so that it compiles with case-sensitive filesystems. Not sure who to tell about that...

 

Revised diffs & compiled /boot attached.

sandybridge_diffs.rc5v823.txt

boot.rc5v823.zip

Link to comment
Share on other sites
cosmo1t
cosmo1t
Posted
Posted
Ok, I synced up my tree with the latest rc5. (Very nice having working ATI radeon hd injection in the mainline along with everything else).

 

I re-did the smbios patch, mapping sandy bridge to imac12,1 which I in turn added, using a genuine imac12,1 bios rev. that I picked up from an apple store :)

I also replaced currcoef to bus_ratio_max within the scope of nehalem/sandy/et. all.

Lastly I fixed the BCLK verbose() message. For reference, my bdmesg output now looks like:

msr(212): platform_info 60012200
msr(216): flex_ratio 000f0000
Unusable flex ratio detected.  Patched MSR now 000e0000
Sticking with [BCLK: 99Mhz, Bus-Ratio: 340]
CPU: Vendor/Model/ExtModel: 0x756e6547/0x2a/0x2
CPU: Family/ExtFamily:	  0x6/0x0
CPU: MaxCoef/CurrCoef:	  0x0/0x22
CPU: MaxDiv/CurrDiv:		0x0/0x0
CPU: TSCFreq:			   3395MHz
CPU: FSBFreq:			   99MHz
CPU: CPUFreq:			   3395MHz
CPU: NoCores/NoThreads:	 8/16
CPU: Features:			  0x000002ff

Oh, and the current rc5 mainline now has a new SMBIOS.h file that needs to be renamed to smbios.h so that it compiles with case-sensitive filesystems. Not sure who to tell about that...

 

Revised diffs & compiled /boot attached.

 

 

Thanks, merged to trunk and committed.

Let me know if you've got any more changes to merge/etc..

thanks

cos

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
Thanks, merged to trunk and committed.
Awesome, thanks. Let me know if any problems with it come up that I need to take a look at.
Let me know if you've got any more changes to merge/etc..
I'm sure I could come up with something if you'd like :)
Link to comment
Share on other sites
^Andy^
^Andy^
Posted
Posted

I've got a couple of niggly problems with the latest trunk build. It no longer detects the memory manufacturer and just displays N/A even though the manufacturer (G Skill in this case) is listed in the relevant header file.

 

My only other gripe from the limited testing that I've done so far tonight is that we are rapidly running out of space for a decent theme (I get the bootfile size greater than blah blah error if I used my current theme and try to embed it).

 

Other than those minor issues I can confirm that it works for snow and lion on a sandybridge with ATI support :)

Link to comment
Share on other sites
Regi Yassin
Regi Yassin
Posted
Posted
I've got a couple of niggly problems with the latest trunk build. It no longer detects the memory manufacturer and just displays N/A even though the manufacturer (G Skill in this case) is listed in the relevant header file.

 

My only other gripe from the limited testing that I've done so far tonight is that we are rapidly running out of space for a decent theme (I get the bootfile size greater than blah blah error if I used my current theme and try to embed it).

 

Other than those minor issues I can confirm that it works for snow and lion on a sandybridge with ATI support :)

 

So when the latest build of ur version released, can't wait for too long with it. Hhehe

The minos issues that u said just a cosmetic, right? Its not a big problem then, :D

Link to comment
Share on other sites
^Andy^
^Andy^
Posted
Posted
So when the latest build of ur version released, can't wait for too long with it. Hhehe

The minos issues that u said just a cosmetic, right? Its not a big problem then, :)

 

Regae - there honestly is no need to use my build anymore. Everything appears to be in the current trunk build and other than my moaning above it all appears to be working fine. At least now it can be maintained and supported properly which was something I was never going to be able to do :D

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
I've got a couple of niggly problems with the latest trunk build. It no longer detects the memory manufacturer and just displays N/A even though the manufacturer (G Skill in this case) is listed in the relevant header file.
This was a recent bug in the chameleon mainline that was fixed shortly after the sandy bridge changes were merged. The image I built the other day was from before the fix; sounds like you tested with my image. You need revision >= 828 for the fix.
Link to comment
Share on other sites
^Andy^
^Andy^
Posted
Posted
This was a recent bug in the chameleon mainline that was fixed shortly after the sandy bridge changes were merged. The image I built the other day was from before the fix; sounds like you tested with my image. You need revision >= 828 for the fix.

 

I used tonights build 833

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
I used tonights build 833

Ok, I thought you were referring to the issue 71 memory problem http://forge.voodooprojects.org/p/chameleon/issues/71/#ic328 , I guess you're having a different problem.

 

I just tried r833 and the memory size/speed are reported correctly (but n/a for manufactuer) with my sandy bridge system, whereas no memory information worked in r823. For reference, in r760, the memory was reported (but was the wrong type - ddr2)

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...