How to boost the OS X boot process...

[GrootWitBaas]

i386/config

i386/config/data.h

i386/config/settings.h

i386/config/acpi/data.h

i386/config/efi/data.h

i386/config/smbios/data.h

 

Templates included. Hockey training now so back later...

All Working as expected. I still have many things to learn but so far it works for me.

 

now a curve-ball .... is it possible to save the debug information to a debug.log/txt/something file. I am sure it is possible, with my camera I don't catch everything all the time and taking a video works, but a file will be better/easier to work with. I am not sure if this was asked or spoken about before, I am sure it might have been.

[blackosx]

What I did for the attached release of Revolution-643 was to change a few things, to make it easier for you.

Thanks DHP. It all makes sense here. Keep up the good work.

 

Good to see what you can come up with

Thanks

Just a quick update to say I've nearly finished re-working to the script for intelligently populating /i386/config/ACPI/data.h, /i386/config/EFI/data.h and /i386/config/SMBIOS/data.h. It uses the files dumped in the STATIC folder from your script.

 

I've tweaked the efidp2struct tool and need to do the same for the smbios2struct tool before I'll be happy with it. Then I can move on to populating /i386/config/settings.h.

 

I'll post the files when I have a fully working example.

[GrootWitBaas]

Hi Groot,

I don't know. I don't think so, but that's mostly based on the idea that Chameleon can't seem to do it.

 

 

I am sure this can be done, we read a file (boot) so we should be able to write a file (log) in theory.

 

Back to testing, with all the old tools I have more static data now that I use, and I have at the moment most info showing correctly, CPU, Memory, Display ....but I see one small fault that I don't know how to fix, only on the about this mac screen, see below

[humph]

Great Stuff, DHP!

 

643 working here fine also (all static). BTW, auto-sleep seems to be working again, lost track I think you fixed something some days ago there. Or perhaps it was my messed up DSDT causing problems in past. Anyway, all nice now!

[GrootWitBaas]

Writing files is different I'm told.

 

Did you set STATIC_RAM_SIZE to some value in settings.h (in the platform.c section)?

I am sure we will find a way.

 

Nope, I don't have STATIC_RAM_SIZE in there, see below from settings.h

//------------------------------ PLATFORM.C ------------------------------------
#define DEBUG_PLATFORM	0// Set to 0 by default. Change this to 1.....

#define STATIC_MAC_PRODUCT_NAME	"MacPro3,1"

#if USE_STATIC_SMBIOS_DATA
// Do nothing.
#else
// Setup RAM module info.
#define STATIC_RAM_VENDORS		{"N/A","Vendor#2","N/A","Vendor#4",'\0'}
#define SMB_MEM_TYPE_DDR2		19
#define SMB_MEM_TYPE_FBDIMM		20
#define SMB_MEM_TYPE_DDR3		24
#define STATIC_RAM_TYPE			SMB_MEM_TYPE_DDR2
#define STATIC_RAM_SPEED		800
#define STATIC_RAM_PART_NUMBERS		{"N/A","Part#2", "N/A","Part#4",0}
#define STATIC_RAM_SERIAL_NUMBERS	{"N/A","Serial#2","N/A","Serial#4",0}
#endif

//==========================END=============================================

[DB1]

Weird. Also. You should get a compiler error about these being re-defined:

#define SMB_MEM_TYPE_DDR2 19
#define SMB_MEM_TYPE_FBDIMM 20
#define SMB_MEM_TYPE_DDR3 24

These are defined in platform.h already so please remove them from settings.h

 

I removed these when I added memory size code.

 

After intense testing happy to report everything showing as should, core 2 solo, MBP6.1, adjusted memory data BUT, a strange phenomenon when taking the new smbios and applying and then setting cpu & smbios static an extremely slow boot, worst yet in fact! however and more strange setting both to dynamic is fastest I've had yet (both these on EFI partition).

 

Is splitting the static data files causing a lag? Probably not as noticeable for those with faster cpu's. This is real weird, the throbber is visibly much slower when i'm set static! Or are those bugs you been talking about to blame?

 

Anyone else noticing this weird situation?

 

Bedtime, catch up tomorrow evening.

[dgsga]

Is splitting the static data files causing a lag? Probably not as noticeable for those with faster cpu's. This is real weird, the throbber is visibly much slower when i'm set static! Or are those bugs you been talking about to blame?

 

Anyone else noticing this weird situation?

 

Bedtime, catch up tomorrow evening.

 

Hi DB1,

 

The slow throbber speed is most likely the correct speed when your FSB is set correctly. I had the same problem, a fast throbber caused by an incorrect FSB value in cpu static data. Try playing a video file after booting with the fast throbber. If the audio and video are outy of sync it's a clear indication that your FSB speed is incorrect. What I did to fix it was get the correct CPU frequency value from Slices's chameleon branch (by far the most comprehensive CPU data calculation, deals with overclocking) and divide it by the CurrDiv value. All values in Hertz (not MHz)... In my case Chameleon reported a CPU frequency of 3627MHz = 3627000000 Hz. I divided this by CurrDiv of 0x14 = 20 decimal, gives a FSB of 181350000 Hz. Now Chameleon reports an FSB of 181MHz = 181000000Hz, this is not accurate enough and gave me the fast throbber. When I changed it to the more precise value all was well, videos played in sync and throbber was slow on boot. Hope this helps

 

DHP,

 

This gets better everyday, latest release of revolution now boots to desktop in 8 revs of the throbber, as opposed to 11. Great work, especially the clean up of the config files. Love it!

 

NB

 

I have noticed we are now all Insanely Mac 'Geeks' or 'Legends'. What does this mean?! BlackOSX, I'm intrigued about the Fluoro, how do I get to be one of those

[blackosx]

I have noticed we are now all Insanely Mac 'Geeks' or 'Legends'. What does this mean?! BlackOSX, I'm intrigued about the Fluoro, how do I get to be one of those

Hi dgsga

 

Doing this in pictures is quicker than typing..

 

-------------------

 

Question:

Does anybody know where in ioreg the current screen resolution being used is stored (if it is stored in ioreg that it is)?

I ask because the script for generating the /i386/config/settings.h is nearing a point for beta testing though before I do, I want to populate the #define STATIC_SCREEN_WIDTH and #define STATIC_SCREEN_HEIGHT directives with the right settings.

 

Also, would it be best if the auto-generated settings.h file had all debug enabled? I am assuming the users who are going to use the script will be new to Revolution and will be running the script from a OS X booted by Chameleon. Which means they won't have afore knowledge of things like their USE_STATIC_ACPI_BASE_ADDRESS.

[dgsga]

Hi dgsga

 

Doing this in pictures is quicker than typing..

 

-------------------

 

Question:

Does anybody know where in ioreg the current screen resolution being used is stored (if it is stored in ioreg that it is)?

I ask because the script for generating the /i386/config/settings.h is nearing a point for beta testing though before I do, I want to populate the #define STATIC_SCREEN_WIDTH and #define STATIC_SCREEN_HEIGHT directives with the right settings.

 

Also, would it be best if the auto-generated settings.h file had all debug enabled? I am assuming the users who are going to use the script will be new to Revolution and will be running the script from a OS X booted by Chameleon. Which means they won't have afore knowledge of things like their USE_STATIC_ACPI_BASE_ADDRESS.

 

Hi BlackOSX

 

Could you put a switch in there at the beginning which would ask whether you want to have debug enabled? If this involves far too much work then just ignore what I said. I will check about the screen res when I get back to the Hack.

 

Thanks to everyone for all their different but great contributions to this thread

[humph]

Does anybody know where in ioreg the current screen resolution being used is stored (if it is stored in ioreg that it is)?

On my MPB, I see hex values related to 1440x900 0x05A0 "x" 0x0384 byte flipped starting at offset 0x22:

IOReg_display_saved_config.tiff

This is under display@0.

But different hardware I think is going to show up in different places (PEGP, GFX, with or w/o PCI bridge etc) also depending on DSDT. Perhaps "display@0" is generic enough to be found in all machines.

 

EDIT: Hmm. Dont know how to make the picture show up as one of those little thumbnails. Sorry.

[blackosx]

Could you put a switch in there at the beginning which would ask whether you want to have debug enabled? If this involves far too much work then just ignore what I said. I will check about the screen res when I get back to the Hack.

Hi dgsga

 

Good idea and I don't see why not. But it will be after what I have posted here below.

 

On my MPB, I see hex values related to 1440x900 0x05A0 "x" 0x0384 byte flipped starting at offset 0x22:

...

But different hardware I think is going to show up in different places (PEGP, GFX, with or w/o PCI bridge etc) also depending on DSDT. Perhaps "display@0" is generic enough to be found in all machines.

Thanks for looking humph, I haven't had time to look myself yet. But I understand what you say and it might be difficult to 'grab'.. I'll see what I can be done.

 

--------------

 

But for now, I want to post where I'm at with the revised script for building the latest style of Revolution config files. I have added the revised functions in to STLVNUB's previous Revstart1.7 and although it's working it won't create complete enough files yet for someone to blindy use and build Revolution expecting it to boot.

 

Changes to previous RevStart1.7

• Moved 'Tools' folder out of Rev_Start_v0.1.5 folder to root of ProjectRevolution_1.7b2.

• Tools folder contains revised DHP tools as binaries.

• Removed Rev_Start_v0.1.5 folder.

• Added new functions to RevStart.command.

• Renamed RevStart.command to v1.7b2.

• Added calls to new functions at the bottom of the MakeACPI function.

• Added extra menu option 'MakeStatic' which only collects static data and builds the config data files.

 

 

EDIT: I have since updated the RevStart.command script. Please replace the one in the above archive with this one. The update allows the MakeStatic option run, even if it's already been run and the ACPI, ISO and STATIC folders already exist. Also, an existing settings.h file will be moved to settings.h.bak (as in the case of the Revolution-Release I point to below).

 

 

If anybody would like to test the new 'MakeStatic' option which will just run the functions to collect the ACPI table data, convert what it can to structs, and build the /i386/config/nnn files then I would be grateful to hear feedback. Especially if you could compare the results generated with your current config files.

• Don't use it on your current build of Revolution

• Download DHP's recently posted build in to the ProjectRevolution folder.

• Run the RevStart1.7b2.command from your OS X system booted from a standard Chameleon.

 

 

STLVNUB - I hope you don't mind the changes and if you can improve on what I have done then feel free to do so. I'll revisit this too when I can and after hopefully I get some feedback.

 

I'm off now. I'll try to log back in later tonight.

[DB1]

Hi DB1,

 

The slow throbber speed is most likely the correct speed when your FSB is set correctly. I had the same problem, a fast throbber caused by an incorrect FSB value in cpu static data. Try playing a video file after booting with the fast throbber. If the audio and video are outy of sync it's a clear indication that your FSB speed is incorrect. What I did to fix it was get the correct CPU frequency value from Slices's chameleon branch (by far the most comprehensive CPU data calculation, deals with overclocking) and divide it by the CurrDiv value. All values in Hertz (not MHz)... In my case Chameleon reported a CPU frequency of 3627MHz = 3627000000 Hz. I divided this by CurrDiv of 0x14 = 20 decimal, gives a FSB of 181350000 Hz. Now Chameleon reports an FSB of 181MHz = 181000000Hz, this is not accurate enough and gave me the fast throbber. When I changed it to the more precise value all was well, videos played in sync and throbber was slow on boot. Hope this helps

 

Hi dgsga,

 

Thanks for the lead on this, I feel so stupid! Checking my static cpu this evening I had missed a 0 on CPUFrequency & a 1 of FSBFrequency. Wonder it booted at all! That's what you get if you play till late in the night (well morning)

 

Everything running sweet now - static all.

[blackosx]

Hi dutchhockeypro

You guys are doing a great work. Thank you so much.

Thanks. I just hope it helps new users try this out if they want.

 

Is that because of SMBIOS or are the other things you need to grab from Chameleon?

Mainly because of grabbing the system-ID that Chameleon feeds the system for generating the hardware UUID. Chameleon records it, in it's boot log. I'm sure you could replicate this functionality in one of your tools? but for now it's the best way I can think of doing it.

 

And yes, also because of the SMBIOS override settings which users will be familiar with and will most probably have set for their hardware etc.

[DB1]

..... will be gone in a next update. As in the values will be ported to a plist, like MC said should be done two years ago. This way we save space, add the overrides for dynamic data gathering and can setup a load of defaults without adding any bytes to the boot loader. And on top of all that, you don't have to compile it to change a silly override value.

 

Wow DB1 That is one heck of a nice looking desktop picture. I like that!

 

Looking forward to the next update, the current one is the most stable and usable my macingtop has been since i started messing in this game.

 

Google Revolution logo. Might not be so good on a larger than 10" screen as is pretty low res.

 

Time to give this thing an identity beyond the name? anyone good with design / logo's?

[blackosx]

Good morning dutchhockeypro

 

Eh maybe I am missing something but system-id is part of settings.h and ioreg (platform node) in the same format. Why do you need Chameleon for this?

Speaking from my experience when starting out with Revolution I needed to add the same system-id to settings.h that standard Chameleon used to allow OS X to generate the same Hardware UUID, otherwise my system will be set differently at boot. For example, my System Prefs/Date & Time/Clock re-appears in the menu bar (as I have set it not to show), and my monitor calibration setting doesn't get applied. So I suggested for new users to boot from standard Chameleon as it's easy to gather that system-id value. I think that system-ID is read from my BIOS?

 

The value I see in ioreg (platform node), when booted from Revolution, is the same as what's in settings.h. So if new users boot with your default settings.h file then the system-ID used will be { 0xc3, 0xd2, 0x10, 0x75, 0xd3, 0x9d, 0x47, 0x8e, 0x98, 0xe5, 0x07, 0xb6, 0x0d, 0x1c, 0x27, 0x26 } which will not be what they have been using before.

 

Or am I missing something here?

 

Do you have examples of values that are essential for people to get a system going?

Not essential no, but an example from my machine is my hardware best represents an iMac 11,1 which is what it automatically gets detected as by both Chameleon and Revolution by default. However, because of an audio issue, and to allow effective power management (for P states I think), I want my machine to be seen as MacPro3,1.

 

First off, you started the ball rolling with RevStart, I just kept it rolling and it picked up speed.

Now its going ballistic. Anyone is free to do what they want, it can only get better.

I agree.. Anyone can contribute to it to try to make it fit everyone's needs.

I will have a look at trying to grab screen res today, thanks to humph finding where it's kept.

 

Well!!! What can I say.

Very impressive stuff blackosx, well done.

 

Have included an updated script

 

Have also adjusted your code to make use the variable AcpiBase, thats why I had it there(knew it would come in handy)

Successfully built static and booted, well after three attempts and then enabling_A20.

Thanks for the feedback. Good to hear you've used it to great effect. I'll take a look at the revised script. And think about what else can be added and how..

 

Have also adjusted your code to make use the variable AcpiBase,

thats why I had it there(knew it would come in handy)

Thanks. But this still needs to be set per individual system if we want to use it. I just need to know how to find the address. So I have set it back to 0x0000000 for now and I am attaching a revised RevStart command as I had a couple of additions which I forgot to add. They are to set the #define INJECT_EFI_DEVICE_PROPERTIES and #define USE_STATIC_SMBIOS_DATA directives if static data exists for them.

 

[blackosx]

Ah of course. And yes it is read from BIOS (SMBIOS) in Chameleon, but in Revolution it is commented out. Making it impossible to identify someone by this setting.

You mean pinpoint the OS X system by system-ID number? Do Apple to that with software update etc.? as I remember MC saying so.

 

but we better use the same value as Chameleon, which is:

#define STATIC_SYSTEM_ID					{ 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F }

But that default only gets applied it Chameleon doesn't find a system-ID in the BIOS. So are you suggesting to use it just because that number is already in circulation for some systems?

 

And does iTunes still complain when booting the system using a different ID? I haven't tried it for a while. I'll test it this evening.

 

So let's use this from now on, instead of anything else.

Meaning we will all use the same system_ID number? In which case wouldn't it be easy to identify all the OS X systems booted using the boot-132/Chameleon code-base?

 

Hmm. DB1 recently had to change the source code to get his Atom based computer identified as a MacBookPro. I think that it is time to add some lines so that people can set (by selection) a Mac model for settings.h and then we have to use that instead of the default.

Good idea. So by having that, are you saying we can eliminate the need to have static SMBIOS data?

[blackosx]

On my MPB, I see hex values related to 1440x900 0x05A0 "x" 0x0384 byte flipped starting at offset 0x22:

IOReg_display_saved_config.tiff

This is under display@0.

But different hardware I think is going to show up in different places (PEGP, GFX, with or w/o PCI bridge etc) also depending on DSDT. Perhaps "display@0" is generic enough to be found in all machines.

I think I've got an answer. Can you and maybe others here please test by running this script to see if the reported screen res is what you're using? Thanks.

GetScreenRes.command.zip

[DB1]

I think I've got an answer. Can you and maybe others here please test by running this script to see if the reported screen res is what you're using? Thanks.

GetScreenRes.command.zip

 

Hi blackosx yes works for me 1024x600

[blackosx]

Thanks for checking the resolution script DHP and DB1. I have gone ahead and added that code to the Revstart script.

 

And also, DHP, to re-cap on our earlier posts. I see your point of not asking the user to boot from Chameleon just to get some data for using with Revolution, and I have just been using my system with the default system-id you mentioned earlier to see if i could spot any issues. Well apart from the issue with the date & time clock and monitor calibration profile I posted earlier, I saw no issues will my apps, though I'm not using time-machine here.

 

Therefore I have also changed the RevStart script to insert the default system-id in to settings.h and it will be up to the user to change it if they wish. I have also added a check to see if the CPU is 64-bit capable for the #define EFI_64_BIT directive.

 

These are all small changes, but the script is slowly becoming more complete.

 

 

 

Not really. What I was proposing is the addition of overrides (in settings.h). This way we can select a target product type (model info) or correct RAM info (think DB1 here) and use that (instead of the defaults) to create a new and improved SMBIOS data structure.

I'll happily test it out if you can work it.

[humph]

I think I've got an answer. Can you and maybe others here please test by running this script to see if the reported screen res is what you're using? Thanks.

GetScreenRes.command.zip

Also woks on my MBP 2006. Not with hack today, but will test soon...

[GrootWitBaas]

I think I've got an answer. Can you and maybe others here please test by running this script to see if the reported screen res is what you're using? Thanks.

Just a late confirmation it works for me also

 

Width=1680

Height=1050

 

Will get to more testing soon. I saw some post back some one here knows ASM .....I need some one to help me a small bit in doing a small ASM program.

[VCH888]

EDIT: Hmm. Dont know how to make the picture show up as one of those little thumbnails. Sorry.

 

Upload a picture as .jpg.

[blackosx]

Thanks GrootWitBaas and humph for your ScreenRes tests. No more testing needed now.

 

Hi tmongkol - Good to see you here

 

try this:

/usr/sbin/system_profiler SPDisplaysDataType | grep Resolution

Thanks STLVNUB - I did wonder how to grep system profile. Now I know and that works just fine.

Also, the edit settings option you added to RevStart is very handy. Good thinking.

 

@DHP - How can I test for the need of setting #define MUST_ENABLE_A20 to 1. I've read this about it but I'm still none the wiser if I can run a check from OS X to find out if the user can boot with or without it set.

[dgsga]

Hey DHP, you're up early, you don't want to lose your beauty sleep! I use:

 

#define STATIC_CPU_QPISpeed 6532000000ULL

 

I got the original value of 6532Mt/s from the my bios in the advanced tweaker section, then converted it to T/s whatever that is. It does not appear to make any difference as long as correct QPI is set in smbios (I get static smbios from Slice's or Kabyl's Chameleon branch). My understanding is that QPI is the replacement for FSB in nehalem based processors, so if the MacBookPro6,1 uses the mobile variant of same CPU then it would be appropriate for it to display QPI. If I change my Mac Model to MacPro3,1(based on pre-nehalem Xeon) from 5,1 then QPI no longer appears in About This Mac, and is replaced by the bus speed. Hope this helps!

 

 

 

 

I think I've got an answer. Can you and maybe others here please test by running this script to see if the reported screen res is what you're using? Thanks.

GetScreenRes.command.zip

 

Works fine here too!

[GrootWitBaas]

And what you like done???

Not a lot, just put some values to some registers

It is about one of the goals and from what I have read it is possible ...to make the boot sound. I have the sound, I am able to make a beep right when boot is loaded, but I want to make theis beep not by using printf"/a" but by using asm instructions calling the "System Timer 2" at 42h and 43h (see more detail here)

 

The only way I see this possible is by using ASM and this needs to be done in one of 3 places, start of boot0, boot1 or boot. I was thinking it will be nice if we can do this using c++ build in am calls, but I failed so far even just to get a beep, never-mind a tune, so I decide to call on the experts about this, and I believe DHP will love it if we give her a sniped she can add to boot.c to make the PC speaker go chime.aiff or chime.wav

 

I know this is possible, I just were not able to do it yet, as I don't have the knowledge of ASM because I did not listen to my dear Dad when I was younger, he said I should study more.

 

Groot