AnVAL (ACPI Loader)

[ivik]

Hi,

 

I already tried that, but IOregistry doesn't change. Does this loader searches for all aml files from extra or only supported ones?

[valv]

Hi,

 

I already tried that, but IOregistry doesn't change. Does this loader searches for all aml files from extra or only supported ones?

I personally provide the loader with a fixed fadt.aml, (no facs table into Extra). Then I use those keys to avoid those tables from bios: oemFADT (with No as its value) and FADT (with <location of fixed fadt.aml> as value). No facs there. I just live it alone. Even though on IoRegEx I get satisfactory result for facs (not the @ one).

In fact, the loader searches for all the tables you were providing into the Extra directory by default. Try getting rid of that table, use the same keys as me, and see what happens.

[valv]

@jlvaio,

u made this topic messier than my own desktop

btw, what you've been posting is a windows driver. No sources no joy.

try this one jlvaio_dsdt_2.zip

[valv]

@jlvaio,

I think u need to read the Acpi Specifications from intel if u want. That'd help u understand the meaning of things like Eisald and many other things on your DSDTable.

Btw, am sorry to not have the time neither the motivation to fix your issue. If any would like to help u out, that's fine. But please, stop posting those links here, 'cauz everyone knows how to use google. Like I told u before, u better open one topic for that matter.

One more thing, be gentel, and remove those long posts from the topic. I count on your understandings. And don't hesitate to post back when you'd have issues with the loader (not those related to manufacturer's irresponsibility towards its own customers. Not my fault!)

Edit: read this.

Greetz.

[valv]

@Azi, sorry for missing your post,

The ramdisk you mention, is it that stuff Meklort uses on his booter?

Yeah it is that one, slightly/ridiculously modded

I'm asking because i already mentioned ramdisks and you made a weird comment. At the time i was talking about

the ramdisks we can already load on e.g: pre-boot discs or to load a diff set of drivers, etc...

times r' changing . But loading kexts from there seems to be not of a use.

Greetz,

[Azimutz]

@valv, no problem

Loading kexts from were? The "Meklort" ramdisk or the other ones...

If it's the Mek one, it's seems so.. i mean, it's not used to load kexts, etc... like the others. The noob here still has to study that one

But, if i do understand has some interesting uses; got me curious!

[valv]

... like the others. The noob here still has to study that one

But, if i do understand has some interesting uses; got me curious!

yeah, u are totally right, I know who the noob is and that noob is glad to provide u with the sources.

This way u can help me out perfecting it. won't u ?

 

edit: ramdisk is not yet commited, sorry! I know a friend who told me I still have to study. no, no, not u

Greetz,

[Azimutz]

I can try to help, but you got to believe me when i say that i'm noob at this stuff!! I really am;

not in the true meaning of the word, though noob as in newbie to all this coding stuff.

I didn't had time yet to look at the code you submited to the branch.. let me take jus a quick peek..

hum, nice was expecting to see many more differences against the trunk; somehow that tought got stuck in my head from previous comparations.

Will take a better look later.. need to finish tests on my stuff first so i can share it.

 

Ttyl...

[valv]

.. was expecting to see many more differences against the trunk;

Reverting back into older andy's revisions, was not an easy decision to take.

From there, I thought it'd be wiser nearing the trunk, for now.

This way, I kept ACPI's load-ability with greater chances to merge the new additions from trunk and elsewhere.

Greetz,

[Azimutz]

Yep, i do think all the guys working with Chameleon should keep their working copies as close as possible to the trunk, especialy those who keep branches on the repo don't think i need to explain why, you already stated the most important reasons.

Man, i keep finding issues to test... will take me some time to look at your branch properly

[anibalin]

Hi anval. Thanks for this build, works great.

I have found yesterday, booting with arch=i386 x86 (because I needed to load some specific audio card kexts) that It doesnt shutdown (it restarts). Under x64 it works okay. I have all fixed under dsdt. Only using fakesmc in extras.

 

Could it be a bug? thanks for your time.

[valv]

Hi anval. Thanks for this build, works great.

I have found yesterday, booting with arch=i386 x86 (because I needed to load some specific audio card kexts) that It doesnt shutdown (it restarts). Under x64 it works okay. I have all fixed under dsdt. Only using fakesmc in extras.

 

Could it be a bug? thanks for your time.

u've been putting false arg, try booting with -x32

also verify that no other arch-related-args are being interfering from boot.plist

btw, if u put no args there, default would be 64Bits

Greetz,

[mitch_de]

" try booting with -x32" .

Isnt that the old way, overhauled in "Normal" chameleon builds since >6 months ?

Would be fine all newer build use same (new) options arch= .

[anibalin]

u've been putting false arg, try booting with -x32

also verify that no other arch-related-args are being interfering from boot.plist

btw, if u put no args there, default would be 64Bits

Greetz,

 

Worked great. Thanks mate.

[Azimutz]

" try booting with -x32" .

Isnt that the old way, overhauled in "Normal" chameleon builds since >6 months ?

Would be fine all newer build use same (new) options arch= .

Nope. arch= is the way on oficial Chamelon releases! Chameleon builds based on the repository trunk, are not oficial releases; those also have the -x32 way (from PC-EFI), it was merged (from Asere's work, i think) as a "compatibility" thing: http://forge.voodooprojects.org/p/chameleo...ot2/boot.c#L413

 

I don't agree with this stuff at all... it's removed from my work. This only creates more confusion!

You can find more of that on PciRoot code: http://forge.voodooprojects.org/p/chameleo.../pci_root.c#L57

 

here we have 4 keys and the already existing PciRoot key was relegated to a "secondary" position.. poor thing

I'm sticking with arch= and PciRoot=, only.

[valv]

..This only creates more confusion!

u'r probably right, as I personally were going onto confusion the first time people began do stick with different args. but I personally prefer shorter args, too lazy to type, too easy to forget more seriously we just don't know how things will become later on trunk.

Always regarding evolutive matters, am trying to get it even more complicated, wishing to implement 18seven's macros without success. did u tried it ? does it work ? I know rekursor/prasys made it already on their respective branches. I just don't see what fails on mine. any sharable knowledge on this one would be welcome.

here we have 4 keys and the already existing PciRoot key was relegated to a "secondary" position.. poor thing

I'm sticking with arch= and PciRoot=, only.

as long as the old ones remain, I don't mind adding -pci into play. the decision remains to user's preferences. but surely we all need to stick with standardized args to avoid confusion, one day.

[valv]

updated

[Freaky Chokra]

updated

Hey valv!

Good Morning! Good to hear about the latest Release; Downloading now... Trying soon after the reboot from Leopard 10.5.8 to 10.6.3.

Again, I've screwed it up a bit, trying the latest fakesmc.kext, which supports reading quite a few Hardware registers of Temp and fan speed monitoring.

But, getting a KP. So last night I was trying it out. Tried a couple of times, but still KPs. Dunno why!?

Now, going back to older Fakesmc v2.5 and will get back to work.

Hope you too will try the newer Fakesmc.kext...

It supports realtime, accurate reading of CPU, GPU, and Northbridge temperatures, as well as fan speeds of 3-4 FANs on the mobo and GPU fan too!

 

Regards,

Freaky Chokra

Edited June 5, 2010 by Freaky Chokra

[mightycrown]

Hey. I m curious about support video card that ATI HD2600 is on the list. Does it mean QE are supported?

[Freaky Chokra]

Hi Valv!

 

The newest release works without problems! Theming works, but with the workaround of image files and .plist files if done correctly.

But yes it does work. GEnabler works too! That partition hiding issue, I am still facing but, that's not important.

May be it is my Computer that is so M-F-ing used to Windows or is just rotten like my programming skills! [miffed@myself]

 

Sigh!

Add, getting yelled @ in InsanelyMac.

 

Regards,

Freaky Chokra

Edited June 5, 2010 by Freaky Chokra

[valv]

Freaky Chokra,

am not willing to open a topic in the topic, but just to let u know I already messed with that one. in fact, Slice and the folks over there are making really good job. the gpu plugins (nvidia + intel, for now) are also into play. u have to know that u need to edit your dsdt and add sections for the keys u'd use...

lastly I've managed to compile a little tool that'd help read out some values like which super I/O chip is soldered on motherboard (as mine was not supported by the kexts yet and that was causing the kps). I'll be posting in a week or so.

till then, hope u get it working. also try to have your kexts loaded from s/l/e as Slice likes.

Greetz,

[Hacktrix2006]

valv how do i install the i386.zip file on mac?? is it possible to make a installer for it or give somekind of tut on how to install the updated files?

 

Also with Ramdisk support now in does this mean i can use it for making a Boot-132 CD ?? thanks for anyhelp!

[Azimutz]

valv how do i install the i386.zip file on mac?? is it possible to make a installer for it or give somekind of tut on how to install the updated files?

 

Also with Ramdisk support now in does this mean i can use it for making a Boot-132 CD ?? thanks for anyhelp!

First post as some links on how to.. check also Voodooprojects, there are some more recente guides there. You can just replace the "boot" file on the root of the system's volume, it will work but, boot0/boot1h were updated so, if you're still using RC4 it's better to do a full install.

Ramdisk support for "pre-boot" ramdisks was never gone. The ramdisk added on this booter it's a post-boot one, has nothing to do with 132 pre-boot discs. Don't ask me what's this post-boot one for.. this noob still didn't had the time to investigate.. this is the best i can point out

 

u'r probably right, as I personally were going onto confusion the first time people began do stick with different args. but I personally prefer shorter args, too lazy to type, too easy to forget more seriously we just don't know how things will become later on trunk.

Always regarding evolutive matters, am trying to get it even more complicated, wishing to implement 18seven's macros without success. did u tried it ? does it work ? I know rekursor/prasys made it already on their respective branches. I just don't see what fails on mine. any sharable knowledge on this one would be welcome.

 

as long as the old ones remain, I don't mind adding -pci into play. the decision remains to user's preferences. but surely we all need to stick with standardized args to avoid confusion, one day.

Nope, didn't turned my attention to the macros or tried them yet.. i see you commited them to the branch..

Any success with them?

 

About the stuff i mentioned, we sure don't know how things will be, but we can have a word on it

Maybe i was being too radical on that one.. my brain just hates duplicated useless stuff and it's just confusing to me; this stuff was created by Asere for "compatibility" because of the naming diffs between Cham/pcefi started by netkas, but if you check on his code for pciroot stuff, it's disabled there so it's not that important, right?! it seems just a name thing?!

And the arch= stuff, if it's just because of the typing, i386 & -x32 have the same number of characters, netkas could have just changed the existing arch= to a kernel flag when he had the idea, since he used Chameleon code at the time!

Anyway, this is just my opinion, not a decision i can take on my own.

 

I'll hit your pm soon..

Stay safe

[kizwan]

Hi valv,

 

Thank you for your effort in making this alternative boot loader available to us. I have a request; I found out that other ACPI tables (tested with FADT.aml) will not load if DSDT.aml file is not exist. I already put the modified DSDT in BIOS image (Aspire 9420) & flashed it to BIOS chip. That is why I don't need DSDT.aml file anymore. However, I have to put the DSDT.aml file for FADT.aml to load. I'm hoping you can release new booter which can load other ACPI tables without DSDT.aml file.

 

On my Dell Studio, I found that PM Profile is set to 0 (PM Profile : 00 (Unspecified)) in FACP/FADT table. However, Battery tab is visible in System Preferences/Energy Saver pane as well as Battery Power in System Profiler (under System Power Settings). In ioreg, the value of system-type is 02 which follow ACPI rev 4 standard for mobile computer. I use original Chameleon 2 RC4 & without system-type entry in com.apple.Boot.plist. The OS X is 10.6.3 which actually cloned from Aspire 9420. I didn't get the same result with Aspire 9420 without modified FADT.aml (PM Profile : 02 (Mobile)) & your booter. I'm hoping you can explain about this.

 

On my Aspire 9420 with your booter & my modifed FADT.aml file (hex edit = PM Profile : 02 (Mobile)), system-type does appear in ioreg & the value is correct which is 02. However, I found that a lot of values in FACP table has been changed which I'm confident it have to do with restart fix. Is this means, to actually get working restart function, we need to change the value of a lot of things (not just "Reset Register Supported=1") in FACP table? I feels more comfortable if I can patch the FADT.aml file myself to fix the restart issue. I'm considering to include the modified FADT.aml file in BIOS image & flash it to BIOS chip.

[kizwan]

Hi valv,

 

I have successfully modified FADT.aml with restart fix & "PM Profile" set to 02 (Mobile). It has been tested with AnVAL booter release 04062010. "system-type" does visible in ioreg with value 02 which taken automatically from the modified FADT.aml file. Thank you to your booter, I'm able to understand how to add restart fix manually in FADT table.

 

I'm also successfully flash Aspire 9420's BIOS with the modified FADT.aml. The restart fix is working without OpenHaltRestart kext as expected. The restart fix message also disappear from boot message indicating that it read correctly the FACP/FADT table in BIOS. However, system-type is not visible in ioreg. I have check FACP table in ioreg, "PM Profile" is indeed 02. For unknown reason AnVAL booter unable to fetch automatically "system-type" value from FACP/FADT table in BIOS. I think this is a bug & if it is I'm here to report it.