Jump to content

How to boost the OS X boot process...


1,027 posts in this topic

Recommended Posts

More good news. The UUID getter/setters are now working properly on a drive with three partitions. Even when I boot from my USB-stick. Yah!

...

Attached is a newly updated copy of disk.c Please give it a try.

Hi DHP.. it works for me.. great job ;)

I removed the UUID reference from my c.a.B.p and let it reboot to see what happens.

However it chose to boot my OSX1 volume, disk0s3. Where I'd rather it booted my Mac volume, disk 1s3. Shall I change the boot order of my drives in BIOS? or is there another way.. Here's my diskutil list.

 

/dev/disk0
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:	  GUID_partition_scheme						*500.1 GB   disk0
  1:						EFI						 209.7 MB   disk0s1
  2:				  Apple_HFS REV					 1.1 GB	 disk0s2
  3:				  Apple_HFS OSX1					120.0 GB   disk0s3
  4:	   Microsoft Basic Data						 80.0 GB	disk0s4
  5:				  Apple_HFS OSXBACKUP			   40.0 GB	disk0s5
  6:				  Apple_HFS STORAGE				 258.3 GB   disk0s6
/dev/disk1
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:	  GUID_partition_scheme						*500.1 GB   disk1
  1:						EFI						 209.7 MB   disk1s1
  2:				  Apple_HFS Booter				  1.1 GB	 disk1s2
  3:				  Apple_HFS Mac					 120.0 GB   disk1s3
  4:	   Microsoft Basic Data						 80.0 GB	disk1s4
  5:				  Apple_HFS Backup				  32.0 GB	disk1s5
  6:				  Apple_HFS Data					266.3 GB   disk1s6
/dev/disk2
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:	  GUID_partition_scheme						*1.0 GB	 disk2
  1:				  Apple_HFS Revolution			  1.0 GB	 disk2s1

 

Hmm. What is mom cooking. I'm getting hungry. Dinner time. Back later...

mmm I'm getting hungry too.. Can I have some.. ha ha :D

Link to comment
Share on other sites

This solved my boot problem with all the HD connected! Good job.

Now I can boot from chameleon the right volume without unplug the other HD.

NOTE: I still have the uuid in c.a.B.p.

 

But again I can't boot without -x in c.a.B.p.

 

If I use dynamic smbios detection I get a KP, not an hang like with my probably uncomplete smbios data...

Link to comment
Share on other sites

Good evening lady (you know who you are!) and gentlemen

 

Have just tested the new disc.c on my rig, it boots the Raid0 volume (my main drive) no problems, the only drawback is that it chooses my external USB backup drive in preference when that is connected at startup. The bios is configured to boot via the raid controller first, usb drive second. I've noticed that in disk utility the USB drive is always disk0, the raid drive volume disk1 when the usb drive is connected at startup. I wonder, is there any way to 'prioiritize' partitions via the bootloader??

 

NB no uuid needed in c.a.B.p

 

NNB Just seen the bit above about removing boot.efi from the drive I don't want to boot from. What if I want to boot from both (for testing Rev amongst other things)?

Link to comment
Share on other sites

And add this as first line:

printf("getAddressOfSmbiosTable() = 0x%08x\n", getAddressOfSmbiosTable() );

Not getting the address will trigger a KP.

I can still boot with this with -x

without uuid it loads another installation than the one on the HD where revolution is installed

 

now i'll try without -x

Link to comment
Share on other sites

Yes. Revolution will boot from the first drive where it locates: /System/Library/CoreServices/boot.efi

so you either have to rename or (re)move this file (on the drive you don't want to boot from). Easy isn't it :(

No problem. I changed boot priority of HDD in bios and now revolution from USB boots my preferred system. :D

Link to comment
Share on other sites

humph should try this too, but swap the two inside "if (gKextLoadStatus != 3) {}" because he gets a KP in Safe Boot.

Hi good evening DHP & all. Trust you had a fun weekend.

Well, that did not work - still get KP if trying to boot safe. But did not try changing both entries etc yet.

 

Also, with new disk.c, it's still booting disk0s4 rather than disk0s2 who's UUID I have in caBp.

(Booting off USB stick so that's another disk).

But not had time to check details etc, and so might be something I'm doing wrong or a typo...More tests tomorrow..

Link to comment
Share on other sites

Will attach another big update later today. Trust me when I say that you gentlemen are going to love this one :P

Eagerly awaiting!! Meaning looking forward to it, no pressure of course! :D

But I'll have to be patient anyway and probably won't be the 1st to try and report back, as have orchestra rehearsal tonight. :)

Link to comment
Share on other sites

Good evening folks,

Make it fit your hardware while I work on a new release... And here it is; Revolution-637

 

Nice to see this modification to private data. I've made my adjustment waiting for the next update, Good Job :(

 

 

 

EDIT: I've added:

#define RAM_SERIAL_NUMBERS				{ "N/A", "Serial#2", "N/A", "Serial#4", 0 }

[color="#FF0000"]#endif
[/color]

 

in private_data.c to compile it, let's try...

Link to comment
Share on other sites

Like the New Private Data ....makes it simple ...

Also added the endif to compile

 

There is a change I see now .... but picture says a thousand words

post-288399-1296508300_thumb.png

Link to comment
Share on other sites

Hi dutchhockeypro.

 

Like the big changes and I agree with the others that moving almost all specific info in to private_data.h is a smart move, and will hopefully keep managing build and updates simpler. Great job.

 

I'm off to try all this now..... BBL

Link to comment
Share on other sites

Good evening folks,

 

Had a two hour long hockey training after dinner so let's get cracking on the new files. Let's start with the one you'll need first. And one that immediately reveals what I have been working on – made a few last minute adjustments, but the site reaction time was pretty slow. Anyway here's number one. Make it fit your hardware while I work on a new release... And here it is; Revolution-637

 

Getting a massage now so I will be off-line for approx ~1 hour.

 

NICE,NICE,NICE, works good for me (on SDCard and will try shortly on my other hdd from EFI) except I got the after throbber delay again but I don't think this directly related to Revolution and I'm still trying to find the answer. The sys.log error points to apple wifi card connection / keychain problem and have read Mac users have had similar since going to 10.6.6.

 

A couple of suggestions:

 

Can the EFI64/32 switch and the EFIBoot_Support switches go in PrivateData?

 

Great work as always, Thanks

 

UPDATE

 

Re memory detection: Have never had part or serial no's detected but now have on one stick. Strange though one stick shows 800mhz and the other 667mhz both are 32mgb instead of 1gb (always have been like this)

 

UPDATE 2

 

Boot's from EFI fine (except the problem previous mentioned)

Link to comment
Share on other sites

Is this with the default settings? If not, which did you change?

 

p.s. Please set the DEBUG directives to 1 to see what it does before it stops.

only added the endif and my own info where needed. Settings are default

Link to comment
Share on other sites

Bah. Something smells awful here. Like burned plastic. Need to check what this is....

Hope it's nothing serious... :unsure:

 

But just reporting success with Revolution-637 with most of the default settings in private_data.h, though I need to double check a few static settings as I had a stall followed by reboot when adding everything in one go to private_data.h. I have since been adding bit by bit and can confirm static SMBIOS and static EFI working, but as of yet need to play again with using static DSDT data.

 

EDIT: static DSDT data works just fine.

 

There's no inclusion of static CPU data in private_data.h? is this to come?

 

But again, great job and once I have familiarised myself with the changes, I'll get to work to tweaking the RevStart script to help out.

Link to comment
Share on other sites

Yes I am actually thinking I might have to flash to latest standard bios .... but I don't want to break this install ....Maybe pull out the old ep35ds4 to try it on ....Not sure. for some reason also when I use chameleon usb boot my GFX is not working correctly, if I use your "modified" boot-loader where I don't need Graphics enabler = yes all works fine.

Link to comment
Share on other sites

Groot - no need you re-flash your bios. Infact having a modified bios should actually make things easier for you.

Here's something for you to try with regard to setting your private_data.h.

 

But note I haven't included everything here, only some of the settings that your bios should allow you to use. I also don't know how far you've got with say creating static SMBIOS data, but you'll still want to set things like your model name, system_ID etc.

 

#define ACPI_10_SUPPORT 1

#define PATCH_ACPI_TABLE_DATA 0

#define STATIC_ACPI_BASE_ADDRESS 0

#define STATIC_APIC_TABLE_INJECTION 0

#define STATIC_DSDT_TABLE_INJECTION 0

#define STATIC_SSDT_PR_TABLE_INJECTION 0

#define STATIC_SSDT_USB_TABLE_INJECTION 0

#define STATIC_GPU_TABLE_INJECTION 0

#define LOAD_DSDT_TABLE_FROM_EXTRA_ACPI 0

#define LOAD_SSDT_TABLE_FROM_EXTRA_ACPI 0

#define DROP_SSDT_TABLES 0

#define APPLE_STYLE_ACPI 1

#define FIX_RESET_GAS 0

#define ACPI_DEBUG 1

 

#define PRE_LINKED_KERNEL_SUPPORT 0

#define DEBUG_BOOT 1

 

#define DEBUG_CPU 1

 

#define APPLE_STYLE_EFI 1

#define DEBUG_EFI 1

 

I'm not saying this will get you booted but with all the debug turned on, and making the most of your bios, let's see how far you get.

Link to comment
Share on other sites

one thing I am not sure of is #define PUT_YOUR_STATIC_ACPI_BASE_ADDRESS_HERE ....

the rest I have set as above for now and will test.

not sure how to do all the static SMBIOS data ....

Rest is fairly straight forward

Link to comment
Share on other sites

You get the static ACPI address from enabling the debug in the source, though can't remember which one so safe bet is to enabled them all. But I guess you haven't managed to see that far in the boot process yet to reveal that, so leave that set to 0 for now.

 

For the SMBIOS data, boot in to your OS X system with chameleon using an optional SMBIOS.plist to populate your info and then run the smbios2struct tool (double-click it). Then copy and paste the data (all the hex numbers) in to private_data.h. You'll find the smbios2struct tool posted recently.. or use my now out-of-date Revstart script to generate it for you as it has the smbios2struct binary in the tools folder (just don't use the private_data.h file).

 

Good luck. I'm off to bed now - I'll check back here in the morning.

Link to comment
Share on other sites

I have the feeling that it stops at this line:

kernelFlags = malloc(kernelFlagsLength);

Please add a few printf statements in this block to see where it stops (appears to be related to a value in com.apple.Boot.plist).

 

Does not even see anything before this code, tried (allot) of printf("test XYZ"); and don't see anything but the one from below

#if SAFE_MALLOC
static void mallocError(char *addr, size_t size, const char *file, int line)
{
stop("\nMemory allocation error! Addr=0x%x, Size=0x%x, File=%s, Line=%d\n", (unsigned)addr, (unsigned)size, file, line);
}
#else
static void mallocError(char *addr, size_t size)
{
printf("\nMemory allocation error (0x%x, 0x%x)\n", (unsigned)addr, (unsigned)size);
asm volatile ("hlt");
}
#endif

 

I tell you this is a steep learning curve for a old man :thumbsup_anim:

Link to comment
Share on other sites

Can the EFI64/32 switch and the EFIBoot_Support switches go in PrivateData?

 

 

I've moved EFI 64/32 putting this in libsaio/efi/essentials.h:

 

#define __LIBSAIO_EFI_ESSENTIALS_H

[color="#FF0000"]// Global private data storage file.
#include "../../../private_data.h"
[/color]
typedef void      VOID;

 

in place of this red part:

 

#endif

//---------------------------------------------------------- EFI/ESSENTIALS.h ---------------------------------------------------------------


[color="#FF0000"]#define EFI_64_BIT							1	// Set to 1 by default for EFI64 on 64-bit platforms. Supporting both 
// 32 and 64-bit boot modes (using arch=i386/x86_64 under Kernel Flags).
// 
// Change this to 0 for 32-bit only platforms (think Intel Atom CPU) 
// or when you want to boot with EFI32 (for testing) on a 64-bit 
// platform, but then you must make one small change in platform.c 
// (see comment in formentioned file).
//
// Note: Do not change this setting, unless you know what you are doing.[/color]


//-------------------------------------------------------------- PLATFORM.C ----------------------------------------------------------------

 

that I have copied in my private_data aftec EFI.C options before platform as you can see.

 

but I can't find the EFIBoot_Support you mentioned...

Link to comment
Share on other sites

@scrax: Please hold off with making changes. Things will be different soon. You better try to get to the bottom of your boot problem first :wacko:

 

Yes I give up and removed the wrong modification when i realized they don't work.

 

Using this option I can boot without -x finally!

#define ACPI_10_SUPPORT						1	// Set to 0 by Default. Set to 1 for ACPI 1.0 compliant BIOS versions.
#define PATCH_ACPI_TABLE_DATA				1	// Set to 1 by default (enabling patching). Use 0 to keep the original 
#define STATIC_ACPI_BASE_ADDRESS			1	// Set to 0 by default. Use 1 only after gathering the base address!
#define STATIC_APIC_TABLE_INJECTION			0	// Set to 0 by default. Use 1 when you want to inject a modified 
#define STATIC_DSDT_TABLE_INJECTION			1	// Set to 0 by default. Use 1 when you want to inject static DSDT data.
#define STATIC_SSDT_PR_TABLE_INJECTION		0	// Set to 0 by default. Use 1 when you want to inject your Intel 
#define STATIC_SSDT_USB_TABLE_INJECTION		0	// Set to 0 by default. Use 1 when want to inject USB related 
#define STATIC_GPU_TABLE_INJECTION			0	// Set to 0 by default. Use 1 when you want to inject modifications
#define LOAD_DSDT_TABLE_FROM_EXTRA_ACPI		0	// Set to 1 by default. Use 0 only when your configuration can do 
#define LOAD_SSDT_TABLE_FROM_EXTRA_ACPI		1	// Set to 0 by default. Use 1 when you know how to override / patch 
#define DROP_SSDT_TABLES					0	// Set to 0 by default. Use 1 with caution (might disable SpeedStep).
#define	APPLE_STYLE_ACPI					1	// Set to 1 by default. Use 0 to use the factory OEMID's.
#define FIX_RESET_GAS						0	// Set to 1 by default. Change to 0 for non-Intel chipsets!
#define ACPI_DEBUG							0	// Set to 0 by default. Use 1 when things don't seem to work for you.
#if STATIC_DSDT_TABLE_INJECTION
#define	PUT_YOUR_STATIC_ACPI_BASE_ADDRESS_HERE		0x000f7d40
#define PUT_YOUR_STATIC_DSDT_DATA_HERE \
0x54445344, 0x00004D69, 0x50410201, 0x20454C50, 0x63614D69, 0x00000000, 0x00090001, 0x4C544E49, \
0x20091112, 0x5250805B, 0x0A013054, 0x5B020A80, 0x52500B81, 0x50123054, 0x10483038, 0x5053805B, \
0x0B015452, 0x020A052E, 0x530B815B, 0x11545250, 0x504D5353, 0x49805B08, 0x01545F4F, 0x0A08000B, \
complete dsdt with graphics and alll...
#endif
#define PRE_LINKED_KERNEL_SUPPORT			0	// Set to 1 by default. Change this to 1 to disable the use of pre-linked kernels.
#define MUST_ENABLE_A20					0	// Set to 0 by default. Change this to 1 when your hardware requires it.
#define SAFE_MALLOC						0	// Set to 0 by default.
#define DEBUG_BOOT						0	// Set to 0 by default. Change this to 1 when things don't seem to work for you.
#define USE_STATIC_CPU_DATA					0	
#define DEBUG_CPU							0	// Set to 0 by default. Change this to 1 when things don't seem to work for you.
#define APPLE_STYLE_EFI						1	// Set to 0 by default. Change this to 1 to add additional 'Mac-like' properties.
#define INJECT_EFI_DEVICE_PROPERTIES			0	// Set to 0 by default. Change this to 1 when you need to inject 'device-properties'.
#define DEBUG_EFI							0	// Set to 0 by default. Change this to 1 when things don't seem to work for you.
#define EFI_64_BIT							1	// Set to 1 by default for EFI64 on 64-bit platforms. Supporting both 
#define DEBUG_PLATFORM						0	// Set to 0 by default. Change this to 1 when things don't seem to work for you.
#define MAC_PRODUCT_NAME					"iMac9,1"
#define USE_STATIC_SMBIOS_DATA				1	
#define DEBUG_SMBIOS						0	
#if USE_STATIC_SMBIOS_DATA
#define	PUT_YOUR_SMBIOS_SM_STRUCTURE_SIZE_HERE		127
#define	PUT_YOUR_SMBIOS_DMI_STRUCTURE_COUNT_HERE	42
#define PUT_YOUR_SMBIOS_DATA_HERE \
/* 0x0000 */	0x00001800, 0xe0000504, 0x9e900f06, 0x00007fcb, 0x05330000, 0xffffffff, 0x656f6850, 0x2078696e, \
/* 0x0008 */	0x68636554, 0x6f6c6f6e, 0x73656967, 0x544c202c, 0x2e360044, 0x50203030, 0x31300047, 0x2f36322f, \
...this is the one I get from smbios2struct with some missing code added...
/* 0x0168 */	0x20000000, 0x0000260b, 0x00000000, 0x00000000, 0x0027047f, 0x06830000, 0x05010028, 0x06840000,	\
/* 0x0170 */	0x00000029
Link to comment
Share on other sites

Yeah. Sorry for not getting it earlier. Please toggle MUST_ENABLE_A20 to 1 and try again.

 

/me writes a short note to add a comment for this...

Compile error ....Will look later into it, gota run now

Link to comment
Share on other sites

Goor Morning DHP :wacko:

 

I know you're busy with more important stuff, but I just thought I'd mention that since the latest changes I now see an off centre Apple logo at boot?

post-331032-1296544556_thumb.jpg

 

Also, just for the record here: my boot time from HDD has reduced further ;).

 

For my Fresh OS X system (nothing added to it)

From bios POST to desktop now takes 40 seconds

(which is better than my 27" i7 iMac which takes 46 seconds).

Split times: from HDD selection in bios to throbber is 10.8 seconds, reaching desktop at 25.4 seconds.

(An improvement on the 29 seconds I'd previously posted)

 

A quick second test for my other OS X system (with VMWare installed and all my other apps etc.)

Split times: from HDD selection in bios to throbber is 10.8 seconds, reaching desktop at 33.4 seconds.

(Compared to Chameleon times of 13.2 / 37.3 respectively).

Link to comment
Share on other sites

 Share

×
×
  • Create New...