Jump to content
TimeWalker75a

OSX on DELL Vostro 3450 / Inspiron N4110 / XPS L702x UEFI Clover

1,149 posts in this topic

Recommended Posts

 

Have you deleted IOWMIFamily and removed the patch to override AMW0? Because I'm not seeing any of "double" brightness changes here no matter how I adjust the backlight level. In case you still have WMIFamily installed it would generate secondary NX_BRIGHTNESS event into the system.

 

Zeroing out the string is a junkie move, the assertion is still there and you need to find the cause of it.

The assertion is produced by AppleHDAWidget::pinDefaultDeviceType() so it's something caused by the changes you made to the pinConfig (ConfigData). With my pinConfig I don't get any sound assertions. 

Sorry to miss this attention about deleting IOWMIFamily and remove the patch AMW0, now it turns out works. For the pinConfig i do modify it when update 10.9.1, revert it back from your, logs have gone.

THX again. 

Share this post


Link to post
Share on other sites
Advertisement

Yes... I see...

 

One "sanity check" you might do is extract each of your DSDT/SSDT tables from ioreg:

- run IORegistryExplorer, search for AppleACPIPlatformExpert, open "ACPI Tables" property

....

- in that directory (with only the dsdt.aml, ssdt*.aml), in Terminal: 'iasl -da *'

 

... If you get a successful load and disassembly of all the binaries, then there is no issue, but if you get errors and failure to disassemble them, you might want to look into why...

Why resort to stone age when I can just run DarwinDumper and get all of the acpi tables in a matter of 3 second (and it will decompile the tables in a common folder too, so same thing as -da happens). I'm quite aware of the IOReg technique (hence I've mentioned it as an option in my previous post). I'm more then positive the tables are ok and there won't be any issues, because if manually coded supplemental tables would have had errors then parts of the _DSM or devices wouldn't inject into the system as no External references would be met.

 

I see no reason for people trying to edit amls since I've posted both dsl tables on my git (just need to upload a separate table to add pieces of code for AMD models to disable SG and remove _DSM from IGPU). If any modifications needs to be done on these tables then dsl are freely available with no extra steps to make them compile properly.

 

 

Sorry to miss this attention about deleting IOWMIFamily and remove the patch AMW0, now it turns out works. For the pinConfig i do modify it when update 10.9.1, revert it back from your, logs have gone.

THX again. 

Good. 

 

 

codec commander is not working in lion 10.7.5

not show sound popup 

 

14. 2. 27. 오전 2:21:10.000 kernel: kxld[org.tw.CodecCommander]: The following symbols are unresolved for this kext:
14. 2. 27. 오전 2:21:10.000 kernel: kxld[org.tw.CodecCommander]: __ZN9IOService12updateReportEP19IOReportChannelListjPvS2_
14. 2. 27. 오전 2:21:10.000 kernel: kxld[org.tw.CodecCommander]: __ZN9IOService15configureReportEP19IOReportChannelListjPvS2_
14. 2. 27. 오전 2:21:10.000 kernel: Can't load kext org.tw.CodecCommander - link failed.

 

If you are trying to use any of the pre-compiled kexts - they are compiled with 10.9 SDK, so they won't work in 10.7.5. Compile from source setting appropriate SDK in Build settings. 

Share this post


Link to post
Share on other sites

Why resort to stone age when I can just run DarwinDumper and get all of the acpi tables in a matter of 3 second. I'm quite aware of the IOReg technique (hence I've mentioned it as an option in my previous post). I'm more then positive the tables are ok and there won't be any issues, because if manually coded supplemental tables would have had errors then parts of the _DSM or devices wouldn't inject into the system as no External references would be met.

The purpose is not to obtain disassembly of the tables. The purpose is to see if they all load into ACPI namespace as you intend. I realize you believe there is no issues, thus why I call this a "sanity check." It is a process by which you verify your assumption. I have tried this in a number of troubleshooting scenarios, and it is very effective.

 

If you don't want to spend the time double-checking your work, that's fine. I'm just sharing a valued technique that you might have been unaware of.

Share this post


Link to post
Share on other sites

The purpose is not to obtain disassembly of the tables. The purpose is to see if they all load into ACPI namespace as you intend. I realize you believe there is no issues, thus why I call this a "sanity check." It is a process by which you verify your assumption. I have tried this in a number of troubleshooting scenarios, and it is very effective.

 

If you don't want to spend the time double-checking your work, that's fine. I'm just sharing a valued technique that you might have been unaware of.

I've edited my message saying that DarwinDumper will do the same thing for you - it will decompile all the tables it has obtained from IOReg in a common folder, essentially performing iasl -da operation on the amls it has obtained. So you can the open them one by one and check if the integrity is ok. Opening up both custom tables with either DSDT Editor and Patcher (java based) or MacIASL results in acpi table being properly loaded into the editor, with the exception of External references being out of order so MethodObj and IntObj declarations end up above DeviceObj declarations and compile will say there's no way to access these references. 

Share this post


Link to post
Share on other sites

I've edited my message saying that DarwinDumper will do the same thing for you - it will decompile all the tables it has obtained from IOReg in a common folder, essentially performing iasl -da operation on the amls it has obtained. So you can the open them one by one and check if the integrity is ok. Opening up both custom tables with either DSDT Editor and Patcher (java based) or MacIASL results in acpi table being properly loaded into the editor, with the exception of External references being out of order so MethodObj and IntObj declarations end up above DeviceObj declarations and compile will say there's no way to access these references.

I don't think DarwingDumper uses 'iasl -da'. It is not the same to disassemble them individually as they are never all loaded into one namespace. The type of checking you get from "iasl -da" only happens because they are all loaded into the same namespace.

 

It can find things like:

- duplicate definitions of common hack utility methods (DTGP, B1B2, etc)

- duplicate definitions of devices (eg. PNLF defined in both DSDT and an SSDT)

- renames that were done in one binary, but not another (eg. GFX0 renamed in DSDT, but not in all SSDTs)

- etc

 

It is a useful "error checking" tool.

Share this post


Link to post
Share on other sites

Ok, indeed DD just performs individual decompilation of each table ("$iasl" -d "$gAMLDir"/$tbl_name.aml &> /dev/null)

I've done as suggested and result is the following (and I can't use fields from EmdebbdedController memory space without having it as external reference)

 

Loading Acpi table from file DSDT.aml
Acpi table [DSDT] successfully installed and loaded
Loading Acpi table from file SSDT-3.aml
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Loading Acpi table from file SSDT-2.aml
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Loading Acpi table from file SSDT-1.aml
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Pass 1 parse of [DSDT]
ACPI Error: [ECRM] Namespace lookup failure, AE_ALREADY_EXISTS (20130823/dswload-436)
ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20130823/psobject-304)

Share this post


Link to post
Share on other sites

Ok, indeed DD just performs individual decompilation of each table ("$iasl"[/size] -d [/size]"$gAMLDir"[/size]/$tbl_name.aml &> /dev/null)[/size]

I've done as suggested and result is the following (and I can't use fields from EmdebbdedController memory space without having it as external reference)

 

Loading Acpi table from file DSDT.aml
Acpi table [DSDT] successfully installed and loaded
Loading Acpi table from file SSDT-3.aml
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Loading Acpi table from file SSDT-2.aml
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Loading Acpi table from file SSDT-1.aml
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Pass 1 parse of [DSDT]
ACPI Error: [ECRM] Namespace lookup failure, AE_ALREADY_EXISTS (20130823/dswload-436)
ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20130823/psobject-304)

 

You should be using External(FOO, FieldUnitObj) to refer to Fields defined in an EC region in another compilation unit.

 

If you are defining new fields (eg. fields at offsets not defined elsewhere), use another declaration of the EmbeddedControl OperationRegion plus a new Field definition, both with unique names. Note that any EmbeddedControl OperationRegion must be declared in the associated EC scope.

 

Hopefully that makes sense.

Share this post


Link to post
Share on other sites

You should be using External(FOO, FieldUnitObj) to refer to Fields defined in an EC region in another compilation unit.

 

If you are defining new fields (eg. fields at offsets not defined elsewhere), use another declaration of the EmbeddedControl OperationRegion plus a new Field definition, both with unique names. Note that any EmbeddedControl OperationRegion must be declared in the associated EC scope.

 

Hopefully that makes sense.

Basically, constructs like this:

   External (_SB_.PCI0.LPCB.EC0_.ECRM) // EC 0x100 byte Memory Space
...
        // read memory ambient temperature          
        Field (ECRM, ByteAcc, Lock, Preserve)
        {
            Offset (0x5C), 
            MCPT,   8, 
        }
Should be written:

        OperationRegion (ECX1, EmbeddedControl, Zero, 0xFF)
        Field (ECX1, ByteAcc, Lock, Preserve)
        {
            Offset (0x5C), 
            MCPT,   8, 
        }
Same in the other SSDT:

            OperationRegion (ECX2, EmbeddedControl, Zero, 0xFF)
            // allow to get and set touchpad LED status from EC RAM 0x45 bit 7           
            Field (ECX2, ByteAcc, Lock, Preserve)
            {
                Offset (0x45), 
                    ,   7, 
                TLED,   1, 
            }
Note how in each case, unique names are used for the OperationRegion/Field declarations. ECX1/ECX2 are not likely used by the DSDT (you should verify).

Share this post


Link to post
Share on other sites

You should be using External(FOO, FieldUnitObj) to refer to Fields defined in an EC region in another compilation unit.

 

If you are defining new fields (eg. fields at offsets not defined elsewhere), use another declaration of the EmbeddedControl OperationRegion plus a new Field definition, both with unique names. Note that any EmbeddedControl OperationRegion must be declared in the associated EC scope.

 

Hopefully that makes sense.

A lot, actually. I was trying to supplement already defined field, I guess it goes against the spec. So I defined a new region and matching filed one with a unique name. 

 

Thing is, there are bound to be errors when simulating ACPI interpreter's work because DSDT is the same for both types of these machines, regardless of their configuration (AMD or Intel only laptops)... so External definitions in stock DELL DSDT will likely fail because there's no AmdRef or SgRef ACPI tables coming from BIOS, so arbitrary things like External (_SB_.PCI0.PEG0.PEGP.DD02) won't exist for some but will be there for the others...

SSDT-2:
        Scope (\_SB.PCI0.LPCB.EC0)
        {
            // allow to get and set touchpad LED status from EC RAM 0x45 bit 7
		   OperationRegion (ECSP, EmbeddedControl, 0x45, 0x005D)           
            Field (ECSP, ByteAcc, Lock, Preserve)
            { 
                    ,   7, 
                TLED,   1, 
            	Offset (0x5C), 
            	MCPT,   8, 
            }
        }
SSDT-1:
    External (_SB_.PCI0.LPCB.EC0_.MCPT, IntObj) // Memory Compartment Temperature

Share this post


Link to post
Share on other sites

A lot, actually. I was trying to supplement already defined field, I guess it goes against the spec. So I defined a new region and matching filed one with a unique name. 

 

Thing is, there are bound to be errors when simulating ACPI interpreter's work because DSDT is the same for both types of these machines, regardless of their configuration (AMD or Intel only laptops)... so External definitions in stock DELL DSDT will likely fail because there's no AmdRef or SgRef ACPI tables coming from BIOS, so arbitrary things like External (_SB_.PCI0.PEG0.PEGP.DD02) won't exist for some but will be there for the others...

SSDT-2:
        Scope (\_SB.PCI0.LPCB.EC0)
        {
            // allow to get and set touchpad LED status from EC RAM 0x45 bit 7
		   OperationRegion (ECSP, EmbeddedControl, 0x45, 0x005D)           
            Field (ECSP, ByteAcc, Lock, Preserve)
            { 
                    ,   7, 
                TLED,   1, 
            	Offset (0x5C), 
            	MCPT,   8, 
            }
        }
SSDT-1:
    External (_SB_.PCI0.LPCB.EC0_.MCPT, IntObj) // Memory Compartment Temperature

 

I see we had the same idea (see my post above)... In the External for MCPT, it should be FieldUnitObj, but probably both work.

 

One day, I would like to try this for the Probook or some of my other hacks, but I'm not sure how I would handle some of the patches we do. For example, to get battery status working is very invasive and does not lend towards using an SSDT or Clover patches. I'm assuming your battery code does not access any multi-byte EC registers, such that a DSDT patch is not necessary?

Share this post


Link to post
Share on other sites

I realized that I have to offset by different number .. because Offsetting 5C from 45 is not the place I want to end up :)

My battery code accessed EC registers (not SMI direct access as on most Asus for example) and I have them split into 8 bit registers down from 16 joining back with B1B2 by means of Clover patches. I basically replace ECRM with patched ECRM in DSDT and override battery device..

Share this post


Link to post
Share on other sites

I realized that I have to offset by different number .. because Offsetting 5C from 45 is not the place I want to end up :)

Yup. I figured you'd discover that when it didn't compile.

 

My battery code accessed EC registers (not SMI direct access as on most Asus for example) and I have them split into 8 bit registers down from 16 joining back with B1B2 by means of Clover patches. I basically replace ECRM with patched ECRM in DSDT and override battery device..

Curious... What kind of process do you use to create such an extensive Clover DSDT patch.

Share this post


Link to post
Share on other sites

Yup. I figured you'd discover that when it didn't compile.

 

 

Curious... What kind of process do you use to create such an extensive Clover DSDT patch.

Why wouldn't it compile? Right after I posted I realized I'd end up at 0x45+0x5C instead of *just* 0x5C.. so I changed it offset by 17 bytes and adjusted the field length accordingly. 

 

1. obtain DSDT from BIOS the way it comes bundled (no dsl-aml-dsl conversions).. get it from AIDA or any flavor of linux. make a copy for future reference 

2. using MacIASL open up the binary file and make the changes you desire one step at a time (like add certain method or change certain device), preferably

3. open up original table using any hex editor of your preferences and locate the scope you were altering .. (search by text for faster results) 

4. select the scope (a method, device or region .. altering Name entries should be done with higher range .. like if you need to change a Name or Mutex, then you'd select a method that is near by that Name entry and the entry itself), first 2 bytes before the name are usually CRC of that scope..

5. open up the binary you have edited and select same scope from there.. try replacing the scope in (3) with the scope you got here.. save the binary and see if it can be properly decompiled retaining the structure.. it's likely that it won't, because checksums won't be correct.. so you have to calculate new CRC by comparing the size of bytes (easy when you edit config with PlistEditPro.. it tells you size of Data entries) you are replacing the scope with. 

4. clover is good at adjusting CRCs when parenthesis structures are not complex, but more often then ever it fails to do so properly, so you will end up with kernel panic in regards to APCIPlatformExpert.. which is easily fixable by going to \patched from Shell and mv non_working_conig then cp working config as config.plist 

Share this post


Link to post
Share on other sites

Why wouldn't it compile? Right after I posted I realized I'd end up at 0x45+0x5C instead of *just* 0x5C.. so I changed it offset by 17 bytes and adjusted the field length accordingly.

It would not have compiled error free as the offset is beyond the bounds as specified in the OperationRegion.

0x45+0x5C is not less than 0x5d.

 

1. obtain DSDT from BIOS the way it comes bundled (no dsl-aml-dsl conversions).. get it from AIDA or any flavor of linux. make a copy for future reference 

2. using MacIASL open up the binary file and make the changes you desire one step at a time (like add certain method or change certain device), preferably

3. open up original table using any hex editor of your preferences and locate the scope you were altering .. (search by text for faster results) 

4. select the scope (a method, device or region .. altering Name entries should be done with higher range .. like if you need to change a Name or Mutex, then you'd select a method that is near by that Name entry), first 2 bytes before the name are usually CRC of that scope..

5. open up the binary you have edited and select same scope from there.. try replacing the scope in (3) with the scope you got here.. save the binary and see if it can be properly decompiled retaining the structure.. it's likely that it won't, because checksums won't be correct.. so you have to calculate new CRC by comparing the size of bytes (easy when you edit config with PlistEditPro.. it tells you size of Data entries) you are replacing the scope with. 

4. clover is good at adjusting CRCs when parenthesis structures are not complex, but more often then ever it fails to do so properly, so you will end up with kernel panic in regards to APCIPlatformExpert.. which is easily fixable by going to \patched from Shell and mv non_working_conig then cp working config as config.plist

That's what I thought you might say. Way way way too much work! If I was to do it, I think I'd write some code to automate it (give it native binary + patched binary, and have it spit out Clover patches). Also, it seems to me if something changes within the patched area in a new version of BIOS, the patch will completely break and have to be re-created again. At least source code-based patches can be applied across BIOS versions.

 

I think I'll stick with my current methods... Thanks for the detailed explanation though.

Share this post


Link to post
Share on other sites

It would not have compiled error free as the offset is beyond the bounds as specified in the OperationRegion.

0x45+0x5C is not less than 0x5d.

 

 

That's what I thought you might say. Way way way too much work! If I was to do it, I think I'd write some code to automate it (give it native binary + patched binary, and have it spit out Clover patches). Also, it seems to me if something changes within the patched area in a new version of BIOS, the patch will completely break and have to be re-created again. At least source code-based patches can be applied across BIOS versions.

 

I think I'll stick with my current methods... Thanks for the detailed explanation though.

Just tried it out of curiosity and it in fact has compiled, since 5C is not out of bound for 5D length. (it treats 0x45 as 0)

 

It's not too much work when all you need really is 5 to 6 patches.. the rest belongs in SSDTs. 

Here we need:

1. IRQs removed from TIMR and RTC reserving them for HPET, otherwise it steals from EHCI

2. Override for battery device to make registers split and join for ACP Platform to parse them

3. EC RAM 16 bit to 8 bit conversion

4. SLPE fix + added PMBase+30 region and B1B2  method all in the same patch

5. We need to wipe FOWM method clean to prevent hangs due to UEFI boot mode

6. Darwin patch patching the _INI method

7. A bunch of simple rename patches (like GFX0 to IGPU etc)

 

The rest is done externally.. 

Share this post


Link to post
Share on other sites

Just tried it out of curiosity and it in fact has compiled, since 5C is not out of bound for 5D length. (it treats 0x45 as 0)

OK. Makes sense. Brain fart for me.

 

It's not too much work when all you need really is 5 to 6 patches.. the rest belongs in SSDTs. 

Here we need:

1. IRQs removed from TIMR and RTC reserving them for HPET, otherwise it steals from EHCI

2. Override for battery device to make registers split and join for ACP Platform to parse them

3. EC RAM 16 bit to 8 bit conversion

4. SLPE fix + added PMBase+30 region and B1B2  method all in the same patch

5. We need to wipe FOWM method clean to prevent hangs due to UEFI boot mode

6. Darwin patch patching the _INI method

7. A bunch of simple rename patches (like GFX0 to IGPU etc)

 

The rest is done externally..

I just can't imagine doing it for each BIOS release and each model (which may be slightly different).

 

Just wow! No friggin' way.

Share this post


Link to post
Share on other sites

OK. Makes sense. Brain fart for me.

 

 

I just can't imagine doing it for each BIOS release and each model (which may be slightly different).

 

Just wow! No friggin' way.

No BIOS releases for well over a year now here .. and not expecting one in the distant future, so we are *safe by the bell* 

Considering majority of BIOS releases do not include changes to ACPI I wouldn't be really stressed about this .. model range is completely different story though.. but as far as ProBooks go they generally all use InsydeH20 lately, so there shouldn't be any dramatic differences in their ACPI code.. HP has payed for the platform code once, so they are interested in reusing it more than once and the more the better.. I'm speaking out of my ass now, because I haven't been around the ProBook scene so I can't really know whether it's the case, but at least that what a normal person would assume ..

 

DELL works on the cheap side of things and the entire range of Sandy Bridge laptops from different price ranges based on SecureCore Tiano generally have same ACPI tables (with the exception of Root Ports being slightly shuffled, but it's handled via SSDTs) ... so majority of the patches apply to Vostro 3450, 3750, Inspiron N4110, XPS L502, L702x, L511z and a 13" model which number I can't remember.. 

Share this post


Link to post
Share on other sites

No BIOS releases for well over a year now here .. and not expecting one in the distant future, so we are *safe by the bell* 

Considering majority of BIOS releases do not include changes to ACPI I wouldn't be really stressed about this .. model range is completely different story though.. but as far as ProBooks go they generally all use InsydeH20 lately, so there shouldn't be any dramatic differences in their ACPI code.. HP has payed for the platform code once, so they are interested in reusing it more than once and the more the better.. I'm speaking out of my ass now, because I haven't been around the ProBook scene so I can't really know whether it's the case, but at least that what a normal person would assume ..

 

DELL works on the cheap side of things and the entire range of Sandy Bridge laptops from different price ranges based on SecureCore Tiano generally have same ACPI tables (with the exception of Root Ports being slightly shuffled, but it's handled via SSDTs) ... so majority of the patches apply to Vostro 3450, 3750, Inspiron N4110, XPS L502, L702x, L511z and a 13" model which number I can't remember..

A few more BIOS updates on the ProBook side -- and the changes do often carry into ACPI. And subtle differences between models. Obviously, the older the computer gets, the time between BIOS updates increases.

 

I think maybe I purchase new computers too often to effectively implement this technique without automated tools.

Share this post


Link to post
Share on other sites

Thanks Timewalker i'm waiting ;).
I have mac 3 version except snow leopard. I'm ready to test codec commander.

 

# i builded codec commander SDK 10.8

kext loaded. but after sleep, Generate Stream is not working. so i cant use headphone

 

here is log

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: cc: --> awake
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: cc: --> hda codec power restored
14. 2. 27. 오전 9:47:36.000 kernel: Previous Sleep Cause: 5
14. 2. 27. 오전 9:47:36.000 kernel: The USB device HubDevice (Port 1 of Hub at 0x1a000000) may have caused a wake by issuing a remote wakeup (2)
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICW stored set command 1470c02
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICB was set, sending verb over the link
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: PIO operation #1
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV was set by hardware
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV cleared, allowing new commands
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICW stored set command 2170c02
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICB was set, sending verb over the link
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: PIO operation #2
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV was set by hardware
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV cleared, allowing new commands
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: cc: --> workloop started
14. 2. 27. 오전 9:47:36.000 kernel: DSP Sound assertion in DspFuncManager at line 425
14. 2. 27. 오전 9:47:36.000 kernel: DSP Sound assertion in DspFuncManager at line 1419
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: cc: --> simulate mute-unmute event
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: hi: scancode 20 in
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: hi: adb keycode 74 out
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: hi: scancode 20 in
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: hi: adb keycode 74 out
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: cc: --> simulate headphone jack event
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICW stored set command 707c0
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICB was set, sending verb over the link
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV was set by hardware
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV cleared, allowing new commands
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICW stored set command 70700
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander:  w: ICB was set, sending verb over the link
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV was set by hardware
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV cleared, allowing new commands

Share this post


Link to post
Share on other sites

Try these patches (just trim the ones you have according to this picture): http://puu.sh/7bEzO.png

 

you are a genius! That did the trick, also i was having problem with the headphone jack, didn't matter if i did the trick to send it to sleep and interrupt it after 5s, most of the time didn't work. after this fix, it's seen that now is working great so far.

 

 

 

UPD: USB3 and speaking are working perfect. but headphone doesn't work at all. it was working fine after i applied the patch for USB3 but now doesnt.

Share this post


Link to post
Share on other sites

UPD: USB3 and speaking are working perfect. but headphone doesn't work at all. it was working fine after i applied the patch for USB3 but now doesnt.

If you rebooted from windows the headphone port will be able to detect the jack, but audio won't pass through ... also, make sure you still have HDA Hardware Config in CustomPeripheral kext.

 

 

i builded codec commander SDK 10.8

kext loaded. but after sleep, Generate Stream is not working. so i cant use headphone

 

14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: rw: IRV cleared, allowing new commands
14. 2. 27. 오전 9:47:36.000 kernel: CodecCommander: cc: --> workloop started
14. 2. 27. 오전 9:47:36.000 kernel: DSP Sound assertion in DspFuncManager at line 425
14. 2. 27. 오전 9:47:36.000 kernel: DSP Sound assertion in DspFuncManager at line 1419

 

Have you built it with 10.8 SDK and trying to use it with 10.7.5? While this somewhat works, certain functions DSP functions may be different in 10.7.5, so kext will not work properly. 

Codec Commander sometimes can't recognize headphone.

 

simulate headphone is not working as default setting

So i changed value like blow.

Just read the readme on git .. if no audio stream is generated headphones won't work in any OSX version after 25 seconds after wake. In 10.9.2 headphones won't be detected after 2nd PIO is sent. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

Announcements

  • Similar Content

    • By MaLd0n
      -OpenCore Vanilla TUTORIAL-
       
       
      -USB Port Mapping TUTORIAL-
       
        1 -Create a USB bootable
       
      Create your usb installer, use this tool and download Catalina or Big Sur from Apple servers
       
      Catalina
      installScript_allfullapp.zip
       
      Big Sur
      installScript_1016fullapp.zip
       
      Credits: crazybirdy
       
      Copy Catalina / Big Sur installer to Applications folder, open terminal and run
       
      Catalina
       
       
      Big Sur
       
       
      If you want check one step by step, check here
       
      -Opencore Vanilla Tutorial
      https://tinyurl.com/ycvcnp8h
       
      2- EFI folder USB installation
       
      -EFI OpenCore Folder Desktop 10th Intel Processors
      Paste this EFI folder in EFI partition in your USB STICK
      https://tinyurl.com/ybwr9kq3
       
      -EFI Clover Folder Desktop 10th Intel Processors
      Paste this EFI folder in EFI partition in your USB STICK
      https://tinyurl.com/yxsw7d3t
       
      3- EFI folder SSD
       
      -EFI OpenCore Folder Desktop 10th Intel Processors
      Paste this EFI folder in EFI partition SSD 
      https://tinyurl.com/ybwr9kq3
       
      -EFI Clover Folder Desktop 10th Intel Processors
      Paste this EFI folder in EFI partition SSD
      https://tinyurl.com/yxsw7d3t
       
      4- Start Fine Tune
       
      Run this app and post full dump here for full ACPI solution
       
      RunMe.app
      https://tinyurl.com/y9562hz7
       
       
      If you like a SSDT way, here we go
      SSDT-OLARILA.aml.zip
       
      5- USB Solution
       
      Use these kexts, enable XHCI port limit patch
       
      USB INTEL SERIE 400.zip
       
      and follow this tutorial for remap USB ports
       
       
      --DSDT PATCHES--
       
      -FIX ERRORS AND WARNINGS -FIX ACPI ERRORS -REMOVE UNUSED SCOPES / DEVICES -HIGH PRECISION EVENT TIMER -SATA SERIE ID -DMAC -REMOVE LINES, PROBLEMATIC and UNUSED -FIX K.P in REBOOT -NVRAM -REAL TIME CLOCK -SLPB -DARWIN / WINDOWS -XHCI -PLUGIN TYPE -HDEF -ARTC -IPIC -TIMR -SBUS -BUS1 -MCHC -ALS0 -SHUTDOWN -UAR1 -LAN -FWHD -USBX -PMCR -PPMC -XSPI -kUSBCompanionIndex -io-device-location -IMEI -EC -PNLF -ARPT -GFX0 -NVME -ACPI-WAKE-GPE -DTGP -HDMI / HDAU  
      --SCREENSHOTS--































      -If you want to buy me a beer - Donations with PayPal
      https://tinyurl.com/r2bvzm7
       
      Big Thanks to XLR and your Badass Motherboard, Ultrafast CPU, Coolest Heatsink, Huge Graphics Card, Tonnes of RAM,
      Gigantic Hard Drive, Lightspeed Disk Burner, Professional Sound Card, Massive LCD Display.
       
       
      -Credits and thanks to the old and new people in the community who developed patches, kexts and bootloaders!
      Slice, Kabyl, usr-sse2, jadran, Blackosx, dmazar, STLVNUB, pcj, apianti, JrCs, pene, FrodoKenny, skoczy, ycr.ru, Oscar09, xsmile, SoThOr, RehabMan, Download-Fritz, Zenit432, cecekpawon, Intel, Apple, Oracle, Chameleon Team, crazybirdy, Mieze, Mirone, Oldnapalm, netkas, Elconiglio, artut-pt, ErmaC, Pavo, Toleda, Master Chief and family, bcc9, The King, PMheart, Sherlocks, Micky1979, vit9696, vandroiy2013, Voodoo Team, Pike R. Alpha, lvs1974, Austere.J, CVad and many, many, many others!

      We're all here to have fun and learn from each other!
    • By Nomade
      Hello All,
       
      It's been a while that I am trying to update my system to 10.15.16.
      The install seem to start, then at reboot time I only see the Normal boot and the Recovery option from the Clover boot menu.
      None of those 2 allow to complete the update.
       
      Is there any ways to force it to install and/or show the "Update" option on the Clover boot screen?
       
      PS: I'm using Z97-Gaming-3
    • By Damx
      The specs CPU: Intel® Core™ i3 Processor 8130U, 2.20 GHz (Kaby Lake Refresh) Chipset: Intel® 300 Series Graphics: Intel® UHD Graphics 620 Display: 21.5'' 1920x1200 RAM: DDR4 PC2400 4GB SSD1: M.2 PLEXTOR (with original Windows 10) SSD2: SATA SAMSUNG 850 EVO (for macOS) Sound: Realtek ALC269 WiFi / BT: Intel 3168 NGW Realtek Card-reader  
       
      Not working
      WiFi: Intel 3168 NGW Realtek Card-reader  
       
      Pre-Installation
       
      I will not go through the basics since it is explained in details here on this site. Briefly, the process is to:
      Get Clover Get Catalina macOS installer Create USB with 2 MBR partitions (FAT32 for Clover and HFS+J for the installer)  
       
      Required kexts
      AppleALC.kext Lilu.kext RealtekRTL8111.kext VirtualSMC.kext WhateverGreen.kext  
       
      Config.plist
      I used the one provided by RehabMan called config_HD615_620_630_640_650.plist. Download it from GitHub. It has almost everything you will need with only few edits for audio.
      Edits:
      [CPU] Make sure there is lilcpu=9 setting in boot arguments needed for Kaby Lake R CPU to be recognised correctly. [GPU] Make sure there is a patch GFX0 to IGPU under ACPI->DSDT [GPU] Under Devices->Properties->PciRoot(0)/Pci(0x02,0) make sure that the AAPL,ig-platform-id value is 00001B59, and the device-id value is 16590000 [AUDIO] Under Devices->Properties->PciRoot(0)/Pci(0x1f,3) set the layout-id to 40 and the device-id to 70A10000 [SMBIOS] Set Mac model ID is iMac19,2  

       

       
      Notes
      For some reason with latest version of Clover the install partition was not visible. If you run into the same issue you can downgrade Clover to r5103, which worked perfectly. WiFi / BT Intel 3168 NGW needs to be replaced if one needs WiFi. Someone mentioned that to get HDMI work properly you may need to change AAPL,ig-platform-id value to 00001659 for PciRoot(0)/Pci(0x02,0) - not my case but may be considered if you get this issue. Don't forget to generate your serial and other SMBUS values before signing in with iCloud services.  
       
    • By MaLd0n
      A very custom DSDT for best experience under macOS. Removed all unused devices, injected all Apple devices, essentials, cosmetics, real improvements. 
       
      -OpenCore Vanilla TUTORIAL-
       
       
      -USB Port Mapping TUTORIAL-
       
          -Original DSDT have 167,880 lines and 762kb
       
      DSDT ORIGINAL.aml.zip138.01 kB · 8 downloads
       
      -Patched DSDT have 30,912 lines and 111kb
       
      DSDT PATCHED.aml.zip27.01 kB · 17 downloads
       
      --Hardware--
      Asus ROG RAMPAGE VI EXTREME OMEGA

      Processor  Intel i9-10980XE

      GPU Radeon RX 5700 XT

      --DSDT Patches--
      -FIX ERRORS AND WARNINGS -FIX ACPI ERRORS -REMOVE UNUSED SCOPES / DEVICES -HIGH PRECISION EVENT TIMER -SATA SERIE ID -DMAC -REMOVE LINES, PROBLEMATIC and UNUSED -REAL TIME CLOCK -SLPB -DARWIN / WINDOWS -XHCI -PLUGIN TYPE -HDEF -ARTC -IPIC -TIMR -SBUS -BUS1 -MCHC -ALS0 -SHUTDOWN -UAR1 -LAN -FWHD -USBX -XSPI -EC -PNLF -ARPT -GFX0 -NVME  
      --Screenshots-



















       
      -Credits and thanks to the old and new people in the community who developed patches, kexts and bootloaders!
      Slice, Kabyl, usr-sse2, jadran, Blackosx, dmazar, STLVNUB, pcj, apianti, JrCs, pene, FrodoKenny, skoczy, ycr.ru, Oscar09, xsmile, SoThOr, RehabMan, Download-Fritz, Zenit432, cecekpawon, Intel, Apple, Oracle, Chameleon Team, crazybirdy, Mieze, Mirone, Oldnapalm, netkas, Elconiglio, artut-pt, ErmaC, Pavo, Toleda, Master Chief and family, bcc9, The King, PMheart, Sherlocks, Micky1979, vit9696, vandroiy2013, Voodoo Team, Pike R. Alpha, lvs1974, Austere.J, CVad and many, many, many others!

      We're all here to have fun and learn from each other!
    • By MaLd0n
      -OpenCore Vanilla TUTORIAL-
       
       
      -USB Port Mapping TUTORIAL-
       
          -Wifi card has been replaced with Dell DW1560!
      -I'm using a S145 Model with Intel Core i5-1035G1 IceLake / Intel HD Graphics ICL
      -Update bios/uefi to last version 
       
      *For now we have 2 problems. Wake from sleep and some bugs in trackpad*
       
      --Bios/UEFI config--
      Go to Security tab and disable Secure boot
       
      -IceLake Premade installation Folder (easy way installation)
      https://tinyurl.com/y3tl6xlx
       
      --Clover and OpenCore Folders--
      Just paste EFI folder inside EFI partition
      -OpenCore
      https://tinyurl.com/y3c4rjkr
      -Clover
      https://tinyurl.com/y4496nq8
       
      --Enable Trackpad Dragging Option--
      Go to System Preferences/Accessibility/PointerControl/Trackpad Options and "Enable dragging"

      -Bluetooth Broadcom
       
      BrcmBluetoothInjector.zip2.46 MB · 4 downloads
       
      -OcQuirks.efi for Clover (Just replace Drivers folder)
       
      drivers.zip74.57 kB · 4 downloads
       
      --DSDT Patches--

      -Patches
      -FIX ERRORS AND WARNINGS -REMOVE UNUSED SCOPES / DEVICES -HIGH PRECISION EVENT TIMER -SATA SERIE 12 ID -DMAC -REMOVE LINES, PROBLEMATIC and UNUSED -SLPB -DARWIN / WINDOWS 2015 -XHCI -PLUGIN TYPE -HDAS to HDEF -HDEF -REAL TIME CLOCK -ARTC -IRQs -SBUS -BUS1 -MCHC -ALS0 -SHUTDOWN -FWHD -USBX -PMCR -PPMC -XSPI -GMM -IMEI -EC -PRWs -_DSMs -PNLF -BRIGHTNESS KEYS -I2C -NATIVE USB -ARPT -GFX0 -DTGP -ACQUIRE MUT0 0XFFFF -OPERATION REGION GPIO -MUTEX MUT0 0x00 -EXTERNAL REFERENCES -UNKNOWNOBJ -FULL RENAMED DEVICES   --IGPU Patch-- (All credits to Austere.J) Discussion about that HERE
       
      <key>PciRoot(0x0)/Pci(0x2,0x0)</key>             <dict>                 <key>AAPL,ig-platform-id</key>                 <data>AABSig==</data>                 <key>device-id</key>                 <data>UooAAA==</data>                 <key>framebuffer-fbmem</key>                 <data>AACQAA==</data>                 <key>framebuffer-patch-enable</key>                 <data>AQAAAA==</data>                 <key>framebuffer-stolenmem</key>                 <data>AAAwAQ==</data>                 <key>framebuffer-unifiedmem</key>                 <data>AAAAgA==</data>                 <key>hda-gfx</key>                 <string>onboard-1</string>                 <key>igfxfw</key>                 <data>AgAAAA==</data>             </dict>  
      --USB Fix-- https://tinyurl.com/y4mqfahz
       
      -ScreenShots

       


























      -Credits and thanks to the old and new people in the community who developed patches, kexts and bootloaders!   Slice, Kabyl, usr-sse2, jadran, Blackosx, dmazar, STLVNUB, pcj, apianti, JrCs, pene, FrodoKenny, skoczy, ycr.ru, Oscar09, xsmile, SoThOr, RehabMan, Download-Fritz, Zenit432, cecekpawon, Intel, Apple, Oracle, Chameleon Team, crazybirdy, Mieze, Mirone, Oldnapalm, netkas, Elconiglio, artut-pt, ErmaC, Pavo, Toleda, Master Chief and family, bcc9, The King, PMheart, Sherlocks, Micky1979, vit9696, vandroiy2013, Voodoo Team, Pike R. Alpha, lvs1974, Austere.J, CVad, Sampath007, onemanosx, erroruser, Jenny David, Acidanthera Team, Olarila Facebook Community, Hackintosh Facebook Community and many others!     We're all here to have fun and learn from each other!
×