Jump to content
About Just Joined group Read more... ×
Sign in to follow this  
Followers 0
Oschly

Stuck at AirPort_Brcm4331::initAirportFamily_kexts-1430.8...

2 posts in this topic

Recommended Posts

Hi! I have a problem with 10.14.4 on booting stage (photo).
My specs:

 

MOBO: Z390 MAG Tomahawk

CPU: i7-8700k

GPU: RX 580 Nitro+

Wifi: BCM4331CD

RAM: Corsair Vengeance LPX 3000MHz 16CL

 

I've updated every kext and driver (clover version too) and only difference is that I don't have lines informing about not loading kexts (common issue here as I see).

UNADJUSTEDNONRAW_thumb_963.jpg

Share this post


Link to post
Share on other sites
Advertisement

I found a problem. It's MSI's BIOS caused it. Flashing from 150 (newest from April) to 120 fixed it, 130 and 140 has same problem, so I don't recommend to update BIOS.

Now everything's fine.

Share this post


Link to post
Share on other sites
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.

Announcements

  • Similar Content

    • By miliuco
      (Basado en el texto publicado por los autores de OpenCore titulado Fixing System Clocks dentro de la sección Getting Started With ACPI del cual en gran parte es una traducción).
       
      Real-time clock (RTC)
       
      Un reloj en tiempo real (RTC) es un reloj que funciona con pila o batería y que se incluye en un microchip en la placa base de un ordenador. Suele estar separado del microprocesador y se denomina «CMOS» (Complementary Metal Oxide Semiconductor). Su función es mantener una corriente cuando la placa base se apaga y/o es desconectada de la corriente eléctrica y, de esta forma, evitar que la BIOS se desconfigure cada vez que se apaga el ordenador.
      Una pequeña memoria en este microchip almacena la descripción del sistema o los valores de configuración, incluidos los valores de tiempo almacenados por el RTC. Cuando encendemos el ordenador, la BIOS lee la hora actual desde la memoria en el chip con el RTC.
      Aunque el término RTC normalmente se refiere a dispositivos en ordenadores y sistemas embebidos, los RTC están presentes en la mayoría de los aparatos electrónicos que necesitan guardar el tiempo exacto.
       
      Placas base con chipset Intel series 300
       
      Algunos fabricantes de placas base Intel, sobre todo de la serie 300 (B360, B365, H310, H370, Z370, Z390, B460, Z490, etc.) han implementado un nuevo tipo de reloj del sistema llamado AWAC (ACPI Wake Alarm Counter Clock). El problema es que macOS no sabe manejar AWAC y, en su lugar, espera encontrar el clásico RTC. Esto puede ocasionar problemas como la desconfiguración de la BIOS en cada apagado o errores importantes al arrancar el sistema operativo. La solución pasa por traer de vuelta el RTC para que macOS pueda funcionar correctamente. Esto es lo que se busca con los archivos SSDT-AWAC y SSDT-RTC0. Cada uno de ellos funciona de forma diferente:
      SSDT-AWAC: deshabilita AWAC y y habilita RTC. En nuestro DSDT generalmente hay una variable llamada STAS que determina qué reloj utilizar, One para RTC y Zero para AWAC
      SSDT-RTC0: crea un falso dispositivo RTC para macOS cuando el DSDT no tiene la opción de utilizar el RTC clásico.
       
      ¿Cómo saber si necesito uno de estos SSDT?
       
      Para saber esto has de obtener el DSDT de tu sistema en formato AML y descompilarlo a formato ASL para que puedas leerlo con un editor de texto (ver más abajo).
       
      Busca en el archivo DSL el texto Device (AWAC). Si no se encuentra ninguna coincidencia (el reloj AWAC no existe), no es necesario que continúes. No tienes dispositivo AWAC y no necesitas ninguno de estos DSDT.
        Si el texto Device (AWAC) existe, busca el texto STAS. Si este texto existe, significa que se puede forzar la utilización del RTC clásico mediante SSDT-AWAC.aml que es el archivo que has de emplear en este caso.
        Si el texto Device (AWAC) existe pero no el texto STAS, has de usar SSDT-RTC0.aml pero es conveniente saber cómo se llama el dispositivo LPC en nuestro DSDT. SSDT-RTC0 por defecto utiliza LPCB pero en el DSDT puede llamarse así o también LBC o incluso LBC0. Puedes averiguarlo buscando el texto Name (_ADR, 0x001F0000) que corresponde al dispositivo LPC (Low Pin Count) y comprobar cómo se llama realmente en tu sistema para corregirlo si es necesario en SSDT-RTC0.
        Por ejemplo, si en tu DSDT se llama LPCB:
      Device (LPCB) { Name (_ADR, 0x001F0000) // _ADR: Address Method (SPTS, 1, NotSerialized) { SLPX = One SLPE = One If (PWBT) { PBEN = One } } no tendrías que hacer ninguna corrección en el archivo SSDT. Pero si tuviese otro de los nombres posibles, habría que corregirlo.
      El archivo SSDT-RTC0 tiene este contenido:
      DefinitionBlock ("", "SSDT", 2, "ACDT", "RTC0", 0x00000000) { External (_SB_.PCI0.LPCB, DeviceObj) // (from opcode) Scope (_SB.PCI0.LPCB) { Device (RTC0) { Name (_HID, EisaId ("PNP0B00")) // _HID: Hardware ID Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {8} }) Method (_STA, 0, NotSerialized) // _STA: Status { If (_OSI ("Darwin")) { Return (0x0F) } Else { Return (0); } } } } } Las 2 apariciones de LPCB quedarían sin modificar o serían cambiadas a LBC o LBC0, según cada caso.
       
      ¿Cómo obtener DSDT.aml del sistema? (ACPI dump)
       
      AML (ACPI machine Language) es el código que utiliza ACPI. Es independiente de la plataforma. El código AML es interpretado cuando se leen cada una de las tablas ACPI.
      ASL (ACPI source language) es el código fuente utilizado por ACPI. Se pude editar con editores de texto.
      Para convertir AML a ASL y viceversa es necesario emplear un compilador. El más utilizado es iasl (Intel ACPI source language optimizing compiler and dissasembler), utilidad libre incluida en distribuciones Linux y que también tiene versiones para macOS y para Windows.
      La versión para macOS se puede descargar desde el repositorio de RehabMan entre otros sitios.
      La versión para Windows se puede obtener incluida en el paquete Windows Binay Tools desde la web acpica.org.
       
      Extraer DSDT en macOS con Clover
       
      Si usas Clover, esta es una de las formas más sencillas de obtener DSDT.aml. Simplemente hay que pulsar F4 en la pantalla del menú de Clover y el archivo se genera en la partición EFI, en EFI / Clover / acpi / origin, junto a otros archivos que no son interesantes para la tarea que nos ocupa. El archivo DSDT.aml no se puede leer tal cual, es necesario descompilarlo al formato DSL. Para ello, desde Terminal:
      > iasl DSDT.aml Intel ACPI Component Architecture ASL+ Optimizing Compiler/Disassembler version 20180427(RM) Copyright (c) 2000 - 2018 Intel Corporation File appears to be binary: found 88786 non-ASCII characters, disassembling Binary file appears to be a valid ACPI table, disassembling Input file DSDT.aml, Length 0x408B7 (264375) bytes ACPI: DSDT 0x0000000000000000 0408B7 (v02 ALASKA A M I 01072009 INTL 20180427) Pass 1 parse of [DSDT] Pass 2 parse of [DSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions) Parsing completed Disassembly completed ASL Output: DSDT.dsl - 1853692 bytes El resultado es un archivo DSDT.dsl en el que podemos hacer las búsquedas relativas al RTC.
       
      Extraer DSDT en Windows
       
      Del paquete Windows Binary Tools solamente vamos a utilizar iasl.exe y acpidump.exe. Para extraer las tablas al directorio actual: acpidump -b. Se obtienen, como en el caso de macOS, una serie de archivos de los que sólo nos interesa dsdt.dat (en Windows el archivo AML obtenido tiene extensión dat). El proceso para descompilar el archivo DSDT es muy parecido a macOS:
      > iasl -d dsdt.dat Intel ACPI Component Architecture ASL+ Optimizing Compiler/Disassembler version 20200925 Copyright (c) 2000 - 2020 Intel Corporation File appears to be binary: found 88982 non-ASCII characters, disassembling Binary file appears to be a valid ACPI table, disassembling Input file dsdt.dat, Length 0x40AAB (264875) bytes ACPI: DSDT 0x0000000000000000 040AAB (v02 ALASKA A M I 01072009 INTL 20160527) Pass 1 parse of [DSDT] Pass 2 parse of [DSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions) Parsing completed Disassembly completed ASL Output: dsdt.dsl - 1980764 bytes El resultado es un archivo dsdt.dsl en el que también podemos hacer las búsquedas relativas al RTC.
       
      Nota: los archivos SSDT han de colocarse en la Carpeta EFI/Clover/ACPI/patched (Clover) o EFI/OC/ACPI (OpenCore). En OpenCore también hay que añadirlos en el archivo config.plist.
    • By miliuco
      What is CFG Lock and MSR 0xE2?
       
      CFG Lock is a BIOS setting that allows writing to a specific register, in this case MSR E2 (MSR = Model Specific Register). An MSR consists of one or more registers in blocks of instructions used to do certain tasks on a CPU. MTRs are also used to control CPU's access to memory ranges. Commands capable of reading and writing to MSR work with elevated privileges (the operating system, primarily).

      Many motherboards come from factory with MSR E2 region locked (read but not write) and quite a few of them even hide this option in BIOS user interface. In those that do show the option to block or unblock this variable, it is usually called CFG Lock. CFG Lock is a bit with 2 values, 0x1 or 0x0. When it is 0x1, macOS cannot write into this region and kernel patches are required.

      macOS wants to write this registry, both the Kernel and AppleIntelPowerManagement. It defines the C-states of the CPU, which is why it is essential for macOS. Without the ability to write to MSR E2, all or most of the CPU power management is lost and the system does not boot.

      In Clover 2 patches have been used: KernelPM (for AppleIntelPowerManagement.kext) and KernelXCPM (for the kernel). In OpenCore 2 others have been used: AppleCpuPmCfgLock (for AppleIntelPowerManagement.kext) and AppleXcpmCfgLock (for the kernel). These patches fix the problem but the registry is still read-only. To ensure native CPU power management, CFG Lock bit must be set to 0x0.

      To achieve this, the firmware must be modified to support writing to MSR E2. This method is preferred over Clover and OC patches, it generates greater system stability and the CPU power management more closely resembles that of a real Mac. The methods that are usually proposed for this task are too complex for most users who do not have a high level of knowledge, requiring specialized tools and even modified Grub.

      Below I comment on an alternative method that is much simpler and that, at least in my case, seems to have been successful. Like any of the methods that modify this bit, it has the risk of not working or even damaging the BIOS, so if you try it it is under your entire responsibility.

      CFGLock.efi

      User @Brumbaer has a tool called CFGLock.efi (see post). It is an EFI application, it has to be installed in OC Tools folder (Misc - Tools in config.plist) and in this way it is available in the OC menu next to Reset NVRAM. It should be accompanied by another tool included in the OC package called VerifyMsrE2.efi that reports current status of CFG Lock (locked / unlocked).

      When CFGLock.efi runs, it displays information (CFG variable found, varstore in which it resides, current reading and requests user intervention to make the change from 0x1 to 0x0 or vice versa). Then you have to restart. With VerifyMsrE2.efi we can check if the change has been successful.

      Both EFI applications can be run by selecting them directly in the OC menu but it is also possible, by installing OpenShell.efi tool, to run this shell and running them from there. Information for handling OpenShell.efi is available in OC and elsewhere.
       

       
      After CFGLock.efi

      I have tried CFGLock.efi and apparently it has worked well.
       
      macOS boots up and works fine with the OC patches AppleCpuPmCfgLock and AppleXcpmCfgLock disabled.
        VerifyMsrE2.efi reports "This firmware has UNLOCKED MSR 0XE2 register!".
        Hackintool in Utilities - Get AppleIntelInfo displays this text: AppleIntelInfo.kext v3.0 Copyright © 2012-2017 Pike R. Alpha. All rights reserved. IA32_MISC_ENABLES................(0x1A0) : 0x850089 ------------------------------------------ - CFG Lock............................. : 0 (MSR not locked) Note: Hackintool current version (3.4.6) doesn't show text after Get AppleIntelInfo in Big Sur beta 10. It's got from Catalina.
        Intel Power Gadget - Frequency graph shows variations between maximum and minimum suggestive of CPUPM.  

    • By Schlachtbank
      Hi. I need help if possible.
      I tried installing Big Sur on my Hackintosh with OC and Catalina working. Every time I try to boot it I receive a kernel panic relative to ACPI. The strange thing is that this kernel panic occurs only with Big Sur and High Sierra. Every other macOS version boots (I tried from 10.9 to 11).
       
      My build is:
      Motherboard: Gigabyte X79-UD3 CPU: Intel Core I7 4820K GPU: XFX Radeon RX570 I'm attaching the kernel panic and my EFI configuration (I still need to map the USBs 'cause I switched to OpenCore yesterday).
      PS. In the OC folder there's not a resources folder because I deleted it to upload it
      Kernel panic Big Sur.rtf
      OC configuration.zip
    • By jrbros1
      Hi there,
       
      So I have my Windows computer, used a USB with Clover setup to boot into Mojave OS that I installed on the SD card in the computer. The world was a great place and all was well!

      Then I did the steps to partition the pc system to now include the additional drive that I would put Clover on. Here's where I messed up: Instead of directly copying over the full Clover folder into the EFI folder of the new drive (which just had the Boot & Microsoft folders in it), I replaced the EFI's boot folder with Clover's boot folder. So the EFI folder now contains a Microsoft folder, a Clover folder, and Clover's Boot folder only.

      Now, I only can access the Clover boot up menu, the macOS, but no Windows at all. Even if I go into BIOS and pick Windows Boot Manager or Partition 1 for the start up, I get a black screen for both. I can still access the macOS as well as Shell, but I don't know what that does other than displaying all of the yellow text fly by..

      Is there a kind soul out there that can help me get Windows back to boot? Keep in mind I'm a bit of a newbie here so laying out the common-sense steps would be helpful!

      Thank you in advance!
×