Gyógyulok! Már 4h-n keresztül fenn tudok maradni, de amikor ezeket a sorokat írom kicsit azért már ki vagyok merülve, pedig, csak 16:00 van.
Nos, pár hete már örömmel jelentettük, hogy a WX58BP-s MOBO-val megáldott Elfyre sikeresen felszármazott az SL RETAIL. Akkor egy HPET kapcsoló probléma volt az amiért nem futottunk azonnal rendben, mert nem voltak láthatóak a HDD-k és am-block az a Bridge ahová a HDD-k vannak kötve. Az érdekes az volt, hogy a HPET bekapcsolással és a "standard" kext-ekkel megoldódott a dolog.
A HDAenabler és társai
Alapvetően az volt a gáz, hogy Elfy SL nem volt hajlandó tudomást venni arról, hogy egy integrált - a 82801IJR [ICH10R] hez - kötött Realtek ALC 889-es un. HDA adaptert kéne érzékelnie.
A sok nem egyértelmű infó alapján az jött ki, hogy az alábbi lehetőségek vannak
- HDAenabler.kext jön és egy megfelelően konfigurált LegacyHDA.kext. Ahol egyébként minden féléket értekeznek arról, hogy az AppleHDA.kext-et pedig jobb kidobni, mert conflict lesz. De persze a MEGFELELŐEN konfigurált fontos. És ha az ember már belenézett a codec infóba (ld.:alább) akkor gyorsan rájöhet, hogy hiába prábálgatod a kombinációkat, ha egyszer az egyik sem értekezik arról hogy 283904137! No, bezzek a 33-végűt!
- AppleHDA.kext full felforgatás, melynek alapja jó öreg linux kernelhez meglevő megfelelő driver. ( Szó se róla, de Win7-es vagy XP-s is megteszi csak az macerásabbnak tűnik, főleg ha azt is számba vesszük, hogy fel kell tenni a win-t) Itt a lényeg, hogy legyünk iszonyat okosak. Olvassuk el az intel speckóját a HDA-ról. Aztán a lekért codec infó alaján rakjuk össze az új config állományokat. Először fejtsünk PinConfigDefaultokat per NID és utána meg fejtsünk connectionokat. Ez mind jó és szép, csak éppen nem biztos, hogy kisegít akkor, ha még a bus végén nem látszik az eszköz. De azért belemélyedni nem rossz reverse-engineering feladat, mondanom sem kell. Azonban a negyedik leírás után feltűnt az is, hogy egyesek nekikeztdtek értekezni a DSDT manipulácó szükségességéről.
Az a vicces hogy az 1. szám alatt azért nem beszélnek ilyenekről, mert biztosak abban, hogy valamelyik kész pack-al dolgozik a lamaHSX tulaj. Pedig most nem. Mert ugye a WX58BP az meglehetősen NEM Gigabyte!
Ugyanakkor meg az is feltűnt, hogy számos nem teljes leírással találkoztam. - VoodooHDA.kext - Na ja! Legalább 64bites! Ezt elvileg fel kell tenni, oszt megy. Na persze, hogy nem ment, mert a DSDT hack azért kell, és nem lehet mindent kext-ekkel megoldani. A boot.plist injectiont meg nem szeretik az egyesek. Pedig próbának jó lenne az is. És ez sem feltétlen tud mindent alapból megoldani.
Hogyan is...
Nos, kérem volt itt minden, és már nagy elkeseredés is, amin persze felül kell emelkedni azzal, hogy nem igaz, hogy nem. Még akkor sem, ha egyesek azt mondják, hogy 0x10EC0889 -» 283904137 VendorID-seszköznek nincs natív dirivere.
Az 1.-es felmérésekből azt megtudtam az indsanelyMac-ről indulva, hogy HDAEnabler-nékül nem látszik az audió eszköz egyáltalán. És még ha vele látszik is, a SystemProfiler-ben, attól még nincs kapcsolva hozzá eszköz, ami szólna. Azzonban így nagyon szépen látszott az is hogy az ATI Videókártyának is lenne HDMI kimeneten keresztü audiója. De hiába a lenne, ha egyszer ninics. Ha nincs HDAEnabler akkor semmi nem látszik.
Azonban a IORegistryExplorer ( ez azért vicces, mert vagy XCode packból instalálja az ember, vagy DSDTSE-ből indítja, mert a packban benne vgyon) szépen mutatta, hogy nincs egyáltalán HDA komponens a PCI buszon. Ez tök jó. De akkor mi legyen? A 2.-es full pach doksikból az derült ki, hogy szeretem nem, Ők biza DSDT-t pach-elnek. Ugye ez a BIOS inject. Na az király mert nekem nem volt egyáltalán. Ugyanakkor az tuti volt hogy valami ezen a tályon bibis, mert a lekérdezett DSDT adatok alapján az 1B alatt az AZAL device ült. Ami nem tom mi. De az biztos, hogy ott HDEF-nek kéne lennie. Na jó. Először ki kellett próbálni, hogy a kinyert és fordított DSDT.aml-el ugyan úgy megy-e minden mint eddig. Ment. Utána egy hitelesnek tűnő forrásból kiemelt snipet-el le kellett váltani a AZAL bejegyzést a HDEF-re. Továbbá mint kiderült, mert egyébiránt a DSDT compiler is visit az Error miatt be kellett inject-álni egy nem mejegyzett un. Methodot ( Ha egyébként közvetlen behúzom a HDEF alá a pinconfigot akkor ez lehet nem kellett volna, de ezt már nem tudjuk meg! )
Device (HDEF)
{
Name (_ADR, 0x001B0000)
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x04)
{
"layout-id",
Buffer (0x04)
{
0x0C, 0x00, 0x00, 0x00
},
"PinConfigurations",
Buffer (Zero) {}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}Method (DTGP, 5, NotSerialized)
Na persze, a AZAL-os hivatkozást, mely a DSDT elején van, szintén le kell cserélin ahhoz, hogy ne kapjunk compile errort! A method meg állítólag a /WAK elé kell keüljön. Én csak beraktam érzésre. A lényeg, hogy átment a cucc, és le is fordult aml-re, ami a helyére került. Eredmény, hogy HDAEnabler nélkül látszik az hogy van egy HDEF eszközünk. Ez jó hír. Cserébe nem látszik az ATI HDMi és egyáltalán nem látszik audió eszköz. Ami látszik az a IOPropertyExplorerben látszik!!!
{
If (LEqual (Arg0, Buffer (0x10)
{
/* 0000 */ 0xC6, 0xB7, 0xB5, 0xA0, 0x18, 0x13, 0x1C, 0x44,
/* 0008 */ 0xB0, 0xC9, 0xFE, 0x69, 0x5E, 0xAF, 0x94, 0x9B
}))
{
If (LEqual (Arg1, One))
{
If (LEqual (Arg2, Zero))
{
Store (Buffer (One)
{
0x03
}, Arg4)
Return (One)
}
If (LEqual (Arg2, One))
{
Return (One)
}
}
}
Store (Buffer (One)
{
0x00
}, Arg4)
Return (Zero)
}
Persze a AppleHDA visít boot-kor, hogy szállnak el a kódok, de az mind1. Ekkor gondolkodtam, hogy most akkor menjek tovább: 1 vagy 2 vagy 3 út!
Visszamentem a kájhához azaz a compatibilty list-hez a wikiben. Egy x58-as MOBO-volt, mégpedig a DX58SO! Megnéztem Inteléknél mit is jelentez pontosan audió fronton és szerencsémre megegyezett a WX58BP-vel! A listben pedig azt írták, hogy a VoodooHDA-val ment az audió.
Nohát akkor nosza! De hogyan is kell feltenni a cuccot. Erről a project google code oldalán bőszen hallgatás van. Hiába raktam be a kext-et a boot Extrák közé, dobálta a faultokat vagy nem csinált semmit. Próbáltam kextload-ni a cuccot, de valamiért ehhez még nem vegyok elég nagy. Azért gondoltam, ne már! Beraktam, kiraktam, forgattam a Extension cachet, bootoltam, és nem! Már könyékig túrtam a sys és kernel logot, de semmi extra. Gondoltam, nehogy már most OSX alatt kernel log levelt kelljen módosítani...
NEM! Internet: nem igaz, hogy ennyi user, ne találkozott volna a problémával. És persze, hogy de. Ugyanakkor nem volt egyszerű a story. A google végül egy elég specifikus kérdésre kidobta a voodooproject egyik fórum oldalát és lőn egy megérzés és próba!
hi people !
been fighting with this issue too for a while now (in order to get a full retail installation with all "iHack" stuff located in /Extra/ folder), and finally made it work doing theses steps :
- add "<key>OSBundleRequired</key><string>Root</string>" to VoodooHDA.kext info.plist
- copy vanilla dependencies (both IOAudioFamily.kext & OSvKernDSPLib.kext) to /E/E/ folder
- add "<key>OSBundleRequired</key><string>Root</string>" to their info.plist and the first one's plugin info.plist
- chmod -R 755 & chown -R root:wheel /E/E/ & /S/L/E/
- rm -R /S/L/E.*
- reboot using -v & -f flags (just in case & to see what's going on ...)
should work (it actually did on my rig, whereas I had to put VoodooHDA.kext into /S/L/E/ before) ...
Fogtam és megcsináltam, mert azt kurkásztam ki a Voodoo forrásaiból, hogy mennie kell a cuccnak:
- AppleHDA kinyírás mikor még felraktam a helyére a VoodooHDA-t! Felraktam a VoodooHDA.prefPlanet és a voodoohdahelper-t. ( ez utóbbi a -dump al dobott egy csúnya futási hibát azzal, hogy nincs is node
- Voodoo módosítás
- IOAudioFamily.kext & OSvKernDSPLib.kext bemásolás Extra/Strored_Kexts alá! ( Én a X58-as combo installerrel updateolok cache-t és ott ez a neve defaultból a injetion koönyvtárnak. Alatta van egy System alá másolt könyvtár is. Ezért külön chmod és rm nem kell! )
- reboot
ÉS Királyság van! Megszólalt Elfy! :D
Lehet ugyan, hogy DSDT patch nélkül is ment volna, ha törlöm az AppleHDA és az AppleAZALIA kexteket, de mostmár mind1. A lényeg, hogy szól!
System Profiler-ben Audió alatt csak a host controller látszik. De a sound alatt van device és a VoodooHDA controller sem száll el!
Ez hosszú menet volt!
Már csak egy ethernet kontrollert kell megoldani és készen is lennénk.