How to boost the OS X boot process...

[humph]

Strangely some kexts that would not load previous are now...

Hmm, I'm not seeing that - well, perhaps we're having separate issues. Or perhaps you can shed some light:

 

Previously, in order to get stuff like GMA950 to load, I either needed to change it to "Root" (from Safe Boot).

Same for the HDA and certain audio dependency kexts needed in /E/E (to Root from no OSBR, mostly).

Or, chuck them into a mkext in /E - even if not "Root" it all works when in mkext.

 

So, thought that now I might be able to revert the kext's OSBR flags to the "normal" ones and it'd work when loading as kexts. Seems not. As before, not sure if this is OSX, or if is bootloader, or a combination of both. In effect, I'm getting a safe boot on these items.

 

Not as straightforward though for audio, since whilst video works OK when loaded as kexts with "Root", audio is not (they do load - I can see it refusing newer kext in log). But weird that all works OK when in mkext. I guess OSX just takes that contents w/o worrying about OSBR.

 

DHP:

But anyway, no complaints really, just observations. 363-4 working fine otherwise AFAICT.

Awesome.

 

Update ref:

Please use the files without modifications, except for removing the = ..

OK, backed off the change. (Now I see that removal of "=" removes the need for the other change. Good job I don't earn my living with software!). But, no impact to above.

[humph]

BTW: Let me attach a PDF file. The one I used to learn how this whole kext concept works (jump to:"Loading Kernel Extensions at Boot Time").

 

Need to finish something for school now so I am going off-line. Good night all...

Thank you for the document. Nice refresher.

Revo, Cham etc working they way they should as a direct replacement of BootX/boot.efi then. Where it's up to user to handle his/her situation.

On other hand, injection of kexts from /E/E is a hack-only thing, and arguably then, the way kexts from /E/E are treated could be different to ones from /S/L/E. But only if kextd can be "fooled", as it appears to be when loading a mkext of all kexts in /E/E irrespective of the OSBR. That's the bit I'm not clear about.

 

EDIT: So, looked at all the kexts unpacked from Startup mkext in MBP, and all are Root or Local Root etc. So I reckon that the OS just assumes it needs to load all kexts from an mkext, since normally in OSX there are no mkexts that include "lower priority" kexts. Off to bed.

 

Meaning, is there a way within bootloader to load all kexts in /E/E (irrespective of OSBR setting for a normal boot) in a way such that kextd etc treat them like they are when part of an mkext; or do you just gotta use "Root", since it's all down to kextd and the kernel doing it's stuff?

It's an academic interest thing really; since workarounds exist that are fine for Safe Boot as well as Normal Boot with the way hack bootloaders work today.

 

Anyway, trust you had good night's sleep and see you all again in the days ahead!

[blackosx]

Sorry I've not visited much as I've been busy experimenting with getting revolution in-bios as a PCI option ROM but no joy so far.

Now that's something I like the sound of but unfortunately I don't have the necessary coding skills to help out. How are you going about it?

 

BTW: Let me attach a PDF file. The one I used to learn how this whole kext concept works (jump to:"Loading Kernel Extensions at Boot Time").

Thanks for the link. I've browsed some of Apple's documentation before but with such a wealth of content to choose from I never really sat down and learnt one specific part, instead just flicked through different topics with the end result of knowing a little about a lot, rather than knowing a lot about some.

[humph]

You're welcome. And this document seem interesting to a lot of people, because 9 downloads in a few hours time... at night. That's a hit.

At 12 now!

They both work identical to BootX itself. And you may have missed it, but post #503 includes a link to the latest available version of drivers.c (used in BootX).

Hm, yes I think I did miss that link!

Relevant bit in plain English makes it all clear, no more confusion from (my) mis/not understanding code :

  // to be loaded by BootX, you must have OSBundleRequired and it
 // must not be set to Safe Boot (that's for kextd later)
 // in other words, BootX always loads the minimal number of kexts
 // if loading them one at a time

Leaves the question whether IF booter does load other stuff from /E/E, whether it gets dropped by kextd. Guess I can try a hack on the hack to see!

 

EDIT: Answer, so it would seem is kextd does not remove stuff already loaded by bootloader.

I messed around with drivers.c, around line 770 and the "required" section. In end deleted that totally to get both Safe Boot and no OSBR kexts to load (as well as Root etc). Of course, that is not what you'd want for kexts loaded from /S/L/E ever, nor even from /E/E if doing a Safe Boot. But as proof of concept, it works. So it would be possible to arrange things that you can keep /E/E kexts as Safe Boot (for when safe booting), but get them to load nicely when not using an mkext - such as when configuring new hardware to avoid hassle of creating mkext for every test.

 

I think there is by using kextcache -local-root-all. Yeah. That should work.

Am just using default (all kexts) like: kextcache - m Extensions.mkext etc. for /E/E mkext, so everything is included.

[dgsga]

Ladies and gentlemen, go here, read on and be educated.

 

http://sites.google.com/site/pinczakko/low...teaching-tool-2.

 

Pinczacco is a prominent figure in the world of bios modding and has written some excellent if complex tutorials

 

To my mind this may well be a way forward to getting revolution in-bios. My line of thinking is that we could combine the standard PCI option rom assembler code with boot2.s so there is a jump at the end from PCI option rom code to the _boot C++ code. I have successfully compiled a version of Revolution's boot which is a PCI option ROM. I flashed this into the bios as a replacement for the LAN boot option ROM but needless to say it doesn't work as I don't know the right code to make the jump. Assembler code is another world, maybe I'll just have to teach myself but you may well grow old waiting!!

[blackosx]

Ladies and gentlemen, go here, read on and be educated.

Wow dgsga - you've been busy and look to have progressed some distance, though likewise my assembler isn't anything to be desired. And thanks for the great link you posted! I had a quick look and see there's a mountain of info there for consumption, but based on my comment above about the Apple docs I know how far I would get with finding time to read it.

 

Thing is, however excited I feel about this I know the direction to go in is as DHP says.

 

... but I think jump right on the UEFI bandwagon instead...

That is the future and the way bootloaders will go. I asked here about this back in November.

[humph]

... I think to jump right on the UEFI bandwagon instead. That to me looks easier (development done in C++) and it is, or should be, the next big push forward.

So glad you think that way! EFI is the future, and has loads of advantages, even if might eliminate option to save some boot time. I did a bit of messing with changes to grub2.efi code for another project some months back, and whilst am no programmer, it sort of seems no so bad to get one's head around. Actually, was gonna ask if the fake efi in Revo/Chameleon is capable to "chainload" something like Grub.efi? Or perhaps not even go that far.

Would be cool, if only for interests sake/project work; to have access to the efi modules (tools). Eg: just being able to explore the FS to find and edit files w/o having to boot whole OS! (Thought that they now support AHCI etc).

Enter kextfind.

Nicely interesting and seems it'll be v useful. However....does not output info on stuff from /E/E. (well, not for -loaded).

So, useful for full info only if you have nothing in /E/E and everything in /S/L/E. Perhaps I am heading off the wrong future track by using /E/E? But seems nicer (easing upgrade issues, a bit)!! Also a key requirement I have is supporting an emergency fallback when/if my old MPB dies, that I can just boot it's HD on the hack via suitable USB booter, w/o having to mod /S/L/E; is why booter congif to keep totally vanilla /S/L/E is important here. OK, could import user files, but I prefer something that gets up and running quickly via a few screws as opposed to hours of disk copy.

It not my only interest in this area - mostly 'cos it's interesting & fun to mess around with booting & loaders!

[humph]

I don't even know where to start.

Me neither ! LOL. Anyway, as for all the EFI stuff, was just sort of wondering out load. No worries!

First. Revolution, unlike Chameleon, won't use your Mac's system mkext, but the one you've put on the USB-stick/SDbooter and thus you should be fine.

Indeed. Very nice. Although even nicer is your added support for prelinked kernel.

..trust me when I say: "I am not fooling around for nothing".

..

..my plan (see post #134) and finish things that I said to work on. No matter how silly they may look to others

..

I'm sticking around, there's some really good stuff in your published plans! And am learning lots as well as having fun.

[humph]

... GT/s (Giga Transfers per second) thing. I mean should I use QPISpeed or QPIFrequency for this?

If using or displaying as eg: 25.6 GB/s etc, then Speed (perhaps more technically is called Bandwidth).

 

If as eg: 3.2GHz, then Freq.

 

Freq x a bunch of stuff x a bunch of other stuff x .. = bits (or bytes)/s

 

But I guess if GT/s, then Speed makes sense, as it's not really bandwidth - you have to x GT/s by number of bits/bytes and stuff to get to the data bandwidth.

[humph]

I have:

	gPlatform.CPU.CurrCoef		= 0x6;					// (which is what I used previously with busratio=17).
gPlatform.CPU.MaxCoef		= 0x12;					// Zero means no turbo?

gPlatform.CPU.CurrDiv		= 0;					//
gPlatform.CPU.MaxDiv		= 0;					// 

gPlatform.CPU.TSCFrequency	= 159600000ULL;			// 
gPlatform.CPU.FSBFrequency	= 133333333ULL;			// hw.busfrequency aka ((2261000 / 17) * 1000). 
gPlatform.CPU.CPUFrequency	= 159600000ULL;			// hw.cpufrequency

 

This for Atom. But showing as 800MHz (again) in SysProf. Works ok though AFAIK.

 

p.s. wasn't sure about Curr.Coef, whether meant min or "bootup" multi or whatever, so used min multiplier for this CPU.

[DB1]

All good with 636_5 here.

 

Just look how much work I had to do to solve problems that I didn't even knew about. No complaints here, but it is a fact that my hardware, and my limited experience with OS X itself, is hindering my development so I need you gentlemen. If only for inspiring me so thanks again for being who you are, and being here. I really appreciate it.

 

Appreciated here and glad to share the experiences and were all learning along the way. Thanks all

[dgsga]

Phew. Good to hear that. Settling for 2.0 LOL Thanks.

 

 

Yeah. A single human can't do everything. Or at least I can't. I think that we all need other people, to inspire and help us push forward. Thanks all!

 

Me soon on TV (Indoor Hockey Nederland - Australia) Look for a blond girl with number 1 on her suit Yup. That'll be me. No {censored}e. Look for the Apple Logo on my bag !!!

 

Awesome! Thanks for the latest file changes, all works fine on my rig. I do agree with you that the way forward is UEFI. I just like a challenge, that's all

[DB1]

Back to the stuff, I'm at a point where this is ready to be my permanent booter BUT I would like to be able to install on EFI partition instead of SD card (or usb) which surly should be faster. What do I/you/we need to change to enable this capability?

 

I've had a look through all the files and can't find anything obvious that looks right to change (remember I'm no coder) if it's possible (and I'm sure it must be). And i've tried it as is and it halts at grey screen, apple no throbber (yeah been there before!)

[blackosx]

Hi dutchhockeypro

 

Just look how much work I had to do to solve problems that I didn't even knew about. No complaints here, but it is a fact that my hardware, and my limited experience with OS X itself, is hindering my development so I need you gentlemen. If only for inspiring me so thanks again for being who you are, and being here. I really appreciate it.

Happy to help. This is also a learning process for me as well as some fun.

 

And here are the new files. So what changed this time:

....

Make sure to use either static or dynamic data gathering for both CPU and SMBIOS, because this is what I was referring to when I said that my CPU speed was displayed wrong (in System Profiler). Apparently a simple SMBIOS initialization error.

Thanks for the 636_5 update and I've successfully booted with it.

 

Now, I used the following which is against your recommendations:

#define DYNAMIC_SMBIOS_DATA_GATHERING 0

#define DYNAMIC_CPU_DATA_GATHERING 1

but I don't see any problems doing so. Maybe there's something I'm missing or not seeing?

 

I also thought I'd look at trying to use static cpu data but I need to better research some of the values required. I started with sysctl -a | grep cpu but I don't think I can get everything from that? I also looked at this Intel page for more details but I'll work more on that later.

[DB1]

Hi DB1,

 

Sounds cool. I think that you need to set a directive for this. Let me check... Ok the directove is there, but I ripped out the EFI support. Can have a go and put it back tomorrow. I'll let you know when I have something to test.

 

Wicked, catch up tomorrow.

[blackosx]

Why don't you use the DEBUG_CPU directive in cpu.c to dump the values?

Thanks. I did and I now have my values

 

p.s. Dad said not to bet on one horse, saying what if... what are you going to then? I think this programming stuff might be it. My backup plan

You're dad's a wise man and it's sensible to have a plan B. So yes, I'm sure your programming aptitude can propel your career if you choose that route.

[blackosx]

And using cpu/static_data.h now also work for you?

I'm not sure.

 

Sysctl -a | grep cpu shows the same info when booting Revolution with my static cpu data, as I see when booting with Chameleon which I guess is correct?

 

I'll hopefully have more time to check things this evening, but for now I can tell you that when using static_cpu data, that I see a difference only in hw.busfrequency_max from the result of sysctl -a.

Booting from Chameleon RC5: hw.busfrequency_max: 1066708400

Booting from Revolution 636_4: hw.busfrequency_max: 1066712932

Booting from Revolution 636_5 with dynamic CPU: hw.busfrequency_max: 1066711864

Booting from Revolution 636_5 with static CPU: hw.busfrequency_max: 1064000000

 

But changing this line:

char * s = "Intel® Core2 Duo CPU E7300 @ 2.66GHz";

to read something completely different didn't have any effect.

 

I haven't wanted to put any different data in to my /cpu/static_data.h incase it causes problems but I might try that later. But if you want to give me a definitive test to try then I will.

 

Gotta pop out now - be back later...

 

 

P.s. sorry to cause trouble, but my mother is rather furious about me speaking out and wants me to remove any/all reference to my sport, so would you gentlemen please follow suit. Thank you.

No problem. Done.

[DB1]

Hi DB1,

 

I have a spare SD card for testing, now that I bought a new/bigger/faster one. I used Disk Utility to create a GUID Partiition Table on it, but there is no EFI partition on it. Should I create it myself?

 

I have since added a debug dump to disk.c and it locates and reads the EFI partition (on another volume) so it looks promising. One note. I changed it to:

Not sure about formatting an SDcard to mirror a hdd with EFI partition but I guess you would just format in the same way you would a hdd (Guid). I don't have a spare SD to try it though.

 

Looks like good progress if your finding on another volume so it probably will work. Unfortunately I have to go out so cannot try this till later today. Have pm'd some info.

[DB1]

And using cpu/static_data.h now also work for you?

 

 

 

Hi DB1,

 

I have a spare SD card for testing, now that I bought a new/bigger/faster one. I used Disk Utility to create a GUID Partiition Table on it, but there is no EFI partition on it. Should I create it myself?

 

I have since added a debug dump to disk.c and it locates and reads the EFI partition (on another volume) so it looks promising. One note. I changed it to:

									if (isPartitionUsed(gptMap))
								{
									BVRef bvr = NULL;
									unsigned int bvrFlags = kBVFlagZero;

[color="#FF0000"]#if DEBUG
									char stringuuid[100];
									efi_guid_unparse_upper((EFI_GUID*)gptMap->ent_type, stringuuid);
									printf("Reading GPT partition %d, type %s\n", gptID, stringuuid);
#endif
[/color]
									if ((efi_guid_compare(&GPT_BOOT_GUID, (EFI_GUID const*)gptMap->ent_type) == 0) ||
										(efi_guid_compare(&GPT_HFS_GUID, (EFI_GUID const*)gptMap->ent_type) == 0))
									{
										bvrFlags = (efi_guid_compare(&GPT_BOOT_GUID, (EFI_GUID const*)gptMap->ent_type) == 0) ? kBVFlagBooter : kBVFlagZero;
										bvr = newGPTBVRef(TYPE_HFS, biosdev, gptID, gptMap->ent_lba_start, gptMap, true, bvrFlags);
									}
[color="#FF0000"]#if EFI_BOOT_SUPPORT
									else if ((efi_guid_compare(&GPT_EFISYS_GUID, (EFI_GUID const*)gptMap->ent_type) == 0))
									{
										printf("Matched: GPT_EFISYS_GUID\n");

										if (readBootSector(biosdev, gptMap->ent_lba_start, (void *)0x7e00 ) == 0)
										{
											printf("readBootSector() was successful.\n");

											bvr = newGPTBVRef(TYPE_HFS, biosdev, gptID, gptMap->ent_lba_start, gptMap, true, kBVFlagEFISystem);
										}
									}
#endif[/color]
									if (bvr)
									{

You need to add the #define DEBUG 1 directive yourself (somewhere at the top of the file).

 

Ok did this and got no boot, then changed this from 0 to 1: #define EFI_BOOT_SUPPORT 0 // Only supported by Chameleon, not by Revolution!

 

And were up and running. Great stuff DHP.

[DB1]

Thanks. This is so sweet. I cannot believe that it was this simple. Waiting for the catch to hit me. BONG. LOL

 

The funny thing is that everything I need is available in the original SMBIOS table. At least on the HP I have here. We just overwrite it with our own data. That doesn't seem right to me.

 

One thing bugging me is that with Chameleon Smbios recognises my machine as Macbook 4.1 and as such I have full functionality with the kexts I have in EFI/E/E. With Revolution smbios finds as MacBookPro 6.1 and I lose some functionality ie. webcam not working and the graphics are sluggish at boot up until login screen. These may not be down to smbios though and could be due to device support in Chameleon but in all honesty I just don't know.

[humph]

Hi all, or perhaps I should be saying "DHP-Gang"

 

Sort of back from somewhat busy weekend and have just got v5 up. It's booting.

But am seeing some newly strange things, which I have yet to check into.

 

0. Using for now, dynamic CPU and SMBIOS..

 

1. SMBIOS dump, converted using smbiso2struct is giving different values for size and count than before. I realize that SMBIOS init is changed. However on previous version(s) got values that I think were same as from a dump in Linux. But that data is on other machine/partition at home so gotta re-check. Also do a byte compare of the tables.

 

2. CPU info is also different! Capabilities number and, interestingly, speed (798MHz); this from debug CPU output.

Whether that is measuring current speed, or max speed might explain things. Or could be a bad calc somewhere? But, as before, do get up to full 1596MHz in real life via MSRTools/VoodooMonitor.

 

p.s. Am also running as MBP6,1; whereas used to be MB5,1 on Cham. Camera sort of works, in that I need to use CamTwist to get output in PhotoBooth - but that's same as before.

[DB1]

This should be a one liner fix. Let me check that right now for you... And here it is.

	sm_defaults = defaults_MacBookPro;

Comment it out (function sm_get_defstr in smbios/dynamic_patcher.h) . That should do the trick.

 

p.s. You need to run smbios2struct after the change when you use static SMBIOS data.

 

Your on it today girl, that's 2 out of 2 for me, now back to MacBook 4.1 and webcam now working and all same kexts loading as Chameleon.

 

There's just the lag between greyscreen and login (Vbios? edid?) to sort out and then it's goodbye chameleon.

 

FI. Chameleon 2.0 RC5 v693 patched for Atom kernel panic avoidance, GMA950, edid.

 

EDIT

 

Checked the kernel log and see message. Display: not usable. Though eventually everything comes up, could explain the time lag. My money is on edid problem. Is this something we can fix via Revolution, can i fix display/graphics somehow by putting edid in Private data, or do I need to find another way? edid showing ok in ioreg and comparable to that when booting Chameleon.

 

Maybe I need to set up static smbios and cpu?

[blackosx]

Small fluctuations are fine (I'm told) for as long as they stay within limits.

That's fine then. I was just questioning why when using static cpu data, hw.busfrequency_max: would show as such a rounded number, in this case 106400000?

 

Correct. This doesn't do anything. Can be removed (saving 64 bytes again).

Removed it.. which works fine.

 

Also tested to see if /cpu/statid_data.h was working by removing all data from:

void initCPUStruct(void)
{
}

and of course compiling with #define DYNAMIC_CPU_DATA_GATHERING set to 0 and the resulting boot KP'd with our well known panic (cpu 0 caller 0xnnnnnn): "tsc_init:...." error. Adding the code back allows the boot to complete so the injection must be working.

 

I wouldn't dare. Too scared to blow up something.

Likewise. I think it's best not to touch anything there.

 

---

 

@DB1 and humph - Great news to hear about your swift progress too

[humph]

Hi, back again. Really weird - but good situation.

 

So, got home, rebooted etc. Now I get CPU debug different again. Main change is Current and Max Coef are 0xC. Capabilities aka Features different to Rev 3&4 but same as last 1st time I tried v5.

And CPU freq is back at 1.6GHz. With a couple of different numbers in smbios table.

 

Still the other differences c/f version 3&4 on smbios size & count. But if changes are to be expected then not gonna worry about all that. As it works.

 

So, wont waste your time with CPU debug message, smbios table info etc. (PS other Chameleon I use is both RC5 trunk and Valv's 5.13 (707?)). P.S. Meant MBP 5,1 not MB 5.1

 

The only thing I can think that's different this time, is that rather than doing a restart when changing out bootloaders from old to new to debug versions, this time I've come at it from a power-off situation. So that might be somehow relevant. Anyway, all is good, and repeatable.

 

@DB1 - So are you using the CPIUID Symbols/Override from Meklort? Thought that gave KP unless MBP 5.1. If is working for you with MB 4,1 perhaps I should give it a try and see if other stuff somehow better. Although I dont seem to have any issues with MBP6,1.

I also get the display not usable message. Can't recall whether have it with Cham. Off to test.

[DB1]

What do you mean with 'edid problem'? You have to inject a patch copy of EDID or is there anything else that you (have to) do with Chameleon for this? And this all just because of a changed model identifier?

 

 

Reading EDID is easy, but I first need to know why you need it.

 

p.s. We obviously do nothing graphics related so that might be it.

 

In chameleon I have patched edid, GMA950 graphics are a pain.

 

Model identifier made my webcam work again but did not effect boot lag, that was there before but I don't recall at what stage I noticed this problem. The kernel message says I have a display issue and as Revolution does nothing with graphics I'll need to find another solution to that then.

 

The lag is between throbber disappearing and log in screen becoming visible so not sure of the cause but the kernel message is only clue I have to go on at the moment.