Jump to content

Chameleon RC5 mode with mem detection enabled and automatic P-States & C-States generation for native power managment

kozlek

By kozlek,
in Chameleon

 Share
1,214 posts in this topic

Recommended Posts

Azimutz
Azimutz
Posted
Posted

Kup, no problemo :)

 

Makkernel2, that usb problem is totally possible! I know a guy that had a problem like that, because of a forgotten usb stick plugged

into the one of the back panel connectors. On his case, even other usb sticks would fail; think he was also using a usb hub!?

Some boards/bios do have usb power management bugs, at least when dealing with OSx86.

Link to comment
Share on other sites
Jingu
Jingu
Posted
Posted

@Mitch_de,

 

WORKS!! You were right. For Azimutz' rev 354, using the flag 32 only sets 32 bit. It's a little non-standard. I never would have guessed. Thanks.

 

@Azimutz,

 

My com.apple.Boot.plist is in /Extra. The other one in L/P/SystemConfiguration is completely vanilla. Got your message about using the latest files in the trunk, not to use someone's particular branch. Thanks.

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted

Ok Jingu, didn't crossed my mind you were using any of my branch. It's not recommended for now! There's to many info missing.

Anyway, this was already helpful; i was drifting away from the CHANGES file :wacko:

 

Dood, if you use this path to checkout the trunk: http://forge.voodooprojects.org/svn/chameleon/trunk

you will always & only get the latest trunk revision. No need to specify the rev, unless you want to update/revert to a specific rev.

Maybe i'm not getting your point here?

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted

Rednous,

as long as it's for testing it's fine with me :( i'm not promoting another bootloader here!

Just be careful.. for instance, except for the obvious files like /kernel, /System/Library/CoreServices/SystemVersion.plist, system caches, etc...,

no other file is loaded from selected volume (paths started with / ).

To put it simple, when installed to a usb stick, this booter will not search for any files on the Extra folder of the volume were the system is installed!

Or in other words, the booter will only check the Extra folder on the booter volume (paths started with bt(0,0) ), the usb stick.

 

Instead of searching selected volume, we get "hands off" search for "override" Boot.plist, dsdt.aml, smbios.plist and drivers,

on bt(0,0)/Extra and bt(0,0)/Extra/OSspecificFolder (e.g. 10.4 or 10.5...)... aah, and on Ramdisks too -_-

There are also changes on some keys.. config=/boot.plist works again; kext=/pathtofolder/ is new, to override default Extra extensions; -legacy also added; only one key/value for PCI-Root-UID, PciRoot=x as before; no -x32/arch=i386, instead 32 sets i386 arch and 64 overrides 32 or -legacy flags and sets x86_64 arch. It's mostly this... the rest it's just (and will always be) trunk.

 

So, be sure you don't get caught of guard. Will have CHANGES file updated by the morning with all the info.

And thanks for trying it :wacko:

Stay safe.

 

p.s.: forgot to mention setting EFI32 values for 32 bit only processors. That should be useful for some.

Link to comment
Share on other sites
d00d
d00d
Posted
Posted
Dood, if you use this path to checkout the trunk: http://forge.voodooprojects.org/svn/chameleon/trunk

you will always & only get the latest trunk revision. No need to specify the rev, unless you want to update/revert to a specific rev.

Maybe i'm not getting your point here?

The latest trunk version is 352, but when compiled it boots as r361, which is a branch;

 

[mac05:mac05/Chameleon/c2rc5] me% svn co http://forge.voodooprojects.org/svn/chameleon/trunk

...

Checked out revision 361.

[mac05:mac05/Chameleon/c2rc5] me% cd trunk

[mac05:Chameleon/c2rc5/trunk] me% make

...

[mac05:Chameleon/c2rc5/trunk] me% cat revision

361

 

It would be nice if the trunk/revision file was accurate to what the current version of trunk is, and not what the latest branch version is.

Link to comment
Share on other sites
scrax
scrax
Posted
Posted
trunk is 352, not 361. 361 is azimutz's branch ;)

As Azimut sad 361 is the repository revision. From that revision I've compiled the TRUNK.

It boot as 361 if you compile it, because that is the LAST revision in the repo, doesn't matter if the last change is only in a branch or somewhere else...

 

;)

 

this is what I use to update my install (if boot1h and boot0 are unchanged):

 

svn co -r HEAD http://forge.voodooprojects.org/svn/chameleon; cd  /Users/scrax/chameleon/trunk; make clean; make; cp /Users/scrax/chameleon/trunk/sym/i386/boot /

 

make works after installing Xtools.

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted (edited)

Dood, i get what you mean now. You guys are right; but it's just how it works!

Update the working copy of the trunk to rev 352 (for instance)

svn up -r 352

or checkout the rev directly

svn co -r 352 http://forge.voodooprojects.org/svn/chameleon/trunk

Same stuff happens here either on cli or client.

Edited by Azimutz
Link to comment
Share on other sites
aikidoka25
aikidoka25
Posted
Posted

good day

 

i added teateam auto kernel patching into boot2/boot.c

			verbose("Loading kernel %s\n", bootFileSpec);
		ret = LoadThinFatFile(bootFileSpec, &binary);
		if (ret <= 0 && archCpuType == CPU_TYPE_X86_64)
		{
		  archCpuType = CPU_TYPE_I386;
		  ret = LoadThinFatFile(bootFileSpec, &binary);				
		}
		// these 2 lines are added to allow vanilla kernel boot with Atom CPU
		verbose("Patching kernel %s\n", bootFileSpec);
		patch_kernel(binary);

	} while (0);

	clearActivityIndicator();

 

patch.zip

 

recompiled andi tried this with HP Mini 311, and here are the results

- native PM works

- memory detection doesn't work (see attached image below)

- the unit cannot reboot after sleep (no problem if PCEFI 10.6 is used with DSDT patch)

 

any idea what went wrong?

 

please let me know if more information is required, i could furnish them here.

 

cheers!

SysProMem.tiff

Link to comment
Share on other sites
makkernel2
makkernel2
Posted
Posted
As Azimut sad 361 is the repository revision. From that revision I've compiled the TRUNK.

It boot as 361 if you compile it, because that is the LAST revision in the repo, doesn't matter if the last change is only in a branch or somewhere else...

 

;)

 

 

make works after installing Xtools.

 

 

branches -- xx hours xx minutes -- 361 azimutz: BootHelp.txt; fix kExtensionsKey key name. These names are absolutely not mandatory! boot.h; clean remains.

 

trunk xx days xx hours 352 mozodojo: Changed vram size detection (Fermi support, dirty fix removed). Added video rom version injection. Tested, working. Need more testers with different hardware. ......

 

last branches 361

last trunk 352

 

:wacko:

Link to comment
Share on other sites
scrax
scrax
Posted
Posted

It seems that we are getting philosophic but:

 

The revisions are relative to the repository, so 361 or 352 are either revisions of the Chameleon Repository, Trunk and Branches are subfolder of the repo and so there is no need to differentiate twice one or the other.

 

If I check svn and then compile the trunk I can see in terminal what repository's revision I'm compiling and that is the revision number i'll report in a discussion.

For me is not logical to check the history log to see when the trunk or a branch was edited just to know how to call the last build...

Also at boot Chameleon show the Repository revision number, and so calling r352 the last build of the trunk in the repository could lead to confusion easier.

 

 

So I mean this:

 

last revision 361

last branches edited till r361

last trunk edited till r352

 

sorry for the terrible english...

Link to comment
Share on other sites
rednous
rednous
Posted
Posted
Rednous,

as long as it's for testing it's fine with me :( i'm not promoting another bootloader here!

Just be careful.. for instance, except for the obvious files like /kernel, /System/Library/CoreServices/SystemVersion.plist, system caches, etc...,

no other file is loaded from selected volume (paths started with / ).

To put it simple, when installed to a usb stick, this booter will not search for any files on the Extra folder of the volume were the system is installed!

Or in other words, the booter will only check the Extra folder on the booter volume (paths started with bt(0,0) ), the usb stick.

 

Instead of searching selected volume, we get "hands off" search for "override" Boot.plist, dsdt.aml, smbios.plist and drivers,

on bt(0,0)/Extra and bt(0,0)/Extra/OSspecificFolder (e.g. 10.4 or 10.5...)... aah, and on Ramdisks too :)

There are also changes on some keys.. config=/boot.plist works again; kext=/pathtofolder/ is new, to override default Extra extensions; -legacy also added; only one key/value for PCI-Root-UID, PciRoot=x as before; no -x32/arch=i386, instead 32 sets i386 arch and 64 overrides 32 or -legacy flags and sets x86_64 arch. It's mostly this... the rest it's just (and will always be) trunk.

 

So, be sure you don't get caught of guard. Will have CHANGES file updated by the morning with all the info.

And thanks for trying it :)

Stay safe.

 

p.s.: forgot to mention setting EFI32 values for 32 bit only processors. That should be useful for some.

 

Azimutz,

WOW, i would say this is the more detailed Chameleon changes description i've ever read :)

Thanx for the detailed explanation :)

 

EDIT: As promised before I tested the functionality of kernel booting with values of 32 and 64 --> working fine. Also if I left <Kernel Flags> key empty I can boot in 64 bit mode.

 

r361 CleanCut introduced a restart bug here. Issuing Ctrl+Cmd+Eject actually restarts my PC but after the OS X restarts itself the monitor stays switched off, and the CPU and System fans are spinning, so i have to restart via the reset switch of my case. Anyone with r361 does have the same behavior?

 

r352 from the trunk doesn't have this bug.

Link to comment
Share on other sites
makkernel2
makkernel2
Posted
Posted

Is this a bug? r361 by azimutz. If dsdt is load by path in com.apple /Extra/DSDT.aml, the DSDT is load 30 times in 30 tables as it is a SSDT table.

With smbios path works

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted

Yep Scrax,

but it's actually more correct to say that Chameleon is currently at rev 352, simply because

Chameleon is compiled from the trunk and that was the last rev, were changes were made to it.

 

Rednous,

LoL don't say :) i spent last night trying to lay down this stuff and ended with almost nothing :)

There's so much more to say and so little time... anyway..

Yep, 32/64 and -legacy flags should work fine; don't have much doubts on those.

Can't comment on that restart issue as i don't have it.

 

Makkernel2,

confirmed! Will look at it better... did just a quick check, not sure if it's on my side.

This is one of the areas i didn't checked yet, interaction with the the new ssdt functions.

 

p.s.: bug found, it's indeed on my side. Some code i removed; as i said, still didn't had time to check

this properly so, thanks Makkernel2 :) Will commit the code soon.

Link to comment
Share on other sites
d00d
d00d
Posted
Posted

Using Gigabyte.GTX285.PCIe.1024MB.Rev.01.rom from http://www.mvktech.net/component/option,co...c,select/id,92/ copied to /Extra/10de_05e3.rom.

 

With OS X software RAID 0 boot SSDs (Extra on slice 3's Apple_Boot Boot OSX) I get the following with VBIOS, GraphicsEnabler, and UseNvidiaROM;

Chipset Model: GeForce GTX 285

Type: GPU

Bus: PCIe

Slot: Slot-1

PCIe Lane Width: x16

VRAM (Total): 1024 MB

Vendor: NVIDIA (0x10de)

Device ID: 0x05e3

Revision ID: 0x00a1

ROM Revision: /Extra/10de_05e3.rom

 

...and with just VBIOS and GraphicsEnabler;

ROM Revision: 0x00

 

...and using nvclock;

-- VideoBios information --

Version: 62.00.50.00.01

 

Dood, i get what you mean now. You guys are right; but it's just how it works!

Update the working copy of the trunk to rev 352 (for instance)

svn up -r 352

or checkout the rev directly

svn co -r 352 http://forge.voodooprojects.org/svn/chameleon/trunk

Same stuff happens here either on cli or client.

thanks
Link to comment
Share on other sites
rednous
rednous
Posted
Posted
...

Rednous,

...

Can't comment on that restart issue as i don't have it.

...

 

Azimutz,

 

I checked again and according to me there's a little restart bug in r361 and r365 (your branch CleanCut revs.) R352 (latest trunk rev.) is free from this bug. Maybe you have RestartFix=Yes all the time and that's why you don't experience this bug. I decided to use the RestartFix=Yes (obsolete key nowadays) with r361 and r365 -- system restart is functional again. AFAIK RestartFix was implemented to defaults to "Yes", unless for some reason a user wants to set it No in com.apple.Boot.plist. So, it seems somehow this is changed in r361 and r356.

Link to comment
Share on other sites
makkernel2
makkernel2
Posted
Posted

Question for Azimutz: excuse but the restart fix now if off on default, because no facp table modded is generated to boot. I need of restartfix=yes in com.apple.boot.plist. Is it normal?

 

Can you fix this as in previous rev? With trunk rev no have this problem.

 

Obrigado

Link to comment
Share on other sites
rednous
rednous
Posted
Posted
Question for Azimutz: excuse but the restart fix now if off on default, because no facp table modded is generated to boot. I need of restartfix=yes in com.apple.boot.plist. Is it normal?

 

Can you fix this as in previous rev? With trunk rev no have this problem.

 

Obrigado

 

same here :happymac: see latest post. there'll be a fix of this bug, eventually

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted (edited)

Rednous & Makkernel2,

 

It was my choice to set the RestartFix to "false" by default, on rev 321 (see here). Should have done this

on a separate commit, sorry. Will make one just to signal this.

The question here is, "is this fix needed by the majority of the users?"

That's a question i can't answer all by my self. All i know is i never needed a restart fix and i'm sure i'm not alone on this; on

the other hand, i did used patched kernel most of the the time (restart/shutdown fix included) so, i can't be sure if i ever needed it?!

If the answer to that question turns out to be "yes", then i'll revert the fix back to "true". Till then, if you guys want to use

CleanCut, use RestartFix=y or change the code your self :P it's an easy edit.

Just doesn't make sense to me executing code that the majority of the users don't need!

 

Noted down 2 votes for Restart=y by default :)

Edited by Azimutz
Link to comment
Share on other sites
makkernel2
makkernel2
Posted
Posted
Rednous & Makkernel2,

 

this is not a bug! It was my choice to set the RestartFix to "false" by default, on rev 321 (see here). Should have done this

on a separate commit, sorry. Will make one just to signal this.

The question here is, "is this fix needed by the majority of the users?"

That's a question i can't answer all by my self. All i know is i never needed a restart fix and i'm sure i'm not alone on this; on

the other hand, i did used patched kernel most of the the time (restart/shutdown fix included) so, i can't be sure if i ever needed it?!

If the answer to that question turns out to be "yes", then i'll revert the fix back to "true". Till then, if you guys want to use

CleanCut, use RestartFix=y or change the code your self :) it's an easy edit.

Just doesn't make sense to me executing code that the majority of the users don't need!

 

Noted down 2 votes for Restart=y by default -_-

 

 

I understand you, perfect, but i haven't say that it was a bug. By the way i fix it my self: fix_restart = true

 

Yep, no problem. :P

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
Posted
Using Gigabyte.GTX285.PCIe.1024MB.Rev.01.rom from http://www.mvktech.net/component/option,co...c,select/id,92/ copied to /Extra/10de_05e3.rom.

 

With OS X software RAID 0 boot SSDs (Extra on slice 3's Apple_Boot Boot OSX) I get the following with VBIOS or GraphicsEnabler, and UseNvidiaROM;

Chipset Model: GeForce GTX 285

Type: GPU

Bus: PCIe

Slot: Slot-1

PCIe Lane Width: x16

VRAM (Total): 1024 MB

Vendor: NVIDIA (0x10de)

Device ID: 0x05e3

Revision ID: 0x00a1

ROM Revision: /Extra/10de_05e3.rom

 

...and with just VBIOS or GraphicsEnabler;

ROM Revision: 0x00

 

...and using nvclock;

-- VideoBios information --

Version: 62.00.50.00.01

 

thanks

 

The intereresting thing would be, what exact Video Bios Version nvclock shows wiith orig. ROM.

If i use an modded rom (diff in rom version number) and compare it to orig. rom (without UseNvidiaRom) i see same rom version and also no OC changes.

Can it be that systemprofiler shows that ROM Revision: /Extra/10de_05e3.rom but in real nothing is changed (no clocks, not the rom version) ?

Have you compared clocks (core, shader, mem) with orig. rom vs modded rom ? (Sure only an diff in clocks if the loeded rom has different clocks, ntibitor(win) shows that.

Link to comment
Share on other sites
Azimutz
Azimutz
Posted
Posted
I understand you, perfect, but i haven't say that it was a bug. By the way i fix it my self: fix_restart = true

 

Yep, no problem. :(

Yeah, there was no need for me to make that statement so, i edited the post. But there was also no need for you

to take it personally :D anyway, that's not important! The feedback was useful, that's what counts.

Now, let's not pollute this topic with more azimutz branch related stuff.

Any problem/doubt pm me; maybe i open a topic later on.

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