Jump to content

Chameleon RC5 Meklort's Branch

aikidoka25

By aikidoka25,
in Chameleon

 Share
82 posts in this topic

Recommended Posts

meklort
meklort
Posted
Posted
@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.

 

 

I haven't had time to look at it recently (and it's not a pressing issue for me), I really only need to change one or two instructions and it should work.

 

If I have time, I'll take a look.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Great Meklort! You did it!

Now Symbols.dylib is embedded and only one module I need to boot my system - ACPIPatcher.dylib.

If it will be embedded too we will have one-file bootloader.

How do you think, is it possible to embed ACPIPatcher? Or just return it to main codes.

 

About patch_video_bios I agree. For safety I exclude it with my Intel VGA and I see bad reports with ATI and NVidia. I think it is better do not this. May be this is a reason that Kabyl's ATI enabler didn't work in my branch.

Extra:
BootHelp.txt
com.apple.Boot.plist
Extensions:
	10.5:
	10.6:
	Common:
modules:
	ACPIPatcher.dylib
smbios.plist
Themes:
	Default:
		background.png
....

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
Posted
...

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.

<geek_talk>This is not a patch but a work around. And in this particular case it is in fact more a hack than a work around.</geek_talk>

 

I wonder if there's anyone out there who actually knows what is going on, because then they would have fixed the problem instead of working around it. Too bad, but that's basically it.

Link to comment
Share on other sites
meklort
meklort
Posted
Posted
Great Meklort! You did it!

Now Symbols.dylib is embedded and only one module I need to boot my system - ACPIPatcher.dylib.

If it will be embedded too we will have one-file bootloader.

How do you think, is it possible to embed ACPIPatcher? Or just return it to main codes.

 

About patch_video_bios I agree. For safety I exclude it with my Intel VGA and I see bad reports with ATI and NVidia. I think it is better do not this. May be this is a reason that Kabyl's ATI enabler didn't work in my branch.

I've probably said this before, but I'm *not* going to integrate any modules into boot. There is a reason why I took them out and made them into modules. The only reason Symbols.dylib is integrated is because it's not really a module, it's tied to that version of boot. If you want to compile the modules in, you are welcome to do so, just link the modules in with boot2 and make the init code run at the appropriate time.

 

My brach is also *not* in a usable state as the commit message says. There are bugs with the embedded Symbols.dylib file (and it is cause because the file is embedded).

 

 

<geek_talk>This is not a patch but a work around. And in this particular case it is in fact more a hack than a work around.</geek_talk>

 

I wonder if there's anyone out there who actually knows what is going on, because then they would have fixed the problem instead of working around it. Too bad, but that's basically it.

 

The patch implemented in the boot loader is just this: http://www.projectosx.com/forum/index.php?showtopic=1210

If you know a more correct way to do it, let me know and I'll add it. I don't have this issue so I can't test it (and since it doesn't affect me, I'm not going to look into another way of fixing it).

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
I've probably said this before, but I'm *not* going to integrate any modules into boot. There is a reason why I took them out and made them into modules. The only reason Symbols.dylib is integrated is because it's not really a module, it's tied to that version of boot. If you want to compile the modules in, you are welcome to do so, just link the modules in with boot2 and make the init code run at the appropriate time.

I think that the "boot" must contains obligatory procedures and modules contains all options. Dunno about others but for my mind ACPIPatcher is always obligatory. So I embedded it and now I have working featureless boot without GUI. It works without modules.

My brach is also *not* in a usable state as the commit message says. There are bugs with the embedded Symbols.dylib file (and it is cause because the file is embedded).

There are no any bugless programs :) I know bugs in your branch. For example losing root_pci_dev pointer. Is it in past?

My branch also contains bugs which I works to eliminate. I wish be helpful for you if you'll tell more info what a bug you encountered.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Made some tracing with module system. Yes, there is a bug.

I have: boot and

modules:
HelloWorld.dylib
HPET.dylib
klibc.dylib
Memory.dylib
uClibc++.dylib

And then look bdmesg (many debugs inserted)

module_loaded: Symbols.dylib
Module Symbols.dylib Loaded.
Loading modules...
Ignoring .DS_Store
Attempting to load HelloWorld.dylib
...
register_hook_callback: Adding callback for 'ExecKernel' hook.
register_hook_callback: Adding callback for 'Kernel Start' hook
...
Attempting to load HPET.dylib
module_loaded: HPET.dylib
register_hook_callback: Adding callback for 'PCIDevice' hook.
....
Attempting to load Memory.dylib
module_loaded: Memory.dylib
register_hook_callback: Adding callback for 'PCIDevice' hook.
register_hook_callback: Adding callback for 'ScanMemory' hook.
...
---Hook Table---
Hook: ExecKernel
Hook: ScanMemory
Hook: PCIDevice
Hook: Kernel Start
................
execute_hook: Attempting to execute hook 'ModulesLoaded'
execute_hook: No callbacks for 'ModulesLoaded' hook.
...
execute_hook: Attempting to execute hook 'PreBoot'
execute_hook: No callbacks for 'PreBoot' hook.
...
execute_hook: Attempting to execute hook 'ExecKernel'
execute_hook: Executing 'ExecKernel' with callback 0x83833B4.
[1] HelloWorld from a c++ function
[2] HelloWorld from a c++ function
Hello world from ExecKernel hook. Binary located at 0x18100000
execute_hook: Hook 'ExecKernel' callback executed, next is 0x0.
execute_hook: Hook 'ExecKernel' executed.
execute_hook: Attempting to execute hook 'DecodedKernel'
execute_hook: No callbacks for 'DecodedKernel' hook.
execute_hook: Attempting to execute hook 'PCIDevice'
execute_hook: No callbacks for 'PCIDevice' hook.
....
execute_hook: Attempting to execute hook 'ScanMemory'
execute_hook: No callbacks for 'ScanMemory' hook.

:(

If it is helpful info....

 

Propositions, what I should check else?

Link to comment
Share on other sites
meklort
meklort
Posted
Posted
Made some tracing with module system. Yes, there is a bug.

 

Care to explain what the bug is / symptoms are? For the information that you posted, I don't see any.

 

EDIT: THe only thing that I see is it mentioned that there are no hooks for what the mem.dylib module added.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Hi, Meklort!

I don't know why the mistake is appeared. May be because of Symbols.dylib embedded, may be some c-dialect settings, may be it always exists. But I resolved it. See my commit 713.

EDITED: the mistake in name comparison

execute_hook: name=ScanMemory hook->name=ExecKernel cmp=14 try next

Positive value!!!

 

Briefly:

I have to refactored modules.c: register_hook_callback() and execute_hook(). I write into comments about changes. Now I see all modules in any mixture is executed.

 

But I hurry to report after few tests so I do not propose final solution.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Fighting to make GUI working I localize the problem:

There is a KP here

int initGUI(void)
{...
if (loadConfigFile(dirspec, &bootInfo->themeConfig) != 0) {

So I place the same log in to places: in main boot.c and in gui.c (module!).

msglog("Address loadConfigFile=%x bootInfo=%x\n", &loadConfigFile, &bootInfo);

And what I see

from module:

Address loadConfigFile=2a14a bootInfo=3ffd4

from boot

Address loadConfigFile=2a14a bootInfo=44064

from file Symbols.h

{.symbol = _bootInfo_string, .addr = 0x0003ffd4},

At this point I stopped and want to hear some explanations about.

Link to comment
Share on other sites
denzel
denzel
Posted
Posted
That was due to the Symbols.dylib file being embedded. I have since fixed the issue (and a few others) and will be uploading the changes soon.

 

 

Hi meklort, now with rev 718 your boot works amazing. It's the best.

 

Only one question: can you trunk it with rev 699 finally?

 

Thanks

Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

Hi meklort

 

After reading your post above I thought I'd try out the latest code in your branch. It's been a while since I tested and I see there have been plenty of changes. First can I comment on the makefile, and how readable the output is. Lovely.

 

However, I haven't been able to boot yet. I tried with only /extra/modules/ACPIPatcher.dylib but I got an error reading something like 'missing klibc.dylib', so I added that and now I get and error reading 'Unable to start klibc.dylib'

 

Am I doing something really silly or is this a problem?

Link to comment
Share on other sites
meklort
meklort
Posted
Posted

My bad, I mist have broken something in r719 or r720, you can use r718 and it'll work fine. I'll fix it later today.

 

As far as the makefile goes, it's much easier to spot warning / errors this way so I changed it to print how it does a while ago.

Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

Hi Meklort

 

Yes you're right, rev 718 does indeed work. :(

I've done some testing and here's my report for you:

 

Of the modules, I only need ACPIPatcher, klibc and the Memory modules to boot properly.

Memory.dylib fails to auto detect my RAM, shown in system profiler, but strangely I need it for my system to show the correct hardware UUID.

post-331032-1296421909_thumb.jpg

 

GraphicsEnabler.dylib works as expected.

ACPIPatcher.dylib is needed and works.

klibc.dylib is needed as without it I see these following errors at boot:

post-331032-1296421891_thumb.jpg

post-331032-1296421898_thumb.jpg

 

Booting with and without the Resolution module shows me this on my 1680x1050 display?

Note: this is without using the GUI module.

post-331032-1296421903_thumb.jpg

 

The GUI module works fine.

 

Well done with your continued development and if there's any further testing you need from me then just ask.

Link to comment
Share on other sites
denzel
denzel
Posted
Posted
My bad, I mist have broken something in r719 or r720, you can use r718 and it'll work fine. I'll fix it later today.

 

As far as the makefile goes, it's much easier to spot warning / errors this way so I changed it to print how it does a while ago.

 

 

Hi meklort, i have also the same problem with r720, same problem of blackosx. Waiting in your fix :(

 

Thanks

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Hi Meklort!

Thanks for your changes. Now my bootloader really works... after reverting those changes:

MakeInc.dir in modules/

-alias $(MODULE_START) start \

else modules didn't start.

	@### Ugly hack, remove the c++ module if this module shouldn't link with it. Needed due to LD behavoir
@echo "\t[LD] $(MODULE_NAME).dylib"
@if [ -f "$(SYMROOT)/uClibc++.dylib" ]; then if [ x"$(shell nm $(OBJROOT)/*.o 2>/dev/null  | grep " __Z")" == x"" ]; then mv $(SYMROOT)/uClibc++.dylib $(SYMROOT)/../uClibc++.dylib; fi; fi;

else uClibc++.dylib is needed while it is not really needed.

 

That's all. Now works.

But I want to ask you. Why klibc.dylib in needed and in what cases? It seems not needed for ACPIpatcher.dylib. Do not check other cases.

I think the ACPIPatcher should be divided into obligatory part acpi_patcher embedded into main boot and optional part like p-state generator as separate module.

 

I have strange behavior with Resolution. The function is called twice. It gives me 1440x900 that is good but initial picture is larger then real screen size (it seems to be default size), and after choosing a system to boot the screen really switch to 1440x900. Have you any advice what to do?

bdmesgSlice.log.txt.zip

Link to comment
Share on other sites
denzel
denzel
Posted
Posted

meklort, hi, problem in compilation with last revision:

 

 

kext_patcher.c: In function ‘mkext_loaded’:
kext_patcher.c:164: warning: implicit declaration of function ‘Adler32’
[CC] inflate.c
[CC] deflate.c
[CC] zutil.c
[CC] inftrees.c
[CC] inffast.c
[CC] adler32.c
[CC] hex_editor.c
[CC] trees.c
[LD] KextPatcher.dylib
Undefined symbols:
 "_Adler32", referenced from:
  _mkext_loaded in kext_patcher.o
  _mkext_loaded in kext_patcher.o
ld: symbol(s) not found
make[3]: *** [dylib_final] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all] Error 2
make: *** [all] Error 2

Link to comment
Share on other sites
denzel
denzel
Posted
Posted

Hi meklort, thanks also to slice, now it works, but there is a problem with gui(?).

If i boot with -v, loader works well, without problems.

If i boot in normal mode, ... nothing, completely nothing, load apple logo and nothing. Everything stopped.

 

Thank you

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
Hi meklort, thanks also to slice, now it works, but there is a problem with gui(?).

If i boot with -v, loader works well, without problems.

If i boot in normal mode, ... nothing, completely nothing, load apple logo and nothing. Everything stopped.

 

Thank you

I may propose that here is not correct

	if (useGUI && initGUI())
{
	// initGUI() returned with an error, disabling GUI.
	useGUI = false;
}
else
{	// will be here if useGUI==false ?!

so I think

	if (useGUI && initGUI())
{
	// initGUI() returned with an error, disabling GUI.
	useGUI = false;
}
if (useGUI)
{

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