Jump to content

Chameleon RC5 Meklort's Branch


  • Please log in to reply
81 replies to this topic

#21
meklort

meklort

    InsanelyMac Geek

  • Developers
  • 139 posts
  • Gender:Male
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.

#22
Slice

Slice

    InsanelyMacaholic

  • Local Moderators
  • 3,193 posts
  • Gender:Male
  • Location:Moscow
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+?

#23
aikidoka25

aikidoka25

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 369 posts
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.

#24
meklort

meklort

    InsanelyMac Geek

  • Developers
  • 139 posts
  • Gender:Male

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.

#25
macq

macq

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 126 posts
@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.

#26
meklort

meklort

    InsanelyMac Geek

  • Developers
  • 139 posts
  • Gender:Male

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

#27
macq

macq

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 126 posts

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.


Thanks for the reply.

#28
Slice

Slice

    InsanelyMacaholic

  • Local Moderators
  • 3,193 posts
  • Gender:Male
  • Location:Moscow
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
....


#29
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu

...
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.

#30
meklort

meklort

    InsanelyMac Geek

  • Developers
  • 139 posts
  • Gender:Male

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.projectos...?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).

#31
Slice

Slice

    InsanelyMacaholic

  • Local Moderators
  • 3,193 posts
  • Gender:Male
  • Location:Moscow

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.

#32
Slice

Slice

    InsanelyMacaholic

  • Local Moderators
  • 3,193 posts
  • Gender:Male
  • Location:Moscow
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.dylibModule Symbols.dylib Loaded.Loading modules...Ignoring .DS_StoreAttempting 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.dylibmodule_loaded: HPET.dylibregister_hook_callback: Adding callback for 'PCIDevice' hook.....Attempting to load Memory.dylibmodule_loaded: Memory.dylibregister_hook_callback: Adding callback for 'PCIDevice' hook.register_hook_callback: Adding callback for 'ScanMemory' hook....---Hook Table---Hook: ExecKernelHook: ScanMemoryHook: PCIDeviceHook: 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++ functionHello world from ExecKernel hook. Binary located at 0x18100000execute_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?

#33
meklort

meklort

    InsanelyMac Geek

  • Developers
  • 139 posts
  • Gender:Male

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.

#34
Slice

Slice

    InsanelyMacaholic

  • Local Moderators
  • 3,193 posts
  • Gender:Male
  • Location:Moscow
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.

#35
Slice

Slice

    InsanelyMacaholic

  • Local Moderators
  • 3,193 posts
  • Gender:Male
  • Location:Moscow
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.

#36
meklort

meklort

    InsanelyMac Geek

  • Developers
  • 139 posts
  • Gender:Male
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.

#37
denzel

denzel

    InsanelyMac Protégé

  • Members
  • Pip
  • 20 posts

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

#38
meklort

meklort

    InsanelyMac Geek

  • Developers
  • 139 posts
  • Gender:Male
The module system is just about ready to by merged into trunk, I'm going to make a few changes before I do though (but it'll be merged soon).

#39
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,170 posts
  • Gender:Male
  • Location:UK
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?

#40
meklort

meklort

    InsanelyMac Geek

  • Developers
  • 139 posts
  • Gender:Male
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.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy