Onderwerp: Gigabyte Mac Edition BIOS Project

@ candykane:
ik zie geen link bij je post? Zou het graag even willen nalezen. Lijkt best wel interessant.

link

Ik ga ook maar eens op zoek naar een van de genoemde (EP43-DS3L ; EP45-UD3L ; EP45-UD3LR ; EP45-DS3L ; EP43-UD3L) Gigabyte borden. Weet iemand of er ook een mATX bord tussen zit? Anders zit ik ook vast aan een grotere kast en dat wil ik eigenlijk niet.

Dit is zeer nieuwswaardig!

In de benadering van hardware vanuit een OS gezien is dit de volgende logische, en ook LAATSTE stap!
En de resultaten liegen er niet om.

Eerst waren er kext (drivers), EFI strings, toen DSDT (abstracte BIOS/EFI layer), en nu de BIOS zelf aanpassen, zonder functionaliteit zoals hij voor een windows bedoeld is te slopen. Er is voorbij dit punt geen 'lager' niveau meer.

ehm het is al 2 jaar mogelijk je bios te flashen met je dsdt, en ja windows start dan ook nog gewoon op.
het punt is dat er gekozen is voor dsdt aan gezien het minder gevaarlijk is dan je bios flashen!

En dat is helemaal zo....!

Maar zoals je zal weten zit er tussen een 'theoretische mogelijkheid' en 'toepasbare realiteit' een aardig gat. Een van 2 jaar blijkt....
En de leuke bijkomstigheid is dat Gigabyte met haar dual-bios implementatie eventuele schade wel binnen de perken houdt.

LOL je begrijpt het zeker niet de DSDT is juist uitgevonden zodat je niet met je bios hoeft te klooien aan gezien de gevolgen voor fout bios flashen erg dramatisch kunnen zijn.
Dual bios heeft juist verhinderd dat er tot nu toe zo een project opgestart werd. aan gezien het flashen van een dual bios niet altijd even prettig verliep.
of je nu dsdt gebruikt of je bios flased maakt niet zo veel uit de werking is gewoon het zelfde. je zou uit al die bios files ook gewoon de dsdt kunnen trekken en die posten.

Ik begrijp het wel. Of misschien toch niet...

Waar DSDT voor is begrijp ik. Maar dat de kunde en kennis om DSDT per systeem tot een 100% te tweaken er niet 'zomaar' is, begrijp ik misschien nog wel beter.

Ik sta altijd open voor nieuwe kennis! Please indulge me,... Waarom lukt het dan via DSDT vrijwel nooit(!) om audio te krijgen ZONDER het gebruik van extra kext!? Dit is met deze BIOS methode -wel- gelukt! En dat is voor mij een zeer overtuigend argument. Waarom is het implementeren van de C-states, NIET de P-States in DSDT dan nog steeds zo een crime!?

Door een 'niveautje lager' te zitten, en daar de 'way things are' leesbaar te maken voor een Hack, verdient bij mij nog altijd de voorkeur boven een 'hardware abstraction layer' (niet gaan muggeziften om deze term!) aan te moeten passen.

Je kan naar china gaan, met een spraakcomputer, en iedereen verstaan. Moet je wel contant updaten, vocabularies laden, en -hier komt het- interpretatie bijstellen naar context.

Je kan ook eerst chinees leren, en dan naar china gaan.


Wat dual-bios betreft; hier heb ik me schijnbaar dan danig in vergist. Maar wat ik wel weet, is dat deze techniek, nu toepasbaar, weleens voor erg mooie installaties kan zorgen.

Een dsdt staat gewoon in je bios het is gewoon een onderdeel van elke bios.

Het tweaken van een dsdt file is gewoon zo veel simpeler dan je denkt.
want het is allemaal het zelfde opgebouwd en elk bios moeten de zelfde dingen gebeuren
dus daar om zijn er een aantal compilers geschreven die gewoon automatisch 95 % van de tweaks
al verwerken in de dsdt files. alleen die laatste paar voor snow zitten bij de meeste er nog niet in.

het is ingewikkelde materie die soundkaarten werkend krijgen.
want je geluids kaart kan alleen via dsdt hack werken als die met de standaard drivers overweg kan.
je hebt alleen voor digitale audio een driver file nodig annaloge audio werkt prima

dus je moet die ACL 888 of die sigmatel 262 of zo iets dergelijks hebben wat met deze drivers over weg kan.
het is een hoop werk om alles werkend te krijgen
/1 je moet zorgen dat osx hem ziet als compatible of juist als een van de boven genoemde kaarten en dan moet je in linuc een codec dump maken
en daar uit een adres pin out doen van je poorten
heb je dat gedaan moet je met een gedeelte van die adressen een nieuw adress voor osx gaan toe delen. al met al het is gewoon een hoop werk.

ik geef je even een voor beeld van mijn asus P5N-VM met een acl 1200 wat eigenlijk een 888 is met wat digitale extra's

So here are my notes on getting the audio to work. I think almost everything is working with the latest (10.5.6) AppleHDA, but I have not tested the inputs nor the internal SPDIF. HDMI and the internal CD-in is not working. I did test the optical output, all four (7.1) analog outputs and a front headphone including auto switching between a rear output and the headphone. Also, there are no assertion errors besides from the HDMI.

Thanx for all the info on insanelymac, especially from THe KiNG and tmongkol.

So this is what I did. Start with the codecdump from ubuntu. I also got the codecverbs from vista as an extra check. If you strip everything except the pin complexes, you get:
CODE
Node 0x11 [Pin Complex] Pin Default 0x99430140: [Fixed] SPDIF Out at Int ATAPI - Unknown
Node 0x14 [Pin Complex] Pin Default 0x01014010: [Jack] Line Out at Ext Rear - Green
Node 0x15 [Pin Complex] Pin Default 0x01011012: [Jack] Line Out at Ext Rear - Black
Node 0x16 [Pin Complex] Pin Default 0x01016011: [Jack] Line Out at Ext Rear - Orange
Node 0x17 [Pin Complex] Pin Default 0x01012014: [Jack] Line Out at Ext Rear - Grey
Node 0x18 [Pin Complex] Pin Default 0x01a19850: [Jack] Mic at Ext Rear - Pink
Node 0x19 [Pin Complex] Pin Default 0x02a19c60: [Jack] Mic at Ext Front - Pink
Node 0x1a [Pin Complex] Pin Default 0x0181305f: [Jack] Line In at Ext Rear - Blue
Node 0x1b [Pin Complex] Pin Default 0x02214c20: [Jack] HP Out at Ext Front - Green
Node 0x1c [Pin Complex] Pin Default 0x593301f0: [N/A] CD at Int ATAPI - Unknown
Node 0x1d [Pin Complex] Pin Default 0x4015e601: [N/A] Speaker at Ext N/A
Node 0x1e [Pin Complex] Pin Default 0x01456130: [Jack] SPDIF Out at Ext Rear - Orange
Node 0x1f [Pin Complex] Pin Default 0x411111f0: [N/A] Speaker at Ext Rear - Black


If you decode the Pin Defaults you get:
CODE
Port Con[2] Loc[6] Device[4] Type[4] Color[4] Misc[4] Ass[4] Seq[4]
Pin Default 0x99430140: Fixed intAT SPDIFo ATAPI Unknown NoPres 4 0 [Fixed] SPDIF Out at Int ATAPI - Unknown
Pin Default 0x01014010: Jack extRear LineOut 1/8 Green Pres 1 0 [Jack] Line Out at Ext Rear - Green
Pin Default 0x01011012: Jack extRear LineOut 1/8 Black Pres 1 2 [Jack] Line Out at Ext Rear - Black
Pin Default 0x01016011: Jack extRear LineOut 1/8 Orange Pres 1 1 [Jack] Line Out at Ext Rear - Orange
Pin Default 0x01012014: Jack extRear LineOut 1/8 Grey Pres 1 4 [Jack] Line Out at Ext Rear - Grey
Pin Default 0x01a19850: Jack extRear MicIn 1/8 Pink Res3 5 0 [Jack] Mic at Ext Rear - Pink
Pin Default 0x02a19c60: Jack extFront MicIn 1/8 Pink Res32 6 0 [Jack] Mic at Ext Front - Pink
Pin Default 0x0181305f: Jack extRear LineIn 1/8 Blue Pres 5 f [Jack] Line In at Ext Rear - Blue
Pin Default 0x02214c20: Jack extFront HPOut 1/8 Green Res32 2 0 [Jack] HP Out at Ext Front - Green
Pin Default 0x593301f0: No intAt CD ATAPI Unknown NoPress f 0 [N/A] CD at Int ATAPI - Unknown
Pin Default 0x4015e601: No extNA Speaker Optical White Res21 0 1 [N/A] Speaker at Ext N/A - White
Pin Default 0x01456130: Jack extRear SPDIFo Optical Orange NoPress 3 0 [Jack] SPDIF Out at Ext Rear - Orange
Pin Default 0x411111f0: No extRear Speaker 1/8 Black NoPress f 0 [N/A] Speaker at Ext Rear - Black


However, nodes 0x1d and 0x1f have a strange pinconfig and the Misc field also has some weird values set for a number of nodes. This is causing sound assertions. Looking at a ALC888 datasheet (the ALC1200 is just a ALC888), you can see that node 0x1d is actually a beep generator input and 0x1f is a SPDIF in, which is not connected on the Asus. For OS X the only values allowed for Misc are 0 in case of jack detection and 1 in case of no detection. So I change the SPDIF and internal nodes 01x11, 0x1c, 0x1d, 0x1e and 0x1f to 1 for Misc and the rest to 0. Furthermore, I changed the port connection and color of CD-in and the correct info for 0x1d and 0x1f.
Now if you use it like that, only the green line out will work. This is because Seq can not be anything other than 0 for OS X. So I change all Seq to 0 and make all Ass(ociastions) unique, except for Ass f, of which you can have as many as you'd like.
Other changes include: the green line out must be made speaker for auto switch with headphone to work, the CD-in and internal SPDIF are not integrated but jacks, and the color of the internal SPDIF and CD-in is set to black.

This results in:
CODE
Port Con[2] Loc[6] Device[4] Type[4] Color[4] Misc[4] Ass[4] Seq[4]
Node 0x11 PD 0x19431170: Jack intAT SPDIFo ATAPI Black NoPres 7 0 [Jack] SPDIF Out at Int ATAPI - Black
Node 0x14 PD 0x01114010: Jack extRear Speaker 1/8 Green Pres 1 0 [Jack] Speaker at Ext Rear - Green
Node 0x15 PD 0x01011020: Jack extRear LineOut 1/8 Black Pres 2 0 [Jack] Line Out at Ext Rear - Black
Node 0x16 PD 0x01016030: Jack extRear LineOut 1/8 Orange Pres 3 0 [Jack] Line Out at Ext Rear - Orange
Node 0x17 PD 0x01012040: Jack extRear LineOut 1/8 Grey Pres 4 0 [Jack] Line Out at Ext Rear - Grey
Node 0x18 PD 0x01a19080: Jack extRear MicIn 1/8 Pink Pres 8 0 [Jack] Mic at Ext Rear - Pink
Node 0x19 PD 0x02a190a0: Jack extFront MicIn 1/8 Pink Pres a 0 [Jack] Mic at Ext Front - Pink
Node 0x1a PD 0x01813090: Jack extRear LineIn 1/8 Blue Pres 9 0 [Jack] Line In at Ext Rear - Blue
Node 0x1b PD 0x02214050: Jack extFront HPOut 1/8 Green Pres 5 0 [Jack] HP Out at Ext Front - Green
Node 0x1c PD 0x193311f0: Jack intAt CD ATAPI Black NoPress f 0 [Jack] CD at Int ATAPI - Black
Node 0x1d PD 0x50ff01f0: No intNA Other Other Unknown NoPress f 0 [N/A] Other at Int N/A - Unknown
Node 0x1e PD 0x01456160: Jack extRear SPDIFo Optical Orange NoPress 6 0 [Jack] SPDIF Out at Ext Rear - Orange
Node 0x1f PD 0x50c001f0: No intNA SPDIFi Unknown Unknown NoPress f 0 [N/A] Speaker at Ext Rear - Black


Adding the node codec verb gives:
CODE
01471c10 01471d40 01471e11 01471f01
01571c20 01571d10 01571e01 01571f01
01671c30 01671d60 01671e01 01671f01
01771c40 01771d20 01771e01 01771f01
01871c80 01871d90 01871ea1 01871f01
01a71c90 01a71d30 01a71e81 01a71f01
01b71c50 01b71d40 01b71e21 01b71f02
01971ca0 01971d90 01971ea1 01971f02
01e71c60 01e71d61 01e71e45 01e71f01
01171c70 01171d11 01171e43 01171f19
01c71cf0 01c71d11 01c71e33 01c71f19
01d71cf0 01d71d01 01d71eff 01d71f50
01f71cf0 01f71d01 01f71ec0 01f71f50


Note, that the order has changed, because this is the order that they show up in System Profiles and I liked this order.
So, that is the codecverb that I added to the attached LegacyAppleHDAController.kext. How to do that you can find in the other guides.

Now for the pathmaps:
Go back to the codec dump. For each output pin complex look at the connections (with a star). For node 0x14, the connection is 0x0c, which is a mixer node. That node must be connected to a output node, in our case node 0x02. SPDIF outputs have no mixer node and a digital output node.
This gives us:
CODE
Node 0x11/17 (PinD) - Node 0x10/16 (OutputD) [Jack] SPDIF Out at Int ATAPI - Black
Node 0x14/20 (PinIO) - Node 0x0c/12 (MixerIO) - Node 0x02/02 (Output) [Jack] Speaker at Ext Rear - Green
Node 0x15/21 (PinIO) - Node 0x0d/13 (MixerIO) - Node 0x03/03 (Output) [Jack] Line Out at Ext Rear - Black
Node 0x16/22 (PinIO) - Node 0x0e/14 (MixerIO) - Node 0x04/04 (Output) [Jack] Line Out at Ext Rear - Orange
Node 0x17/23 (PinIO) - Node 0x0f/15 (MixerIO) - Node 0x05/05 (Output) [Jack] Line Out at Ext Rear - Grey
Node 0x1b/27 (PinIO) - Node 0x26/38 (MixerIO) - Node 0x25/37 (Output) [Jack] HP Out at Ext Front - Green
Node 0x1e/30 (PinD) - Node 0x06/06 (OutputD) [Jack] SPDIF Out at Ext Rear - Orange


For the inputs it is the other way around, start with a input node and follow the connections to the pin complex:
CODE
Node 0x18/24 (PinIO) - Node 0x26/22 (MixerI) - Node 0x09/09 (InputI) [Jack] Mic at Ext Rear - Pink
Node 0x19/25 (PinIO) - Node 0x26/22 (MixerI) - Node 0x09/09 (InputI) [Jack] Mic at Ext Front - Pink
Node 0x1a/26 (PinIO) - Node 0x23/35 (MixerI) - Node 0x08/08 (InputI) [Jack] Line In at Ext Rear - Blue
Node 0x1c/28 (Pin) [N/A] CD at Int ATAPI - Black
Node 0x1d/29 (Pin) [N/A] Other at Int N/A - Unknown
Node 0x1f/31 (PinD) - Node 0x0a/10 (InputD) [N/A] Speaker at Ext Rear - Black

The front and rear mic share the same mixer and input nodes, so only one of them can be active at the same time. This is because there are only two input nodes we can use.
You can see that node 0x07 [Vendor Defined Widget], 0x0b [Audio Mixer], 0x12 [Vendor Defined Widget], 0x13 [Vendor Defined Widget], 0x20 [Vendor Defined Widget], 0x21 [Vendor Defined Widget], 0x22 [Audio Mixer], and 0x24 [Vendor Defined Widget] are unused.
I tried to use the same nodes from line-in for cd-in, but that did not work.

For LegacyAppleHDAPlatformDriver.kext under layouts I have:
CODE
Layouts


LayoutID
888
PathMapRef


CodecID

283904136

Headphone

Inputs

LineIn
Mic

IntSpeaker

LineIn

LineOut

MuteGPIO
1

Mic

SignalProcessing

...


Outputs

IntSpeaker
Headphone
LineOut
SPDIFOut

PathMapID
888
SPDIFOut



CodecID

282984455

HDMI

Outputs

HDMI

PathMapID
282984455





Some notes here: CodecID is for ALC888. IntSpeaker is needed or else OS X will not boot. LineOut needs a MuteGPIO to get rid of a pathmap assertion error. The signal processing is for ambient noise reduction for the mic (copied from another layout). The second layout dict is for HDMI, which is not working, but this reduces the number of assertion errors.

Now for the pathmaps itself: It is layered into three levels of tags. The first level contains all the audio inputs and outputs of that pathmap. The second level groups inputs and outputs that you want to autoswitch, so I put LineOut and HeadPhones together and the two Mics. The third level is unknown, I thought it was for multichannel audio, but I did not get it to work. Then the nodes from above are contained in seperate dicts in the same order. So for digital it is only:
CODE




NodeID
30


NodeID
6






Analog nodes also have amp info for the mixer node, which I kept as standard, so for LineOut:
CODE

NodeID
20


Amp

Channels


Bind
1
Channel
1


Bind
2
Channel
2


MuteInputAmp

PublishMute

PublishVolume

VolumeInputAmp


NodeID
12


NodeID
2



Mic nodes have some extra info, ProcessingState for the signal processing, Boost for amplification and VREF for the reference voltage from the datasheet:
CODE

Amp

...

NodeID
9
ProcessingState



NodeID
34
Boost
3


NodeID
24
VREF
80



This is all the info you need to construct the LegacyAppleHDAPlatformDriver.kext attached.

Now some guides say you don't have to edit AppleHDA.kext. This is fine for analog audio as that all works. However, you can also find that digital AC-3 or DTS pass-through does not work without binary patching AppleHDA.kext. I can confirm this. So download HexEdit, find 8508EC10 and change to 8808EC10 twice for the AppleHDA binary and it works. Patched, but otherwise unmodified, 10.5.6 AppleHDA.kext attached.
Another problem is that you can only have four unshared inputs and outputs. So I commented out the pathmaps four the fourth (rear speakers) line-out and the internal SPDIF.

Ik begrijp je punt wel, maar daar gaat het net om... die specifieke SNOW zaken.
Ik heb een soortgelijke DSDT edit voor een Sigmatel 9502 (die in dell laptops zitten). Het werkt, en goed, maar de nasmaak zit er nog steeds in.

Bovendien zou ik graag de (programmeer)principes van een DSDT willen begrijpen. Niet (alleen) hoe ik fixes moet toepassen. Dat is mij vooralsnog te ondoorzichtig.