How to boost the OS X boot process...

[blackosx]

@ blackosx

Totally screwed up MakeMedia in that last file I posted.

Fixed Now and then some But for my use only at this time.

Hi STLVNUB

 

Was that something to do with the ISO folder not being created before the /Extra/Extensions check?

Don't worry. It's coming on fine and we can iron out bug here and there as we go.

I look forward to seeing what changes you've made now.. Because I have been tinkering here and I feel that by now we have two different versions going between us.

 

To show what I have been doing, here's a Revised project folder that I have here. It's not fully working and there are problems with it, but it shows what I have been doing with the Menu etc.. Otherwise the code below is almost the same as what you have (I think). It includes the smbios2struct2 tool.

 

EDIT: Removed, see here for newer version..

 

p.s. I'm out for most of today so I'll check in what I can.

[humph]

Hi again!

Well, I was totally looking forward to seeing some nice improvement in booting. But perhaps I am doing something wrong...As it seems if anything to be some seconds slower on average.

 

The smbios table I got via the new 2struct2 app has a bunch of zeros at the end, and since I pasted that as-is into the static data table, that's what I see in IOReg. So I tried the app on the MBP, and also get a lot of trailing zeros.

But in IOReg, this is not seen (on MBP).

eg; total byte count 0x5fc or thereabouts, with zeros from 0x2c0 or thereabouts.

But total size and number of structures is way less at 7 vs 37 (on hack).

 

Perhaps this is just due to the stripping out of un-needed data so is to be expected? On other hand seems to include stuff with references to SATA, CPU, DIMMs etc, based on looking at MBP smbios table dump from IOReg.

 

Perhaps I should have booted with dynamic smbios then grabbed, rather than booting with static smbios table produced from old version of smbios2struc? Although i dont understand how that could make any difference...?

 

Tried also with not including the zeros in the data.h table, and that did not make any performance difference, although of course now now zeros in IOReg table.

 

humph - stumped

[GrootWitBaas]

I have located the problem, but I'm not willing to waste tome on the old code anymore. Started to write my own lines. 50% smaller and 500ms faster already.

Now that's the way to go. And again Practice makes perfect, and I think you are getting to the perfect part (yes there will be bug, but that is normal, just take them one at a time)

 

I have a question for you, is there some secret sequence list for all the files, or am I just not seeing it ? From the very little I have learned of c++ there should be a int main() somewhere, but so far I have not seen it ....maybe you can enlighten me ? and what is the 1st "file" we go into when boot is called ? boot.c right ? just to make sure I follow it right ...

[GrootWitBaas]

For normal application / command line tools yes, but not for a boot loader. Take a look at: boot2.s which calls boot() in boot.c That's out main()

so boot2.s is our "main" good ....I can work from there ...also see below

 

 

Theres a GOOD little tool called OTX.

It decompiles Apple Executables.

But wait, you may say, boot is NOT an Apple Executable.

That is correct, BUT

boot.sys IS.

Use OTX on boot.sys and you get a GOOD overview of the boot process,

using it at the moment to implement a BOOT CHIME

 

My tip of the week

loads of information .....wow

you are aware of the thread I started about that right ??

[Krishna21]

7 seconds from post, and only 12 turns

[blackosx]

I've a newer version of RevStart here, that I should have posted earlier.

removed due to problems with Prep and MakeMedia options - please don't use those options.

 

Let me make a new disk.c with additional debug info that I need. Only need the output of the following line:

"Init B/RootVolume - partition: N, flags: N, gptID: N"

Thanks for looking in to it DHP. I'll look a bit later - got to go out again.

 

UPDATE:

Sorry for the delay DHP.

I've added the revised disk.c and booted from HDD, trying with both of my two HDD's as default drive in BIOS. Each boot my OS X installation on HDD 0 and the output I read is the same for both:

"Init B/RootVolume - partition: 2, flags: 10, gptID: 2"

Using the same boot file from USB, when it boots my OS X installation on HDD 1 (which I can't boot from HDD), the debug reads:

"Init B/RootVolume - partition: 1, flags: 10, gptID: 1"

Hope that helps identify what's going on.

 

Oh.. and while I'm back to my testing phase, I still have a considerable delay when booting from USB compared to HDD. It occurs after the last disk debug message which reads:

boot.efi found on bvr->part_no: X
Sleeping for 5 seconds

This can then take 20 seconds before I see

Entering Setup ACPI(1)

Note: The enabled debug for this test is:

#define DEBUG_ACPI 1

#define DEBUG_DISK 1

#define DEBUG_PLATFORM 1

 

UPDATE 2:

I have made a couple of videos to show you.

I am using here the latest build of Revolution with the revised disk.c.

 

#define ACPI_10_SUPPORT 1

#define PATCH_ACPI_TABLE_DATA 1

#define STATIC_APIC_TABLE_INJECTION 1

#define STATIC_DSDT_TABLE_INJECTION 1

#define STATIC_FACS_TABLE_INJECTION 1

#define STATIC_HPET_TABLE_INJECTION 1

#define PRE_LINKED_KERNEL_SUPPORT 1

#define DEBUG_DISK 1

#define APPLE_STYLE_EFI 1

#define INJECT_EFI_DEVICE_PROPERTIES 1

#define EFI_64_BIT 1

#define USE_STATIC_SMBIOS_DATA 1

 

Video showing boot from HDD

Video showing boot from USB

[GrootWitBaas]

For those not following the thread about boot sound, with the help of humph and others sharing information ...we now can have a two (or more) tone start-up sound right where the grey background is loaded. working on getting the G-Major oktaves from sosumi

[blackosx]

Please change the sleep(1); into _DISK_DEBUG_DUMP(1); to see if that's the one we're after.

Gives this:

 

Also, when I replied to DB1 about his increased boot speed, by saying I haven't really noticed any speed imrovement, you replied:

I guess that it depends on the BIOS (smbios data) but why don't you set VERBOSE to 1 and tell us what you see. How many / which structures are dropped

Well thanks to your smbios2struct2 v1.02 I can tell you this:

Table:   0                      BIOS Information  @0x100825430  Formatted area: 24 bytes  Structure length: 137 bytes.
Table:   1                    System Information  @0x1008254b9  Formatted area: 27 bytes  Structure length: 130 bytes.
Table:   2      Base Board or Module Information  @0x10082553b  Formatted area:  8 bytes  Structure length:  87 bytes.
Table:   3           System Enclosure or Chassis  @0x100825592  Formatted area: 17 bytes  Structure length:  54 bytes (dropped).
Table:   4                 Processor Information  @0x1008255c8  Formatted area: 35 bytes  Structure length:  93 bytes.
Table:   5         Memory Controller Information  @0x100825625  Formatted area: 24 bytes  Structure length:  27 bytes (dropped).
Table:   6             Memory Module Information  @0x100825640  Formatted area: 12 bytes  Structure length:  16 bytes (dropped).
Table:   6             Memory Module Information  @0x100825650  Formatted area: 12 bytes  Structure length:  16 bytes (dropped).
Table:   6             Memory Module Information  @0x100825660  Formatted area: 12 bytes  Structure length:  16 bytes (dropped).
Table:   6             Memory Module Information  @0x100825670  Formatted area: 12 bytes  Structure length:  16 bytes (dropped).
Table:   7                     Cache Information  @0x100825680  Formatted area: 19 bytes  Structure length:  35 bytes (dropped).
Table:   7                     Cache Information  @0x1008256a3  Formatted area: 19 bytes  Structure length:  35 bytes (dropped).
Table:   8            Port Connector Information  @0x1008256c6  Formatted area:  9 bytes  Structure length:  24 bytes (dropped).
Table:   8            Port Connector Information  @0x1008256de  Formatted area:  9 bytes  Structure length:  26 bytes (dropped).
Table:   8            Port Connector Information  @0x1008256f8  Formatted area:  9 bytes  Structure length:  16 bytes (dropped).
Table:   8            Port Connector Information  @0x100825708  Formatted area:  9 bytes  Structure length:  17 bytes (dropped).
Table:   8            Port Connector Information  @0x100825719  Formatted area:  9 bytes  Structure length:  17 bytes (dropped).
Table:   8            Port Connector Information  @0x10082572a  Formatted area:  9 bytes  Structure length:  17 bytes (dropped).
Table:   8            Port Connector Information  @0x10082573b  Formatted area:  9 bytes  Structure length:  21 bytes (dropped).
Table:   8            Port Connector Information  @0x100825750  Formatted area:  9 bytes  Structure length:  30 bytes (dropped).
Table:   8            Port Connector Information  @0x10082576e  Formatted area:  9 bytes  Structure length:  16 bytes (dropped).
Table:   8            Port Connector Information  @0x10082577e  Formatted area:  9 bytes  Structure length:  16 bytes (dropped).
Table:   9                          System Slots  @0x10082578e  Formatted area: 13 bytes  Structure length:  18 bytes (dropped).
Table:   9                          System Slots  @0x1008257a0  Formatted area: 13 bytes  Structure length:  18 bytes (dropped).
Table:  13             BIOS Language Information  @0x1008257b2  Formatted area: 22 bytes  Structure length:  81 bytes (dropped).
Table:  16                 Physical Memory Array  @0x100825803  Formatted area: 15 bytes  Structure length:  18 bytes.
Table:  17                         Memory Device  @0x100825815  Formatted area: 27 bytes  Structure length:  80 bytes.
Table:  17                         Memory Device  @0x100825865  Formatted area: 27 bytes  Structure length:  59 bytes.
Table:  17                         Memory Device  @0x1008258a0  Formatted area: 27 bytes  Structure length:  80 bytes.
Table:  17                         Memory Device  @0x1008258f0  Formatted area: 27 bytes  Structure length:  59 bytes.
Table:  19           Memory Array Mapped Address  @0x10082592b  Formatted area: 15 bytes  Structure length:  18 bytes (dropped).
Table:  20          Memory Device Mapped Address  @0x10082593d  Formatted area: 19 bytes  Structure length:  22 bytes (dropped).
Table:  20          Memory Device Mapped Address  @0x100825953  Formatted area: 19 bytes  Structure length:  22 bytes (dropped).
Table:  20          Memory Device Mapped Address  @0x100825969  Formatted area: 19 bytes  Structure length:  22 bytes (dropped).
Table:  20          Memory Device Mapped Address  @0x10082597f  Formatted area: 19 bytes  Structure length:  22 bytes (dropped).
Table:  32               System Boot Information  @0x100825995  Formatted area: 11 bytes  Structure length:  14 bytes (dropped).
Table:  64                                        @0x1008259a3  Formatted area: 13 bytes  Structure length:  16 bytes (dropped).
Table: 127                          End-of-Table  @0x1008259b3  Formatted area:  4 bytes  Structure length:   7 bytes (dropped).
Table: 131                    OEM Processor Type  @0x1008259ba  Formatted area:  6 bytes  Structure length:   8 bytes.
Table: 132               OEM Processor Bus Speed  @0x1008259c2  Formatted area:  6 bytes  Structure length:   6 bytes.

Dropped tables: 29.

[GrootWitBaas]

P.S anybody remember Impossible Mission, came out on the C64 on tape.

I coded a disk loader for it, 25 odd minutes from tape, about 2 minutes from disk.

Those where the days.

I really loved that C64 and its 1541 disk drive (a computer in itself).

Stupid Commodore, the Amiga was the one that started it all.(multimedia that is)

I started on a C64 with 1541 ...I have a working C64 in my attic, but sadly not with a 1541, only a tape. Yes I remember those days (when I was still Young AND Beautiful, Now I just Young) when I knew what poke 53280,1 and peek 53281 meant

[blackosx]

Hmm. Not exactly what I expected, but still. At least now we know that it isn't related to read errors. Have searched for forgotten sleep instructions, but can't seem to find any. I'm intrigued by it. Wondering what I am missing.

 

Enabling one of the other debug directives solves the wait or not? That should at least show you where it waits so long. That is if it is a sleep in structure and not something running in a loop.

Hi dutchhockeypro

 

I've been on a bug hunt this morning and although I'm not there yet, I have some progress.

 

My delay when booting from USB only happens when #define DEBUG_BOOT is set to 0.

I've tracked the code as far as this in boot.c

		else // Booting from USB-stick or SDboot media.
	{
		_BOOT_DEBUG_DUMP("Booting from a Non System Volume, getting UUID.\n");

		// Get target System Volume and UUID in one go. 
		BVRef rootVolume = getTargetRootVolume(rootUUID);

		[color="#FF0000"]The code returns to here, then I have the long delay[/color]
		[color="#FF0000"]before seeing the SUCCESS message below.[/color]

		if (rootVolume)
		{
			_BOOT_DEBUG_DUMP("Success [%s]\n", rootUUID);

			// gPlatform.RootVolume = rootVolume;
		}
	}

I'm off out in half an hour then won't be back until later this afternoon where I'll look further in to trying to nail this sucker

 

For those not following the thread about boot sound, with the help of humph and others sharing information ...we now can have a two (or more) tone start-up sound right where the grey background is loaded.

Hi Groot - thanks for the note about the success you're having and well done!. I haven't had a chance to look at it yet, but I will soon. Good job.

[humph]

New update of smbios2struct2 (v1.02) attached to fix the trailing zero byte error...

Hello HDP, trust the game(s) went well today!

So this new converter seems to work nicely, no more gazillion zeros! Although I did run from:

- When booted using dynamic smbios, and

- When booted using old static data

And got vastly different data! Also, even from dynamic the max number thing changed from 134 to 127.

Have not checked in much detail for strange stuff, other than I note that defaulted to MB4.1 via dynamic. Since I lost track of those changes I suspect that is as intented. If any of the comments above concern you, as in not expected results then I can do a deep dive into stuff here.

Anyway, am now running static using data derived from a dynamic boot but with modded source to get me back to MBP6,1 so speedstep works again.

[blackosx]

If it returns there without delay then that is a strange place for a delay. Almost like the hardware has to recover from something bad. Do you have four or six drive connectors on your motherboard?

Yeah. It is strange, but I still wonder why this happens only when #define DEBUG_BOOT is set to 0? as setting it to 1 allows the boot process to continue straight to loading the pre-linked kernel.

 

I have six SATA pots on my motherboard.

HDD's plugged in to Port 0 and 1, e-SATA plugged in to Port 2, DVD drive plugged in to Port 5.

 

Also. Open sys.c and scroll down to the bottom of the file to find function getTargetRootVolume. What happens when you limit / change LAST_HDD_TO_CHECK to 0x84 or maybe even lower say 0x82 perhaps?!?

Setting this to both 0x84 and 0x82 doesn't make any difference

[humph]

Is pool champion good enough? And yes. This is with the second team I defend the goal for. Next week may become my third pool championship in one season.

Very impressive!

No more zeros is good. Thanks for the confirmations. Now about the vastly different data part. What do you mean by that? The length changes or the content? Have two examples for me?

I'm guessing/hoping is probably just due to the MB4,1 vs MBP6,1 - at least I saw the length change from 127(MB) to 134(MBP) when mucking about with that. So will do some tests with new version from your post. If still seems strange, then sure can provide the output files etc.

 

EDIT: Can't get the above to compile. Added #include model_data.h to dynamic_data.h. Tried some stuff, can't see what's gone wrong. Perhaps am too tired. Anyway, getting error due to 1st use of sm_defaults = STATIC_DEFAULT_DATA; or something...!

[DB1]

This is the work DB1 and Humph (possibly others as well) have been waiting for. Change your config/settings.h so that it includes:

//-------------------------------------------------------------- SMBIOS.C ------------------------------------------------------------------


#define USE_STATIC_SMBIOS_DATA				0	// Set to 0 by default (dynamic data collection). Change this to 1 to use static data.

[color="#FF0000"][b]#define OVERRIDE_DYNAMIC_PRODUCT_DETECTION	1	// Set to 0 by default. Change this to 1 when you want to use a predefined product type.

#if OVERRIDE_DYNAMIC_PRODUCT_DETECTION
#define STATIC_SMBIOS_MODEL_ID			IMAC	// Supported models: IMAC, MACBOOK, MACBOOKPRO, MACMINI or MACPRO
#endif[/b][/color]

#define DEBUG_SMBIOS						0	// Set to 0 by default. Change this to 1 when things don't seem to work for you.

Then open libsaio/smbios/dynamic_data.h and remove the defaults_[iMac/MacBook/MacBookPro/Macmini/MacPro] blocks that I moved into model_data.h and change the following function:

static const char *sm_get_defstr(const char *name)
{
int i;
char (*sm_defaults)[2][40];

[color="#FF0000"][b]#if OVERRIDE_DYNAMIC_PRODUCT_DETECTION
sm_defaults = STATIC_DEFAULT_DATA;
#else[/b][/color]
if (gPlatform.CPU.Mobile)
   {
       if (gPlatform.CPU.NumCores > 1)
	{
		sm_defaults = defaults_MacBookPro;
	}
	else
	{
		sm_defaults = defaults_MacBook;
	}
}
else
{
	switch (gPlatform.CPU.NumCores)
	{
		case 1:		sm_defaults = defaults_Macmini;
			break;
		case 2:		sm_defaults = defaults_iMac;
			break;
		default:	sm_defaults = defaults_MacPro;
			break;
       }
   }
[color="#FF0000"][b]#endif[/b][/color]
for (i = 0; sm_defaults[i][0][0]; i++)
{
	if (!strcmp(sm_defaults[i][0], name))
	{
		return sm_defaults[i][1];
	}
}

_SMBIOS_DEBUG_DUMP("Error: no default for '%s' known\n", name);
_SMBIOS_DEBUG_SLEEP(5);

return "";
}

Then you can compile Revolution for a specific (target) model. I verified it by selecting IMAC for the HP – which is normally set to MacBookPro

 

Note: model_data.h will in time change to load the data from a plist file.

 

Now I really, really need to stop. Back later (very late probably)...

I get compile error:

In file included from smbios.c:63:
smbios/dynamic_data.h: In function ‘sm_get_defstr’:
smbios/dynamic_data.h:104: error: ‘STATIC_DEFAULT_DATA’ undeclared (first use in this function)
smbios/dynamic_data.h:104: error: (Each undeclared identifier is reported only once
smbios/dynamic_data.h:104: error: for each function it appears in.)
make[2]: *** [smbios.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

[blackosx]

Hi DB1

 

I had that also.

I don't know if this is correct or not, but I added #include "model_data.h" at the top of /i386/libsaio/smbios/dynamic_data.h

 

So DHP, the override is for using with dynamic smbios data only? which works great

 

I ask because I tried booting with dynamic smbios data (without the override), then used smbios2struct v1.02 to build my static smbios data (with model set to iMac 11,1 as it does with dynamic). Then booted with:

#define USE_STATIC_SMBIOS_DATA 1

#define OVERRIDE_DYNAMIC_PRODUCT_DETECTION 1

#define STATIC_SMBIOS_MODEL_ID MACPRO

but the override didn't override static data. I guess this is by design?

To answer my own ramblings I guess why use static smbios data to then override it?

 

Also, using dynamic smbios data, my processor is shown as 2.67 Ghz Unknown. I've never really used dynamic smbios data before so never before noticed this.

 

I have no idea what the problem is. Especially since there is no code to execute. Just a void space in between a function return and if clause. Adding a few new printf() statements left and right may help to locate the problem.

.../snip/..

I might be wrong of course, but I still think that this is the place to look for bugs.

I'll keep looking and look again at function getTargetRootVolume.

 

BTW: You also boot in verbose mode when DEBUG_BOOT is set to 0? And setting DEBUG_EFI and/or DEBUG_SMBIOS to 1 doesn't do any good either?

Booting with DEBUG_BOOT set to 0 and no other debug enabled, shows me the grey screen with the Apple logo. I know the code stalls as I have to wait 29 seconds before seeing the throbber/spinner.

 

Enabling DEBUG_EFI and/or DEBUG_SMBIOS does there own thing but doesn't affect the stall. The stall is only present when DEBUG_BOOT is set to 0.

 

I have like 25 minutes before I have to go out for another award ceremony

Wow.. I think you'll have to be buying a new trophy cabinet soon..

Well done.

[DB1]

Hi DB1

 

I had that also.

I don't know if this is correct or not, but I added #include "model_data.h" at the top of /i386/libsaio/smbios/dynamic_data.h

 

Yeah blackosx tried that already but still get error!. Need to check over what i did and retry. Thanks anyway.

[blackosx]

Yeah blackosx tried that already but still get error!. Need to check over what i did and retry. Thanks anyway.

And model_data.h is in /i386/libsaio/smbios ?

[humph]

And model_data.h is in /i386/libsaio/smbios ?

That's where I put it..

[DB1]

And model_data.h is in /i386/libsaio/smbios ?

 

Yeah, and tried in libsao. Still getting the error, maybe I change something elsewhere. need to go on a back check mission.

[DB1]

Hi DB1,

See my reply to Humph. Verified it with the new directive set to 0/1 and various models. The HP doesn't like IMAC but it works.

 

Sorted now, back on the same song sheet. Went back and started clean. Tried various models both on SD & EFI all works great, well done with this and the hockey. Your parents must be sooooo proud.

 

Catch you all tomorrow evening.

[blackosx]

Good morning DHP.. Sounds like you had a good evening last night and that was a nice surprise from your dad.

Just to be sure. The stall is there even when you set other debug directives to 1 and DEBUG_BOOT to 0?

Yes, other directives can be enabled, but it's only when DEBUG_BOOT is set to 0 the stall occurs.

 

This morning I experimented with all dynamic data and the only directives set to 1 in settings.h were

#define ACPI_10_SUPPORT 1

#define EFI_64_BIT 1

and it stalls, but again only from USB.

 

UPDATE:

I remembered during the night that when I last looked for what's causing my delay, I had only got as far as what I posted in post #1088 and hadn't finished my bug trail, so we can rule out the strange void which I had presumed the code stopped at! Doh!!

 

I had to leave for work early this morning, so I didn't have much time but I did some more searching and enabling #define DEBUG_EFI to 1 has allowed me to track the code further and I have got as far as this in boot.c :

 

   // Parse args, load and start kernel.
   while (1)
   {

printf("Blackosx: function boot in boot.c : Now in while(1) before // Initialize globals. \n");  // blackosx added
       // Initialize globals.

       sysConfigValid = 0;
       gErrors        = 0;

	int retStatus = -1;

	printf("Blackosx: function boot in boot.c : About to call getAndProcessBootArguments \n");  // blackosx added

	getAndProcessBootArguments(kernelFlags);

	printf("Blackosx: function boot in boot.c : Returned from getAndProcessBootArguments \n");  // blackosx added

               [color="#FF0000"]GOT TO HERE - Will look further this evening....[/color]

#if PRE_LINKED_KERNEL_SUPPORT

 

though I haven't finished yet and will continue this evening.

And I can also tell you that the delay happens with or without using the pre-linked kernel so we can skip that bit.

 

I've attached a debug screenshot.

 

I know I'm getting close to finding the problem and hopefully tonight I will find it.

 

...but before that I'll attach a new update to smbios/dynamic_data.h This one to fix the CPU detection bug.

Nice one. I've applied the source and compiled successfully. I'll test the boot file when I get home.

[blackosx]

@blackosx

If you don't mind can I get your current complete Project folder with Revolution in it, something screwed in mine.

Certainly - this is what I have including the changes DHP made this morning in post #1104.

Revolution_Release_FINAL_Override_CPUDetect.zip

There's also an newer version of ProjectRevolution to match - but it's not ready yet.

 

Note. I've only just made these today and haven't actually used either yet. I will do tonight.

[FKA]

Hi All

 

Just wanted to say I've managed my first boot with Revolution!!

 

I have to say all looks absolutely spot on so far - I just need to work on shutdown / restart.

 

I'll be happy to test on my RAID0 install when there's support.

 

Huge decrease of boot time, I've gone from nearly 26 turns to 10!

 

Massive thank you to all involved. Dutch' you are quite something!

And a huge thanks to BlackOSX and STLVNUB, cos there is no way I would have had time to catch up with this without your killer script!

 

Be seeing you!

[DB1]

Hi DB1,

 

Perfect. And yes they are – dad is here so we are going to do fun stuff after having a nice hot cup of coffee, but before that I'll attach a new update to smbios/dynamic_data.h This one to fix the CPU detection bug.

 

p.s. You may need to add a few lines to your platform.c section in config/settings.h:

#define USE_STATIC_RAM_SIZE 0 // Set to 0 by default. Change this to 1 when you need to use static ram size info.
#if USE_STATIC_RAM_SIZE
#define STATIC_RAM_SIZES				{ SMB_MEM_SIZE_2GB, SMB_MEM_SIZE_2GB }
#endif

 

Hi DHP, great you had a good night and a great day today.

 

Ok, tried this putting this here:

#define STATIC_MAC_PRODUCT_NAME				"MacBookPro6,1"


#if USE_STATIC_SMBIOS_DATA
// Do nothing.
#else
// Setup RAM module info.
#define STATIC_RAM_VENDORS				{ "N/A", "Crucial", "N/A", "Vendor#4", '\0' }

//	#define USE_STATIC_RAM_SIZE				0

										// Should only be used to correct wrong values.
//	#define STATIC_RAM_SIZE					SMB_MEM_SIZE_1GB	// See platform.h for other values.

#define USE_STATIC_RAM_SIZE					0 // Set to 0 by default. Change this to 1 when you need to use static ram size info.

#if USE_STATIC_RAM_SIZE
#define STATIC_RAM_SIZES					{ SMB_MEM_SIZE_1GB, SMB_MEM_SIZE_1GB }
#endif

#define STATIC_RAM_TYPE					SMB_MEM_TYPE_DDR2

#define STATIC_RAM_SPEED				667

#define STATIC_RAM_PART_NUMBERS			{ "N/A", "128X64K-67E", "N/A", "Part#4", 0 }

#define STATIC_RAM_SERIAL_NUMBERS		{ "N/A", "1158940424", "N/A", "Serial#4", 0 }
#endif

 

And set dynamic cpu, smbios, and ram and it compiles fine, about this mac confirms right cpu and ram BUT in System Profiler/Memory complains "There was an error while gathering this information". When I set use static ram size 1 it wont compile, giving error:

platform.c: In function ‘initPlatform’:
platform.c:167: error: ‘STATIC_RAM_SIZE’ undeclared (first use in this function)
platform.c:167: error: (Each undeclared identifier is reported only once
platform.c:167: error: for each function it appears in.)
make[2]: *** [platform.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

 

No problem for me patching along the way between full releases.

[DB1]

Hi DB1,

Thanks. We had a lot of fun yeah. Can't talk about it but the future is bright.

 

 

Cool. And you must have noticed that we're using a plural form now so it is ‘STATIC_RAM_SIZES and not ‘STATIC_RAM_SIZE anymore. Let me attach a file that may be causing you problems (just to be sure that you have what you should be using).

 

p.s. Back after the movie (going out with friends).

 

Yeah noticed the plural, and the attached file sorted out compile issue. And testing cpu, smbios, and memory dynamic same System profiler/memory message as before. With cpu, smbios dynamic and memory static same result. In both cases about this mac correct. Final test all static is fine.

 

Catch up after the movie.