How to boost the OS X boot process...

[DB1]

Thanks. A major work it is indeed. And hopefully another step forward again (mostly for DB1 / 32-bit support).

 

Note: Please check the various dynamic/static settings, and DB1 should change this line:

#define EFI_64_BIT	1

Setting it to 0 might do the trick for you Sir

 

So close I can smell it! BUT - getting this compile error.

In file included from smbios_patcher.c:14:
smbios/dynamic_data.h: In function ‘sm_get_defstr’:
smbios/dynamic_data.h:189: error: ‘Platform’ undeclared (first use in this function)
smbios/dynamic_data.h:189: error: (Each undeclared identifier is reported only once
smbios/dynamic_data.h:189: error: for each function it appears in.)
smbios/dynamic_data.h:189: error: ‘CPU_FEATURE_MOBILE’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘sm_get_fsb’:
smbios/dynamic_data.h:230: error: ‘Platform’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘sm_get_cpu’:
smbios/dynamic_data.h:238: error: ‘Platform’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘sm_get_bus_speed’:
smbios/dynamic_data.h:247: error: ‘Platform’ undeclared (first use in this function)
smbios/dynamic_data.h:256: error: ‘CPU_MODEL_YONAH’ undeclared (first use in this function)
smbios/dynamic_data.h:257: error: ‘CPU_MODEL_MEROM’ undeclared (first use in this function)
smbios/dynamic_data.h:258: error: ‘CPU_MODEL_PENRYN’ undeclared (first use in this function)
smbios/dynamic_data.h:259: error: ‘CPU_MODEL_ATOM’ undeclared (first use in this function)
smbios/dynamic_data.h:273: error: ‘CPU_MODEL_WESTMERE_EX’ undeclared (first use in this function)
smbios/dynamic_data.h:280: error: ‘CPU_MODEL_NEHALEM’ undeclared (first use in this function)
smbios/dynamic_data.h:281: error: ‘CPU_MODEL_FIELDS’ undeclared (first use in this function)
smbios/dynamic_data.h:282: error: ‘CPU_MODEL_DALES’ undeclared (first use in this function)
smbios/dynamic_data.h:283: error: ‘CPU_MODEL_DALES_32NM’ undeclared (first use in this function)
smbios/dynamic_data.h:284: error: ‘CPU_MODEL_WESTMERE’ undeclared (first use in this function)
smbios/dynamic_data.h:285: error: ‘CPU_MODEL_NEHALEM_EX’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘sm_get_simplecputype’:
smbios/dynamic_data.h:337: error: ‘Platform’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘sm_get_cputype’:
smbios/dynamic_data.h:358: error: ‘Platform’ undeclared (first use in this function)
smbios/dynamic_data.h:375: error: ‘CPU_MODEL_YONAH’ undeclared (first use in this function)
smbios/dynamic_data.h:376: error: ‘CPU_MODEL_MEROM’ undeclared (first use in this function)
smbios/dynamic_data.h:377: error: ‘CPU_MODEL_PENRYN’ undeclared (first use in this function)
smbios/dynamic_data.h:378: error: ‘CPU_MODEL_ATOM’ undeclared (first use in this function)
smbios/dynamic_data.h:381: error: ‘CPU_MODEL_NEHALEM’ undeclared (first use in this function)
smbios/dynamic_data.h:384: error: ‘CPU_MODEL_FIELDS’ undeclared (first use in this function)
smbios/dynamic_data.h:389: error: ‘CPU_MODEL_DALES’ undeclared (first use in this function)
smbios/dynamic_data.h:394: error: ‘CPU_MODEL_DALES_32NM’ undeclared (first use in this function)
smbios/dynamic_data.h:401: error: ‘CPU_MODEL_WESTMERE’ undeclared (first use in this function)
smbios/dynamic_data.h:402: error: ‘CPU_MODEL_WESTMERE_EX’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘sm_get_memtype’:
smbios/dynamic_data.h:429: error: ‘SMB_MEM_TYPE_DDR3’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘setupSMBIOS’:
smbios/dynamic_data.h:1108: error: ‘gPlatform’ undeclared (first use in this function)
make[2]: *** [smbios_patcher.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

 

Just double checking now I have all my Private date file paths in relevant places.

[DB1]

My mistake. Sorry. Simply rename all occurrences of "Platform." into "gPlatform." – globals must start with a lower case character – and add an extra include for "platform.h" (below essentials.h) and then it will compile.

That fixed it and yes now able to compile.

p.s. Need to go. Have a field hockey match. Be back afterwards...

Hope it's a win for you.

 

Unfortunately still no boot for me as yet. The debug seems to confirm my Factory ACPI table was untouched - does this mean my dsdt did not load?

 

 

Looks like the EFI stuff working but until a boot or someone else checks it with a 32bit processor we cannot be certain.

[scrax]

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

 

 

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

On the Zotac I use ZEvoReboot.kext for my system that is in fact an Evoreboot with all the legacy kext needed for my config included LegacyHDA and I was using on my p5Kc a stipped down AppleHDA like MC did in his topic las year, I think, so you are right it's time to use both method together, thanks for the reminder.

 

I'll try the last modifications

 

Using the last EFI patch in 32bit mode gives me a kp about EFI not supported.

I have not yet tried 64bit and I'm still booting with only one HD.

 

If i set to 64bit and I boot with all 2 the HD cannected I have a reboot after revolution finish his job...

time to test it with only one HD, bbs

[dgsga]

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

 

 

Yeah, good idea. I did this for my AD2000b and it works fine I've always been into making things as easy as possible.

[ntsmkfob]

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.

Great tip, and miraculously, autosleep started to work once I made the mods to fakesmc's info.plist. Always had to sleep manually before. Haven't tried stripping AppleHDA yet.

[DB1]

Correct. The ACPI tables are untouched. Please check your "switches" once more.

 

Here's how I'm setup:

boot.c

 

#define PRE_LINKED_KERNEL_SUPPORT 0

#define DEBUG 1

 

acpi_patcher.c

 

#define ACPI_10_SUPPORT 0

#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 FAKE_APPLE_DATA 0

#define DEBUG 1

 

cpu.c

 

#define DEBUG_CPU 0

#define DYNAMIC_CPU_DATA_GATHERING 1

 

efi.c

 

#define EFI_64_BIT 0

#define APPLE_STYLE 0

#define DEBUG 1

 

smbios_patcher.c

 

#define DYNAMIC_SMBIOS_DATA_GATHERING 1

[DB1]

new:

#if PATCH_ACPI_TABLE_DATA && (STATIC_APIC_TABLE_INJECTION || \
STATIC_SSDT_TABLE_INJECTION || STATIC_SSDT_PR_TABLE_INJECTION || \
STATIC_SSDT_USB_TABLE_INJECTION || STATIC_GPU_TABLE_INJECTION || \
STATIC_DSDT_TABLE_INJECTION || LOAD_DSDT_TABLE_FROM_EXTRA_ACPI || \
LOAD_SSDT_TABLE_FROM_EXTRA_ACPI)

And in addition to the above change:

old:

rsdt_mod = xsdt_mod = NULL;

 

		rsdp_mod = NULL;
	xsdt_mod = NULL;

Will have a look at the: warning: unused variable ‘tableLength’ tomorrow (just a warning).

 

Bye for now...

 

Done these, no change for me.

[scrax]

Picture please!!!

I know, sorry bu t i was without a camera now I'll try to do a better report

Hmm. Not so good. No answer / solution yet.

I can't boot also in 64 bit with only one HD so there is a regression before the old versions or I just forgot some switches...

Attached is my latest work in diff form. Won't have time for more today. School tomorrow.

I'll try those and let's see...

 

 

Without the last diff I have this options:

boot.c

#define PRE_LINKED_KERNEL_SUPPORT 0

#define DEBUG 1

smbios_patcher.c

#define DYNAMIC_SMBIOS_DATA_GATHERING 0

 

I have this error if compiled with 1:

In file included from smbios_patcher.c:14:
smbios/dynamic_data.h: In function ‘sm_get_defstr’:
smbios/dynamic_data.h:189: error: ‘CPU’ undeclared (first use in this function)
smbios/dynamic_data.h:189: error: (Each undeclared identifier is reported only once
smbios/dynamic_data.h:189: error: for each function it appears in.)
smbios/dynamic_data.h:189: error: ‘CPU_FEATURE_MOBILE’ undeclared (first use in this function)
smbios/dynamic_data.h:191: error: ‘gPlatform’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘sm_get_fsb’:
smbios/dynamic_data.h:230: error: ‘gPlatform’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘sm_get_cpu’:
smbios/dynamic_data.h:238: error: ‘gPlatform’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘sm_get_bus_speed’:
smbios/dynamic_data.h:247: error: ‘gPlatform’ undeclared (first use in this function)
smbios/dynamic_data.h:256: error: ‘CPU_MODEL_YONAH’ undeclared (first use in this function)
smbios/dynamic_data.h:257: error: ‘CPU_MODEL_MEROM’ undeclared (first use in this function)
smbios/dynamic_data.h:258: error: ‘CPU_MODEL_PENRYN’ undeclared (first use in this function)
smbios/dynamic_data.h:259: error: ‘CPU_MODEL_ATOM’ undeclared (first use in this function)
smbios/dynamic_data.h:273: error: ‘CPU_MODEL_WESTMERE_EX’ undeclared (first use in this function)
smbios/dynamic_data.h:280: error: ‘CPU_MODEL_NEHALEM’ undeclared (first use in this function)
smbios/dynamic_data.h:281: error: ‘CPU_MODEL_FIELDS’ undeclared (first use in this function)
smbios/dynamic_data.h:282: error: ‘CPU_MODEL_DALES’ undeclared (first use in this function)
smbios/dynamic_data.h:283: error: ‘CPU_MODEL_DALES_32NM’ undeclared (first use in this function)
smbios/dynamic_data.h:284: error: ‘CPU_MODEL_WESTMERE’ undeclared (first use in this function)
smbios/dynamic_data.h:285: error: ‘CPU_MODEL_NEHALEM_EX’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘sm_get_simplecputype’:
smbios/dynamic_data.h:337: error: ‘gPlatform’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘sm_get_cputype’:
smbios/dynamic_data.h:358: error: ‘gPlatform’ undeclared (first use in this function)
smbios/dynamic_data.h:375: error: ‘CPU_MODEL_YONAH’ undeclared (first use in this function)
smbios/dynamic_data.h:376: error: ‘CPU_MODEL_MEROM’ undeclared (first use in this function)
smbios/dynamic_data.h:377: error: ‘CPU_MODEL_PENRYN’ undeclared (first use in this function)
smbios/dynamic_data.h:378: error: ‘CPU_MODEL_ATOM’ undeclared (first use in this function)
smbios/dynamic_data.h:381: error: ‘CPU_MODEL_NEHALEM’ undeclared (first use in this function)
smbios/dynamic_data.h:384: error: ‘CPU_MODEL_FIELDS’ undeclared (first use in this function)
smbios/dynamic_data.h:389: error: ‘CPU_MODEL_DALES’ undeclared (first use in this function)
smbios/dynamic_data.h:394: error: ‘CPU_MODEL_DALES_32NM’ undeclared (first use in this function)
smbios/dynamic_data.h:401: error: ‘CPU_MODEL_WESTMERE’ undeclared (first use in this function)
smbios/dynamic_data.h:402: error: ‘CPU_MODEL_WESTMERE_EX’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘sm_get_memtype’:
smbios/dynamic_data.h:429: error: ‘SMB_MEM_TYPE_DDR3’ undeclared (first use in this function)
smbios/dynamic_data.h: In function ‘setupSMBIOS’:
smbios/dynamic_data.h:1108: error: ‘SMBIOS’ undeclared (first use in this function)
make[2]: *** [smbios_patcher.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

 

acpi_patcher.c

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

#define LOAD_SSDT_TABLE_FROM_EXTRA_ACPI 1

#define DROP_SSDT_TABLES 1

#define FAKE_APPLE_DATA 1

#define DEBUG 1

 

I can't compile if I add:

 

#define STATIC_DSDT_TABLE_INJECTION 1

#define STATIC_SSDT_TABLE_INJECTION 1

 

now i''l reboot and take some pics...

[blackosx]

I've taken the latest files in Revolution_634_EFI_step_5.zip from post #382, applied the diff_634_EFI_5_7.txt from post #389 and made the amendments from post #391.

 

Then making only the following directive changes for me:

#define ACPI_10_SUPPORT 1

#define STATIC_ACPI_BASE_ADDRESS 1

#define DROP_SSDT_TABLES 1

#define FAKE_APPLE_DATA 1

 

I fail to boot with the following 'EFI not supported' KP (same as Scrax? - EDIT: - Yes, scrax confirmed below):

 

EDIT:

Made the following changes:

Added -v to kernel flags in caBp and set #define DEBUG to 1 in efi.c and recorded a video so I could capture the frame with the debug just before it KP's. This is what it shows:

[scrax]

I've taken the latest files in Revolution_634_EFI_step_5.zip from post #382, applied the diff_634_EFI_5_7.txt from post #389 and made the amendments from post #391.

 

Then making only the following directive changes for me:

#define ACPI_10_SUPPORT 1

#define STATIC_ACPI_BASE_ADDRESS 1

#define DROP_SSDT_TABLES 1

#define FAKE_APPLE_DATA 1

 

I fail to boot with the following 'EFI not supported' KP (same as Scrax?):

Yes it's the same KP i get

[blackosx]

Hi DHP

 

Well done with your work today. I'll catch up either tomorrow or later in the week.

But for reference, setting the EFI_64_BIT directive doesn't make any difference - I get the same KP with it set to either 0 or 1.

[DB1]

Noticed after my last post.

Attached is my latest work in diff form. Won't have time for more today. School tomorrow Attached File(s)

diff_634_EFI_5_7.txt ( 31.76K ) Number of downloads: 6

 

Made all the changes in the diff, debug pics:

 

Still no go for me. Keep up the good work and don't feel pressured to deliver. Schooling and home life come first. Might catch up for half hour in morning cause I know you'll be up at the call "rise and shine" otherwise will be tomorrow evening for me to catch up. Last glass of red sunk, and off to bed.

 

Could not resist one more test - all debugs off and -v taken out of a.c.B.p WOW, quicker than the bios from signs of Revo boot to grey screen and apple (unfortunately as yet no further). This thing is going to be amazing when it's cracked.

[blackosx]

I see. Let me add that there are two things to check. During boot ups with arch=i386 under Kernel Flags, we set efi->firmware-abi to "EFI32" (in efi.c) and when x86_64 is used we use EFI64 instead. This might (have to) change. Too early to tell, but I will check this myself later today.

 

The second things we do is to set bootArgs->efiMode (in bootstruct.c) based on the chosen architecture, to either 64 (kBootArgsEfiMode64) or 32 (kBootArgsEfiMode32). For now make them match

Good morning DHP.

Thanks for the info and in response I made two different compilations of Revolution:

1) with efi->firmware-abi forced to EFI32, bootArgs->efiMode forced to kBootArgsEfiMode32

2) with efi->firmware-abi forced to EFI64, bootArgs->efiMode forced to kBootArgsEfiMode64

 

Booting build 1 with kernel flag set to arch=i386, and I get same KP as reported earlier.

Booting build 2 with kernel flag set to arch=x86_64, machine reboots just before I would see a KP.

[DB1]

DB1's configuration, for example, boots fine with firmware-abi set to EFI64 and 64-bit table addresses. I'm sort of stumped about the why here, but reading the Chameleon source code made me thing that DB'1 configuration is simply using EFI64 and kBootArgsEfiMode32. So why isn't our EFI implementation working for him?

 

Hi DHP, If this is the case maybe it is cpu related. Perhaps the kexts I use to trick the kernel to stop panic as ATOM not supported does not work with Revolution for some reason. I could post up the kexts or the patch I used previous if you think it may help decide if it is a cpu problem.

[dgsga]

Your, and scax, problem to boot is completely my error. Something I expect to work simply doesn't. Looking into it right now.

 

 

DHP, I don't see the the current failure to boot as 'your error'. More a case of discovery with help from friends on this thread. I get exactly the same result as BlackOSX with the latest EFI changes, but the apple logo that comes up in 64-bit before reboot appears almost instantaneously after the bios hands over. Looks very promising indeed...

[blackosx]

Good to hear you've solved it dutchhockeypro. Well done

 

Yeah, good idea. I did this for my AD2000b and it works fine I've always been into making things as easy as possible.

The script for the AppleHDA binary patch works for me too and I have now adopted your idea of adding my necessary audio info and the orangeiconfix in to my FakeSMC info.plist. I'll keep it like that for a while and see if I stick with it permanently.

For reference, the latest FakeSMC is v3.1.0 - binaries posted by slice at projectosx on 6th Jan (just incase you didn't know).

[dgsga]

Thanks. Had my shower, breakfast and got dressed already. Let's see how far we come this morning...at 6:12AM

 

Hmm. Almost done but there's too much to change. Won't make it now. Will work in the train some more and hope to finish it before school starts. Back later with an update.

Nice one

[scrax]

I'm fightin to automate the erase off all the {censored} related to the App Store, but I 'm here around

[blackosx]

Welcome back dutchhockeypro. I bet you're glad to finally have the code in a state for release?

Thanks and well done - I'll have a look now...

[blackosx]

I'm pleased to report a successful boot here

It's good to be booting again.. good work.

 

Though I did get a compilation error when setting #define STATIC_ACPI_BASE_ADDRESS to 1. I moved the line above the #include "acpi/essentials.h" or more importantly, above #if STATIC_ACPI_BASE_ADDRESS as you had it before and it worked.

 

Oh and also in acpi_patcher.c you've accidentally? left the #define LOAD_SSDT_TABLE_FROM_EXTRA_ACPI set to 1. No problem though.

[blackosx]

Good catch! This is/was the number one issue (in post #412) I said to (have to) work on, and here is it:

Glad to be of service.

 

This is actually something I worked on for you as you've mentioned something about including GPU code.

That reminds me to resume testing with that again as I had left if alone for now - Thanks for thinking about it.

 

p.s. I am working from home today due to transportation issues – teachers who can't get in time due to slippery roads.

That'll save you some travelling time - enjoy your day

[blackosx]

Thanks for the heads up about the error in acpi/patcher.h. I will make sure I correct it when I do some testing. And I also wish to hear good news from DB1.. fingers crossed for you and him.

 

I'm off to work now. I'll check in when I get a chance.

[DB1]

@DB1 Please read my note in platform.c

 

Just got in from work. Great you got it sorted out, well done.

 

Got to freshen up before my dinner so only got a few minutes just now. Read your note in platform.c and thats great you can boot EFI 32.

 

Just need a clarification before I start playing after dinner: When I looked at efi/essentials.h it says (requires arch=i386 on configurations) does this mean I need to change something somewhere else? or put arch=i386 in c.a.B.p?

 

Catch up later

[DB1]

Thanks. But does it work for you? I mean I don't have a 32-bit only and/or Atom CPU to play with so... please let me know if it is working for you.

 

 

No. Not on a 32-bit configuration. Only on 64-bit configurations (fixed the note already) where EFI64 is the default – it has something to do with the address width, which is twice as wide (8 versus 4) on a 64-bit CPU.

 

There's still room for more improvements. I'm sure there is, but this was as far as I could get in the limited amount of time I had available. Thinking about pushing the envelop even further, but I'll wait and hold of for now. That is until I got a clear acknowledgment from your side.

 

Sorry for the wait, i checked, double checked, and treble checked everything and unfortunately have report still no boot with 32bit cpu . I really appreciate all the hard work you been doing to try and get me up and running. Debug don't look much different to me except it's obvious dsdt is loading which I was not absolutely sure it was previous for me.

 

I also tried setting EFI to 64 bit just to what happened: EFI_64_BIT setting (1) error detected!

 

CPU Debug:

[DB1]

That's too bad, but I was kind of expecting it. A voice told me that EFI isn't the problem here. Gonna have a chat with it in a little time – unrelated to this matter, but that is why I am awake (have had a few hours of sleep already).

 

 

No problem. At least now we know that your DSDT is loading.

 

 

LOL So my check really works. Great. Anyway. Using 64-bit addresses should not work on a 32-bit configuration. We're missing something else. I mean looking at some old posts here: scrax used Revolution 6.20 with OS X 10.6.3 so why can't he boot anymore? Is that due to my changes in boot2/drivers.c or you guys not having the MKext(s) in the right spot, or maybe SMBIOS issues?

 

Gonna ask for help but first:

 

1.) What is the Chameleon patch you've been using before?

2.) These kexts you talked about, what are they doing? Is there source code available I can read?

 

Have pm'd you. It's late I really aught to be in bed myself. Probably won't get chance to check in, in the morning will catch up tomorrow evening.

 

LOL I know what it's like when you got something bugging your brain and you can't sleep.