How to boost the OS X boot process...

[blackosx]

Oh dear. Let it work. Please let it work (I'm keeping my fingers crossed).

After verbose message for boot1, I see the grey screen with Apple Logo, then immediately after the screen turns black with the following message:

Can't find:

Memory allocation error (0x424c320, x02d330000)

[blackosx]

Bummer. But let's be positive. And about that black screen. You may have set -v as kernel flag, no? Would you mind setting -s to see if that gets picked up? That would be a good sign.

Yes I did have -v set as a kernel flag. Changing it to -s makes no difference to the behaviour previously described.

[blackosx]

Sorry for the delay but I had to pop out.

Update: I somehow copied a file or two, that shouldn't be there in this release. The first one that need to be restored from Revolution-633 (or earlier) is: i386/libsa/memory.h (a work in progress file). An easy fix. The other file is boot.c which now complains about unused/undefined vars, depending on the value of PRE_LINKED_KERNEL SUPPORT setting. Also an easy fix:

After doing this and setting #define DEBUG 1 in boot.c I see the following:

gBootVolume: hd(0,1)
bvChain	: hd(0,1)
adler32: F91571DD
Setting gMacOSVersion to: 10.6

mayUsePreLinkedKernel == true
Sleeping for 11 seconds...
Can't find:

Memory allocation error (0x424c320, 0x2d500000)

I've still got the kernel flag -s in com.apple.Boot.plist. I'll remove all kernel flags now to see if the screen turns black.

[blackosx]

Confirm, removing -v and/or -s kernel flag from com.apple.Boot.plist leaves the grey screen showing the Apple logo.

 

Thanks for the update. Seems much better already. Did you copy the pre-linked kernel file to your USB-stick (into the same directory)?

I've copied the mach_kernel to the root of my USB stick. Is that the same as the pre-linked kernel?

BlackSnowMain:~ blackosx$ ls -al /Volumes/Revolution/
total 36632
drwxrwxr-x  14 blackosx  staff	   544 30 Dec 18:09 .
drwxrwxrwt@ 13 root	  admin	   442 30 Dec 18:13 ..
-rw-r--r--@  1 blackosx  staff	  6148 30 Dec 18:11 .DS_Store
drwx------   3 blackosx  staff	   102 24 Dec 07:16 .Spotlight-V100
drwxrwxrwt@  3 blackosx  staff	   102 24 Dec 07:19 .TemporaryItems
d-wx-wx-wt   3 blackosx  staff	   102 30 Dec 17:52 .Trashes
drwx------  40 blackosx  staff	  1360 30 Dec 18:11 .fseventsd
drwxr-xr-x   5 root	  wheel	   170 28 Dec 14:58 Extra
drwxr-xr-x   4 blackosx  staff	   136 23 Dec 21:17 Library
drwxr-xr-x   4 blackosx  staff	   136 23 Dec 21:17 System
-rw-r--r--   1 blackosx  staff	 51712 30 Dec 18:09 boot
-rw-r--r--@  1 root	  wheel  18693813 24 Dec 07:18 mach_kernel

[blackosx]

No. The pre-linked kernel includes the MKext and can be found in the cache directory:

 

/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache_i386.F91571DD

or:

/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache_x86_64.F91571DD

Okay - thanks - I must have missed that page in the documentation

However, adding it leaves me with exactly the same debug info as I had previously.

 

p.s. kextcache -system-prelinked-kernel will create it, just in case the adler is wrong; we add essential properties in the device tree read by kextcache. You can check the new properties with IORegistryExplorer (change IOService to IODeviceTree in the menulist and select /chosen node).

I'll try making a new one to see if it makes a difference

[blackosx]

No. The pre-linked kernel includes the MKext and can be found in the cache directory:

 

/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache_i386.F91571DD

or:

/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache_x86_64.F91571DD

So should the hex number at the end of the kernelcache filename equal that of adler32 as show in the debug output from the booter?

 

I ask because the debug output reads: adler32: F91571DD

where my kernelcache filename reads: kernelcache_i386.8602B51D

 

I've also run kextcache -system-prelinked-kernel to re-make the kernel cache.

 

And DHP, there's no rush with this at my end, though I will continue to double check things here and see if I can get the '"Pre-linked kernel cache located!' message..

 

EDIT:

I've been playing around with the code and found out the booter was looking for kernelcache_x86_64.F91571DD which I have (for now just renamed my file) to that to see what happens next.

But I have now progressed to reading the following debug output:

gBootVolume: hd(0,1)
bvChain	: hd(0,1)
adler32: F91571DD
Setting gMacOSVersion to: 10.6
Pre-linked kernel cache located!
Load pre-linked kernel: /S*/L*/C*/c*/kernelcache_x86_64.F91571D

mayUsePreLinkedKernel == true
Sleeping for 11 seconds...
AllocateMemoryRange: 0x424c320 - 0x865ex - 0x2007000
No SMBIOS replacement found.

Then I am followed with a screen full of random multi-coloured blocks where I guess the video is trying to be initialised?

 

I will look to do some more testing and try adding arch=x86 to my kernel flags.

 

EDIT:

Yep - should have guess earlier that adding arch=x86 to kernel flags makes booter look for kernelcache_i386.XXXXX

But I still have to figure out why my adler32 number is different to the kernelcache number?

[blackosx]

.....

The next thing to do is to open boot.c and group a couple of variables like so:

	rootUUID[0] = '\0';

[color="#A0522D"]#if PRE_LINKED_KERNEL_SUPPORT[/color]
[color="#FF0000"]unsigned long adler32;

static char adler32Key[PLATFORM_NAME_LEN + ROOT_PATH_LEN];
static char preLinkedKernelPath[80];

preLinkedKernelPath[0] = '\0';[/color]
[color="#A0522D"]#endif[/color]

gBIOSDev = (biosdev & kBIOSDevMask); // Save boot device (masked with 0xFF).

This will stop the compiler from complaining about unused and/or undefined variables – depending on the value of PRE_LINKED_KERNEL SUPPORT – which to me is also an easy fix.

When doing this, the complier errors with:

boot.c:318: error: redeclaration of ‘adler32’ with no linkage
boot.c:313: error: previous declaration of ‘adler32’ was here
boot.c:320: error: redeclaration of ‘adler32Key’ with no linkage
boot.c:298: error: previous declaration of ‘adler32Key’ was here
boot.c:321: error: redeclaration of ‘preLinkedKernelPath’ with no linkage
boot.c:299: error: previous declaration of ‘preLinkedKernelPath’ was here

so when I did this earlier, I commented out the newly added lines. Now, I've tried re-enabling the newly added lines and commenting out the original lines 313,289 & 299. Booting this time now gives me a black screen after the 'No SMBIOS replacement found.' message rather than a multi coloured screen. Though still no further...

[blackosx]

Please skip working on getting the pre-linked kernel to load, because that is doomed to fail with any other boot loader.

I did try booting with:

#define PRE_LINKED_KERNEL_SUPPORT 0

#define DYNAMIC_SMBIOS_DATA_GATHERING 0

 

and got as far as:

gBootVolume: hd(0,1)
bvChain : hd(0,1)
Load Kernel: mach_kernel
AllocateMemoryRange : 0x424c320 - 0x865ec - 0x908000
ShouldLoadMkext: true
.AllocateMemoryRange : 0x424cd60 - 0xf9ff - 0x990000
Loading mkexts...
AllocateMemoryRange : 0x424cd80 - 0x4bd3fd - 0x9a0000
gKextLoadStatus: 3

Then the screen shows the multicoloured blocks as I've seen previously.

 

I'll now attach a diff file with my changes. This to make sure that we are using the same source code.

Okay - I'll have a look.

 

And thank you so much for helping me! You sir are doing a great job. Helping me to locate my silly errors.

As long as my experiments are worthwhile then I will continue

 

p.s. I have noticed that someone using the name: DB1 (in red) is a frequent visitor, and I was wondering how he got his name red. I'm not in trouble, watched over by some admin am I?

DB1 is a long term user at InsanelyMac who, from previous posts I've seen, knows a lot more than me. And I think he worked previously with MasterChief on a few projects so I guess he's obviously interested in the work you're doing here - so you have nothing to worry about As for his name is in red, that's because he's made a donation to InsanelyMac which entitled you to a 'Donator' badge under your name and for you name to appear in red.

[blackosx]

I'll now attach a diff file with my changes. This to make sure that we are using the same source code.

patch applied and I now see more info.. To save typing I have attached a photo.

(Note: this was from using my previous settings.)

 

EDIT: This is with #define DYNAMIC_SMBIOS_DATA_GATHERING 1

and #define DYNAMIC_CPU_DATA_GATHERING 1

 

And at least it finds the mach kernel and config file now. Which is a step forward. What if you set the second line to 1?

I'll try that next.

 

p.s. Your SMBIOS data is OK now? I mean you didn't copy the wrong data, that failed previously (the duplicated line error).

I fixed the duplicated incorrect line in my SMBIOS data. But I am still stuck on exactly what data to add in to the system-id field.

[blackosx]

So far so good. But what happens after pressing a key?

sorry, I update my previous post..

and after the No SMBIOS replacement found message, I then get to see the multicoloured blocks when it crashes.

[blackosx]

It appears to be stuck in SMBIOS patcher. Have you replaced my data with yours?

All I've changed is my private_data.h but as I'm now using dynamic then this doesn't get used?

 

Please check function sm_get_cputype and sm_get_bus_speed in dynamic_data.h because there you will need to change the #if CHAMELEON into #if 1 // CHAMELEON or it won't do anything.

I've made the changes but I now get this compilation error:

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

[blackosx]

Same #if CHAMELEON {censored}. We got to get rid of it a.s.a.p.

Fixed it.. by changing

#if 1 // CHAMELEON
static int sm_get_simplecputype()

 

another step forward.. I now have CPU identification.

 

But then I get to the coloured blocks...

[blackosx]

Ok. You may also need:

-	if (platformCPUFeature(CPU_FEATURE_MOBILE))
+	if (Platform.CPU.Features & CPU_FEATURE_MOBILE)

and possibly:

-	return (platformCPUFeature(CPU_FEATURE_MOBILE)) ? 667 : 800;
+	return (Platform.CPU.Features & CPU_FEATURE_MOBILE) ? 667 : 800;

adding these made no difference to the CPU debug output shown here

 

You are almost there. Open cpu/dynamic_data.h and make it dump the CPU info.

Okay - adding #define DEBUG_CPU 1.

will rebuild and reboot. - back shortly.

 

EDIT:

using DEBUG_CPU 1

after I see Verifying DMI Data Pool, the screen is cleared and then the debug info is drawn. But after 'Press a key' appears, nothing happens.. The keyboard lights for Caps Lock, scroll lock etc. still work but there's nothing else I can do here.

 

Where as without DEBUG_CPU 1

The debug info follows the Verifying DMI Data Pool without the screen being cleared, and I see more output (but obviously no CPU data).

 

Then the screen shows the multicoloured blocks before crashing.

[DB1]

p.s. I have noticed that someone using the name: DB1 (in red) is a frequent visitor, and I was wondering how he got his name red. I'm not in trouble, watched over by some admin am I?

 

HA,Ha OSX Police! no just an interested party.

 

I had the topic subscribed and was surprised when it kicked off again. Also suspected you DHP was MC. I've been trying this on my Advent (wind clone) and got as far as blackosx (up to post 201) had and same results.

 

I wont post unless I have something different to tell or suggest. Looking at whats happened today I have a bit to catch up on and try which I will later today.

 

Keep up the great work DHP, and best regards to your Dad.

[blackosx]

Make sure you set DEBUG_CPU to 1 in libsaio/cpu.c I just checked it here and it works, so if you don't get to see it, something is not right. Not to mention that this function is called ahead of almost everything, meaning that it has to work. Otherwise you won't get this far. The only problem I'm having, without the actual CPU info, is what the frequency is set to.

Doh!... thanks DHP - I had it in cpu/dynamic_data.h ?? That's why you're the coder and I'm the tester.. Lol.

Here's the feedback:

 

HA,Ha OSX Police! no just an interested party.

Funny - hi DB1

[blackosx]

Please enable the debug data for it, to see if I am right.

I'll ask this time before doing it... So shall I add #define DEBUG 1 to acpi_patcher.c ?

[blackosx]

Simply add:

printf("loadACPITable(%s)\n", tableName);
sleep(5);

in function loadACPITable()

Okay. I'll try this now.

 

Assuming that you load: /Extra/ACPI/dsdt.aml and/or /Extra/ACPI/ssdt.aml by setting LOAD_DSDT_TABLE_FROM_EXTRA_ACPI and/or LOAD_SSDT_TABLE_FROM_EXTRA_ACPI in libsaio/acpi_patcher.c to 1

Both of these were set to 0.

Now changed LOAD_DSDT_TABLE_FROM_EXTRA_ACPI to 1.

 

I have to go out shortly so this might be my last trial for now...

I'll report back in a minute.

 

EDIT:

well I added

	int fd = open (dirspec, 0);

printf("loadACPITable(%s)\n", tableName);  // blackosx Added
sleep(5);	// blackosx Added

if (fd < 0)

in function loadACPITable in /acpi/patcher.h

but after reboot, I saw no additional output ? is this function being called?

 

I have to go out now and probably won't be back for 6 hours or so I'll say happy new year to everyone now just incase I'm not back later.

[dgsga]

I feel lousy for not being able to get this sorted. I'm sorry.

 

 

Hey DHP,

 

Don't beat yourself up about this. problem solving is all part of the process, no-one expects 100% success first time round. I'll keep on with testing...

[DB1]

Funny - hi DB1

I have a bit to catch up on and try which I will later today.

 

ok, I caught up.

 

With:

 

boot.c #define DEBUG 1

acpi_patcher.c #define STATIC_ACPI_BASE_ADDRESS 0

#define PATCH_ACPI_TABLE_DATA 1

#define LOAD_DSDT_TABLE_FROM_EXTRA_ACPI 1

cpu.c #define DEBUG_CPU 0

smbios_patcher.c #define DYNAMIC_SMBIOS_DATA_GATHERING 1

smbios/dynamic_data.h #define DUMP_DATA_VALUES 0

#define DEBUG_SMBIOS 1

 

 

 

boot0: GPT
boot0: testing
boot0: done
boot1: /bootBIOSDev : 128
gArchCPUType (CPU) : i386
gBootVolume			 : hd (0,1)
byChain -1				: hd (0,1)
rootVolume			   : hd (1,2)
byChain					: hd (0,1)
Setting mayUsePreLinkedKernel to false
Load Kernel	: mach_kernel
Sleeping for 5 seconds
Kernel header data
================================
Signature				  : 0xfeedface
CompressType		  : 0x00000007
adler32					 : 0x00000003
uncompressed size	 : 0x00000002
compressed size		: 0x00000012
platformName			:
rootpath					: ♀
Press a key

 

then

No SMBIOS replacement table found
LoadingACPITable (DSDT)

 

then to grey screen with apple and no throbber

 

Thats enough for today, getting ready to party. Happy New Year all.

[blackosx]

ok, I caught up.

../snip/..

then

No SMBIOS replacement table found
LoadingACPITable (DSDT)

 

then to grey screen with apple and no throbber

 

Thats enough for today, getting ready to party. Happy New Year all.

You did well DB1 - and I see you managed to get the LoadingACPITable message to appear

Happy New year.

 

I also have the LoadingACPITable message, it was due to the DEBUG_CPU 1 setting. Changing this back to 0 allows the CPU identification, No SMBIOS replacement and LoadingACPITable messages to appear.

 

Thank you. I'm feeling much better already. And Happy New Year everyone !!!

Happy new year to you too

Sorry about my abrupt exit yesterday but time got the better of me and I was running late.

 

dad laughed so hard that he spilled his drink out of his noise

Brilliant

 

 

And there's one thing that we need to take care of in boot2/options.c:

	int bootArgsLength = strlen(cp);

if (bootArgsLength > cntRemaining)
{
	truncated = true;
	bootArgsLength = cntRemaining;
}

if (truncated)
{
	error("Warning: boot arguments too long, truncating\n");
}

// Store boot args.
strncpy(&argP[kernelFlagsLength], cp, bootArgsLength);
argP[kernelFlagsLength + bootArgsLength] = '\0';

if (configKernelFlags)
{
	// Free the earlier allocated (in boot.c) / passed on Kernel Flags.
	free(configKernelFlags);
}
}

There was no if() clause and configKernelFlags is NULL without com.apple.Boot.plist and/or Kernel Flags.

Wow - you've been busy already.. I'll take a look.

 

EDIT:

Added and the boot process continues as it did.

 

==========================================

 

I can't sleep. Had a look at the changes and I don't know if this can be used on every motherboard;

#if MUST_ENABLE_A20
   // Enable A20 gate before accessing memory above 1Mb.
if (fastEnableA20() != 0)
{
	[color="#FF0000"]enableA20();[/color] // Fast enable failed. Try the old method.
}
#endif

Testing it is easy. Simply compile Chameleon with the red function call removed. No problem when it boots up, but otherwise you need to change this snippet. And if setting it to 1 doesn't help then simply call it without the extra cruft surrounding it.

Just tried this with the latest version of RC5: this is how it looks:

	initialize_runtime();
// Enable A20 gate before accessing memory above 1Mb.
//enableA20();
common_boot(biosdev);
}

And I can boot my OS X installation with the latest Chameleon RC5 just fine with enableA20(); commented out.

[dgsga]

Thank you. I'm feeling much better already. And Happy New Year everyone !!!

 

 

Ah so you passed the SMBIOS hurdle already. Sweet. And there's one thing that we need to take care of in boot2/options.c:

	int bootArgsLength = strlen(cp);

if (bootArgsLength > cntRemaining)
{
	truncated = true;
	bootArgsLength = cntRemaining;
}

if (truncated)
{
	error("Warning: boot arguments too long, truncating\n");
}

// Store boot args.
strncpy(&argP[kernelFlagsLength], cp, bootArgsLength);
argP[kernelFlagsLength + bootArgsLength] = '\0';

if (configKernelFlags)
{
	// Free the earlier allocated (in boot.c) / passed on Kernel Flags.
	free(configKernelFlags);
}
}

There was no if() clause and configKernelFlags is NULL without com.apple.Boot.plist and/or Kernel Flags.

 

Have just tried 634 with the options.c diff and the foillowing settings and get one step further :

 

boot.c #define DEBUG 1

acpi_patcher.c #define STATIC_ACPI_BASE_ADDRESS 0

#define PATCH_ACPI_TABLE_DATA 1

#define LOAD_DSDT_TABLE_FROM_EXTRA_ACPI 1

#define DUMP_ADDRESS 1

cpu.c #define DEBUG_CPU 0

smbios_patcher.c #define DYNAMIC_SMBIOS_DATA_GATHERING 1

smbios/dynamic_data.h #define DUMP_DATA_VALUES 0

#define DEBUG_SMBIOS 1

 

What happens is I get the debug info from boot.c and drivers.c, press a key and get the dumped ACPI base address, the kernel loads and I immediately get the "Unable to find driver for this platform" KP and the 'You need to restart your computer' message appears. So we know the kernel has been found but there is a failure in the provision of the SMBIOS table.

 

EDIT: Switched dynamic smbios data gathering to 0 and I get the same result. So it's not a failure in gathering the SMBIOS data, the data is not being passed onto the kernel.

[dgsga]

Success at last!

 

Finally booted to desktop with 634 by moving DSDT.aml from /Extra to /Extra/ACPI (Doh!) which fixed the KP and then commenting out the following lines in boot.c:

	}
#endif // CHAMELEON

// Did we switch to graphics mode yet (think verbose mode)?
/*if (gVerboseMode || bootArgs->Video.v_display == VGA_TEXT_MODE)
{
	// Switch to graphics mode and show the Apple logo on a gray-ish background.
	showBootLogo(); // formerly drawBootGraphics();
}*/

finalizeKernelBootConfig();

startMachKernel(kernelEntry, bootArgs); // asm.s
}

 

 

BlackOSX, try this as you seemed to be getting the same DEBUG output and halt as myself.

[blackosx]

Success at last!

...

BlackOSX, try this as you seemed to be getting the same DEBUG output and halt as myself.

Hi dgsga - Great news for you. Well done

 

However, I already have my DSDT.aml in /Extra/ACPI and after making the above code changes, there's unfortunately no difference here.

 

What happens is I get the debug info from boot.c and drivers.c, press a key and get the dumped ACPI base address, the kernel loads and I immediately get the "Unable to find driver for this platform" KP and the 'You need to restart your computer' message appears. So we know the kernel has been found but there is a failure in the provision of the SMBIOS table..

And I don't get as far as you had been as I don't get to see the "Unable to find driver for this platform" KP. I get to the same place as DB1 where the last message seen is "LoadingACPITable (DSDT)".

 

EDIT:

I just tried using #define DUMP_ADDRESS 1 as I saw in your list above. This now shows me the following on a freshly cleared black screen, after the LoadingACPITable (DSDT) message:

baseAddress: 0xf7150

I then get a different looking garbled screen to the multicoloured blocks I had been seeing before, though unfortunately not a booted system.

[DB1]

However, I already have my DSDT.aml in /Extra/ACPI and after making the above code changes, there's unfortunately no difference here.

 

same here.

 

I can with debug get to the base address but after its grey screen, apple and no throbber as before. black screen

 

Good for you though dgsga. Are you doing this on a desktop or a laptop?

[dgsga]

Hi dgsga - Great news for you. Well done

 

However, I already have my DSDT.aml in /Extra/ACPI and after making the above code changes, there's unfortunately no difference here.

 

 

And I don't get as far as you had been as I don't get to see the "Unable to find driver for this platform" KP. I get to the same place as DB1 where the last message seen is "LoadingACPITable (DSDT)".

 

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

 

Get DHP's last 634.zip file.

Apply the subsequent diff she uploaded in post 202 to make sure we had the same code as her, then make the change to options.c.

Set the following, compile and install boot file:

boot.c #define DEBUG 1

acpi_patcher.c #define STATIC_ACPI_BASE_ADDRESS 0

#define PATCH_ACPI_TABLE_DATA 1

#define LOAD_DSDT_TABLE_FROM_EXTRA_ACPI 1

#define DUMP_ADDRESS 1

cpu.c #define DEBUG_CPU 0

smbios_patcher.c #define DYNAMIC_SMBIOS_DATA_GATHERING 1

smbios/dynamic_data.h #define DUMP_DATA_VALUES 0

#define DEBUG_SMBIOS 1

Make sure DSDT.aml is in /Extra/ACPI.

 

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)

 

In my case this is: OperationRegion (BIOS, SystemMemory, 0xBF798064, 0xFF). You can get this info by extracting and decompiling your DSDT.aml from ioregistry explorer in a working system. I've found in the past that failure to make this change by using the DSDT.aml taken directly from the bios causes the system to freeze when trying to load the DSDT.aml. Hope this makes sense

 

PS I am running a desktop rig with Asus mobo.