How to boost the OS X boot process...

humph · January 28, 2011

What do you mean with nothing? You can't even boot with -x anymore? ..?

Same here KP if booting with -x:

SAFE BOOT DETECTED etc

Not loading kext _kernel_

Panic ACPI......Platform expert..

or words like that.

Revo is supposed to load stuff from /Extra on safe boot?

(NB: This was using /Extra/ACPI/DSDT.aml, not embedded DSDT). EDIT. Mioght have been with embedded DSDT. Not sure now which version boot. Got to dash so will check later.

Works fine -v or normal. EDIT: This last parts true, though!

blackosx · January 28, 2011

Here's what MC used back in time:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<!-- NVIDIA 9600GT / 512MB -->
<key>PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)</key>
<dict>
	<key>@0,compatible</key>
	<string>NVDA,NVMac</string>
	<key>@0,device_type</key>
	<string>display</string>
	<key>@0,name</key>
	<string>NVDA,Display-A</string>
	<key>@1,compatible</key>
	<string>NVDA,NVMac</string>
	<key>@1,device_type</key>
	<string>display</string>
	<key>@1,name</key>
	<string>NVDA,Display-B</string>
	<key>NVCAP</key>
	<data>
	BAAAAAAAAwAMAAAAAAAABwAAAAA=
	</data>
	<key>NVPM</key>
	<data>
	AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
	</data>
	<key>VRAM,totalsize</key>
	<string>0x20000000</string>
	<key>device_type</key>
	<string>NVDA,Parent</string>
	<key>model</key>
	<string>nVidia GeForce 9600 GT</string>
	<key>name</key>
	<string>display</string>
	<key>rom-revision</key>
	<string>nVidia GeForce 9600 GT OpenGL Engine</string>
</dict>
<!-- SATA properties -->
<key>PciRoot(0x0)/Pci(0x1F,0x2)</key>
<dict>
	<key>device-id</key>
	<integer>0x80862681</integer>
</dict>
<!-- HDEF 883 properties -->
<key>PciRoot(0x0)/Pci(0x1B,0x0)</key>
<dict>
	<key>layout-id</key>
	<data>A3M=</data>
	<key>PinConfigurations</key>
	<data>AA==</data>
</dict>
<!-- LAN properties -->
<key>PciRoot(0x0)/Pci(0x1c,0x5)/Pci(0x0,0x0)</key>
<dict>
	<key>built-in</key>
	<string>0x01</string>
</dict>
<!-- UHC4 -->
<key>PciRoot(0x0)/Pci(0x1a,0x0)</key>
<dict>
	<key>device-id</key>
	<string>0x3a37</string>
</dict>
<!-- UHC5 -->
<key>PciRoot(0x0)/Pci(0x1a,0x1)</key>
<dict>
	<key>device-id</key>
	<string>0x3a38</string>
</dict>
<!-- UHC6 -->
<key>PciRoot(0x0)/Pci(0x1a,0x2)</key>
<dict>
	<key>device-id</key>
	<string>0x3a39</string>
</dict>
<!-- UHCI -->
<key>PciRoot(0x0)/Pci(0x1a,0x7)</key>
<dict>
	<key>device-id</key>
	<string>0x3a3c</string>
</dict>
<!-- UHC1 -->
<key>PciRoot(0x0)/Pci(0x1d,0x0)</key>
<dict>
	<key>device-id</key>
	<string>0x3a34</string>
</dict>
<!-- UHC2 -->
<key>PciRoot(0x0)/Pci(0x1d,0x1)</key>
<dict>
	<key>device-id</key>
	<string>0x3a35</string>
</dict>
<!-- UHC3 -->
<key>PciRoot(0x0)/Pci(0x1d,0x2)</key>
<dict>
	<key>device-id</key>
	<string>0x3a36</string>
</dict>
<!-- EHCI -->
<key>PciRoot(0x0)/Pci(0x1d,0x7)</key>
<dict>
	<key>device-id</key>
	<string>0x3a3a</string>
</dict>
</dict>
</plist>

Did you make something similar like this and then converted it with:

gfxutil -s -n -i efi.xml -o bin ./efi.xml ./efi.bin

or did you use the new data extractor?

Yup. And looking at the data in device-properties I would say that we are missing something.Not a 100% match. Data in Chameleon is fine he said. Just not when you (have to) do things manually.

Just thinking about your video issue, how does the final hex look compared to when following aquamac's instructions?

scrax · January 29, 2011

What do you mean with nothing? You can't even boot with -x anymore?

I mean nothing new, it doesn't matter if I start with the code full of zero, the cutted one or the manually adapted one I still can boot only if -x is in L/P/SC/c.a.B.p if I try with only -v I get stuck right after the kernel start.

And being able to boot with -x has to be mkext/kext related so what 3th party kexts do you use?

Only fakeSMC.kext (and a binpatched appleHDA)

I've removed Evoreboot because I would like to see if Revolution can fix my restart issue (chameleo cant't because the restart fix added by MC is for intel only, not nvidia chipset)

If I startwith chameleon I have no problem in using mkext (but i can also use -f to avoid it and load the kext one by one).

About options, here they are:

acpi_patch.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

efi.c

#define APPLE_STYLE 1

#define DEBUG 0

smbios_patcher.c

#define DYNAMIC_SMBIOS_DATA_GATHERING 0

boot.c

#define PRE_LINKED_KERNEL_SUPPORT 0

#define DEBUG 0

GrootWitBaas · January 29, 2011

So time for the noob to jump on the band wagon.

I have read the complete thread from start to finish. I have on my desktop a folder "Kernel" and "Revo", in Revo I have rev616 to 636-5 and some tools and other folders.

I am not good at command line things, but guess with a small bit of guidance I will be able to become part of this and can try to help.

I would like to test on a seperate drive for now (will backup my ssd to a normal Sata drive and use that as my normal every day system, and plan to run revo straight from the SSD drive.

Now as I said I need some pointers and would greatly appreciate any help. Remember I run on a Cartri v.8 bios and are currently using the final boot-loader BlackOSX made for the cartri bios. Boot time from no power till browsing right now is 47.3 seconds (again just for future ref)

PS Remember I am a noob so you might have to feed it with a spoon the 1st 3 times ....

blackosx · January 29, 2011

Hi Groot

As you've discovered there is no definitive step by step guide yet, though all the details are in this thread if you follow it, but here's a couple of pointers to get you started.

1) You are going to need the Apple developer tools installed.

2) Boot in to your system using the latest version of Chameleon RC5 using GraphicsEnabler.

3) download Revolution_634_EFI_step_5.zip from this post

4) download the attached Rev_Start_0.1.4

(Changes from Rev_Start_v0.1.3 to v0.1.4 are: I have combined the two previous scripts in to now just one and renamed it RevStart. It will now automatically add the systemID used by Chameleon for generating your hardware UUID to your private_data.h. It also includes the latest smbios2struct binary tool.). .

5) Create a folder named 'project' in your home folder.

6) Add the Revolution_634_EFI_step_5.zip to your ~/project folder.

7) Add the Rev_Start_0.1.4.zip to your ~/project folder.

8) Unzip both zip files.

9) in Terminal, type sudo -s then press return

10) type your password then press return

11) type cd ~/project/Rev_Start_v0.1.4 then press return

12) type ./RevStart.sh then press return

Note: As you're using a modified bios then you won't necessarily need to add your DSDT.aml at this point (for ref, I'm using a modified cartri bios and I still use a separate dsdt.aml), but users of a normal bios might want to though this is not essential at this point as it can be loaded from /Extra/ACPI on the boot drive.

13) type cp ~/project/Rev_Start_v0.1.4/Output/private_data.h ~/project then press return

14) type cd ~/project/Revolution-634-new then press return

15) type make then press return

That'll get you to the point of having a compiled boot file which in theory you could use, but it'll fail at the moment and won't successfully boot your machine. Changes are going to be needed to some of the directives in the source code to customise Revolution for your system. Most of them are in /i386/project/libsaio/acpi_patcher.c but there are more dotted around. You will also need to setup your boot drive with a set of files/folders in the required manner with a copy of the mach_kernel at the root, along with kexts, and to com.apple.Boot.plist etc.. I'll talk about this step another time, although for speed this was discussed previously somewhere in the previous posts here.

Also, the private_data.h file doesn't yet contain the static ACPI base address, but that's not necessary just yet as the default is set to dynamic.

Hopefully this will get you started and up to a point where we can continue.... But I'm going be out for a lot of today so I'll check in when I can. In the mean time, if anybody else here spots any problems with the above steps then please feel free to point it out.

blackosx · January 29, 2011

Hi STLVNUB

Thanks

And no problems. This is an open project and I am no specialist at creating scripts so any help is appreciated.

I really have to go out now so I'll look at it a bit later.

Regards

blackosx

GrootWitBaas · January 29, 2011

Hi BlackOSX,

Ok 1st time revo compiled for me without a error. Guess it must have been some magic in the steps you gave BlackOSX.

Now next step ....mach_kernel .... I believe this is the folder called kernal I have made from the instructions way back in

Post #111

So I will guess next I will need a key drive for testing (yes I have some of those, will a 2Gb one do) and some pointers how to get this Kernel up to date (should I just follow from scratch those instructions) or is it fine like it is. Next is the structure and files need for the keydrive, and then I should be set.

Edit: have just followed all instructions from post #111 again (so this should be ok)

Your steps made it so easy for me thanks again. one other question, when a update/diff is posted, I just replace this files in my project folder and run make again ?

O and to all here, wonderful job

GrootWitBaas · January 29, 2011

Hope you enjoyed the trip to Germany.

and I'll explain the use of a bad word in My Native Language " Ek is nog 'n dom Kop, maar leer vinnig" and I am sure you will most probably understand it 100% with no need for Google translate

Yes this time I actually have time to commit to this more than before, so much that I was able to read ALL the posts from start to finish, and are now doing it for the 2, ermmm 3rd time to try and understand it all. :wacko:

blackosx · January 29, 2011

Hi Groot

I'm glad you got to the point of building Revolution successfully, but we have to remember here that the steps I showed before were just to get you to the point of setting up your system ready for the real work.

I guess what we have to remember here is Revolution is young and in continuous development, as such, dutchhockeypro could change many things from now. So at this point I don't think it's right to try to pin down any exact procedures to get to a finished point as they'll end up changing too.

The real fun in this topic, at least for me and I guess the others here, is the chance to understand and move with the development process that dutchhockeypro is showing. Some of the code changes are experimental and not guaranteed to work for everyone, so I guess the more users trying the changes will give greater feedback to what works and what doesn't.

So before we carry on with the tutorial from earlier, we have to think along the lines of what Revolution is.. in that it's designed to be made specifically for your system. So for that to happen you have to supply and add some of your system details in to the source code before compilation.

STLVNUB kindly made some changes to the RevStart script that I have been working on, but those changes, at the moment, have gone one step too far in as much as including the make instruction for compiling, probably as I showed that in my earlier steps. I say this because we're not really ready to compile yet as we need to look at what some of the source code directives are, what they do and which ones need changing to suit your individual setup. You can see a list of them in scrax's post #664 above.

For instance, in the source code from Revolution_634_EFI_step_5, /i386/libsaio/acpi_patcher has the directive to enable support for ACPI v1.0. This is by default turned off as dutchhockeypro's system uses, I think, ACPI v3.0. I have to change this directive to 1 before I compile otherwise the compiled boot file won't contain the correct code for my system. So you now need to set this directive for your system depending on what version of ACPI your mobo uses.

Again, these details have been discussed previously in this top so rather than me type more here, see if you can figure some of the directives out by looking back at older posts.

Good luck with this and if you have any questions don't hesitate to ask.. I have and will continue to do as believe me, I know very little here too :thumbsup_anim:

blackosx · January 29, 2011

Just went 2 steps to far, now it copies boot to my USB as well.
AFAIK compiling is the ONLY way to test it OR is it??

Lol.. yes, but I would recommend turning on some of the debugging directives first then at least the booter will show some clue as to what it's doing then users have something to work with if it fails.

Though don't get me wrong. I'm all for a more automated approach. I welcome your additions and the RevStart script can develop in time, but I just think it's important to highlight to Groot and to other starters here that some things can and should be done before trying to boot.

Good evening folks. Went to Germany today with some friends. Was a cold but satisfying day. Should do this more often.

Hi DHP - welcome back from your travels :angel:

He used one file (EFI.xml) and two different versions of gfxutil (0.71b and 0.75b) and now I have to look at the differences. To me they should all be the same, but let's found it. About to attach a couple of files now... Ok done.

Remember the first time I looked at this data blob with device-properties... Brrr. Scary stuff. Now have a look at EFI-1061.txt because that will tell you, and everyone else here who is interested, what it is. Still a few gaps to fill, but this is in a nut shell what the bytes are used for. And Device Paths are here to stay...

I'll have a look, but I'm gonna be out for a few more hours shortly so I'll check back in later.

GrootWitBaas · January 29, 2011

Except maybe for the gun on the dashboard (to stop carjackers) and a 20 feet high fence (hi voltage electricity) around the house.

Now you know why I have moved away.

Hi Groot

I'm glad you got to the point of building Revolution successfully, but we have to remember here that the steps I showed before were just to get you to the point of setting up your system ready for the real work.

....

Again, these details have been discussed previously in this top so rather than me type more here, see if you can figure some of the directives out by looking back at older posts.

...

yes I have read some post and it is kind off overflow. One thing I would like to know (have more concrete list maybe) is the structure/setup files needed on the "boot" drive be it a usb or internal, just the bare basics needed.

I think I have the mach_kernel compiled correctly for my X86_64 but are not sure what is needed on the boot drive.

A small sample list of for example your boot drive will help me I guess, Then I know by reading and reading and trying if I have the correct structure eventually I should be able to boot.

blackosx · January 29, 2011

One thing I would like to know (have more concrete list maybe) is the structure/setup files needed on the "boot" drive be it a usb or internal, just the bare basics needed.

Hi Groot :thumbsup_anim:

That's something else I was going to post about later but for now I don't have time. But if you look at the attachment in this post you will see a image file named 'USB stick folder structre in Finder' which shows you what i did, along with another file or two to show the ownership/permissions I set for each.

Gotta dash.. bye

DB1 · January 29, 2011

I "Could" incorporate into RevStart.sh RevStart.command These Features.

1. Ask for USB/HD

2. Ask for Source Drive for necessary files.

3. Format USB/HD , enable permissions.

4. Copy Source Drive files to USB/HD

5. Do Blackosx magic

6. Compile boot

7. Make USB/HD BOOTABLE

Donation ware for this feature...

8. Pick the "WINNING" Lotto numbers for the rest of eternity.

I'm saying "Could" so I "DON'T" waste my time.

At my age TIME IS PRECIOUS!!!

Sound's like a great idea hatching, don't forget those who like to use EFI partition. And if you got one for the lotto numbers (and it creates winners) I'm up for that!

blackosx · January 29, 2011

I "Could" incorporate into RevStart.sh RevStart.command These Features.

Brilliant..yes please STLVNUB. I'll look forward to that.

And point 8 too.. Lol

GrootWitBaas · January 29, 2011

I "Could" incorporate into RevStart.sh RevStart.command These Features.
....

I'm saying "Could" so I "DON'T" waste my time.

At my age TIME IS PRECIOUS!!!

Please Do.

Think I have the basics setup ....just need to set all ownerships then it should work ...... but I'll also wait for a more detailed guide from BlackOSX or the above mentioned Features ....or both

blackosx · January 29, 2011

Now have a look at EFI-1061.txt because that will tell you, and everyone else here who is interested, what it is. Still a few gaps to fill, but this is in a nut shell what the bytes are used for. And Device Paths are here to stay...

How was EFI-1061 generated and from what?

blackosx · January 29, 2011

but I'll also wait for a more detailed guide from BlackOSX...

Hi Groot

I'm not sure if this will work for you but give this a try..

Format a USB flash drive as HFS Extended with a GPT. Then in Finder, 'get info' on the mounted disk and make sure 'Ignore ownership on this volume' is not ticked. Then create the folder structure as I showed in the screenshot that I mentioned in the previous post. You can use the finder for that.

You will also need to copy the mach_kernel file from the root of your OS X volume to the root of your USB flash drive. Do that in Terminal.

Next set ownership/permissions of your folders/files on your USB flash drive to be the same as your OS X volume. Then edit the Revolution source files as follows:

Load up the following files in TextEdit and make the changes:

/i386/libsaio/acpi_patcher.c

#define ACPI_10_SUPPORT to 1

#define DROP_SSDT_TABLES to 1

#define FAKE_APPLE_DATA to 1

#define DEBUG to 1

/i386/libsaio/cpu.c

#define DEBUG_CPU to 1

#define DYNAMIC_CPU_DATA_GATHERING to 1

Next run the make command as I showed in my post this morning. Which will now give you a boot file to copy to your USB flash drive.

The final thing to do will be to set the contents of your com.apple.Boot.plist to match this, except you will need to change the uuid value to that of your OS X volume. You can get that from Disk Utility by selecting your OS X volume and clicking the 'Info' button.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
<string>arch=i386 rd=uuid boot-uuid=00000000-0000-0000-0000-000000000000</string>
<key>TargetOSVersion</key>
<string>10.6.6</string>
</dict>
</plist>

Update:

I forgot to say you need to write Chameleon's stage0 and stage1 files to the USB flash drive too, then check the partition is marked active. Sorry about forgetting this but I almost take this for granted these days.

continued...

Then try booting from your USB.

Now I'm not saying that this will boot your system, but it's something to get you trying.

And as before, if anybody see's any problem with these instructions then please point it out.

EFI-1061.txt itself is the result of hard manual labor after a lot of reading at this place.

Okay.. I asked just because I didn't recognise the format as being from any particular dump and now I know why.

p.s. Everything I have in this copy of EFI.xml works. Adding a graphics section also works, but NVKernel isn't loaded (due to a failing match I presume) and therefore we're not getting the usual transparent menu bar. That's the only issue I have this far.

So this is like you said before that the strings are converted to hex which prevents NVDAResman from matching it? I might try to make my own manual EFI to try it out here to gain a better understanding.

humph · January 30, 2011

Hi all. Late night out, but just had to check in and see the latest!

Good evening folks. Went to Germany today with some friends. Was a cold but satisfying day. Should do this more often.

Indeed! Nice place, even up north! And cold down here south today also, but at least it's close to the slopes, so hoping for more snow!

Right. That's AppleACPIPlatform.kext refusing to cooperate. Toggle the STATIC_ACPI_BASE_ADDRESS directive in acpi_patcher.c to 0 and try again. Want to make sure the address is fine (might move). And make sure it includes either a static DSDT or that it loads one from /Extra/ACPI/

Am using Dynamic base address and loading a good DSDT already....

Yes. But please keep in mind that I have yet to change i386/boot2/driver.c to make it do what we want – loads all kexts but the once that are tagged for "Safe Boot".

I guess that might explain a lot. The other thing I realized is that my -x test was by pressing x on keyboard at boot, rather than an -x flag in c.a.B.p (which was the way scrax had success). So perhaps its related somehow to that difference...?

blackosx · January 30, 2011

Problem fixed by removing:
He now only has to fix the name, and check the VRAM size – we only had a GT8800 and GT9600 card available for testing.

That's good news that you've sorted it, well done.

I attempted last night to try it here but failed miserably. Not too sure what I was doing but I made this based upon the code you posted previously. I added my video for my 8800GT by using the string from aquamac's forum and double checked my device-id's against the ones in your post

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<!-- Video properties -->
<key>PciRoot(0x1)/Pci(0x1,0x0)/Pci(0x0,0x0)</key>
<dict>
	<key>@0,compatible</key>
	<string>NVDA,NVMac</string>
	<key>@0,device_type</key>
	<string>display</string>
	<key>@0,name</key>
	<string>NVDA,Display-A</string>
	<key>@1,compatible</key>
	<string>NVDA,NVMac</string>
	<key>@1,device_type</key>
	<string>display</string>
	<key>@1,name</key>
	<string>NVDA,Display-B</string>
	<key>@2,#adress-cells</key>
	<string>0x01000000</string>
	<key>@2,#size-cells</key>
	<string>0x00000000</string>
	<key>@2,compatible</key>
	<string>NVDA,sensor-parent</string>
	<key>@2,device_type</key>
	<string>NVDA,gpu-diode</string>
	<key>@2,hwctrl-params-version</key>
	<string>0x02000000</string>
	<key>@2,hwsensor-params-version</key>
	<string>0x02000000</string>
	<key>@2,name</key>
	<string>sensor-parent</string>
	<key>@2,reg</key>
	<string>0x02000000</string>
	<key>NVCAP</key>
	<data>BAAAAAAAAwAMAAAAAAAABwAAAAA=</data>
	<key>NVPM</key>
	<data>AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==</data>
	<key>VRAM,totalsize</key>
	<data>AAAAIA==</data>
	<key>device_type</key>
	<string>NVDA,GeForce</string>
	<key>model</key>
	<string>NVIDIA GeForce 8800 GT DDL</string>
	<key>name</key>
	<string>NVDA,Parent</string>
	<key>rom-revision</key>
	<string>3172a</string>
</dict>
<!-- Ethernet properties -->
<key>PciRoot(0x1)/Pci(0x1c,0x5)/Pci(0x0,0x0)</key>
<dict>
	<key>built-in</key>
	<string>0x01</string>
</dict>
<!-- HDEF properties -->
<key>PciRoot(0x1)/Pci(0x1b,0x0)</key>
<dict>
	<key>PinConfigurations</key>
	<string></string>
	<key>built-in</key>
	<string>0x00</string>
	<key>layout-id</key>
	<string>0x0000000c</string>
	<key>revision-id</key>
	<string>0x00000001</string>
	<key>subsystem-id</key>
	<string>0x0000a002</string>
	<key>subsystem-vendor-id</key>
	<string>0x00001458</string>
	<key>vendor-id</key>
	<string>0x00008086</string>
</dict>
<!-- SATA properties -->
<key>PciRoot(0x0)/Pci(0x1F,0x2)</key>
<dict>
	<key>device-id</key>
	<integer>0x80863a22</integer>
</dict>
<!-- UHC4 -->
<key>PciRoot(0x0)/Pci(0x1a,0x0)</key>
<dict>
	<key>device-id</key>
	<string>0x3a37</string>
</dict>
<!-- UHC5 -->
<key>PciRoot(0x0)/Pci(0x1a,0x1)</key>
<dict>
	<key>device-id</key>
	<string>0x3a38</string>
</dict>
<!-- UHC6 -->
<key>PciRoot(0x0)/Pci(0x1a,0x2)</key>
<dict>
	<key>device-id</key>
	<string>0x3a39</string>
</dict>
<!-- UHCI -->
<key>PciRoot(0x0)/Pci(0x1a,0x7)</key>
<dict>
	<key>device-id</key>
	<string>0x3a3c</string>
</dict>
<!-- UHC1 -->
<key>PciRoot(0x0)/Pci(0x1d,0x0)</key>
<dict>
	<key>device-id</key>
	<string>0x3a34</string>
</dict>
<!-- UHC2 -->
<key>PciRoot(0x0)/Pci(0x1d,0x1)</key>
<dict>
	<key>device-id</key>
	<string>0x3a35</string>
</dict>
<!-- UHC3 -->
<key>PciRoot(0x0)/Pci(0x1d,0x2)</key>
<dict>
	<key>device-id</key>
	<string>0x3a36</string>
</dict>
<!-- EHCI -->
<key>PciRoot(0x0)/Pci(0x1d,0x7)</key>
<dict>
	<key>device-id</key>
	<string>0x3a3a</string>
</dict>
<!-- FRWR properties -->
<key>PciRoot(0x0)/Pci(0x1E,0x0)/Pci(0x3,0x0)</key>
<dict>
	<key>fw-hub</key>
	<data>AAAAAA==</data>
</dict>

</dict>
</plist>

I then saved the file as EFI.xml and ran ./gfxutil -i xml -o bin ./EFI.xml ./EFI.bin I.bin to give me my EFI.bin. Opening it up in a hex editor gives me my device properties which I thought I could then inject with Revolution. But I failed at converting it to a struct.. didn't know how.. and was tired so i left it.

Also, the device-properties for my 8800GT generated from EFI studio had less 'fields' than the one from aquamac's forum? and running the above command in blue gave me the following error.

./gfxutil: invalid property list xml inputfile './EFI.xml'!

Though I guess this doesn't matter now as you've solved the issue.

GrootWitBaas · January 30, 2011

Update:
I forgot to say you need to write Chameleon's stage0 and stage1 files to the USB flash drive too, then check the partition is marked active. Sorry about forgetting this but I almost take this for granted these days.

continued...

Then try booting from your USB.

Now I'm not saying that this will boot your system, but it's something to get you trying.

Ok I cheated, because my biggest problem is not setting all the things in Revo, but doing the basic things in command line like making the drive bookable (yes I know I SHOULD know this basic things ...). My cheat was basicly make a chamelion boot drive, then remove everything visible in finder and then make the structure as below. Also setting the permission for everything(visible) to root:wheel and to mach_kernal (not visible in finder). So with this I was able to boot ....well half way ....1st a page with loads of info on my CPU, all there seemed fine, then the next screen .... see for your self ...guess I have loads to do/try and read more ......

-Groot

GrootWitBaas · January 30, 2011

Let's fix this:

Ok Let see .... compile error ...

boot.c:202: warning: passing argument 4 of ‘mallocInit’ from incompatible pointer type
make[2]: *** [boot.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2

So lets see if I understood the move and edit correctly, Boot.c looks like this now ...

.....
#include "boot.h"
#include "bootstruct.h"
#include "sl.h"
#define DEBUG							1	// Default to 0 by default. Use 1 when things don't seem to work for you.

#if DEBUG
#define _BOOT_DEBUG_DUMP(x...)	printf(x)
#define _BOOT_DEBUG_DUMP_SLEEP(x)	printf("Sleeping for %d seconds...\n", x); sleep(x);
#define SAFE_MALLOC					1
#else
#define _BOOT_DEBUG_DUMP(x...)
#define _BOOT_DEBUG_DUMP_SLEEP(x)
#endif

#include "libsa.h"

// Global private data storage file.

....

blackosx · January 30, 2011

What I want, need really, is to keep on pushing and make progress on the TODO list of post #134 otherwise I might burn out one day.

You're absolutely right with the need to stay focused on your objectives otherwise there will be no progress.

Grrr. I forgot to add the name of a nifty little command line utility (to show partition type GUID's not UUID's)
....

Yup. Here it is: /System/Library/Filesystems/hfs.fs/hfs.util -k disk1s2 (example).

Nice shortcut. Thanks for sharing

GrootWitBaas · January 30, 2011

Step 6 done.

Placment of this make make run long time if on 1st uncommented line but with error

boot.c: In function ‘initializeRuntime’:
boot.c:201: warning: passing argument 4 of ‘mallocInit’ from incompatible pointer type
make[2]: *** [boot.o] Error 1

If placed below #define ZDEBUG 0 then make fails straight away with

zalloc.c:92: error: conflicting types for ‘mallocInit’
libsa.h:103: error: previous declaration of ‘mallocInit’ was here
make[2]: *** [zalloc.o] Error 1

GrootWitBaas · January 30, 2011

Told You I'll need spoon feeding .... hopefully in a week or so I can follow on my own sort of

Compile fine now

Ok Now add "File cache.c Line 94" to the error screen output

GrootWitBaas · January 30, 2011

grootwitbaas:~ grootwitbaas$ diskutil list
/dev/disk0
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:	  GUID_partition_scheme						*30.9 GB	disk0
  1:						EFI						 209.7 MB   disk0s1
  2:				  Apple_HFS OSX SSD				 30.5 GB	disk0s2
/dev/disk1
  #:					   TYPE NAME					SIZE	   IDENTIFIER
  0:	  GUID_partition_scheme						*131.1 MB   disk1
  1:				  Apple_HFS RevoBoot				131.0 MB   disk1s1

Trying disk.c now. --> No Change

O and I am back on page 8 of this thread following to see if all was done correctly ...

How to boost the OS X boot process...

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites