[pre-release] macOS Big Sur

[mnfesq]

6 minutes ago, valeryimm said:

Hi, is your HP Envy with the touchscreen? Did you use I2C kext?

Also, in DSDT do you have GPI0 device? Cause in my HP Envy this device is missing.

 

My HP Envy 17 does not have a touchscreen - it has the UHD resolution.  With my model, it's one or the other.  I need to use the VoodooI2C.kext or I cannot see my internal drives.  My DSDT has 11 references to GPI0 but it does not appear as a separate device.  While GPI0 is not a device in your DSDT, does it show up when you do a word search?  I should mention that I am using Clover to boot, not OC, and that the problems I reported earlier regarding a lack of kext injection was resolved by booting to an installation of BS on a USB drive and then rebuilding kextcache using Hackintool and then repairing permissions and rebuilding kextcache on my SSD and HDD installations of BS.  Apparently, with Clover, it is really important to have a good kextcache before rebooting.  

[valeryimm]

18 minutes ago, mnfesq said:

 

My HP Envy 17 does not have a touchscreen - it has the UHD resolution.  With my model, it's one or the other.  I need to use the VoodooI2C.kext or I cannot see my internal drives.  My DSDT has 11 references to GPI0 but it does not appear as a separate device.  While GPI0 is not a device in your DSDT, does it show up when you do a word search?  I should mention that I am using Clover to boot, not OC, and that the problems I reported earlier regarding a lack of kext injection was resolved by booting to an installation of BS on a USB drive and then rebuilding kextcache using Hackintool and then repairing permissions and rebuilding kextcache on my SSD and HDD installations of BS.  Apparently, with Clover, it is really important to have a good kextcache before rebooting.  
 

Now I also use VoodooI2C kext to see internal SATA drives. Hopefully the will fix this issue in the next betas. I do not have separate GPI0 device itself in my DSDT. But my laptop has both: touchscreen and UHD resolution on Intel Iris HD 540. Do you get you IGPU fully working on BS?

Now I am trying to get my wifi working , I have DW1560 card.

[Jake Lo]

21 hours ago, markl18 said:

hi if anybody has a tpl0 device can anybody get this compiled

SSDT-TPL0.dsl

file will compile if you remove these 2 lines

 0x0032,
 }
 

[markl18]

Just now, Jake Lo said:

file will compile if you remove these 2 lines

 0x0032,
 }
 

I think they are very essential the other I don't know about 

Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, )
                        {
                            0x00000022,
                        }
 

[mnfesq]

4 minutes ago, valeryimm said:

Now I also use VoodooI2C kext to see internal SATA drives. Hopefully the will fix this issue in the next betas. I do not have separate GPI0 device itself in my DSDT. But my laptop has both: touchscreen and UHD resolution on Intel Iris HD 540. Do you get you IGPU fully working on BS?

Now I am trying to get my wifi working , I have DW1560 card.

 

As @markl18 pointed out, the actual GPI0 device may have a different name in your DSDT.  Mine are TPD0 and TPL1.  I don't think this is a bug.  I think that using I2C to read SATA drives is a more modern method and AHCI may get phased out.  Not really sure about that.

 

I do have full function of IGPU.  I only wish I could use my dGPU but it is disabled in the BIOS.  I believe I have the DW1560 wifi/BT card and it is working fine with this kext version.

 

Wifi for BigSur.zip

[markl18]

4 minutes ago, mnfesq said:

 

As @markl18 pointed out, the actual GPI0 device may have a different name in your DSDT.  Mine are TPD0 and TPL1.  I don't think this is a bug.  I think that using I2C to read SATA drives is a more modern method and AHCI may get phased out.  Not really sure about that.

 

I do have full function of IGPU.  I only wish I could use my dGPU but it is disabled in the BIOS.  I believe I have the DW1560 wifi/BT card and it is working fine with this kext version.

 

Wifi for BigSur.zip

do they have something altered in them or it is just freshly compiled because I got my compiled at 3:55

 

[iGPU]

6 hours ago, eSaF said:

Yea if your finding is correct with Clover, then there is something flaky with or a misconfiguration in Opencore causing the BS disk not to show in the Startup Disk section in System Preferences. It has been a daily task of mine trying to find out why and I've yet to track it down. 

 

I still think this is how OC is dealing with new APFS partitions in BigSur, and why we're having problems with getting Recovery to work properly. BigSur has changed something in APFS so that OC isn't properly working (and why disks are disappearing when using Startup Disk section).

 

According to OC docs, 0x00000100 — OC_SCAN_ALLOW_FS_APFS should work with an APFS partition, but it does not. We must set ScanPolicy to 0 to get into BigSur Recovery (and even then disabling csrutil doesn't seem to 'stick' on re-boot). [Usual OC settings do get into Catalina Recovery, just not BigSur Recovery.]

[Jake Lo]

17 minutes ago, markl18 said:

I think they are very essential the other I don't know about 

Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, )
                        {
                            0x00000022,
                        }
 

I don't know where you grab the codes from, but those lines don't belong there is what I'm saying.

[valeryimm]

24 minutes ago, mnfesq said:

 

As @markl18 pointed out, the actual GPI0 device may have a different name in your DSDT.  Mine are TPD0 and TPL1.  I don't think this is a bug.  I think that using I2C to read SATA drives is a more modern method and AHCI may get phased out.  Not really sure about that.

 

I do have full function of IGPU.  I only wish I could use my dGPU but it is disabled in the BIOS.  I believe I have the DW1560 wifi/BT card and it is working fine with this kext version.

 

Wifi for BigSur.zip

Did you use DeviceProperties injection for your pci wifi card as some guys recommend?
My wifi still doesn’t work. My I2C device TPL1

Edited July 28, 2020 by valeryimm

[markl18]

6 minutes ago, mnfesq said:

9 minutes ago, Jake Lo said:

I don't know where you grab the codes from, but those lines don't belong there is what I'm saying.

this is the original in DSDT and then this prog i2c rewrites according to voodoo author daud spec

 

 Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
                {
                    Name (SBFI, ResourceTemplate ()
                    {
                        I2cSerialBusV2 (0x0010, ControllerInitiated, 0x00061A80,
                            AddressingMode7Bit, "\\_SB.PCI0.I2C1",
                            0x00, ResourceConsumer, , Exclusive,
                            )
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0032
                            }
                        Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, )
                        {
                            0x00000022,
                        }
                    })
                    Return (SBFI)
                }

20 minutes ago, iGPU said:

 

I still think this is how OC is dealing with new APFS partitions in BigSur, and why we're having problems with getting Recovery to work properly. BigSur has changed something in APFS so that OC isn't properly working (and why disks are disappearing when using Startup Disk section).

 

According to OC docs, 0x00000100 — OC_SCAN_ALLOW_FS_APFS should work with an APFS partition, but it does not. We must set ScanPolicy to 0 to get into BigSur Recovery (and even then disabling csrutil doesn't seem to 'stick' on re-boot). [Usual OC settings do get into Catalina Recovery, just not BigSur Recovery.]

if you use disk utility to see the new partition hfs+ jornaled their is a tiny partition there that's looks empty but there for some nefarious reason created by Big Sur so yes something has been drastically altered

[valeryimm]

1 hour ago, markl18 said:

https://github.com/VoodooI2C/VoodooI2C read it

Where can I get I2C app for ssdt-tab0 generation, cause I didn’t see it in VoodooI2C manuals?

[markl18]

3 minutes ago, valeryimm said:

Where can I get I2C app for ssdt-tab0 generation, cause I didn’t see it in VoodooI2C manuals?

just google i2c. app Hackintosh the first thing that comes up is this

https://github.com/VoodooI2C/VoodooI2C

[Jake Lo]

@markl18

 

Now it compiles

SSDT-TPL0.dsl.zip

[mnfesq]

@markl18 and @valeryimm, here is the wifi kext that worked for me.  It may be that the newest compilations have all the changes that are in this compilation made on July 16th.  All I know is that it works for me.

 

 

[SavageAUS]

@MICKHAEL This is the EFI i use now for Big Sur, Catalina, Windows 10 and Arch Linux.

I have removed my serials etc and audio files.

EFI-i7-9750H-Laptop.zip

[htanh034]

I installed beta 3 successfully on my computer but black screen for a while after boot, I had to press ESC for a while (30s) to go to the login screen (MSI RX 5500 XT)

My EFI: https://drive.google.com/file/d/1Ls62lTinMCi9Hd84D0FlJh9rsgXBeo7O/view?usp=sharing

PC: Msi B450 Tomahawk Max, Ryzen 5 3600, Msi Rx 5500 XT 8G Gaming X, RAM 16G, Ethernet Realtek RTL 8111, Audio Realtek ALC892, MacOS 10.16 Beta 3, Opencore 0.6.0 (method USB Installer)

[TrickyHunter]

So I have OpenCore 0.5.9 working perfectly on Catalina 10.15.6 and decided to try out Big Sur on a separate SSD.

 

OpenCore 0.6.0 built from source together with kexts:

• AppleALC
• BrcmPatchRam
• Lilu
• VirtualSMC + vsmcgen=1 (or FakeSMC)
• WhateverGreen
• NVMeFix

Kexts and other configs are exactly the same as 0.5.9 on Catalina.

 

The installer boots and install without issues.

 

Now after the install, it boots (progress bar completes) but stays in black screen on all my 3 monitors. I have iGPU enabled but NOT connected to any monitor. It's the 5700 XT that's driving the displays.

 

The weird thing is that in 10 boots, there could be one that ends up working lol. I've had twice happen to me.

 

I haven't tried beta 2 or 1 not sure if it'd make a difference. I have 9700k and 5700 XT here.

 

Any help would be appreciated. Otherwise I'll wait for beta 4.

Edited July 29, 2020 by TrickyHunter

[jmacie]

@TrickyHunter

I'm pretty sure without specs in your sig you aren't going to get much help, as noone really knows what you're using besides cpu and gpu, imo

 

[TrickyHunter]

56 minutes ago, jmacie said:

@TrickyHunter

I'm pretty sure without specs in your sig you aren't going to get much help, as noone really knows what you're using besides cpu and gpu, imo

 

 

Thanks for the tip mate. Added some of my spec in the signature.

[markl18]

also does any one know why the video and the mouse are so retartedly slow in bs is it because I have no metal 

[markl18]

I know this is probably of topic but same thing here I tried to save the file one way and it keeps on changing _SB to _SB_ please does any one has any kind of idea @Jake LoJake

*/
DefinitionBlock ("", "SSDT", 2, "hack", "IGPU", 0x00000000)
{
    External (_SB.PCI0.IGPU, DeviceObj)    // (from opcode)

    Scope (_SB.PCI0.IGPU)
    {
        OperationRegion (RMP1, PCI_Config, Zero, 0x14)
        Field (RMP1, AnyAcc, NoLock, Preserve)
        {
            Offset (0x02), 
            GDID,   16, 
            Offset (0x10), 
            BAR1,   32
        }Untitled.heic

Edited July 29, 2020 by markl18

[markl18]

On 7/25/2020 at 8:11 AM, crazybirdy said:

 

I get this stupid issue "Couldn't alloc class "AppleIntelPchSeriesAHCI"  " with OC and Clover 5120.

But Clover 5119 mod pass this issue.

hi how did you get out of this problem by the way I am smack in the middle of it I got ssd-tpl0 and voodoocelan.kext finally to be excepted bu than this error

[Montblanc]

6 hours ago, eSaF said:

@eSaF

3. Now this is the strangest one I found, the injected SmUUID you formulated and injected into the config.plist is completely changed to another value, this only happened with Beta3 and I cannot fathom why - Use Hackintool/System/System ID to verify whether it is just my system.

 

Yes, same here on both Hacks. Very odd

[mnfesq]

4 minutes ago, markl18 said:

hi how did you get out of this problem by the way I am smack in the middle of it I got ssd-tpl0 and voodoocelan.kext finally to be excepted bu than this error

 

When I got the "Couldn't alloc class "AppleIntelPchSeriesAHCI", it meant one of two things:  Either VoodooI2C.kext was not loading or that I was not getting any kext injection and there were many other "Couldn't alloc class" errors.  Our hardware is different and I don't need that SSDT you have, nor do I have an I2C trackpad.  However, I did figure out that my kext injection issues resulted from the fact that Big Sur really likes having kext caches and the more you tinker with your system, the more important it is to "repair permissions" and rebuild the kernel cache.  Now, that's easy for a system that boots because you can do it from within the system using something like Hackintool but it's much harder to do it on an installation that can't boot.  I use KCPM Utility Pro but I'm sure that you can just find the right terminal commands to do it as well.  But the catch for me was that rebuilding the kext cache for Big Sur didn't work right when I built it in Catalina.  I had to get into a Big Sur installation and rebuild it there.  I managed to boot to a USB drive with Big Sur on it and used that to rebuild kext caches on Big Sur installations on my internal SSD and HDD.  

 

Also, are you sure you need that SSDT for your I2C device?  Doesn't your own DSDT already map the device? 

[markl18]

14 minutes ago, mnfesq said:

 

When I got the "Couldn't alloc class "AppleIntelPchSeriesAHCI", it meant one of two things:  Either VoodooI2C.kext was not loading or that I was not getting any kext injection and there were many other "Couldn't alloc class" errors.  Our hardware is different and I don't need that SSDT you have, nor do I have an I2C trackpad.  However, I did figure out that my kext injection issues resulted from the fact that Big Sur really likes having kext caches and the more you tinker with your system, the more important it is to "repair permissions" and rebuild the kernel cache.  Now, that's easy for a system that boots because you can do it from within the system using something like Hackintool but it's much harder to do it on an installation that can't boot.  I use KCPM Utility Pro but I'm sure that you can just find the right terminal commands to do it as well.  But the catch for me was that rebuilding the kext cache for Big Sur didn't work right when I built it in Catalina.  I had to get into a Big Sur installation and rebuild it there.  I managed to boot to a USB drive with Big Sur on it and used that to rebuild kext caches on Big Sur installations on my internal SSD and HDD.  

 

Also, are you sure you need that SSDT for your I2C device?  Doesn't your own DSDT already map the device? 

well I just stuck the ssd-tpl0 right into dsdt and got exactly same error