Bit Shoveler Posted January 23, 2009 Share Posted January 23, 2009 I've been successful at getting my Hack (see sig) running smoothly on Leopard 10.5.6. Thanks to all who provided solutions! Now I want to reduce the number of non-standard tweaks to the installation, and share my results here. Being a SW geek for a living, I'm really curious about how all this configuration stuff works, and I'm not afraid to RTFM (when I can locate it) and try some experiments from the Terminal. Heck, I live in the command line at my day job. Much of the discussion here centers on solving two very different kinds of problems: (1) finding and installing drivers that were never shipped with the OS; and (2) telling the OS that it can use an existing driver for this hardware it doesn't know how to recognize. This post is about case (2). Seems to me that there's a big overlap between EFI strings (A.K.A the device-properties item on com.apple.Boot.plist) and fixed DSDT.aml files. Both attempt to provide the OS a description of the hardware that it can understand. I suspect a lot of the configuration tweaking we do around here could be avoided if we could get ahold of an accurate DSDT for our particular hardware from the BIOS. But of course the BIOSes are tuned for Windows... even the Linux and *BSD guys have this problem. And we hack the Info.plist files of vanilla drivers to let the OS know that it already has a way to handle our hardware. I really like the plist-only kext approach, it just seems really clean. But again, some of these cases (e.g. the various Realtek sound fixes) seem like they might be solvable if the DSDT was available and correct. I see an overlap here as well. If this seems confused, I certainly feel confused. Please help me figure some of this out. Thanks. Link to comment https://www.insanelymac.com/forum/topic/148653-efi-strings-hacked-infoplist-files-fixed-dsdtaml-files-etc/ Share on other sites More sharing options...
Bit Shoveler Posted January 23, 2009 Author Share Posted January 23, 2009 Still confused, but I'm sorting this out a little at a time. I hope to be able to contribute some useful code to the community once my confusion is resolved, and I hope this thinking-out-loud exercise helps someone else through this process. It occurs to me (duh!) that we're really doing a few different things with the configuration info under case (2) above. (2a) The first is spoofing OSX86 and its apps into believing they're running on their preferred hardware (e.g. model names, etc.). (2b) Next is telling OSX86 that it can use its native drivers for hardware it doesn't recognize (e.g. Legacy plist hacks for AHCI drivers). (2c) Next is providing configuration information for use with the native drivers (e.g. sound codec hacks, EFI strings). (2d) Last is fixing the information provided by the native BIOS into a form OSX86 can use (e.g. DSDT hacking to get HPET enabled). There's some overlap between this and (2c). It's easy to get these things confused, especially when all you want to do is get the damned Hack up and running! The temptation is strong to just install a pile of hacked kexts into /System/Library/Extensions and be done with it, but that invites failure later when updated software arrives from Cupertino. I'm interested in solving (2c) and (2d), first for my particular configuration, and then in a more general way. I believe the Chameleon team is working on the general solution. I'd like to get up to speed so I can help them. Link to comment https://www.insanelymac.com/forum/topic/148653-efi-strings-hacked-infoplist-files-fixed-dsdtaml-files-etc/#findComment-1053209 Share on other sites More sharing options...
Pink Waters Posted January 24, 2009 Share Posted January 24, 2009 I know this may sound stupid but what if, we have a bootloader that somehow before loading osx86 it extracts all dsdt and ssdt (on the fly) from bios and then overrride it when booting, or maybe can do that if needed with an argument (-D or something).. so no need for dsdt patchers. so we have those bios tables over-with of course the issue that would come up here is that it would be not that intelligent fetching all audio codecs and built in video cards and other onboard devices so it covers all motherboards we are using! or maybe if we had a second stage kind of mac friendly bios ?! that a bootloader can load it prior loading the osx86? and hopefully with a gimmy: managing the efi partition files that are on the boot disk? just thinking with you. Link to comment https://www.insanelymac.com/forum/topic/148653-efi-strings-hacked-infoplist-files-fixed-dsdtaml-files-etc/#findComment-1053681 Share on other sites More sharing options...
Pink Waters Posted January 24, 2009 Share Posted January 24, 2009 I know that the above screenshot idea is a dream that we wish to happen but its so out of our league Link to comment https://www.insanelymac.com/forum/topic/148653-efi-strings-hacked-infoplist-files-fixed-dsdtaml-files-etc/#findComment-1053703 Share on other sites More sharing options...
Bit Shoveler Posted January 24, 2009 Author Share Posted January 24, 2009 Man, this stuff is making my head swim... I downloaded the source to the boot-132-dfe-turbo-munky bootloader (thanks to all of the above) and it's doing a LOT of stuff under the hood to set up the EFI environment for OSX86. Copying the SMBIOS info verbatim, splicing the user-provided DSDT into the BIOS generated ACPI data (twice!), then copying the device-properties data into the EFI tree. I found some information (but no ready-built tools) for reading device properties here and here. Looks like I've got some research to do. Time to fire up, and figure out, Xcode... this IDE stuff is a novelty to a command-line guy like me! Keep dreaming, Pink Waters! I think we'd all like to see this stuff get a lot easier. I just went through the codec chaos with my own rig (889A). Thanks to tmongkol for figuring this one out! It may be possible to set up a default configuration for audio codecs, but music geeks like me want to see this multi-channel capability put to full use in apps like Garage Band, etc. via the Audio Midi Setup configuration app. I haven't checked to see if this is working (or possible) yet. The point is that there needs to be a way for the user to easily change that mapping - i.e. boot time configuration has to be modifiable on the fly through a GUI. Hacking Info.plist files gets old in a hurry. Did I mention I loathe XML? Makes me long for the simplicity and readability of Lisp. Link to comment https://www.insanelymac.com/forum/topic/148653-efi-strings-hacked-infoplist-files-fixed-dsdtaml-files-etc/#findComment-1053888 Share on other sites More sharing options...
Pink Waters Posted January 24, 2009 Share Posted January 24, 2009 Happy Digging man! Link to comment https://www.insanelymac.com/forum/topic/148653-efi-strings-hacked-infoplist-files-fixed-dsdtaml-files-etc/#findComment-1053915 Share on other sites More sharing options...
node64 Posted February 6, 2009 Share Posted February 6, 2009 What if we could overwrite the DSDT tables in our bios's with one that OS X would understand? Link to comment https://www.insanelymac.com/forum/topic/148653-efi-strings-hacked-infoplist-files-fixed-dsdtaml-files-etc/#findComment-1071075 Share on other sites More sharing options...
Bit Shoveler Posted February 6, 2009 Author Share Posted February 6, 2009 What if we could overwrite the DSDT tables in our bios's with one that OS X would understand? Look around this board, there are several people doing exactly that. The tools for doing this are hard to come by, and most of them require Windows. If you can find the tools you need, go for it! I like the approach BuildSmart is taking on the BadAxe mobos. Link to comment https://www.insanelymac.com/forum/topic/148653-efi-strings-hacked-infoplist-files-fixed-dsdtaml-files-etc/#findComment-1071429 Share on other sites More sharing options...
Recommended Posts