How to boost the OS X boot process...

[DB1]

Hi DB1,

 

May I ask how did you collect this info? Also. Your dump tells me that your system is ACPI 3.0 compliant. Why? Because under "Factory RSDP:" I see this rsdp->Revision: 2 and your RSDP signature is XSDT instead of RSDT (for ACPI 1.0). Please compile Revolution with ACPI_10_SUPPORT set to 0 and attach the same kind of dump. Thank you.

 

I video then typed up, it was set at 1 and then I tried 0 but did notice any significant changes and had not re video to check. Re ACPI 3.0 blackosx pointed us at that a couple of days back but I was not convinced as previous ACPI dumps and extracted dsdt stated ACPI 1.0. A bit bizarre to say the least.

 

attached my updated debug: DubugOutput.txt

 

Off to work now may catch up this evening.

[blackosx]

Gentlemen: The files in this attachment aren't thoroughly tested, but it is mostly a matter of moving the new code into macro's. There's one new file called debug.h where all debug related stuff went to.

 

I had to make this change because reading the file(s) became too tedious. Even on my MacBookPro. Give it a go and let me know what you think of it.

Good idea. I've downloaded the files and had a quick look though I might not get time to any testing this evening. I'll report back when I do. Keep up the good work.

 

oh.. and dutchhockeypro, about the tests which I failed to do, if you still want me to run them, I will do but I will need your assistance to show me exactly what to do.

[DB1]

may be related to his CPU Wasn't that some Atom type?

 

So tell me. Are you using dynamic or static CPU/SMBIOS data?

 

Just to be sure: What is the problem at this moment? HPET related KP?

 

Gentlemen: The files in this attachment aren't thoroughly tested, but it is mostly a matter of moving the new code into macro's. There's one new file called debug.h where all debug related stuff went to.

 

Both are set dynamic and when I dubug cpu it finds and details it ok. I only raised the HPET thing because I notice others debugs had it in. I get grey screen, apple no throbber after the debug finishes.

 

I get a compile error with the new files.

 

In file included from acpi/patcher.h:10,
			 from acpi_patcher.c:94:
acpi/debug.h:89:37: error: macro parameters must be comma-separated
In file included from acpi_patcher.c:94:
acpi/patcher.h: In function ‘setupACPI’:
acpi/patcher.h:180: warning: unused variable ‘tableName’
acpi/patcher.h:335: warning: implicit declaration of function ‘_ACPI_DEBUG_DUMP_SLEEP’
make[2]: *** [acpi_patcher.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

[dgsga]

I've just tested the latest acpi changes (acpi634 v3 plus patch) on my acpi 2.0 rig, compiles fine, all appears well on debug, but the DSDT.aml in Extra/ACPI isn't loaded. Luckily I still get to desktop but a quick look at ioreg confirms that the native DSDT is being used. I have LOAD_DSDT_TABLE_FROM_EXTRA_ACPI set to 1 in acpi_patcher.c, and have checked the aml file is where it should be. Am I missing something obvious here?

[DB1]

The only thing I miss in it is the rootUUID debug output (see post #327). Can you please add that to see if it locates your system volume?

 

I get: (rootUUID [0] == Initializing property boot-uuid (589727)

 

Thank you for catching these. This should do the trick.

acpi/debug.h

-#define _ACPI_DEBUG_DUMP_SLEEP(int seconds)
+#define _ACPI_DEBUG_DUMP_SLEEP(seconds)

acpi/patcher.h

+#if DEBUG
		char * tableName[] = { 0, 0, 0, 0, 0 };
+#endif

yeah that fixed it, thanks. And it's pleasure to help out where i can.

p.s. See boot.h for that issue with the Apple boot logo being off center. The (static) default values are 1024 / 768 but that obviously isn't working for your system.

Sorted this out now thanks again.

I would also like to recommend that you use the same file group/ownership settings as on your regular OS X system volumes. This because I think that OS X uses these file rights to launch applications with. I'm not sure what the correct name for this is, but I remember having read something about it.

I dont think thats a problem as that and the previous permissions set up works fine on my Chameleon EFI configuration.

 

Ok, I think I may have an inkling where to narrow down the problem I have and its because you raised the possibility of Atom cpu. In 10.6.1 (from memory) Atom support was withdrawn from mach_kernel, some guy's came up with a kernel patch for the Chameleon boot loader which worked fine. More recently some others created a couple of kexts so the kernel no longer needed a patch and I have these in my /Extra/Extensions on the USB SD card booter.

 

So whats the relevance! Well it works ok on the SD card and EFI booter with Chameleon boot so in theory it should work with Revolution, but maybe the pace at which it boots maybe the kexts are not loading to do their magic before the kernel panics. OR my Extra/Extensions are not loading at all (12 kexts). Hmmm!

 

EDIT

 

Having just read dgsga (hi pal) it seems possible dsdt might not be loading (is anything loading from Extra - for anyone?)

 

EDIT 2

 

To eliminate potential Atom cpu panic I applied the patch to boot 2 as we (Atom cpu users) used to for Chameleon, still no boot.

[DB1]

this may be due to PATCH_ACPI_TABLE_DATA set to 0 In which case it will skip almost everything.

 

Got to do my homework first now. Will be back later.

 

No I'm set at 1.

[dgsga]

Can't test this (the HP is being used by someone else) but this may be due to PATCH_ACPI_TABLE_DATA set to 0 In which case it will skip almost everything.

 

Got to do my homework first now. Will be back later.

 

 

PATCH_ACPI_TABLE_DATA is set to 1. I'll check again to see if I've missed anything

[blackosx]

Hi DHP

 

I have replace my files with the new files from the acpi_634_3.zip along with the fixes from past #348 then flicked the switches in acpi_patcher.c to 1 for the following options:

#define ACPI_10_SUPPORT 1

#define PATCH_ACPI_TABLE_DATA 1

#define STATIC_ACPI_BASE_ADDRESS 1

#define LOAD_DSDT_TABLE_FROM_EXTRA_ACPI 1

#define DEBUG 1

 

Rebooting gets so far, but after loading all the ACPI tables etc.. the machine just reboots and doesn't get as far as loading the kernel.

 

Here's the debug I see (though the pics don't show the remainder of the ACPI tables loading)

 

From looking at the debug, I don't see any of the ACPI 1.0 changes to the modified RSDT as coded in updateACPITableData in acpi_patcher.c.

 

I'll look into this more.

 

EDIT:

Sussed that I needed to change #define FAKE_APPLE_DATA to 1

and now I see correctly modified RSDP and RSDT tables as per function updateACPITableData

The machine still reboots though before loading the kernel.

[blackosx]

First. Sorry for not being here yesterday evening, but my mom blocked me from working on this. You know. The usual protective stuff – you are working too much on this.

../snip/..

Yikes! We're still not dropping tables, and indeed do not inject anything DSDT'ish. Investigating...

Good morning dutchhockeypro.

 

No need for apologies on your attendance here, come as go as it best suits you (or your mom - bless; she's only looking out for you). Shall I hold off on the diff for now until you've looked at the dropping / injecting of tables?

[blackosx]

OKay - Can I just check I'm doing it right?

I've been using the command patch -p1 < xxx for previous patches is that still the best way to do it? as this time I get:

missing header for unified diff at line 3 of patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
....

[blackosx]

No probs. I've done it by hand

testing now...

 

Booted successfully and DSDT loaded fine.

I'll just put together my debug photos - here you go.

[blackosx]

I have made another version here but this time using your files from acpi_634_5.zip.

This compiles and boots fine - good job

Also booting with this one shows me some extra debug, which I guess you added since the previous patch or maybe I missed when doing my manual patching - either way it doesn't matter, but those lines I see are:

customDSDT @ : 0x00ec7000
mayDropTable: 0x474d4154
mayDropTable: 0x43494c53

I won't post new pics but just letting you know I see it.

 

p.s My boot is now 50912 bytes.

[blackosx]

It will be 3,167 bytes smaller with the next update, when you get the following data from /System/Library/CoreServices/boot.efi

Wonderful. I'll keep my eye out for future updates.

[dgsga]

Wonderful. I'll keep my eye out for future updates.

 

 

Hi All

 

Can confirm that latest v5 ACPI is working great Stirling job, DHP, thanks for all your hard work. I don't know how you find the time to do it all... Looking forward to the next update, it's great that less than 50KB of code can get us where we neeed to be.

[dgsga]

Another tip to speed up the boot precess. If you use AppleHDA.kext and a legacy sound kext (like moi) then go to the main AppleHDA.kext in S/L/E and remove all Layout and PathMaps entries from AppleHDAPlatformDriver.kext plist, all HDAConfigDefault entries from AppleHDAHardwareConfigDriver.kext plist (plugins in the main AppleHDA.kext). Then add your IOKitPersonalities plist entries in the legacy kext to FakeSMC plist and get rid of the legacy kext. This saves approx 8 revs of the throbber on my rig as AppleHDA no longer has to load all the plist entries to find a match, only the one for your sound chip.

[DB1]

Thanks for this reminder. We have to show a human readable value.

 

I'll look into it. Say. Do you have /Extra/Extensions.mkext?

 

 

I see. What changes are that?

 

p.s. My /boot is now 43456 bytes – with clut, logo and crc32 files/data removed (we're getting it from boot.efi now).

The latest update ACPI files tested, dsdt now loading however still no boot for me. ACPI 30?

 

Yes I have /Extra/Extensions.mkext, and before you suggest have tried with and without. And have also tried with and without in S/L/C/c.a.k.c/Startup

 

Re the changes to prevent atom panicking kernel it's a patch file added to boot 2. But more recently Meklort has come up with a couple of kexts that replace the need for the patching which is what i'm currently using with Chameleon and have been with Revolution.

 

My dubug with latest files:

 

DHP - Would it be worth checking acpi_patcher.c & .h and acpi.h on the Chameleon trunk to see what it's doing that Revolution might not be? I can boot fine (but slow) with that. No good me checking I dont know what I'm looking for as im not a coder.

 

Appreciate all the hard work you been doing and there's no rush to solve the problem.

[blackosx]

BTW: There's something wrong with this forum; all kind of images/info is missing How am I supposted to logout now, without a link for it?!?

Yeah it was strange but fixed now.

 

The latest update ACPI files tested, dsdt now loading however still no boot for me.

Well done for sticking at it DB1..

I'm just Sorry I don't have the necessary skills to help you with it.

 

EDIT:

I did a couple of tests earlier to see if using Revolution reduced my boot time. I converted my DSDT.aml in to a struct and added it in to /acpi/static_data.h and added #define STATIC_DSDT_TABLE_INJECTION 1 in to acpi_patcher.c. The other options i have set in acpi_patcher.c are:

#define ACPI_10_SUPPORT 1

#define PATCH_ACPI_TABLE_DATA 1

#define STATIC_ACPI_BASE_ADDRESS 1

#define FAKE_APPLE_DATA 1

 

smbios_patcher.c:

#define DYNAMIC_SMBIOS_DATA_GATHERING 0

 

boot.c:

#define PRE_LINKED_KERNEL_SUPPORT 0

 

I then turned off all debug settings and rebooted.

 

Starting timing from when I press return from selecting my USB boot device from BIOS, it took 30 seconds until the throbber appeared, and 53 seconds in total until I was at the desktop.. I have to admit though that I have VMWare Fusion installed and that does increase boot time considerably, however I want to do further testing to build up a better picture.

 

I've also got some data I posted in post #13 which I can bring in to my comparisons (blimey - that was nearly a year ago!)

 

EDIT2:

For comparison, I've just booted from USB using the latest version of Chameleon RC5 (GUI disabled by using GUI=No in c.a.B.p) with the same DSDT and kexts and including the time it took for me to press the down arrow to select my OS X partition, it took 19 seconds for the throbber to appear and 40 seconds until I was at the desktop.

 

I know these simple tests are hardly conclusive and maybe in the future I can construct a proper test with help from DHP to optimize my Revolution build to make the most of it's slimline frame and therefore give it a fair comparison.

 

With that I'm off bed. Goodnight.

[scrax]

no more cmos error with the last change but still not a complete boot...

I'll post dump asap

[DB1]

One down. many to go. Can you please attach your factory facp.dsl for me?

FACP.dsl.zip Does it matter if this extracted from osx or do i need to get from Linux (attached is from osx)

Good thinking. Say. Have you ever, in the past, been able to boot with Revolution?

No never have yet.

 

Ok so the kexts are fine. I wonder if we load them. Have you tried with safe boot (-x) already?

No but will try next. Tried but no go.

 

I did. What I noticed is that Chameleon has a more extended reset fix, which is why I asked you to attach your facp.dsl (to check if that might be the problem). But looking at your ioreg dump... I would say no. I don't think so. Chameleon also runs the loop twice. The first time for ACPI 1.0 and the second run for ACPI 2.0 and greater. But dad told me to ignore it so I will.

He will know!

 

Thank you. You are most welcome. Great to see you here. Hanging in with me while I try to fix this, and learn new things at the same time. And I must say that I really really appreciate it. Thank you!

I'm stubborn!

We'll have a showoff later on, with hard evidence, where and what we gained in milliseconds... or even seconds in certain procedures.

More tricks?

p.s. About finding the time for this; I start hacking around 5-6 AM each day (see post time) so that's the deal.

Wow you are keen and dedicated!

Update: Re-writing EFI source code. Might have found out why some people – most notably DB1 and scrax here – can't boot with Revolution. Light bulb: Can you boot in 64-bit mode with Chameleon? I'm pretty sure DB1's Atom is 32-bit only, but I have yet to check what Scrax is using so... please chime in gentlemen.

Atom is 32bit so never will boot 64bit

[scrax]

That is good to hear. Can you please attach a ioreg dump of your running hack for me? TIA.

 

I'm pretty sure DB1's Atom is 32-bit only, but I have yet to check what Scrax is using so... please chime in gentlemen.

 

I'm using the Zotac in my signature, usually I prefer to boot in 32bit mode, but with chameleon or Grub2 I can boot also in 64bit without problems.

With only 4 GB of RAM I don't think 64bit is really needed but I have made no changes in Revolution or in the c.a.B.p to determine which mode to use so if 64bit is the default mode as chameleon i'm trying to start in 64bit

 

IOREG:

iMacdiScrax.ioreg.zip

 

 

EDIT: SUCCESS!?!

I've added arch=x86_64 in caBp, -x instead of -v and it worked! But... it loaded the wrong system???

 

I have 2 HD

First one with Chameleon and my working system in disk0s2:

/dev/disk0
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:	  GUID_partition_scheme						*128.0 GB   disk0
  1:	   Microsoft Basic Data EFI					 209.7 MB   disk0s1
  2:				  Apple_HFS Gskill				  115.0 GB   disk0s2
  3:				  Apple_HFS Mac OS X Install DVD	12.6 GB	disk0s3

the other one with revolution and my test install on disk1s2:

/dev/disk1
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:	  GUID_partition_scheme						*1.0 TB	 disk1
  1:						EFI						 209.7 MB   disk1s1
  2:				  Apple_HFS ScraxMac				100.0 GB   disk1s2
  3:				  Apple_HFS Data					899.6 GB   disk1s3

 

boot uuid is from disk1s2 but after finishing the debug prompt it loads disk0s3 a volume where I have restored the install DVD of snowLeopard with fakesmc included to load it.

 

I'm pretty sure that it loads c.a.B.p from ScraxMac (disk1s2) because I can see the changes I made to it reflected it the debug info.

 

I'll try to remove the first HD and reboot now, and then I''l make some other test just to have some more to report.

 

 

EDIT2: With only one HD all goes fine but only if I use the -x flag I can boot.

[scrax]

Thank you for testing. Hope to be of assistant.

 

I have this kernel flags in caBp in /Volumes/ScraxMac/Library/Preferences/SystemConfiguration/com.apple.Boot.plist:

 

arch=x86_64 -x rd=uuid boot-uuid=ECFBE09E-8AC0-34E2-93DC-952E4B7E8117

(the uuid is the one i get with disk utility->info on the ScraxMac volume)

 

In acpi_patcher.c I have this options:

#define ACPI_10_SUPPORT					1	
#define PATCH_ACPI_TABLE_DATA			1	
#define STATIC_ACPI_BASE_ADDRESS		1	
#define STATIC_APIC_TABLE_INJECTION		0	
#define STATIC_SSDT_PR_TABLE_INJECTION	0	
#define STATIC_SSDT_USB_TABLE_INJECTION	0	
#define STATIC_GPU_TABLE_INJECTION		0	
#define STATIC_DSDT_TABLE_INJECTION		1
#define LOAD_DSDT_TABLE_FROM_EXTRA_ACPI	0	
#define STATIC_SSDT_TABLE_INJECTION		1
#define LOAD_SSDT_TABLE_FROM_EXTRA_ACPI	0
#define DROP_SSDT_TABLES				1
#define FAKE_APPLE_DATA					1
#define DEBUG							1

 

static dsdt and ssdt data added using the data I have with chameleon now, but when revolution starts I have a unrecognized sata chipset instead of the correct one that i have with chameleon. I'll now try to load the dsdt.aml from /Extra/ACPI to see if it works better. (problem solved, was a missed patch in dsdt.)

 

So now I can boot with only one HD connected, maybe I need to try with an usb bootloader?

 

What do you think about the problem of not booting without -x? Is there some dump that I can provide you?

 

Now I need to leave, see you al tomorrow.

[dgsga]

Great work, but doing this by hand – every time a new update comes out – sucks (sorry to put it so blunt) so would someone here please be so kind and write a script for it?

 

Your wish is my command... The wonders of terminal. This fix patches AppleHDA.kext in S/L/E and can be run each time theres an update. It is an executable shell script, just decompress, double click and it will ask for your password (as chasnges are being made to a file in S/L/E). The addition of legacy HDA plist entries to FakeSMC.kext only needs to be done once and so is much less hassle.

AppleHDAFix.zip

[dgsga]

I thought I'd attach my FakeSMC.kext plist so people can use it as a template. It's combines fakesmc, legacyHDA and orange icon fix all rolled into one so only ever one additional kext to worry about when installing from Snow Leo DVD.

 

I won't go further off-topic than this as I think we should keep this thread focused on Revolution

Info.plist.zip

[FKA]

Thank you dgsga - great thread guys

[blackosx]

Another tip to speed up the boot precess. If you use AppleHDA.kext and a legacy sound kext (like moi) then go to the main AppleHDA.kext in S/L/E and remove all Layout and PathMaps entries from AppleHDAPlatformDriver.kext plist, all HDAConfigDefault entries from AppleHDAHardwareConfigDriver.kext plist (plugins in the main AppleHDA.kext). Then add your IOKitPersonalities plist entries in the legacy kext to FakeSMC plist and get rid of the legacy kext.

Interesting idea dgsga. I already had my AppleHDA stripped to include just the Layout and PathMap from LegacyHDA. So I moved them to FakeSMC as you described, along with the OrangeIconFix info. It works just as you say.

 

The other thing I need to do for my ALC888 support is to patch the original AppleHDA binary. I might look at playing with extending your script to add something like this ? from MaLd0n's topic.

sudo perl -pi -e 's|\x85\x08\xec\x10|\x88\x08\xec\x10|g' /System/Library/Extensions/AppleHDA.kext/Contents/MacOS/AppleHDA

Thanks for the contribution

 

Pfff. It took me nearly three hours – this morning alone – the get Revolution to compile and boot again. The good news is that I can now see light in the end of the tunnel. It was a very long ride, but what a great one. Almost giving up on this insane big EFI patch. Well. It is breakfast time now (and I have to make it myself this morning) so I'll be back later.

Sounds like some major work going on at your house this morning DHP. If anyone can do it then you can, so eat well and show us your creation only when you feel it's ready