Jump to content
8755 posts in this topic

Recommended Posts

On 8/2/2020 at 4:34 PM, FredWst said:

 

@vit9696

I've found the issue, but not able to explain why...

I always made tweak DSDT and the one for my MM8,1 set ASPM in PCI space  for WIFI sleep/wake. (OC do that now but write 0x0)

 

 


  Scope (_SB)
    {
        Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            ^PCI0.RP01.ASPM = 0x41
            ^PCI0.RP01.ARPT.ASPM = 0x41
        }
*************************************

            Device (RP01)
            {
                Name (_ADR, 0x001C0007)  // _ADR: Address
                OperationRegion (LLLL, PCI_Config, 0x50, One)
                Field (LLLL, AnyAcc, NoLock, Preserve)
                {
                    ASPM,   8
                }

************************************

                Device (ARPT)
                {
                    Name (_ADR, Zero)  // _ADR: Address
                    OperationRegion (LLLL, PCI_Config, 0xBC, One)
                    Field (LLLL, AnyAcc, NoLock, Preserve)
                    {
                        ASPM,   8
                    }

 

 

 

Fred

 

Have you tried replacing 0x41 with this values: 0x40 or 0x42 or 0x43. Here you can find out more.

On 8/2/2020 at 9:28 PM, FredWst said:

 

Open a terminal

git clone https://github.com/acidanthera/OpenCorePkg.git

Go to Opencore directory just create after "git clone" launch ./build_oc.tool

Build results will be in subdirectory UDK/Build/OpenCorePkg/ -> DEBUG,NOOPT,RELEASE

Unzip OpenCore-0.6.0-xxxx.zip according to your choice.

Result will be in OpenCore-0.6.0-xxxx/Utilities/ocvalidate

 

Fred

Or use my "Bob The Builder"

  • Like 2

I just switched from Clover to OpenCore yesterday and I'm impressed. Though I really need something akin to Clover's ResetHDA functionality.

VoodooHDA doesn't cut it and has its own issues and, for obvious reasons, I'd prefer to use the native audio solution on macOS.

 

What's the best way to approach the developers on this? I'd personally try my shot at implementing it, depending on where to start.

Does it make sense to add it to OpenCore itself or is it preferred to be implemented as an EFI driver?

(Never tried EFI hacking before, though I might find a way around it).

5 hours ago, beidl said:

I just switched from Clover to OpenCore yesterday and I'm impressed. Though I really need something akin to Clover's ResetHDA functionality.

VoodooHDA doesn't cut it and has its own issues and, for obvious reasons, I'd prefer to use the native audio solution on macOS.

 

What's the best way to approach the developers on this? I'd personally try my shot at implementing it, depending on where to start.

Does it make sense to add it to OpenCore itself or is it preferred to be implemented as an EFI driver?

(Never tried EFI hacking before, though I might find a way around it).

Applealc.kext. It goes in the kexts folder and you need to use a boot arg (NvRam section) alcid=x

x being a layout ID like 1, 3, 5, 7 etc, for

most dedicated graphics cards it is 1.   
If you look in the info.plist of the alc.kext there are several options to chose for laptops and other builds.   

1 hour ago, Gigamaxx said:

Applealc.kext. It goes in the kexts folder and you need to use a boot arg (NvRam section) alcid=x

x being a layout ID like 1, 3, 5, 7 etc, for

most dedicated graphics cards it is 1.   
If you look in the info.plist of the alc.kext there are several options to chose for laptops and other builds.   

That's not the problem, I have AppleALC and the layout set up already, problem is that the sound card is quirky and needs to be reset each boot. Else I'll have to cold-boot every twice every time I want to use audio.

22 minutes ago, beidl said:

That's not the problem, I have AppleALC and the layout set up already, problem is that the sound card is quirky and needs to be reset each boot. Else I'll have to cold-boot every twice every time I want to use audio.

USB or PCI card?    If it’s USB you may want to create a ports kext.   Or make a custom DSDT.

Just been reading the Dortania guide now its updated to 0.6.0 and the first thing I noticed was...

 

Quote

Note that Ivy Bridge's iGPU is only supported up-to macOS 10.15, Catalina. Hacks for running later versions will not be covered

 

Am I totally wasting my time trying Big Sur / OpenCore with the hardware in my Signature then?

24 minutes ago, Gigamaxx said:

USB or PCI card?    If it’s USB you may want to create a ports kext.   Or make a custom DSDT.

It's PCI, and it can't be fixed via DSDT changes.

 

So, again, if any developers are reading here: What would the preferred way of implementing something like "ResetHDA" be?

22 minutes ago, D-an-W said:

Just been reading the Dortania guide now its updated to 0.6.0 and the first thing I noticed was...

 

 

Am I totally wasting my time trying Big Sur / OpenCore with the hardware in my Signature then?

Dortania contains many mis. 

In the presents time Ivy Bridge's iGPU is supported in 11.0 db3. 

But it can be deleted in the release. In the presents time we don't know as Apple will decide.

  • Thanks 1
4 minutes ago, D-an-W said:

@Andrey1970 many thanks, I will keep on setting things up then.

 

In general if I ensure all the kexts are up to date and I can boot 10.15.6 using OC 0.6.0 with no (Apparent) issues should that be enough to try installing Big Sur onto a new partition?

You shall use supported in 11.0 Mac-model, on an installation time. You can return then yours Mac-model after installation and add boot-arg: -no_compat_check

  • Like 1
  • Thanks 1

@Andrey1970 great info thanks, I recently changed my Mac Model to "Mac mini (Late 2014)" (Macmini7,1) so the Big Sur update shows up in System Preferences. Am I right in thinking then I can just leave that alone now and not use the boot-arg: -no_compat_check or would it be best to still add that for future release?

1 hour ago, D-an-W said:

@Andrey1970 great info thanks, I recently changed my Mac Model to "Mac mini (Late 2014)" (Macmini7,1) so the Big Sur update shows up in System Preferences. Am I right in thinking then I can just leave that alone now and not use the boot-arg: -no_compat_check or would it be best to still add that for future release?

Don't use -no_compat_check if you don't return on not supported model.

  • Thanks 1
2 hours ago, Andrey1970 said:

Don't use -no_compat_check if you don't return on not supported model.

 

Just installed Big Sur on a fresh partition I created on my Internal SSD and it literally installed and booted with zero errors, many thanks for the info.

11 hours ago, beidl said:

That's not the problem, I have AppleALC and the layout set up already, problem is that the sound card is quirky and needs to be reset each boot. Else I'll have to cold-boot every twice every time I want to use audio.

AppleALC implements TCSEL reset register functionality (named as ResetHDA in Clover) via alctcsel boot argument or alctcsel device property. Just inject alctcsel <01 00 00 00> into HDEF or pass alctcsel=1 via boot-args, and it should work. To debug this you can always check for "updating TCSEL register" line in the joint Lilu/AppleALC log by adding -liludbgall liludump=60 arguments and then inspecting /var/log/Lilu_x.x.x.txt file after booting macOS and waiting for 60 seconds for the file to save.

  • Like 4
  • Thanks 4
×
×
  • Create New...