How to boost the OS X boot process...

[dgsga]

Well well this is fantastic news. Finally. At last. It had to be something simple when you got that far already.

 

 

Weird stuff. You mean the call to finalizeKernelBootConfig should go first?

 

Ignore what I said about commenting out the section in the above post. I eventually found that with Debug in boot.c set to 1 all loads fine but with Debug=0 I get the endless apple with no throbber. When debug is set to 1 there is a gap where the system appears to have stalled after the Press a key... prompt. If you leave it the desktop eventually loads. I fixed the debug=0 problem by removing the second call to showBootLogo in one of the DEBUG sections of boot.c.

 

I also found that when using the existing acpi patcher (static or dynamic) I lost CPU power management for some bizzare reason. It was restored by using my own customized static version (see attachments).

 

DHP, see my heavily Master Chiefed DSDT.dsl for more info about the required change.

acpi_patcher.c.zip

acpi_patcher.h.zip

DSDT.dsl.zip

[blackosx]

BlackOSX and DB1, try this as this is exactly what I did:

Thanks for the list of what worked for you dgsga. I re-did exactly that but I think it was what I had already and I don't get any different results.

 

What might be causing the ACPI failure is your DSDT file. Make sure that the following line near the beginning of DSDT.dsl is set to how it appears in the loaded DSDT.aml in a working system:

 

OperationRegion (BIOS, SystemMemory, 0xFFFFFF00, 0xFF)

Thanks for this tip and for posting your DSDT, but I don't have APIC defined in my DSDT anymore. All references to it were removed a long time ago. Looking back at my original Gigabyte DSDT, Name (APIC.. ) doesn't have an operation region anyhow. Did you add that to yours?

 

Just dug out my trusty ACPIspec PDF and I see this for APIC device:

This optional device describes a discrete I/O APIC device that is not bus enumerated (e.g., as a PCI device). Describing such a device in the ACPI name space is only necessary if hot plug of this device is supported.

 

There is more but my knowledge of these things are limited. also I can't think of any hot plug device that I would use, other than USB or SATA which I guess makes sense as to why I don't have it.. Maybe it's more specific to your ASUS board?

[DB1]

QUOTE (dgsga @ Jan 1 2011, 04:20 PM)

BlackOSX and DB1, try this as this is exactly what I did:

 

Redid as suggested - no difference.

 

Re the DSDT I also do not have that operation region and never did (The bios is very basic on Wind/clones). My dsdt is a heavily customized a la MC methods which works fine with all past and current Chameleon versions.

[DB1]

You appear to be using 10.6.2 so did you change the boot argument revision info?

 

Note: This is set to 5 in Chameleon.

 

I'm on 10.6.5, just have not updated signature for a while. And yes made the change to boot argument revision info

[dgsga]

I'll look into it. Thanks.

 

Update: Got it. That's because we drop SSDT tables – without asking – but your configuration wants it. Let's add a new directive for this in acpi_patcher.c:

#define DROP_SSDT_TABLES				0 // Defaults to off.

And change this snippet in acpi/patcher.h like so (red text):

			if (tableID == SSDT_TABLE_SIGNATURE)
		{
			if (ssdtTableIndex == 0) // Replace the first SSDT table with the new Scope (_PR).
			{
#if STATIC_SSDT_PR_TABLE_INJECTION
				xsdt_entries[i - dropoffset] = (uint32_t)customSSDT_PR;
#el[color="#FF0000"]if DROP_SSDT_TABLES[/color]
				dropoffset++;
#endif
			}

			if (ssdtTableIndex == 1) // Replace the second SSDT table.
			{
#if STATIC_ATI_TABLE_INJECTION
				xsdt_entries[i - dropoffset] = (uint32_t)customSSDT_ATI;
#el[color="#FF0000"]if DROP_SSDT_TABLES[/color]
				dropoffset++;
#endif
			}

			ssdtTableIndex++;
			continue;
		}
       }

That should do the trick.

 

 

Name(APIC... and Method (LDRC... appear to have been removed a long time ago already. The memory range point to io-apic in our IORegistryExplorer dumps and is claimed by OS X already.

 

DHP, you don't mess around do you!! Thanks for the update about my DSDT.dsl and the ACPI fix, have removed the offending APIC & LDRC and am now down to 51872 bytes with DSDT.aml built-in. Great work your'e doing here...

 

BlackOSX and DB1, sorry to hear the method hasn't worked, I'm struggling to see what else might be wrong. It's weird but I never have had the "LoadingACPITable (DSDT)" message appear. Just a thought, have you tried using the acpi_patcher files I attached earlier? You just need to replace the DSDT data in acpi_patcher.h with your own, and the base address in acpi_patcher.c with your own.

[blackosx]

BlackOSX and DB1, sorry to hear the method hasn't worked, I'm struggling to see what else might be wrong.

No problem - I appreciate your suggestions

 

It's weird but I never have had the "LoadingACPITable (DSDT)" message appear.

That only appeared after we added it as DHP suggested in post 220

 

Just a thought, have you tried using the acpi_patcher files I attached earlier? You just need to replace the DSDT data in acpi_patcher.h with your own, and the base address in acpi_patcher.c with your own.

I'll have a look now.

 

EDIT:

Your acpi_patcher.c is quite a bit different from the one I currently have from Revolution-634 and I currently don't have acpi_patcher.h so I need to ask a couple of questions before I continue.

1) How do I get my DSDT in to the hex table as you have in acpi_patcher.h ?

2) Where do I get the base address and where exactly do I put it in acpi_patcher.c ?

3) Do I just replace my acpi_patcher.c with your one?

4) Do I just add your acpi_patcher.h to my /libsaio/ ?

 

Sorry for the seemingly basic questions - but if I don't know then I can't try it.

[blackosx]

@blackosx: I think that post #113 says it all

Thanks for showing me the light, though I am still a little but stuck... can I ask for some more help please?

 

From my earlier questions:

1) How do I get my DSDT in to the hex table as you have in acpi_patcher.h ?

I've used aml2struct.pl to convert my DSDT.aml and place the hex in to acpi_patcher.h.

 

2) Where do I get the base address and where exactly do I put it in acpi_patcher.c ?

Still stuck on that one.

 

3) Do I just replace my acpi_patcher.c with your one?

I did that

 

4) Do I just add your acpi_patcher.h to my /libsaio/ ?

I did that also

 

Trying to compile what I have now gives me the following errors.. and I guess I now need acpi.h?

acpi_patcher.c:7:18: error: acpi.h: No such file or directory
acpi_patcher.c: In function ‘setupACPI’:
acpi_patcher.c:22: error: ‘DSDT_Table’ undeclared (first use in this function)
acpi_patcher.c:22: error: (Each undeclared identifier is reported only once
acpi_patcher.c:22: error: for each function it appears in.)
acpi_patcher.c:30: error: dereferencing pointer to incomplete type
acpi_patcher.c:31: error: dereferencing pointer to incomplete type
acpi_patcher.c:32: error: dereferencing pointer to incomplete type
acpi_patcher.c:35: error: dereferencing pointer to incomplete type
acpi_patcher.c:37: error: dereferencing pointer to incomplete type
acpi_patcher.c:37: error: dereferencing pointer to incomplete type
acpi_patcher.c:43: error: dereferencing pointer to incomplete type
acpi_patcher.c:44: error: dereferencing pointer to incomplete type
acpi_patcher.c:45: error: dereferencing pointer to incomplete type
acpi_patcher.c:46: error: dereferencing pointer to incomplete type
acpi_patcher.c:46: error: invalid application of ‘sizeof’ to incomplete type ‘struct acpi_2_xsdt’ 
acpi_patcher.c:47: error: invalid use of undefined type ‘struct acpi_2_xsdt’
acpi_patcher.c:71: error: dereferencing pointer to incomplete type
acpi_patcher.c:72: error: dereferencing pointer to incomplete type
acpi_patcher.c:74: error: dereferencing pointer to incomplete type
acpi_patcher.c:76: error: dereferencing pointer to incomplete type
acpi_patcher.c:78: error: dereferencing pointer to incomplete type
acpi_patcher.c:78: error: dereferencing pointer to incomplete type
acpi_patcher.c:79: error: dereferencing pointer to incomplete type
acpi_patcher.c:81: error: dereferencing pointer to incomplete type
acpi_patcher.c:82: error: dereferencing pointer to incomplete type
acpi_patcher.c:82: error: dereferencing pointer to incomplete type
acpi_patcher.c:95: error: dereferencing pointer to incomplete type
acpi_patcher.c:96: error: dereferencing pointer to incomplete type
acpi_patcher.c:97: error: dereferencing pointer to incomplete type
acpi_patcher.c:97: error: dereferencing pointer to incomplete type
acpi_patcher.c:100: error: dereferencing pointer to incomplete type
acpi_patcher.c:101: error: dereferencing pointer to incomplete type
acpi_patcher.c:102: error: dereferencing pointer to incomplete type
acpi_patcher.c:103: error: dereferencing pointer to incomplete type
acpi_patcher.c:103: error: dereferencing pointer to incomplete type
make[2]: *** [acpi_patcher.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

 

EDIT:

Found a copy of acpi.h in Revolution 616

[blackosx]

But of course.

Thank you

 

This is where DUMP_ADDRESS comes in place (acpi_patcher.c). Set it to 1 and it should show you your address. Set it to 0 afterwards. A one time only event (per configuration).

I got that earlier, but I still wasn't sure where exactly to add it in acpi_patcher.c. Would it be after static uint32_t const DSDT_TABLE_SIGNATURE = ?

I guess this doesn't matter now? (see next item)

 

I would like to advise you to stick with the files as they are now, with the latest changes making us no longer drop SSDT tables.

That's fine with me. So I'll stick with your master files without going along with the additional acpi_patcher.h and acpi.h as suggested by dsgsa ?

 

I now also changed fake_efi.c a little:

I'll have a look.

 

EDIT:

After making the fake_efi.c changes I now get the following verbose output after the kernel header details boot:

finalizeEFITree-1
finalizeEFITree-2
No SMBIOS replacement found.
CPU is Intel(R)... blah
finalizeEFITree-3
finalizeEFITree-4
loadACPITable(DSDT.AML)

I've still got DUMP ADDRESS enabled so I then see the baseAddress: output. - now disabled.

I then have to press a key before I see a garbled screen.

oh.. and for info, the above output includes the changes to DROP_SSDT_TABLES in patcher.h

 

EDIT 2:

Trying to narrow down where exactly the code fails in function setupACPI

I know the code gets past:

	rsdp = getACPIBaseAddress();
rsdp_mod = (struct acpi_2_rsdp *) AllocateKernelMemory(rsdp->Length); // 36 / 0x24

but it never makes it past:

	memcpy(rsdp_mod, rsdp, rsdp->Length);

Or the printf statements I put after these lines don't get executed as this is the point I see the multicoloured blocks and garbled screen.

 

EDIT 3:

I've gathered some more info about the memcpy line and found values being used:

rsdp_mod = 15085568

rsdp = 1012048

 

I'm leaving this for tonight, but I'll re-visit in the morning.

[cparm]

hi dutchhockeypro, here is a little contribution to this project,

 

i 've seen your last sources (rev 634), in fake_efi.c we can see:

 

DT__AddProperty(chosenNode, "boot-device-path", 38, "\\System\\Library\\CoreServices\\boot.efi");
DT__AddProperty(chosenNode, "boot-file-path", sizeof(BOOT_FILE_PATH), &BOOT_FILE_PATH);

 

i am pretty sure the value "boot-device-path" is a ........suspense........ device path (of the boot volume)

 

Have a look at here.

 

"boot-file-path" is also a (media ?) device path, and seems to point to boot.efi (not sure), anyway i think boot-file-path is useless on our hackintosh

 

last thing, i confirm that fill the options node can cause instability.

kabyl talk about it somewhere on the voodoo forum (sorry, i don't remember where exactly)

 

ps: moved to / Post-Installation / OSx86 Snow Leopard (10.6) and pinned

[scrax]

Hi all, I've started to try rev 634 with all the last changes suggest and I have same behavior as blackosx reported.

Please correct me if I'm wrong I'm using latest chameleonRC5 but with the boot compiled from revolution sources

[blackosx]

Ok. Let me make you two news file. The first one being i386/libsaio/acpi_patcher.c and the second one i386/libsaio/acpi/patcher.h

 

Both files are in text format, so that everyone can see what I changed / they do. Oh and you have to set DEBUG to 1 of course. This change also adds the possibility to skip ACPI patching altogether.

Great. Thanks - I'll look at them now.

[blackosx]

Ok. Let me make you two new files. The first one being i386/libsaio/acpi_patcher.c and the second one i386/libsaio/acpi/patcher.h

 

Both files are in text format, so that everyone can see what I changed / they do. Oh and you have to set DEBUG to 1 of course. This change also adds the possibility to skip ACPI patching altogether.

Setting DEBUG to 1 in acpi_patcher.c gives compile error:

/usr/bin/ld_classic: Undefined symbols:
_loadACPITable
collect2: ld returned 1 exit status
make[2]: *** [boot] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

Leaving DEBUG to 0 in acpi_patcher gives compile error:

In file included from acpi_patcher.c:52:
acpi/patcher.h: In function ‘setupACPI’:
acpi/patcher.h:50: warning: implicit declaration of function ‘DEBUG_ACPI’
acpi/patcher.h:124: warning: implicit declaration of function ‘loadACPITable’
acpi/patcher.h:124: warning: assignment makes pointer from integer without a cast
acpi/patcher.h:272: error: ‘tableName’ undeclared (first use in this function)
acpi/patcher.h:272: error: (Each undeclared identifier is reported only once
acpi/patcher.h:272: error: for each function it appears in.)
make[2]: *** [acpi_patcher.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

 

However, changing #define PATCH_ACPI_TABLE_DATA to 0 allows compilation to complete. Now I know this is not recommended but I am using a patched BIOS which will allow me to boot without the need to load patched ACPI tables. I'll try rebooting now and see what happens.

 

EDIT:

Kernel starts

But only gets as far as USBMSC identifier, then sits at waiting for root device.

 

EDIT2:

Settting:

PATCH_ACPI_TABLE_DATA to 1

LOAD_DSDT_TABLE_FROM_EXTRA_ACPI to 0

DEBUG to 1

compiles fine.

 

And booting results in the following extra verbose output:

finalizeEFITree-4

Enterint setupACPI()
getACPIBaseAddress() returned:  0x000f7150
rsdp->RsdtAddress: 0xdfee3040
rsdp->Length	 : -538038208
rsdp->XsdtAddress: 0xdfee30c0
Sleeping for 5 seconds

Then it shows the multicoloured blocks before crashing.

 

My best guess would be that some (most?) systems (read: BIOS) lack support for ACPI 2.0 (thanks dad) but what do I know. Let's find out shall we?

Mine is ACPI 1.0

 

/*
* Intel ACPI Component Architecture
* AML Disassembler version 20101209-64 [Dec 10 2010]
* Copyright © 2000 - 2010 Intel Corporation
* 
* Disassembly of /Users/blackosx/Desktop/ACPI/DSDT.aml, Sat Jan  1 16:55:13 2011
*
* Original Table Header:
*	 Signature		"DSDT"
*	 Length		   0x0000112E (4398)
*	 Revision		 0x01 **** ACPI 1.0, no 64-bit math support
*	 Checksum		 0xF6
*	 OEM ID		   "GBT   "
*	 OEM Table ID	 "GBTUACPI"
*	 OEM Revision	 0x00001000 (4096)
*	 Compiler ID	  "INTL"
*	 Compiler Version 0x20101209 (537924105)
*/

[blackosx]

But people like you, with a patched BIOS, should use it.

Yes I know - but it's also useful for me to be able to load a different DSDT if I choose.

 

Gosh. Just one spot on tip. Now please boot into verbose mode and look for the following line:

rooting via boot-uuid from /chosen: <rootUUID>

You see that?

Can't see it - the screen moves too fast.. I did capture this:

 

but maybe the message you're looking for appears before?

 

Update: We need this change.

#if DEBUG
#define DEBUG_ACPI(x...)	printf(x)
#else
#define DEBUG_ACPI(x...)
#endif

Adding two new lines.

Adding these still gives me:

/usr/bin/ld_classic: Undefined symbols:
_loadACPITable
collect2: ld returned 1 exit status
make[2]: *** [boot] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

[blackosx]

The call to initEFITree(rootUUID); should dump: "Initializing property boot-uuid (rootUUID)" that is when you use the follow code in fake_efi.c:

../snip/..

Did I post this already or not? Have to check... Yes I did in post #245.

Yes I have this is fake_efi.c. I'll try booting again to see if I see the message.

 

EDIT:

I've recorded a video of the boot process with my iPhone4 so I can study it. No message seen.

 

Question:

Where is the rootUUID coming from?

 

EDIT:

Just added this to fake_efi.c

bool setRootUUID(Node *chosenNode, char *rootUUID)
{

printf("DEBUG - rootUUID =  (%d)\n", rootUUID);	// blackosx added.
sleep(5);   // blackosx added

// Only accept a UUID with the correct length.
if (strlen(rootUUID) == 36)

and I see the following which is not 36 characters in length.

DEBUG - rootUUID = 589727

 

Does this help?

[blackosx]

Can you please add the following two lines:

	DEBUG_DUMP("(rootUUID == NULL) %s\n", (rootUUID == NULL) ? "true" : "false");
DEBUG_DUMP_SLEEP(10);

Right above the call to initEFITree(rootUUID) and enable debug output.

I see:

(rootUUID == NULL) false

 

I have to go visit family now. Will be back after lunch...

No problem. I'll catch up later

[blackosx]

rootUUID is a string which can be dumped with: %s (not %d). And yes doing this helps.

Thanks for the correction, and yep this results in

DEBUG - rootUUID = ()

 

p.s. You can set it in the usual way in com.apple.Boot.plist but that would basically defeat the whole purpose of this exercise / new feature.

Just to test this out, I can confirm that I can successfully boot my system by adding

rd=uuid boot-uuid=00000000-0000-0000-0000-00000000000000

in to kernel flags in my c.a.B.p.

Where the UUID value is that of my OSX partition as shown in disk utility.

 

Screenshot of the Revolution debug info from the settings I have

 

and I see the following in the verbose kernel log.

rooting via boot-uuid from /chosen: <rootUUID>

 

So it just confirms, along with the other debug output, that the auto detection of my UUID is failing.

 

EDIT:

I've just tested my private_data.h by changing #define DYNAMIC_SMBIOS_DATA_GATHERING 0 and all my normal settings are loaded correctly so I can be happy my SMBIOS data is good.

 

How is video injection achieved? do I need to wait for ACPI 1.0 support so I can load my DSDT with patched video?

[DB1]

What a bummer.

 

@DB1: Your system may too have ACPI 1.0 support only, but at least it located your rootVolume so you won't have this problem. Can you please confirm your ACPI version info? Thanks!

 

Yes I have ACPI 1.0

[blackosx]

Ok. Could you gentlemen please add the following line to the if (rdsp) {} debug dump section in patcher.h:

		printf("rsdp->Revision: %d\n", rsdp->Revision);

And tell me what you get? Is that a 0 or a 1?

I get 0

 

Oh well. At least that works. Giving you an opportunity to create a pre-linked kernel

Good thinking. I did that too

[DB1]

Ok. Could you gentlemen please add the following line to the if (rdsp) {} debug dump section in patcher.h:

		printf("rsdp->Revision: %d\n", rsdp->Revision);

And tell me what you get? Is that a 0 or a 1?

 

I'm still playing catch up with all that's being done today. i'm getting the same compile error current as was blackosx.

 

It's hard work on a 101/2" screen! A diff against 633 would be helpful to speed things up otherwise I'll try to work out where i'm going wrong and eventually catch up. or wait for next version. I would so like to get this to boot!

 

keep up the great work DHP / blackosx

[blackosx]

I would so like to get this to boot!

You might be able to boot if you add your OSX partition's UUID to the kernel flags in your com.apple.Boot.plist. That's the only way I'm doing it now, and due to the fact that I have a modified BIOS.

 

Until DHP works her magic with fixes for the automatic UUID detection and ACPI 1.0 support then we will just have to wait for now. And DHP - don't take that as a dig in any way. There's no rush for you here - you just churn out what you can, when you can and we'll keep testing

 

p.s. Which post # did you add your USB-stick partition info again?

Post #153

 

Please correct me if I'm wrong I'm using latest chameleonRC5 but with the boot compiled from revolution sources

Hi scrax - That's the same as me

[dgsga]

Glad to hear the source of the problem has been identified, it fits as I have ACPI 2.0 option im my bios. I dont know if this helps but valv's branch of chameleon has code in acpi_patcher that

Added ACPI V1 to V4 conversion, also auto generates XSDT from RSDT if needed

Have attached the file for convenience

acpi.zip

[blackosx]

p.s. You'll have to rename one thing in saio_globals.h yourself, because I changed acpi20_p into gACPITableAddress. Saving me from attaching another file (which is really small and meaningless anyway).

Numbskull here can't compile... Please advise DHP.

EDIT: I left the gACPITableAddress commented out.. that's fixed now - this is current error.

/usr/bin/ld_classic: Undefined symbols:
_loadACPITable
collect2: ld returned 1 exit status
make[2]: *** [boot] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

Same as I had previously which wasn't fixed here.

[Time2Retire]

Numbskull here can't compile... Please advise DHP.

EDIT: I left the gACPITableAddress commented out.. that's fixed now - this is current error.

/usr/bin/ld_classic: Undefined symbols:
_loadACPITable
collect2: ld returned 1 exit status
make[2]: *** [boot] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

What are the directives set to in acpi_patcher.c?

[blackosx]

What are the directives set to in acpi_patcher.c?

#define PATCH_ACPI_TABLE_DATA 1

#define STATIC_ACPI_BASE_ADDRESS 0

#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 LOAD_DSDT_TABLE_FROM_EXTRA_ACPI 1

#define LOAD_SSDT_TABLE_FROM_EXTRA_ACPI 0

#define DROP_SSDT_TABLES 0

#define DEBUG 0

[blackosx]

Aha. I apparently left out one of my earlier patches:

....

That fixes it - well done

Right - I'll try booting..