Jump to content

[pre-release] macOS Big Sur

gengik84

By gengik84,
in New Releases and Updates

 Share
3,698 posts in this topic

Recommended Posts

valeryimm
valeryimm
Posted
Posted (edited)
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 by valeryimm
Link to comment
Share on other sites
markl18
markl18
Posted
Posted
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

  • Like 1
Link to comment
Share on other sites
htanh034
htanh034
Posted
Posted

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)

Link to comment
Share on other sites
TrickyHunter
TrickyHunter
Posted
Posted (edited)

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 by TrickyHunter
Link to comment
Share on other sites
eSaF
eSaF
Posted
Posted

I have retraced the installation of BS back to the first Beta each time doing clean installs apart from Beta3 which was installed over the previous Beta to rid the system of the name Preboot but that proved futile as it created a guess account at logon that proved very difficult to remove so Beta3 was also a clean install. This was done on the system in my profile as I noticed there are varied results on the various systems being posted. All the installs were done with latest OC ver: 0.6.0 and all kexts latest versions. These are the changes noted across each Beta apart from Apple bug fixes so far.

1. The volume name at Boot Menu (If you used Open Canopy and External in config.plist) is what you named the Volume also the appearance of the Startup Disk until the installation of Beta3. With Beta3 you get the name Preboot regardless, which may revert to what you name it.

2. One member reported his Startup Disk shows but his installation is done with Clover so is this a Glitch within the latest OC commit? As I posted previously, it shows if another OS X Disk (Catalina) is on line in the system.

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.

We will see what the next update brings whether worst or better but at this moment I'm done. :)

  • Like 3
Link to comment
Share on other sites
markl18
markl18
Posted
Posted (edited)

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 by markl18
Link to comment
Share on other sites
markl18
markl18
Posted
Posted
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

Link to comment
Share on other sites
Montblanc
Montblanc
Posted
Posted
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

  • Thanks 1
Link to comment
Share on other sites
mnfesq
mnfesq
Posted
Posted
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? 

Link to comment
Share on other sites
markl18
markl18
Posted
Posted
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 stuckUntitled.thumb.jpg.793888e925fdefbf226f7d262001b2cd.jpg the ssd-tpl0 right into dsdt and got exactly same error

 

Link to comment
Share on other sites
eSaF
eSaF
Posted
Posted
36 minutes ago, Montblanc said:

Yes, same here on both Hacks. Very odd

I don't expect you to do this because it's a PITA but the one that is shown in Hackintool, (I removed the machine from my account in iCloud before reinstall) I injected that SmUUID and a made another clean install just to see what happens if that too would change to something else other than what was entered and it is now showing exactly what was entered. Even after going through all that bother, I still got Preboot and No Startup Disk - Was hoping for a big revelation in finding that and hopefully force a change but alas no, so at the moment I'm looking around the room for something to break. :lol:

  • Like 1
  • Haha 2
Link to comment
Share on other sites
mnfesq
mnfesq
Posted
Posted
9 minutes ago, markl18 said:

well I just stuckUntitled.thumb.jpg.793888e925fdefbf226f7d262001b2cd.jpg the ssd-tpl0 right into dsdt and got exactly same error

 

 

When you get the "Couldn't alloc class 'AppleIntelPchSeriesAHCI" error, there is usually something earlier in the boot process that says whether it was unable to load kexts.  I can't tell much from the photo you posted.  However, I do see that you have a Synaptics trackpad and you have been trying to load the elan i2c kext.  I'm thinking that you just need to use the VoodooI2C.kext and the VoodooPS2Controller.kext with no other I2C kexts and no SSDT for TPL0.  Also, make sure that both kexts are the most recent so that you don't have any conflict with the VoodooInput.kext that is a plug-in for both of the other Voodoo kexts.

Link to comment
Share on other sites
Montblanc
Montblanc
Posted
Posted

@eSaF

I've now tried Chris1111's Wireless-USB-Big-Sur-Adapter on both machines and it gets rid of Preboot and reverts to the correct name.

No Startup disk showing though on either Hacks, or real Macs iMac 13,2 or Macbook Pro 2017.

So that looks really broken in beta3!

  • Thanks 1
Link to comment
Share on other sites
markl18
markl18
Posted
Posted
13 minutes ago, mnfesq said:

 

When you get the "Couldn't alloc class 'AppleIntelPchSeriesAHCI" error, there is usually something earlier in the boot process that says whether it was unable to load kexts.  I can't tell much from the photo you posted.  However, I do see that you have a Synaptics trackpad and you have been trying to load the elan i2c kext.  I'm thinking that you just need to use the VoodooI2C.kext and the VoodooPS2Controller.kext with no other I2C kexts and no SSDT for TPL0.  Also, make sure that both kexts are the most recent so that you don't have any conflict with the VoodooInput.kext that is a plug-in for both of the other Voodoo kexts.

well these are all the entries in my kernel section and this is the error

error.jpg

Untitled.jpg

Link to comment
Share on other sites
Loloflat6
Loloflat6
Posted
Posted (edited)

I updated Big Sur Beta 2 —————> Big Sur Beta 3 on my X299 Gigabyte UD4 System ( Finaly )

The installation process went smoothly in four stage.

 

No improvement or other bug as reported here and in comparison on my AMD X570 system.

 

I used the same EFI OC 6.0.0 as for Beta 2.

 

Now a humorous thing :

 

In France, here in Chartreuse we also have our Big Sur named Grande Sure :whistle:

 

Look : :) :yes:

 

Spoiler

 

2122454597_Screenshot2020-07-29at19_41_53.thumb.png.bd660de33c1c8b0152667cc29e78fecf.png

 

 

 

 

Edited by Loloflat6
  • Like 1
  • Haha 3
Link to comment
Share on other sites
devillived666
devillived666
Posted
Posted

Hi guys. I successfully installed beta 3 from usb. I just finally got my dw 1560 wifi using oc latest along with latest kexts. The odd thing is using airportbrcmfixup makes my keyboard stop working. Ive got a S405UA-EB906T:

Intel Core i5 7200U
Intel HD Graphics 620
8gb DDR4
Elan touchpad
conexant 8150
Not sure i need to include efi folder or not? 

Without the airportbrcmfixup kext, keyboard works but wifi icon is grey and just says 'trun on' under settings but cant change anything. 
Link to comment
Share on other sites
eSaF
eSaF
Posted
Posted (edited)
1 hour ago, Montblanc said:

@eSaF

I've now tried Chris1111's Wireless-USB-Big-Sur-Adapter on both machines and it gets rid of Preboot and reverts to the correct name.

No Startup disk showing though on either Hacks, or real Macs iMac 13,2 or Macbook Pro 2017.

So that looks really broken in beta3!

Oh ok!!! - On a negative note, I must say I am happy to hear the no Startup Disk is also a bug on real Macs, thanks for the post. :thumbsup_anim:

I forgot to add my disk is now showing up at the Boot Menu as I named it - 'macOS Big Sur' - after a few reboots.

Edited by eSaF
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...