Jump to content
  • Announcements

    • Allan

      Forum Rules   04/13/2018

      Hello folks! As some things are being fixed, we'll keep you updated. Per hour the Forum Rules don't have a dedicated "Tab", so here is the place that we have our Rules back. New Users Lounge > [READ] - InsanelyMac Forum Rules - The InsanelyMac Staff Team. 
aikidoka25

Chameleon RC5 Meklort's Branch

82 posts in this topic

Recommended Posts

Ciao!

 

I started this thread, so we can discuss and give feedback on Meklort's branch of Chameleon RC5.

I am using his branch because the netbook I have uses Atom CPU, hence it is important for the booter to support it so a vanilla kernel can be used.

 

You can get the latest revision by using svn and compile it on your machine

svn co http://forge.voodooprojects.org/svn/chameleon/branches/meklort

 

 

Please help by keeping the thread in topic! Thanks!

 

 

 

meklort,

 

here is the detail about rev 669 doesn't generate P-States.

according to slice, there was a change in ACPI patcher in the trunk, and it was for Nehalem CPU's min divider.

 

i wonder if it is possible to have a backward compatibility with Atom, what do you think?

 

excerpt of bdmesg

...
Actual model name is 'HP Mini 311-1000'
Read HFS+ file: [hd(0,2)/Extra/DSDT.aml] 38885 bytes.
ACPI table not found: SSDT.aml
FADT: Restart Fix applied!
FADT: Using custom DSDT!
Found ACPI CPU: CPU0
Found ACPI CPU: CPU1
Found ACPI CPU: CPU2
Found ACPI CPU: CPU3
SSDT with CPU C-States generated successfully
Unsupported CPU: P-States not generated !!!
RSDT: Added 1 SSDT table(s)
FADT: Restart Fix applied!
FADT: Using custom DSDT!
Unsupported CPU: P-States not generated !!!
Added 1 SSDT table(s) into XSDT
...

 

ioregexplorer reported less P-States array

post-508994-1292445714_thumb.png

 

compared to revision 653

post-508994-1292445736_thumb.png

Share this post


Link to post
Share on other sites

I checked the source code and it should already support the Intel Atom cpu. Would you please post the complete boot log (say, to pastbin). I have also modified it to print out the cpuid if it thinks the cpu isn't supported, run the new version and let me know what it says the cpuid is.

Share this post


Link to post
Share on other sites
I checked the source code and it should already support the Intel Atom cpu. Would you please post the complete boot log (say, to pastbin). I have also modified it to print out the cpuid if it thinks the cpu isn't supported, run the new version and let me know what it says the cpuid is.

 

here is bdmesg using rev 670

bdmesg_r670_aikidoka25.txt

Share this post


Link to post
Share on other sites

Thanks Meklort for the netbook's Chameleon bootloader.

I have a HP mini 2140 and used your bootloader for a while.

When bootloader goes with modules and I found something not work very well.

Resolution.dylib looks like only worked in verbose mode.

I have an 808627AE GMA 950 graphic and KextPatcher.dylib never got to worked.

I boot my SL from SD card and leave HDD in totally vanilla.

I don't know booting from SD card is the point make them not worked well.

And I don't use DSDT file.

I give my log file for you to reference.

 

671log.zip

Share this post


Link to post
Share on other sites
Thanks Meklort for the netbook's Chameleon bootloader.

I have a HP mini 2140 and used your bootloader for a while.

When bootloader goes with modules and I found something not work very well.

Resolution.dylib looks like only worked in verbose mode.

I have an 808627AE GMA 950 graphic and KextPatcher.dylib never got to worked.

I boot my SL from SD card and leave HDD in totally vanilla.

I don't know booting from SD card is the point make them not worked well.

And I don't use DSDT file.

I give my log file for you to reference.

 

671log.zip

 

In order for the kext patcher to work, the kext must be inside of an mkext loaded by the bootloader, the easiest way is to run sudo kextcache -system-mkext. I also wrote a kext (included in nbi) that changes the behavior to include all kexts by default. The log you posted tells me that the mkext doesn't have the GMA950 kext in it, so that's why it's not patched.

 

I haven't had any issues with the resolution module, what are you sing when not in verbose mode. I'll add some logging so that when you use bdmesg it'll tell you what resolution it determined was the best / what resolution it's using.

 

SD card shouldn't effect anything.

Share this post


Link to post
Share on other sites
I also wrote a kext (included in nbi) that changes the behavior to include all kexts by default.

Huh? Why not use: sudo kextcache -system-mkext -local-root Isn't that what people want?

 

Want to slim down things? Add option: -arch=<i386/x86_64>. Hope this helps.

Share this post


Link to post
Share on other sites
Huh? Why not use: sudo kextcache -system-mkext -local-root Isn't that what people want?

 

Want to slim down things? Add option: -arch=<i386/x86_64>. Hope this helps.

 

I *want* to include all kexts in the kext, if you *don't*, the kext patcher won't be able to find certain kexts (like the GMA950 ones, because they *don't* exist). The kext that I wrote modifies the default behavior and strips out the local root flag so that when kextcache is run automatically (say, after a system update or when a user touches /S/L/E), it includes *all* off the kexts.

Share this post


Link to post
Share on other sites
Resolution.dylib looks like only worked in verbose mode.

Yes, something wrong.

I modify gui.c to see what is happen with gui resolution

	if(is_module_loaded("Resolution.dylib"))
{
	getResolution(&screen_params[0], &screen_params[1], &screen_params[2]);
	msglog("GUI module screen width=%d height=%d\n",(int)screen_params[0], (int)screen_params[1]);
}
if (((int)screen_params[0]<800) || ((int)screen_params[1]<600))
{
	if (getIntForKey("screen_width", &val, &bootInfo->themeConfig) && val > 0)
	{
		screen_params[0] = val;
	}
	if (getIntForKey("screen_height", &val, &bootInfo->themeConfig) && val > 0)
	{
		screen_params[1] = val;
	}		
	msglog("GUI theme screen width=%d height=%d\n",screen_params[0], screen_params[1]);		
}

And bdmesg

GUI module screen width=-96 height=-124
GUI theme screen width=1024 height=768

Looks like getResolution() is not worked. (IntelX3100 devID=2a02)

Share this post


Link to post
Share on other sites

 

hello, thx a lot, now i have some more to play around ;)

i tried it with the latest trunk and with the one from kabyl and it works. (by the way, with Kaby i get false CPU Mhz output in smck-Sat)

 

So i tried it with the Meklort and Slice branch. Both boot well but at the end of boot i get kernel panic. would you like a kernel log ?

if you´ve got some more tips or a readme it would be great. iám a noob but i like to test your work :)

Share this post


Link to post
Share on other sites
...

So i tried it with the Meklort and Slice branch. Both boot well but at the end of boot i get kernel panic. would you like a kernel log ?

if you´ve got some more tips or a readme it would be great. iám a noob but i like to test your work :)

 

post it here, and indicate from which booter (meklort or slice)

i will try to see why it went kp, if i couldn't help you i guess others can.

Share this post


Link to post
Share on other sites

Hi,

 

I use this chameleon version with an Asus 1201N and it works great :censored2:. I activate the P-States and C-States generation without any issue (after having remove everything linked in DSDT for sure). And with the last version of Chameleon, memory informations can be access in "About this Mac", "More Info", "Memory". Previously I'd got an error reading here.

 

However, the memory detection as "some issues" (please, note that I removed all memory information in SMBIOS.plist, that only contains for me "Macbook" Air 2.1 information).

 

It detects 4 DIMM slots but we have only 2 in the netbook.

 

 

BANK0/DIMM0 :

 

Taille : 2 Go

Type : DDR2 SDRAM

Vitesse : 800 MHz

État : OK

Fabricant : N/A

Numéro de pièce : N/A

Numéro de série : N/A

 

BANK1/DIMM1 :

 

Taille : Vide

Type : Vide

Vitesse : Vide

État : Vide

Fabricant : Vide

Numéro de pièce : Vide

Numéro de série : Vide

 

BANK2/DIMM2 :

 

Taille : 2 Go

Type : DDR2 SDRAM

Vitesse : 800 MHz

État : OK

Fabricant : N/A

Numéro de pièce : N/A

Numéro de série : N/A

 

BANK3/DIMM3 :

 

Taille : Vide

Type : Vide

Vitesse : Vide

État : Vide

Fabricant : Vide

Numéro de pièce : Vide

Numéro de série : Vide

 

For sure, it is only cosmetic, and I'm very happy with the last progress that provide us native power management (and if Meklort can include what is doing LegacyAGPM as an Chameleon plugin, it would be a dream :)).

 

Thanks for your hard work !!!!

Share this post


Link to post
Share on other sites
For sure, it is only cosmetic, and I'm very happy with the last progress that provide us native power management (and if Meklort can include what is doing LegacyAGPM as an Chameleon plugin, it would be a dream :wacko:).

 

Thanks for your hard work !!!!

 

 

I generally don't work on the memory code myself.

 

If you point me in the right direction for LegacyAGPM, I'll see what I can do.

Share this post


Link to post
Share on other sites

Ok, thanks, I will post the question on the other Chameleon thread :wacko:.

 

LegacyAGPM seems to be an "simple" injector to activate the power management on the Nvidia chip. It seems that we declare inside the different "P-States" of the chip with other needed information.

 

For me it "seems" near to what is done on the last release of Chameleon for the CPU detection.

 

Sorry, I'm not a specialist, I'm just a guy that integrate all your work to deal with it hackintosh.

 

However, thanks for your hard work, I really appreciate it ;).

 

Merry Christmas to all of you !!!

 

P.S.: I tried to compile the last version rev 689 and I've got this error. What I did wrong ?

 

make[2]: *** No rule to make target `/Users/VMonHeros/meklort/sym/i386/libklibc.a', needed by `boot'. Stop.

make[1]: *** [embedtheme] Error 2

make: *** [embedtheme] Error 2

LegacyAGPM.kext.zip

Share this post


Link to post
Share on other sites

Meklort,

 

Were there any special changes on the latest revision?

The old ways of copying only boot and modules files was not working anymore.

When started, the machine complained cannot find Symbols.dylib

 

From the make log, I could see Symbols.dylib was compiled, but it cannot be found in sym/i386

 

================= Compiling Symbols.dylib =================
[LD] Symbols.dylib
[LD] boot_embeded.sys
================= Embedding Symbols.dylib =================
[MACHOCONV] boot
IOHibernatePrivate.h Makefile Symbols.c WKdm.h WKdmDecompress.c appleClut8.h bmdecompress.c boot.c boot.h boot2.s drivers.c drivers.h graphics.c graphics.h lzss.c mboot.c mboot.h modules.c modules.h modules_support.s multiboot.h options.c options.h prompt.c ramdisk.c ramdisk.h resume.c Patching at 108904 IOHibernatePrivate.h Makefile Symbols.c WKdm.h WKdmDecompress.c appleClut8.h bmdecompress.c boot.c boot.h boot2.s drivers.c drivers.h graphics.c graphics.h lzss.c mboot.c mboot.h modules.c modules.h modules_support.s multiboot.h options.c options.h prompt.c ramdisk.c ramdisk.h resume.c
[MACHOCONV] boot_embeded

Share this post


Link to post
Share on other sites

It's been a while since I've worked on chameleon (well, a few weeks). I may have enabled the code that embeds Symbols.dylib file into boot, however I am not certain about that. If I did, I must have forgotten to enable of of the changes that were needed. I'll take a look sometime.

Share this post


Link to post
Share on other sites

Some problem I encountered.

Modules can't be read from FAT32 for example EFI partition. Did you propose to make a driver that read from FAT32 as well as from HFS+?

Share this post


Link to post
Share on other sites

I think it is a good idea to embed Symbols.dylib, because that part is dependent with boot2 code. We cannot compile that part by itself, hence in a way it is not modular.

Share this post


Link to post
Share on other sites
Some problem I encountered.

Modules can't be read from FAT32 for example EFI partition. Did you propose to make a driver that read from FAT32 as well as from HFS+?

 

Modules can be read from any file system that chameleon supports, which includes fat32. It's using the boot partition to determine where to load the modules from. I haven't tested it with the efi partition, so there may be a different bug causing it (most likely chameleon is deciding to use a diff partition instead for some reason), but they can be loaded from pure fat32 partitions.

 

 

I think it is a good idea to embed Symbols.dylib, because that part is dependent with boot2 code. We cannot compile that part by itself, hence in a way it is not modular.

That's the main reason why the module code isn't in trunk yet. It's not complete enough. Once that change is finished (and working properly), it can then be merged into trunk. That is, assuming the bug that slice mentioned is fixed.

Share this post


Link to post
Share on other sites

@meklort,

your branch of RC5 has the lapic.c fix for the HP notebooks so as to enable them to boot with the vanilla kernel natively,however its only for x32 bit install.

 

Would you consider my humble request to port it for x64 bit also if it is at all possible for you?.

There's no one else who seems to know how to do it.

 

It would be of great help for HP users(and there are a lot of us) to boot the vanilla kernel x64 bit mode.Please consider!!!

 

Thanks for your time and attention in advance.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×