Whether Chameleon could choose the right AML file

[therebelmc]

I was asking in irc:irc.voodooprojects.org/#Chameleon two things that might interest you:

1) Why DSDT loading status is not logged
2) Whether Chameleon could choose the right AML file

[10:37am]TheRebelMC: Is there a log that shows whether the DSDT.aml file was loaded? i.e. no log after the machine has booted
[10:38am]TheRebelMC: I believe there is something to show the -v output more slowly
TheRebelMC must have typed the wrong: it didn't wait for long, but did show a log
[11:12am] zef: TheRebelMC: you can catch the boot process by booting with -v Wait=y options
[11:14am] TheRebelMC: doesn't record it does it?
[11:15am] zef: doesn't, since we can't write to the filesystem.
[11:16am] zef: Wait=y
[11:16am] zef: case sensitive
[11:16am] TheRebelMC: oh, case sensitive!!
[11:16am] TheRebelMC: why can't it write to the fs?
[11:17am] zef: the hfs implementation can only read from the fileystem.
[11:18am] TheRebelMC: oh, I suppose you had to reimplement! too soon for OS
[11:18am] TheRebelMC: why is the flag case sensitive?
[11:19am] TheRebelMC: can't write to a USB key in something simple, like FAT I suppose?
[11:19am] • TheRebelMC discovers, against his best guess, that his DSDT.aml file is in fact loading
[11:19am] zef: we may inject the boot log into the device tree
[11:20am] zef: that can be inspected later, if the system boots properly
[11:20am] TheRebelMC: You could use it to insert the before and after DSDT too, I suppose
[11:21am] TheRebelMC: maybe have a device-tree to log converter, to put them back as logs after the fact


[11:31am] TheRebelMC: Does Chameleon get to see the model of the motherboard in use? e.g. GA-P35C-DS3R?
[11:36am] TheRebelMC: because a downstream problem is having the right DSDT for your mobo
[11:36am] TheRebelMC: so if it could choose a directory based on your mobo people could distribute sets
[11:46am] Neonkoala: bad idea as a lot of DSDTs have CPU specific properties such as P-states which means multiple DSDTs for the same mobo. Not really a good idea
[11:54am] TheRebelMC: well, what is matching was very strict?
[11:54am] TheRebelMC: e.g. /Extra/DSDT/Gigabyte/F7/P35C/DS3R/P0,otherspecificstuff/DSDT.aml
[11:58am] Vaibhav left the chat room. (Quit: Vaibhav)
[12:04pm] TheRebelMC: So, this: http://tonymacx86.blogspot.com/2009/12/ ... oards.html is dangerous?
[12:05pm] Neonkoala: not necessarily, there's lot's of factors which means not every board is the same
[12:05pm] Neonkoala: usually p-states is the big one
[12:06pm] TheRebelMC: So reading the DSDT and patching is the way to go
[12:07pm] Neonkoala: well that would be more difficult, I guess you could code some basic patches in
[12:08pm] TheRebelMC: how about, then, if there is no DSDT.aml, reading the DSDT, finding the right patches based on a directory structure, and patching. The user could allow more or less patches to be added.
[12:09pm] TheRebelMC: I also wondered whether you could record the CMOS's DSDT.aml and log it, so it can be diffed from the loaded one
[12:10pm] TheRebelMC: assuming that after it's patched the machine can't see the one in CMOS (if that's where it's stored)
[12:11pm] TheRebelMC: is the motherboard model readily accessible during chameleon's start?

To date I didn't get an answer to that last question.

 

[tonymacx86]

Interesting discussion- you mean an automatic DSDT parser integrated into Chameleon with data for each board? Actually wouldn't be so hard to code, and lightweight considering most DSDTs are only about 20-40kb.

This is ubergeek country....

 

[therebelmc]

Y, I can imagine many ways of doing it.

1. a set of prebuilt amls, one per mobo+stepping combination
2. a set of patch documents, one per motherboard, so the more specific the case, patched during first run if the AML was missing.

It would help if Chameleon would extract the CMOS version of the DSDT and was able to write back to the filesystem. Hence my comment about it being able to use a workaround for writing logs. (i.e. via the only thing it can write to, the device tree, coupled with an extractor).

M.

 

[tonymacx86]

Well we're halfway there- We have the set of prebuilt .amls for P55s, it would take all of 10 minutes to convert them to include SpeedStepping info for i5/i7. Although I really only have experience editing GA boards.

We'd be starting from scratch though with the 2nd part.

 

[therebelmc]

[1:55pm] Kabyl: is the motherboard model readily accessible during chameleon's start?
[1:55pm] Kabyl: that's in SMBIOS, so yes
[1:55pm] Kabyl: but some boards don't have that set
[1:57pm] Kabyl: IMO, the P-States AML code should be left in an SSDT
[1:57pm] Kabyl: maybe then, you can distribute CPU-specific SSDTs

 

[therebelmc]

A set of DSDT .diff files that could be applied via command line patch.

Like DSDTSE's list, but with:
1) some help as to which to apply
2) some automation as users often cause errors by pasting into the wrong part of the file

A reported-bad flag for a mobo-stepping + patch & a disclaimer would be handy.

Patching rather than pre-supplying reduces the risk over an AML presupplied that would trash a mobo with incompatible stepping.

M.

 

[tonymacx86]

A set of DSDT .diff files that could be applied via command line patch.

Like DSDTSE's list, but with:
1) some help as to which to apply
2) some automation as users often cause errors by pasting into the wrong part of the file

A reported-bad flag for a mobo-stepping + patch & a disclaimer would be handy.

Patching rather than pre-supplying reduces the risk over an AML presupplied that would trash a mobo with incompatible stepping.

M.

You're right, but since I don't ever supply .amls with SpeedStep info, it greatly reduces the risk- and I've always highlighted the dangers in the SpeedStep guide and docs. But any risk is some risk.

In either case, I'd love to see this idea come to fruition. It would simplify things greatly- something I'm all about. Wonder if rekursor and the Chameleon team guys would give this a go. Or would you have any experience coding this kind of thing?

 

[therebelmc]

... I'd love to see this idea come to fruition. It would simplify things greatly- something I'm all about.

Y, simplicity is a factor that seems to have escaped many in the community. Effort is all very fragmented. It drives me nuts seeing huge numbers of long pages of instructions, only to get 34 pages in and to find that people have worked out a better solution but didn't bother to update the thread. (I despise forums for that! ...)

Wonder if rekursor and the Chameleon team guys would give this a go.

I was surprised you'd put it into the remit of the Chameleon team but I investigated and saw http://forum.voodooprojects.org/index.p ... ml#msg4999 - I'm unclear what it is they've built though.

Still, I'd have thought this would be an alternative tool to DSDTSE or DSDT_patcher, and separate so it could be used by the plethora of (competing, sadly) bootloaders.

Or would you have any experience coding this kind of thing?

Some, but self-employed, and I can't afford the time

M.