AnVAL (ACPI Loader)

[Monkey D. Luffy]

@valv, anv and chameleon team, thanks for your work!

 

BTW, can someone point me to the link for the sources of this specific release? I need to compile it myself. Thanks!

[valv]

Go SVN

[bolly]

how to uninstall this version of chameleon.. i want to revert to rc4...my hackintosh cannot boot in 64 bit ang fakesmc cannot be loaded...i already run the rc4 but it cannot overwrite this rc5

[milanca]

Hi,

 

I am using this loader for quite some time now. It is the best loader for my board so far. An option to load all of the ACPI tables is just great. Thanks again.

 

Maybe some users would need this info to better understand the possibilities of this modified Chameleon. I personally assisted in testing it on EP35-DS3 (P35 chipset) together with AnV while developing (thanks bro again). Besides all of the other possibilities regarding ACPI, my goal was to get rid of OpenHaltRestart. Before the latest official Chameleon release there was a modified version (by Duvel or Rekursor i really can't remember now, sorry about that) so fixed FADT.aml could be loaded and thus OHR removed. Chameleon Team integrated this patch into their latest release (restart works with RestartFix=Yes param added) which is great of course but unfortunately it doesn't work on P35 chipsets. Ability to load FADT isn't integrated so OHR had to be used again or revert back to older loader (without all the newly integrated functions).

 

So this loader gives us everything from the Chameleon plus full ACPI control. Now i can run my 10.6.3 on EP35-DS3 with only one kext, fakesmc.

 

Regards!

[Azimutz]

Well, i wish you guys start teaching people how to install over Terminal instead of using installer packages!

And before someone remembers to criticize these words, i do plan to do just that, when i have time.

For a change, you guys having troubles loading kexts while booting k64, are bieng victims of "bad" postinstall scripts.

Let's analyze:

1-

mkextunpack -d "${2}/Extra/Extensions" "${2}/Extra/Extensions.mkext"

This is the line that unpacks Extensions.mkext if you have it in Extra; "mkextunpack" extracts ONLY the current active arch, meaning that if you are unpacking a mkext that has both i386/x86_64 archs in it and you run it on a system that's running k32, ONLY i386 arch is extracted!! It's just the way "mkextunpack" works.

 

2- to make matters worse..

ditto --noextattr --noqtn --arch i386 "${2}/.Chameleon/Extra/Extensions" "${temp}/Extensions"

this is the line that copies kests on E/Extensions folder to the temporary folder before "kextcache" creates mkext... noticed the arch being copied??

 

So, anyway you do it, with the installer you always end up with only i386 arch kexts/mkext.

Boot with arch=i386, replace the kexts and you're god to go.

Hope i'm not saying BS.. this was just a quick look at it. I can't bare to see you guys suffer like that

[milanca]

Installers can screw things up sometimes. For me the best way is to install everything manually. For Chameleon, if you download from its website, there is a folder 'doc' and README file inside. To install it you need three command lines to execute.

 

Normal Install (non-RAID):

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

 

Suppose that your installation is on /dev/disk0s2

 

- Install boot0 to the MBR:

sudo fdisk -f boot0 -u -y /dev/rdisk0

 

- Install boot1h to the partition's bootsector:

sudo dd if=boot1h of=/dev/rdisk0s2

 

- Install boot to the partition's root directory:

sudo cp boot /

 

No need to use startupfiletool anymore!

[FKA]

Well, i wish you guys start teaching people how to install over Terminal instead of using installer packages!

 

How to install Chameleon manually

 

How to install Chameleon manually to EFI partition

 

D

 

Ooops forgot one:

 

How to install chameleon manually to a software RAID

[bs0d]

@Azimutz, you posted a install script that was designed for leopard.

 

Lolz.

[Azimutz]

@Azimutz, you posted a install script that was designed for leopard.

 

Lolz.

You're maybe right but, that's not what i've done! I downloaded the package from the first post, extracted the postinstall scripts and...

Do i need to explain more?

If someone posted anything designed for Leo, wasn't me!

 

p.s.: @bs0d, i reacted like if you were mocking at my comment; if that's not the case, sorry

 

By the way, i don't have nothing against installers and there's nothing wrong in posting stuff designed for Leo, just as long as you know you're doing it and you mention it. Installers are supposed to easy life, not complicate it!

Anyway, to be constructive, removing the --arch option on the ditto line should make the package work fine for the arch you're booted on.

Just keep in mind "mkextunpack" only extracts one arch at a time, the one in use. And this option --noextattr, also needs --norsrc, according to "man ditto".

Edited April 30, 2010 by Azimutz

[bs0d]

well people will just post stuff without clearly checking .... to score brownie points ? .. feed their ego ?

 

so valv, you clearly didnt check what your posting .... and people wonder why this scene is a mess.

 

have fun

[Freaky Chokra]

how to uninstall this version of chameleon.. i want to revert to rc4...my hackintosh cannot boot in 64 bit ang fakesmc cannot be loaded...i already run the rc4 but it cannot overwrite this rc5

 

 

Hi bolly.

 

Firstly, you can NOT uninstall a boot loader.

 

You have to overwrite it with another one. And, the most frequently and easy ways is to do so from a working OSX install. It can be a "backed up" SnowLeo, or another Leopard residing on another partition.

Just like I have.

[see my sig Lolz!]

 

Installers can screw things up sometimes. For me the best way is to install everything manually. For Chameleon, if you download from its website, there is a folder 'doc' and README file inside. To install it you need three command lines to execute.

 

Normal Install (non-RAID):

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

 

Suppose that your installation is on /dev/disk0s2

 

- Install boot0 to the MBR:

sudo fdisk -f boot0 -u -y /dev/rdisk0

 

- Install boot1h to the partition's bootsector:

sudo dd if=boot1h of=/dev/rdisk0s2

 

- Install boot to the partition's root directory:

sudo cp boot /

 

No need to use startupfiletool anymore!

 

By the way, Milanca's post as above lays down the commands necessary to over write with a new or older or whatever, OTHER boot loader.

 

Lastly, after you type the last line to copy the "boot" file to /Volumes/(your Snow Leopard partition name)

 

Do enter the last command: sudo chmod 755 boot

 

1]

Attached is my working boot loader: Chameleon RC3 RC 658. Chameleon_RC3_RC_658.zip

 

I don't exactly remember the exact version revision number. But it has served me well since the past 8 months.

There is I think newer version(s), but this seems to do the trick. You can replace your existing bootloader with this and things might get working.

 

2]

Another thing might be that, you might not have installed the most important and correct working decrypter kext.

Leopard used the DSMOS.kext, or Appledecrypt.Kext, etc.

Here, in Snow Leopard (10.6.0->10.6.3) you need the FakeSMC.kext. fakesmc.kext.AnV_Improved.zip

I've also attached the latest working version by AnV, the guru! It is simply Awesome!

 

Hope this should get your setup working.

 

Regards,

Freaky Chokra

[Freaky Chokra]

You're maybe right but, that's not what i've done! I downloaded the package from the first post, extracted the ./postinstall scripts and...

Do i need to explain more?

If someone posted anything designed for Leo, wasn't me!

 

p.s.: @bs0d, i reacted like if you were mocking at my comment; if that's not the case, sorry

 

By the way, i don't have nothing against installers and there's nothing wrong in posting stuff designed for Leo, just as long as you know you're doing it and you mention it. Installers are supposed to easy life, not complicate it!

Anyway, to be constructive, removing the --arch option on the ditto line should make the package work fine for the arch you're booted on.

Just keep in mind "mkextunpack" only extracts one arch at a time, the one in use. And this option --noextattr, also needs --norsrc, according to "man ditto".

Hi Azimtuz. And bs0d.

Nicely analyzed my input on the mkext unpack routine of the ./postflight install script, and the way the mkextunpack works.

I don't know why it does the way it does things. Guess, I'd have to take up C and Shell programming/scripting again! Sigh! Btw, I just gave my Structured Languages Exam yesterday, and C and OOPs is a tough boy!

 

Anyways... Greetings valv. How're you?

More updates and feedback that I'd promised as my exams were done with ... Here:

As I currently use the following .mkext rebuild script from my root login, whenever trying out new implementations.

 

chown -Rf 0:0 /Volumes/Snow/System/Library/Extensions/
chown -Rf root:wheel /Volumes/Snow/System/Library/Extensions/
chmod -Rf 755 /Volumes/Snow/System/Library/Extensions/
kextcache -v 1 -a i386 -a x86_64 -m /Volumes/Snow/System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext /Volumes/Snow/System/Library/Extensions/

chown -Rf 0:0 /Volumes/Snow/Extra/Extensions/
chown -Rf root:wheel /Volumes/Snow/Extra/Extensions/
chmod -Rf 755 /Volumes/Snow/Extra/Extensions/
kextcache -v 1 -a i386 -a x86_64 -m /Volumes/Snow/Extra/Extensions.mkext /Volumes/Snow/Extra/Extensions/

 

This way, I've both the .mkext files packing in i386 (32 bit) and x86_64 (64 bit) KEXTs packed together, the installer rebuild script could have messed up things.

 

And, as we all know, SnowLeo is very very eccentrically finicky about kexts and plists and other stuff that loads.

 

That is why, I have refrained from Speed-Stepping etc etc etc. even though, BlackCH, DB1, MasterChief have a thread that has almost achieved perfection on the ASUS P5K-VM motherboard.

 

Well, I used to envy other people having the GigaByte UD3 P35 chipset series... I still can't remember the entire mobo model numbers...

Till, these gurus made amazing progress on my mobo model.

 

So to summarize (for those experiencing the same problems faced by me), the way I fixed the non-bootable issue as under:

 

1] Booted to Leopard in root login. Replaced with older Chameleon RC3 RC 658 Chameleon_RC3_RC_658.zip (I think that is the revision or release number) boot file, using terminal commands as posted above by Milanca.

Though, recently I'd replaced that with this newer PC-EFI 10.6 boot file : PC_EFI_10.6_boot_file.rar The PC-EFI 10.6 boot Installer PC_EFI_10.6_Installer.zip

2] Had to delete the unpacked kexts in /Extra/Extensions.

3] Replaced all of them, from a backup I keep as /Extra/Xtnsns/*.kext -> fakesmc, platformuuid, Realtek8139, Yukon2, OHR.kext, RestartOSX.kext, etc. among few others.

4] Rebooted to SnowLeo using arch=i386 -x32 -f -v flags. Go to login, went to root login. used the kext rebuild commands said as above.

3] Rebooted couple of times, tested using GeekBench and XBench. Browsers, uTorrent, etc.

4] Simply backed up the RC 658 "boot" file by command: cp boot boot.658

5] Then went old school, used terminal command to simply copy the newer "boot" file to /Volumes/Snow/

6] I Didn't write the Newer boot1h and boot0 files to HDD header.

I don't know what they do or are they even required... Silly me!

7] Edited the com.apple.Boot.plist file as suggested by valv for the DSDT, HPET, GraphicsEnabler, UHCIReset, EHCIRequire flags.

8] Voila! New bootloader (with the basic Chameleon boot screen ] with scores of lines as output.

Several failures in loading XXXX.aml files by bootloader. I think it couldn't read the ACPI tables from my motherboard, or I don't know too much into it.

Or maybe I need to remove the DSDT.aml file in /Extra/ folder and see how it goes.

Or as suggested by valv, try removing the PlatformUUID.kext and see if SL does boot or not.

 

Well, that's what I've been able to do yet so far. Today, I'll be into trying tons of stuff, and keep on with the updates.

I'm a free bird! Yay!

 

And, yeah... valv now I'm a "geek" ... Finally...my 100 posts! after 5 years! Ha ha ha!

 

I'll count on you, thanks

that's the way we grow things up over here

AnyTime, buddy. Anytime!

I like to move it, move it.... Lolz! Move towards progress... Perfection and Refinement.

 

By the way, in my own guide, I've just been lenient about posting the Time difference issue fix.

It is the most simplest thing ever, trust me! There is no need to run commands etc. Nothing! Nada!

All Credits to guru BlackCH... and his xXx 10.5.6 Universal Discs. I've almost all of 'em.

From his 10.5.6 install disc, I simply extracted the "Loacal Time Toggle" package (that is not a typo... the service daemon is named as such), using Pacifist and installed it. Kablaaam!.. Problem dismissed!

Here it is:

Loacal time toggle installer package -> LoacalTimeToggle.pkg.rar

Simply run the package, and the time issue should be fixed!

I've been doing that as first thing since I had started experimenting Snow Leopard installations.

 

Till next time, Happy Hacking!

 

Regards,

Freaky Chokra

[mitch_de]

Thanks to all refreshed the old+save, manual install way of bootloader files !

Q: I know that installers(.pgk) also include an modded fdisk, installed over the orig. (Apple) fdisk .

Does anyone know what excat the diff of that fdisk to Apple fdisk or what reason for that modded fdisk?

Some users may use orig. Apple fdisk

when using that

sudo fdisk -f boot0 -u -y /dev/rdisk0 command ! (because OS X updates also fdisk sometimes = modded fdisk overwritten !)

Also it can be that that modded fdisk (with .pgk) is from 10.4 or 10.5 and maybe not 10.6 ?

[Azimutz]

Q: I know that installers(.pgk) also include an modded fdisk, installed over the orig. (Apple) fdisk .

Does anyone know what excat the diff of that fdisk to Apple fdisk or what reason for that modded fdisk?...

Mitch, check this topic: http://forum.voodooprojects.org/index.php/topic,1141.0.html

It's explained there. Basically the now renamed to "fdisk440" (pass the word!!) fdisk, writes only to the first 440 bytes of MBR boot sector, leaving Windows bootsector intact (something like this). The source is on the repo: http://forge.voodooprojects.org/p/chameleo...unk/fdisk.tproj

 

Hi Azimtuz. And bs0d.

Nicely analyzed my input on the mkext unpack routine of the ./postflight install script, and the way the mkextunpack works.

I don't know why it does the way it does things. Guess, I'd have to take up C and Shell programming/scripting again!...

Hi Freaky.. so, are you the autor of those scripts? As far as i can see, they are the exact same scripts present on Chameleon. They are untouched since RC1, that wasn't "supposed" to work under Snow.

Well, i'm no programming/scripting genius, just learning. "mkextunpack just works like that, nothing we can do about it; there's no way to make it extract more than one arch at a time!

As for "kextcache":

kextcache -a i386 -a x86_664 -m /mkext /kext repo

to create mkext for Snow under Leo. (kextcache -m, won't do the trick!)

kextcache -mkext1 /mkext /kext repo

to create mkext for Leo under Snow.

kextcache -m /mkext /kext repo

caches all archs present on kexts either on Leo or Snow.

 

I'd dump the installer or make it just a booter installer (no kext/mkext, etc... handling).

In place of the installer, tell people how to install over Terminal, point them to guides, whatever...

But, that's just me.

[Freaky Chokra]

,whatever! am gettin' :censored2: with your thinkin'. take it easy and let us respect this non-sense.

 

my fault, sorry guys for this. I will remediate to this heck quickly. in fact I compiled it with default theme embedded sorry for this

 

EDIT= verified. it doesn't seem to be a compile mistake. maybe renaming your theme to default and replacing the one in the first place could resolve the problem. afraid to say we have to stick with this for now.

 

hey man, Congrats

u are a geek now

 

I'll count on you, thanks

that's the way we grow things up over here

 

Hey Dear valv!

 

Well, Today's been pretty hectic.

 

Well, I was simply trying out another ALC 883 modification in the Original AppleHDA.kext version 1.8.4fc3 from 10.6.3 update.

 

And, it didn't work. Then there was the latest build of VoodooHDA.kext version 0.2.6 x64 bit for Snow Leopard.

That too didn't fulfil my expectations. IT gave only stereo output -> hence, no use to me!

 

Then, I tried restoring my old AppleHDA.kext which was binary patched by hex editing.

That too was failing. But finally @ 1:30am, I've managed to fix the issue and restore a working copy of the Kext back to S/L/E/

So audio is now alive. Phew!

 

However, I wished to inform you about the progress on your new boot loader.

 

As quoted above, you asked to change the folder name to default, so that your boot loader could use the theme and background files located there.

For eg., my theme was Twilight. I've to rename folder "Twilight" to folder "Default" or "default". Whichever.

 

But. But. I tried either and even removed the original "default" theme folder...

This bootloader still shows the default chameleon boot graphics, etc. etc. etc.

 

Lastly, How should I post my results on the run-time (boot-time) DSDT table loading errors, etc.?

I am thinking of shooting a video using my phone cam. Would that be fine?

Coz, still it doesn't load my tables. I've blazed my eyes through the runaway text output ...

 

It lists all the kinds of tables:

SSDT.aml

DSDT.aml

FFDT.aml

??DT.aml

 

All these tables could not be loaded -> that is the output.

 

Hope this will lead to further the progress and eliminating minuscule errors.

 

Lastly, as I told in my first post, during boot time, it pauses for 5 seconds.

 

I have seen this error when I did not have a Core2Duo processor. It was a Pentium D 945 3.4 GHz (dual core) processor [478 pins].... u know....

 

But not with your boot loader.

The earlier PC-EFI 10.6 latest boot loader (I'd installed) did not present that error and my system booted to desktop in less than 15 seconds. It was even shorter time with the latest FakeSMC.kext version 2.5 from guru AnV.

 

But this version of the bootloader has added that 5 seconds pause, and "that shortened" boot sequence also has increased by almost 8-10 seconds. Total Time increase = about 20 seconds.

 

I hope this is some valuable input from me. And taken constructively.

 

Regards,

Freaky Chokra

[Azimutz]

@Freaky, that theme issue is another one of those... probably wouldn't happen if Andy were working with up to date sources, like updated to the trunk.

That's really the only remark i can do to this booter. Check Zef's comment on rev 87. All that stuff works fine here, using latest trunk, theme embedded or not. No need to rename folders or keep the Theme key on Boot.plist.

 

p.s.: check my previous post.

[Freaky Chokra]

@Freaky, that theme issue is another one of those... probably wouldn't happen if Andy were working with up to date sources, like updated to the trunk.

That's really the only remark i can do to this booter. Check Zef's comment on rev 87. All that stuff works fine here, using latest trunk, theme embedded or not. No need to rename folders or keep the Theme key on Boot.plist.

 

p.s.: check my previous post.

 

Hi Azimutz.

 

Thx for the input. Well, yesterday, I just logged in and posted before calling it a day. Very tiresome it was hah!

 

Can you post the link to Zef' comment on rev 87? Which page or topic? Here or other forum?

 

Well, your previous post you asked about the scripts on rebuilding the kexts.

 

I've researched and then did a bit of modifying the command so as to include i386 (32bit) & x86_64 (64bit) architecture kexts together for some of the kexts are 32bit only, as of yet.

And in default boot mode, where you have set the kernel flags as arch=x86_64 -x64,

then, Snowwill load successfully everything 64 bit -> kernels, kexts, everything.

BUT. but. but.

ONLY 64 bit. All the 32 bit things are ignored. applications will run, but any 32bit supported kexts will not be loaded.

Say the Realtek8139 isn't loaded if I have it disabled when I've started/rebooted my PC a couple of times.

It seems to auto-disable the 3rd party modded KEXT.

Again, similarly, it's just related to few kext issues that won't be loaded.

Hence, the combined architecture in the mkext, which includes both 32bit kext binaries, as well as 64 bit kext binaries.

 

However, to solve your dillemma, the -m does in fact work and is deployed by Apple in kextcache command.

The source of the following info? -> Terminal -> man kextcache

 

PRIMARY OPTIONS
    You must specify one of these options to have kextcache do anything:

    -m filename, -mkext filename
             Create an mkext of the latest supported format.

    -mkext1 filename
             Create an mkext of format 1, used on Mac OS X versions 10.5 (Leopard) and earlier.

    -mkext2 filename
             Create an mkext of format 2, used on Mac OS X versions 10.6 (Snow Leopard) and later.

    -e, -system-mkext
             This option is a convenience to update the startup mkext for the root volume.  Using this option with -local-root updates the startup mkext for a local disk
             startup.

    -c [filename], -prelinked-kernel [filename]
             Create a prelinked kernel.  filename is required unless this option is the last argument.  If this option is the last argument and no filename is given, the
             startup prelinked kernel for the system is created.  See -all-loaded.

    -system-prelinked-kernel
             This option is a convenience to update the prelinked kernel used for startup on the root volume, with all kexts in the system extensions folder that have been
             loaded to date.  This option implies -all-loaded.

    -system-caches
             Rebuild the info caches for system kexts on the root volume.

    -u os_volume, -update-volume os_volume
             Rebuild out-of-date caches and any helper partitions associated with os_volume.  The mkext is first checked and updated if needed.  Then any modified files that
             belong in the helper partitions are updated.  If -force is also specified, all helper partition are fully updated regardless of whether the data in
             /System/Library/Caches/com.apple.bootstamps/ suggests that they are up to date.  OS volumes without a /usr/standalone/bootcaches.plist file are ignored (success
             is returned).

    -U os_volume
             Used by the system to update volumes during startup.  Not for use otherwise.

 

Hope that should do it.

 

Lastly, good inputs from you here and at projectosx about the ALC 883 audio issue.

Well, yesterday (as you must have read my previous post) I tried the latest VoodooHDA.kext version 0.2.6.

No success. I want my 5.1 speaker output.

Can you help me with that if possible?

I'm frustrated at the Audio {censored purposely} that Apple messes up. Coz it knows, no one can do without sound. Aaargh!

 

Regards,

Freaky Chokra

[Azimutz]

... Can you post the link to Zef' comment on rev 87? Which page or topic? Here or other forum?...

Hi @Freaky... better explain you how.

Go to Chameleon repo; select Chameleon, Source tab, Change log; then use the "Go to revision" button on the left to jump to the rev. Simple

 

Will, post more... trying to process your post to many hours without sleep...

Hum... better check this again.. been a while since i tested this stuff, need to refresh memory... later.

Edited May 2, 2010 by Azimutz

[nomaj]

As many of u was waiting for this, let me introduce a new friend to your HDD on its way to vanilla.

I call it The Anv's Chameleon 2. Big thanks to Andy and the VoodooTeam for the hard work on this.

This is 2..0-RC5pre7...

 

People TNX for the nice work!

 

Now questions =)

 

I have lenovo g550 - and i'm relay happy with osx on it.... BUT!

Speedstep and high cpu temperature is what bothers me....

 

Does this means that with this boot loader i can load just dumped ACPI tables without their modifications?

 

Right now i dumped my tables and named it with SSDT-(X).aml and saved in EXTRA.

When i boot i see that boot log says that they not found? in boot.plst i have oemSSDT=Yes

 

when system is up and if in terminal i type ioreg -lw0 | grep CSTInfo

i get something like "CSTInfo" = 19136773

and after that ioreg -lw0 | grep PerformanceStateArray get something....98080000b88800000a0000000a000000230b0000230b0000......

 

Also i pached AppleLPC.kext with my device id.

 

In voodoomonitor i see that i have speedstep form 1194MHz to 2189MHz swapping between those values...

also i noticed that my sound is stuttering...

 

Need help here ... completely new for this stuff... =/

[valv]

Dear Chokra,

this is how I edited my boot.plist

try using the wait key to halt the screen and look what kind of tables get loaded then.

btw: I don't mind using the default theme, but for your convenience I'll hope we get some light (merging from ther other branch stated by Azimutz)

 

Does this means that with this boot loader i can load just dumped ACPI tables without their modifications?

sure u can load modded ones, for this u could use oemSSDT=No, put your modded tables on disk (/Extra) and use DropSSDT=No

Right now i dumped my tables and named it with SSDT-(X).aml and saved in EXTRA.

When i boot i see that boot log says that they not found? in boot.plst i have oemSSDT=Yes

...In voodoomonitor i see that i have speedstep form 1194MHz to 2189MHz swapping between those values...

While using oemSSDT=Yes (those directly from your Bios, not the ones u were placing on disk) u have a fully working speed-step. that means to me, that u don't even need the SSDT-X amls on disk.

also i noticed that my sound is stuttering...

Audio stuttering is another story, I think it's related to IRQs as stated on post 283 from the "DSDT - Vanilla Speedstep - Generic Scope (_PR)" topic

[valv]

well people will just post stuff without clearly checking .... to score brownie points ? .. feed their ego ?

 

so valv, you clearly didnt check what your posting .... and people wonder why this scene is a mess.

 

have fun

 

People, why do I feel like being persecuted since I made this thing. anyway, Azimutz, bs0d and all the people that disliked this, am not saying like I am the member of the century, am just learning things, and sharing stuff with friends. so don't blame me if the forum get's messy with topics posted by people like me. blame your self for being too lazy to share knowledge. no offense, but many guys where asking for this. btw I don't feel like stealing things from Andy, because I was asking him first.

So if you find some interest on this, let's help improve things together. if you are here just to blame me with your unmeasured sarcasm, then go your way, and shut the ***k up. after all you are so geek, that you need to open your own forum without giving me membership for it. this way you keep it clean. not my problem if it remains as clean as empty though.

 

sorry for this guys, but I needed to say it, as such people not even thank you for trying, no they permit themselves to feel better then anybody else. and you're talking about ego? whatever..

 

sorry especially on Chokra and all the people that where asking for help. I was so discouraged with some posts, that I was not able to concentrate on the priorities. I know, Iknow, that's a weakness in it, but am human..

[nomaj]

While using oemSSDT=Yes (those directly from your Bios, not the ones u were placing on disk) u have a fully working speed-step. that means to me, that u don't even need the SSDT-X amls on disk.

Audio stuttering is another story, I think it's related to IRQs as stated on post 283 from the "DSDT - Vanilla Speedstep - Generic Scope (_PR)" topic

Tnx! for your response!!!

 

Right... So this actually mean that with DropSSDT=YES and this boot i can load my dupmed non-modified tables?

Did i put ssdt-x.aml in right place?

I have speedstep but my battery life i short right now... and CPU temp goes around 60'. And problem is that i have only two cstate values.

 

Regards!

[Kasakka]

Is there any reason I should use this over AsereBLN 1.1.9? At the moment the only thing that isn't working is sleep (won't wake up), will this help with that?

[valv]

Tnx! for your response!

 

Right... So this actually mean that with DropSSDT=YES and this boot i can load my dupmed non-modified tables?

Did i put ssdt-x.aml in right place?

I have speedstep but my battery life i short right now... and CPU temp goes around 60'. And problem is that i have only two cstate values.

 

Regards!

ok, I think we are doing messy things here. first off, if u use the DropSSDT=Yes, you will not even load those ssdts from bios. why do u use these?

did u inject your ssdts into dsdt? that's another way of making speed-step working (not my case).

could you post your boot.plist? and/or further explain what tables you've put into /extra. also take a look at mine two posts before.

regarding the place to put your tables in, yes you are using the right place.

for battery consumption and cpu temps it's related to more stuff than the bootloader itself. one thing about temps, is fine tuning your dsdt in a correct way. ssdts, if edited should be corrected. also take a look at the 2006/vista hack for fan device..

 

Is there any reason I should use this over AsereBLN 1.1.9? At the moment the only thing that isn't working is sleep (won't wake up), will this help with that?

I was never testing aserebln, so I cannot judge it. but heard that it doesn't honor smbios.plist (maybe am wrong. some clearance please).

this one should help you load all kind of acpi tables. concerning sleep, it is dsdt related. hack your table accordingly to what people using same machine as yours are saying. personally I've got to deal with usb hacks, lid etc. you can find big help on the forum for this. if not then we'll maybe take a look into.

btw: if u already edited your dsdt, and sleep is missing only with this bootloader, then try using following keys on boot.plist: ForceHPET=Yes, USBLegacyOff=Yes.. u better take a look into boothelp though

[FKA]

it is quite buggy - I'm back with trunk for now.

The option to load, from file, each table is very useful though.

 

D