How to boost the OS X boot process...

[DB1]

@DB1 - So are you using the CPIUID Symbols/Override from Meklort? Thought that gave KP unless MBP 5.1. If is working for you with MB 4,1 perhaps I should give it a try and see if other stuff somehow better. Although I dont seem to have any issues with MBP6,1.

I also get the display not usable message. Can't recall whether have it with Cham. Off to test.

 

With Chameleon & Meklort CPUIDSymbols & Overide and no smbios.plist I boot and model identifier is macbook 4.1. Have patches for GMA950,edid, resume, atom id. Also have native speedstep and hyperthreading (see my radically optimised dsdt at Insanelywind).

 

Have not been able to boot Revolution with native kernel (yet)

[humph]

With Chameleon & Meklort CPUIDSymbols & Overide and no smbios.plist I boot and model identifier is macbook 4.1. Have patches for GMA950,edid, resume, atom id. Also have native speedstep and hyperthreading (see my radically optimised dsdt at Insanelywind).

Hm, well whilst I can boot w/o KP using MB4,1 from Revo; I do not get SS, just stuck at 800MHz. So perhaps is due to your radical DSDT, or just some convoluted machine differences.

 

Ref display. After spinner, I see grey screen, light blue, dark blue (calibration), background and abt same time login window. About 4-6s between loss of spinner and login. How does that compare to yours now and previously?

[blackosx]

I flashed this into the bios as a replacement for the LAN boot option ROM but needless to say it doesn't work as I don't know the right code to make the jump.

Hi dgsga

 

Despite the fact that UEFI is the future, I'm still excited by the idea of having the small revolution code in bios. So am I right in saying is all you need is the jump instruction to kickstart the code? Well I don't have that for you, but I saw this old post at voodooproject's forum referring to what memory address the boot code needs to be loaded at. Then looking at /i386/libsa/memory.h the above mentioned numbers match the directives set for #define BOOT2_SEG and #define BOOT2_OFS.

 

This might be old news to you and have nothing to do with what you're looking for, but I was just doing a little bit of reading and thought I'd point it out.

[dgsga]

Despite the fact that UEFI is the future, I'm still excited by the idea of having the small revolution code in bios. So am I right in saying is all you need is the jump instruction to kickstart the code? Well I don't have that for you, but I saw this old post at voodooproject's forum referring to what memory address the boot code needs to be loaded at. Then looking at /i386/libsa/memory.h the above mentioned numbers match the directives set for #define BOOT2_SEG and #define BOOT2_OFS.

 

This might be old news to you and have nothing to do with what you're looking for, but I was just doing a little bit of reading and thought I'd point it out.

 

Hi blackosx

 

Thanks for feeding back on this, I did already realise the memory address that boot2 needed to be loaded at, but I just can't fathom assembler code yet. I have been reading a tutorial, and would like to have something for you before I become eligible for a bus pass.

[DB1]

Hm, well whilst I can boot w/o KP using MB4,1 from Revo; I do not get SS, just stuck at 800MHz. So perhaps is due to your radical DSDT, or just some convoluted machine differences.

 

Atom support was withdrawn from kernel at 10.6.2 hence the need in chameleon for a patch or meklort kexts however these did't seem to work with Revolution when I tried them but that might be when we were having trouble loading kexts before DHP sorted it out. As soon as the wife gets off the netbook I'll try the native kernel and the kexts on my EFI to see if I can get a boot up to OS.

 

 

Ref display. After spinner, I see grey screen, light blue, dark blue (calibration), background and abt same time login window. About 4-6s between loss of spinner and login. How does that compare to yours now and previously?

 

With Chameleon a flash of grey twice over a couple of seconds then log in (No display error though in system log) Just rechecked and I do have the display error!, with Revolution a good 30 seconds from grey to log in and the error in the log. I'm pretty certain it's edid because I patch for that in Chameleon. Edit have since eliminated this possibility

 

p.s. I'm open for debate (of course) so if you have other ideas about this then clue me in. Thanks!

I'm good with where your heading and being able to get to Lion and later maybe UEFI sounds pretty good to me.

 

Just need to sort my display, and have worked the tool you posted DHP. Just need to know now how I use the data to make a plist only kext.

 

???

 

Mini-Mac-Air:~ db1$ /tmp/dumpEDID ; exit;

/* Using device: IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/GFX0@2/AppleIntelFramebuffer */
/* Bus 0: */
/* Read result 0x0, 0x80 bytes */
/*    0    1    2    3    4    5    6    7    8    9    A    B    C    D    E    F */
   0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0x22,0x64,0xe9,0x03,0x9b,0x00,0x00,0x00,
   0x2c,0x11,0x01,0x03,0x80,0x16,0x0d,0x78,0x0a,0x86,0x26,0x94,0x57,0x51,0x90,0x27,
   0x21,0x4f,0x54,0x00,0x00,0x00,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
   0x01,0x01,0x01,0x01,0x01,0x01,0x94,0x11,0x00,0xb0,0x40,0x58,0x19,0x20,0x35,0x23,
   0x45,0x00,0xdc,0x81,0x00,0x00,0x00,0x19,0x16,0x14,0x00,0xd8,0x40,0x58,0x26,0x20,
   0x5d,0x23,0x15,0x04,0xdc,0x81,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xfe,0x00,0x00,
   0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xfe,
   0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x14,
sum: 0
EDID checksum:  -1
/* Checksums ok */

[humph]

DB1 has Intel SpeedStep nicely integrated in his DSDT.

Me not, so far. Loads from SSDT/BIOS. Or not-loads I guess in the case of MB4,1. Think I'll stick with MBP6,1 and live with any other strange stuff (like loading of AGPM that does not seem to have any adverse impact!).

 

...because then we need EFI modules for things like graphics cards.

Although if are as modules, then those who dont need stuff can just trash the module(s). So might still be possible to have a sort of streamlined booter?

 

Atom support was withdrawn from kernel at 10.6.2 hence the need in chameleon for a patch or meklort kexts however these did't seem to work with Revolution when I tried them but that might be when we were having trouble loading kexts before DHP sorted it out.

Pretty sure we need either patch kernel or patch booter, the kexts just enable speed step?

 

With Chameleon a flash of grey twice over a couple of seconds then log in (No display error though in system log), with Revolution a good 30 seconds from grey to log in and the error in the log. I'm pretty certain it's edid because I patch for that in Chameleon.

Hm, so definitely not nice. Just tried an EDID kext here and made no difference, still 6s. Then again, am running with an IOGraphicsFamily in /E/E already, and it's not even the right (latest) one, so that might not be helping! Better sort out my GMA kexts sooner or later!

EDIT: I should add, that I am using changed graphics mode setting in Revo and also as kernel flag. So auto-resolution or EDID stuff would not make any difference here anyway, I guess.

[DB1]

See attachment. I simply copied the EDID from your IOREG dump (Chameleon) and paste it in (using property editor pro).

 

Note: The checksums are ok, apparently, so that can't be it.

 

Oops. I forgot to remove the following property IODisplayConnectFlags so please remove it.

DHP thanks for this I was just re reading on the subject of Legacy plist only type kexts (cyclonfir) and flipped back and caught this so you gave me the short cut. Unfortunately not as I thought the problem!

 

Ok so here's the deal with Revolution, i boot from EFI and it's about 10 seconds from bios to throbber (great), then 15 seconds of throbber to blue screen, then 50 seconds to log in window. So the lag is after throbber and before log in window. I thought this related to the edid due to the display error in kernel log which is still there after LegacyEdid.kext addition.

 

So for comparison I plug in my other hdd with Chameleon EFI and its thus: from bios to throbber 25 seconds (so Revolution much quicker here), then 10 seconds of throbber to blue screen (Revolution slower here), then 10 seconds to login in window (Chameleon much quicker here).

 

So total for Revolution is 75 seconds, and total for Chameleon is 45 seconds. If I/we can understand what's causing the lag between blue screen after throbber to log in Revolution I'll be on a winner. What additional support am I getting from Chameleon in terms of devices or drivers????

 

Attached logs from Revolution:kernelLog.rtf.zip

SystemLog.rtf

 

Attached Chameleon logs:

ChameleonKernelLog.rtf.zipChameleonSystemLog.rtf.zip

 

I've bold some dodgy looking suspects! anyone any ideas. Yeah I know how to sort out the UUID 35 error.

 

Not tried native kernel again yet.

 

DB1 has Intel SpeedStep nicely integrated in his DSDT.

 

I learnt how to do this from obi1kenobi (MasterChief). May the force be with you!

 

 (like loading of AGPM that does not seem to have any adverse impact!).

 

Conversely it seems to serve no purpose for me! I have it with 6.1 and loose it with 4.1, interestingly with 6.1 I don't have hyperthreading but in 4.1 I do so 4.1 seems to be nearer the hardware build for the Wind/Advent than 6.1

 

DHP sorry to bloat the thread with what is probably Atom Legacy issues, I'll understand if you forge ahead and forget Atom. (kernel does not support so only going to get more difficult when they go to Lion)

[humph]

Ok so here's the deal, i boot from EFI and it's about 10 seconds from bios to throbber (great), then 15 seconds of throbber to blue screen, then 50 seconds to log in window.

I have similar time BIOS to throbber, but then around 50s throbber then a few sec of grey/blue screens to login.

Conversely, I see you get DMOS arriving very very early on, whereas I get it late on, then display unusable in log abt same time as display actually changes from throbber spinny thing.

So just wondering here overall time is similar, but boot "order" rather different. Were you getting 15-20s BIOS to log-in on Chameleon; guess you must have!

 

(I might PM you to find more abt your config....booting in 15-20sec amazing if that's what you get std for Atom!!).

 

 

Conversely it seems to serve no purpose for me! I have it with 6.1 and loose it with 4.1, interestingly with 6.1 I don't have hyperthreading but in 4.1 I do so 4.1 seems to be nearer the hardware build for the Wind/Advent than 6.1

Opposite here, HT only on MBP6,1. Whereas a MB2,1 more like this Lenovo! Ho hum.

[humph]

..With Chameleon you have two SSDT tables but with Revolution three SSDT tables.

I would never have thought in the past to check that sort of stuff. Is a pleasure learning from someone as advanced as you are, DHP! Good news is that with Revov5, am back to the two SSDTs for SATA and CPUPM. So that's not the issue in this instance I guess.

When Intel Speedstep isn't working for you, with certain model identifiers, then you can use the LegacyAGPM.kext..

Huh? Thought AGPM was only going to help with graphics card PM, not CPU speedstep? If not, then got much more to learn! Couldn't find any references to 10.6.6. AGPM. It'd be nice to be able to use a MacBook model where GMA950 used if AGPM is what makes that, as opposed to DSDT CPU patching.

Are you sure that the kext is loading? Did you check this? I would say add a simple dummy property..

Not sure, will recheck in due course.

I see that both of you have two different GPU device-id's being 27a6 and 27ae. Why is that? You have two GPU's?..

AFAIK, AE is internal panel on most netbooks, A6 is port for external display. Apple products use A2 not AE. I understand that (some - AndyV's etc) Chameleon patches up both AE & A6. Never tried with an ext display however to see if my basic DSDT GFX section covers both.

[blackosx]

p.s. Also check this post (halve way down about AAPL,display-alias and the next post fore AAPL,primary-display).

Wow.. I didn't know that topic existed. That looks like a wonderful post to highlight the progression that's been made there.... and a very interesting resource too.

[scrax]

Hi all,

with last code posted I can boot again! Thank's.

So far I've booted only with -x and a single disk.

 

If I boot without -x I get the same hang when kernel loads as before.

 

I'm loading from /Extra/ACPI the dsdt.aml I use with chameleon and a ssdt.aml made from the 4 ssdt table generated by chameleon

[humph]

DHP:

 

Wow.. I didn't know that topic existed. That looks like a wonderful post to highlight the progression that's been made there.... and a very interesting resource too.

 

Ditto from me.

And the other EFI inject stuff, and links. So many great things. Have to go out tis eve, but I foresee a late night when I get back.

 

But I have to admit, that I saw your post about PSS some time ago - didn't understand it then and still don't. So I "don't spot the error" other than numbers different!! Perhaps the wine we're about to have will help my thinking processes for when I get back.

[blackosx]

Then add the following data to private_data.h

#define PUT_YOUR_EFI_DEVICE_PROPERTIES_HERE \
.......
.......

And now you have static EFI device properties added. Eliminating the need for other patches (we're going to move everything from _DSM Methods to this blurb).

Hi dutchhockeypro

 

I see in my iMac's ioreg a huge data block in efi->device-properties, so is that what we'll be adding here?

In that case, where on my hack do I get the data to add in to 'PUT_YOUR_EFI_DEVICE_PROPERTIES_HERE' ?

 

I also notice I have some data in efi->device-properties in my ioreg when from booting with Chameleon. Though I don't know what it is? But I'm sure you can tell me.

 

Thanks for feeding back on this, I did already realise the memory address that boot2 needed to be loaded at, but I just can't fathom assembler code yet. I have been reading a tutorial...

No problem and like I said - I am interested in it.

Best of luck with the assembler. I tried learning it many years ago and gave up so I won't be trying again anytime soon.

... and would like to have something for you before I become eligible for a bus pass.

Lol.. yeah. You'd better had as when you get your bus pass you won't have time for assembler as you'll be off out everywhere with free travel (like my Dad)

[blackosx]

Yup. That's the one we want to use/fill. Thinking of writing a simple extraction tool for this – ala smbios2struct – but I only just returned back home so nothing is done yet i.e. you'll have to do the labor yourself (for now).

 

p.s. I haven't even used this myself (totally untested) so we might need to change/move things around, but I thought to let you gentlemen figure this out during todays practice games.

Just sussed, the data in efi->device-properties when booting from Chameleon is for my video. It's added when enabling Graphics Enabler. Therefore if I add the same data in private.h for Revolution then I can remove the video data from my DSDT.aml? and also use if for any other instance where I would add device strings?.. I'll try it now.

 

@DB1: Got a reply about this obi1kenob figure "Go use Google". Hilarious failure. Never seen a startrek movie. .

No, No... It's Star Wars!!! (Blasphemer) he he

[DB1]

Are you sure that the kext is loading? Did you check this? I would say add a simple dummy property, and when that shows up...

Probably not as the bundle version on that was was 2.1 where as in 10.6.6 it's 2.2. However with this changed and confirming it loading no change to booting.

That is strange. I didn't know MC used that nick

 

LOL, LOL, I thought everyone seen star wars! It was meant as a complement.

 

No problem. I'm intrigued by the matter. And of course. The easiest way would have been to walk away from it. To ignore it, but then I'm no better. Also. This may in fact help a lot of people eventually so I am sticking with it (at least for now).

Thanks, really appreciate your time, effort and creativity.

I see that both of you have two different GPU device-id's being 27a6 and 27ae. Why is that? You have two GPU's? Is only one patched maybe? BTW gma.c only adds AAPL,haspanel and built-in and that could be done in your DSDT, or a small SSDT_GPU.dsl correct? It (gma.c) also finds 27ae before 27a6 (higher in list) so might that be a problem?

 

Have haspanel in dsdt.

 

Ok had a brief look at the stuff on the link and will need to read and digest. Maybe I just go out and buy a HP to save all this pain! No only joking.

 

Did the stuff in #600 (EFI injection) I have done some comparison's between my Chameleon and Revolution after these changes and saved the ioreg's and I noticed what may be the problem. (how to resolve is another matter however)

 

On Display0

 

Chameleon gives:

AppleBacklightDisplay IOProbeScore 0xbb8

FrameBuffer12CInterface>IO12InterfaceID = 0x536700...........

IOFramebufferClient = pid 55, WindowServer

IOFBDepenndantID = 0x534bc00

Intel915 (all of them) = pid 55

 

Revolution gives:

AppleBacklightDisplay IOProbeScore 0xclc

FrameBuffer12CInterface>IO12InterfaceID = 0x52aa800...........

IOFramebufferClient = pid 70, WindowServer

IOFBDepenndantID = 0x5284400

Intel915 (all of them) = pid 70

 

So I'm fairly certain this is a display issue causing the time lag between throbber and log in.

 

Now off to read more in depth your stuff on the other topic.... amazing stuff

[blackosx]

Just sussed, the data in efi->device-properties when booting from Chameleon is for my video. It's added when enabling Graphics Enabler. Therefore if I add the same data in private.h for Revolution then I can remove the video data from my DSDT.aml? and also use if for any other instance where I would add device strings?.. I'll try it now.

Done and it works

Video removed from DSDT.aml and device properties injected perfectly.

 

Good job DHP.

Bed time for me now - if I don't catch you in the morning I hope your important day goes well.

 

EDIT;

Been tweaking my second HDD with a fresh OSX 10.6.6 system dedicated for loading from my HDD version of Revolution. I have used static data for CPU, DSDT, EFI (Video), SMBIOS and set it to load the prelinked kernel.

 

So I now have only three files:

boot

/L*/P*/S/*/com.apple.Boot.plist

/S*/L/*C*/c*/S*/kernelcache_i386.XXXXXXXX

[blackosx]

Do you have more/other _DSM methods setting properties? If yes, you need to start thinking about converting them because this will speed up your boot time (time between apple logo and throbber will be shorter).

 

And I will need to think about how we can incorporate this without too much hassle for people (had a go with command line tools like: efistudio and gfxutils before).

I'll check my DSDT for anything else I think I might be able to add when I get time later.

For users with an already working system using standard Chameleon they can extract their efi device properties from ioreg using this:

ioreg -p "IODeviceTree" -lw0 | grep "device-properties" | awk '{print $5}' | sed -n '1p' > ioreg_efi_device_props.txt

It's not much but it's a start...

[scrax]

Hi scrax,

 

The -x boot option (safe boot) limits the number of kexts we load, and then we let kextd load the rest of the required kexts. This also means that when it is missing from your system mkext, that it is there and loaded by kextd afterwards. And when it is there, but for the wrong architecture, or corrupt, then it won't get loaded.

 

I would say create a new system mkext (and /Extra/Extensions.mkext if you have one) and when that doesn't work, unpack them to see what is included. One of them might be damaged, corrupt or made for the wrong (a single) architecture (I ran into this a while ago).

I tried with a new mkext and it gives me the same hang. If I start with chameleon mkext is loaded fine so i belive it's not corrupted.

 

I have all my kext in S/L/E/

[Kabyl]

And for so long I was wondering what this boot loader-related "Revolution" is... interesting project, good read..

 

And I am about to publish new files today. This time I am working on the SMBIOS patcher to make it quicker, smaller. Basically do the same with less arguments, functions and less source code. Making it more logical, by moving stuff to where it belongs. I'm sure that other developers will say: "Right. Why didn't we do that a long time ago.". Well. Today is that day and here is where it starts. Loads of new fun stuff to work on... and here's one example:

static int sm_get_cputype(void)
{
return gPlatform.CPU.Type;
}

Or this one:

static int sm_get_bus_speed(void)
{
return gPlatform.CPU.QPISpeed; // QuickPath Interconnect Speed.
}

Now compare these with the ones you are using right now. Much more fun this way though I am still struggling with this GT/s (Giga Transfers per second) thing. I mean should I use QPISpeed or QPIFrequency for this?

 

You might be interested in my effort at rewriting the SMBIOS patcher: http://forge.voodooprojects.org/p/chameleo.../branches/Kabyl

 

The getters functions still need to be worked on.

[humph]

Unable to test this from here but please give it a go.

Prog works really nicely (should have waited a bit longer.... I'd just done it manually with a find all " " replace with ", 0x" from my raw grab of numbers from IOReg, to get right format!). And now display injection working here also via entry in private_data.h.

 

(Note for DB1 - does not remove the Display Unusable log entry though, so that must be something else going on).

 

Also working on minimizing DSDT, now down from 25k (yikes!) to 18k. Not all due to display inject of course, a long way to get a DB1 sort of size...

[blackosx]

Unable to test this from here but please give it a go.

You're clever.. I've spent two hours looking for a unix command help with doing just that but I guess it just goes to show there's no better way than to write a custom piece

 

It compiles fine and masterfully creates the struct however it stops short on my iMac?

The device properties in ioreg on my iMac are much larger than the extracted struct.

 

Data size:

0x2193a in ioreg

0x0c9c in the struct.

 

I'll run it on my hack when I get home and report back.

 

EDIT: works great on my hack. Job done

[DB1]

Unable to test this from here but please give it a go.

 

Done this on my Chameleon install and patched private data and recompiled Revolution, removed the kext you made recent and removed GFX0 from dsdt and booting much better, at least equal to Chameleon in terms of time.

 

Just a little confused on what the "EFI" device properties is injecting for me, tried taking out my 27ae patched GMA950 & FrameBuffer kexts and no boot.

 

Need to sort out graphics! Need to get static dsdt, smbios done, cpu into private. My heads a bit mashed at the moment.

[blackosx]

It took me hours to understand this whole EFI path concept, and I still don't know everything, but apparently we are getting somewhere anyway.

You've made and are making good progress with this. I'm enjoying watching the developments - it's like being back at school for me

 

I use the wrong var format (only 16-bit wide instead of 32-bits). Should be an easy fix.

I did actually think of that.. (he he.. I'm learning!)

 

Also, if you wanted to catch the eye of the Chameleon devs, then it doesn't come much better than that complement from kabyl earlier. Keep up the good work!

 

Need to sort out graphics! Need to get static dsdt, smbios done, cpu into private. My heads a bit mashed at the moment.

Hi DB1

 

I'm sure you know what to do for adding your static dsdt, but to recap this is what I did:

• Get aml2struct.pl

• Run sudo perl aml2struct.pl DSDT.aml DSDT.txt

• Copy and paste the result in to /i386/libsaio/acpi/statid_data.h at entry point #if STATIC_DSDT_TABLE_INJECTION.

• But remember to change the variable name in the new pasted declaration from

static uint32_t MY_Table[] = to static uint32_t DSDT_Table[] =

or patcher_h will complain when compiling.

• Finally add the following directive in to /i386/libsaio/acpi_patcher.c

#define STATIC_DSDT_TABLE_INJECTION 1

I added it just above #define LOAD_DSDT_TABLE_FROM_EXTRA_ACPI 0

 

But there's a lot to change to suit ourselves when DHP releases a new version, so much so I have built up a collection of notes here to try to remember what to do and where to do it!.. It might be worth trying to put a little package together to automate some of this, for at least the EFI, DSDT and SMBIOS data collection.

 

EDIT:

Here's my first attempt to make a little automater.

Removed as a revised version is available in this post.

 

It's a simple bash script, a couple of folders and the tools supplied in this topic by dutchhockeypro.

To use:

• Add your DSDT.aml in to the ADD_your_DSDT_AML_File_in_Here directory.

• In terminal, cd to the Rev_Make_Stucts_v0.1 directory

• Run MakeStructs.sh

 

It will dump textfiles for your dsdt, efi_data and smbios_data in the FinalStructs directory. These can then be added to the relevant places within Revolutions source code.

 

If this seems like something worth progressing with then I'm sure I can get it to do more. Maybe even to patch the source files too?

[DB1]

You've made and are making good progress with this. I'm enjoying watching the developments - it's like being back at school for me

 

 

I did actually think of that.. (he he.. I'm learning!)

 

Also, if you wanted to catch the eye of the Chameleon devs, then it doesn't come much better than that complement from kabyl earlier. Keep up the good work!

 

 

Hi DB1

 

I'm sure you know what to do for adding your static dsdt, but to recap this is what I did:

• Get aml2struct.pl

• Run sudo perl aml2struct.pl DSDT.aml DSDT.txt

• Copy and paste the result in to /i386/libsaio/acpi/statid_data.h at entry point #if STATIC_DSDT_TABLE_INJECTION.

• But remember to change the variable name in the new pasted declaration from

static uint32_t MY_Table[] = to static uint32_t DSDT_Table[] =

or patcher_h will complain when compiling.

• Finally add the following directive in to /i386/libsaio/acpi_patcher.c

#define STATIC_DSDT_TABLE_INJECTION 1

I added it just above #define LOAD_DSDT_TABLE_FROM_EXTRA_ACPI 0

 

But there's a lot to change to suit ourselves when DHP releases a new version, so much so I have built up a collection of notes here to try to remember what to do and where to do it!.. It might be worth trying to put a little package together to automate some of this, for at least the EFI, DSDT and SMBIOS data collection.

 

EDIT:

Here's my first attempt to make a little automater.

 

It's a simple bash script, a couple of folders and the tools supplied in this topic by dutchhockeypro.

To use:

• Add your DSDT.aml in to the ADD_your_DSDT_AML_File_in_Here directory.

• In terminal, cd to the Rev_Make_Stucts_v0.1 directory

• Run MakeStructs.sh

 

It will dump textfiles for your dsdt, efi_data and smbios_data in the FinalStructs directory. These can then be added to the relevant places within Revolutions source code.

 

If this seems like something worth progressing with then I'm sure I can get it to do more. Maybe even to patch the source files too?

 

 

Nice one blackosx, I been bouncing back and forth over the topic trying to remember what tools where and how and I have swapping the hdd in and out like a fiddlers elbow. I got a bit tied up with the graphics thing but last night sorted the EFI and Smbios statics, will sort the rest this evening. The notes and the tool should make things much easier i'll give it a go when I get back from work this evening. Thanks.

[blackosx]

Nice one blackosx, I been bouncing back and forth over the topic trying to remember what tools where and how and I have swapping the hdd in and out like a fiddlers elbow. I got a bit tied up with the graphics thing but last night sorted the EFI and Smbios statics, will sort the rest this evening. The notes and the tool should make things much easier i'll give it a go when I get back from work this evening. Thanks.

It's nothing special (at least not just yet), but if it helps here then you're welcome.

 

Fabulous. And yes please. That'll be awesome!

Okay. I'll work on it when I get some time.

 

Attached is the patched file (change the name to whatever you like but we'll use efidp2struct here).

Cool. It now creates a completed struct. Good job DHP.

 

However as it was, it failed to find the device-properties so I fixed it by changing:

CFDataRef dataRef = IORegistryEntryCreateCFProperty(entry, CFSTR("dev-prop"), kCFAllocatorDefault, kNilOptions);

to

CFDataRef dataRef = IORegistryEntryCreateCFProperty(entry, CFSTR("device-properties"), kCFAllocatorDefault, kNilOptions);

 

I've added the revised binary to the Tools folder for my script:

Removed as a revised package is available in this post.