A23SS4NDRO

per mappare senza Xhciportlimit, riflettevo, c'è un metodo a parte oppure si mappano prima le prime 15 USB 2.0 che compaiono su ioreg - poi si disattivano tutte le 2.0 manualmente su ssdt originale con GUPC(zero) e si controlla cosa succede alle altre 10 3.0?

Attenzione che RTL8100 di mieze, la V2.1.0 potrebbe dare problemi (almeno quando l'ho testata io su catalina con un Dell inspiron 5570, quando collegavo il cavo di rete non voleva saperne, si assegnava un IP da solo senza contattare il DHCP server - nonostante fosse attivo.) Solo la 1.0.0 release funzionava alla perfezione, dovrebbe essere stata aggiunta da @iCanaro tempo fa

quindi vi è modo per avere la stessa compatibilità che ha catalina con BigSur? intendo senza dover caricare kext altrove

Ecco qui la lista dei vendor e device-ids 14e4 43a0 unknown unknown (Scheda Broadcom) 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller 10ec 8168 Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller 8086 282a Intel Corporation 82801 Mobile SATA Controller [RAID mode] 8086 282a Intel Corporation 82801 Mobile SATA Controller [RAID mode] 8086 282a Intel Corporation 82801 Mobile SATA Controller [RAID mode] 1d6b 0003 Linux Foundation 3.0 root hub 05ac 828d unknown unknown 0a5c 4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) 058f 6366 Alcor Micro Corp. Multi Flash Reader 05c8 03bc unknown unknown 046d c05b Logitech, Inc. M-U0004 810-001317 [B110 Optical USB Mouse] 1d6b 0002 Linux Foundation 2.0 root hub Quindi per il controller del disco SATA abbiamo: 8086 282a Intel Corporation 82801 Mobile SATA Controller [RAID mode]

ok correggo con GENG(Zero, Zero) per una qualsiasi porta disattiva

Buongiorno, tempo fa io e @dreamwhite avevamo preso come impegno la traduzione di questo ottimo metodo per renderlo disponibile alla lettura di tutti, ovviamente con i credits adeguati Forse sono andato un po' too far quando ho anche messo ehe-ehm... qualche puntino sulle "i" riguardo alla storia della guida.. La PR originale la trovate qui: https://github.com/dortania/OpenCore-Post-Install/pull/54 in particolare il commit cui mi riferisco è il seguente: https://github.com/1alessandro1/OpenCore-Post-Install/commit/727cfdb6751c3263102c6e28cfe17d488bff41b2#diff-6ea6b084a90e0ca9de817e6032040b3989555200ba1c2c770c5667a3805e0809 dovrò trovare un modo per menzionare l'abuso che ne è stato fatto in passato, in maniera meno diretta (purtroppo, e le cose non le faccio alludere se le devo dire) Vorrei comunque comunicarvi che sarà lieto di mantenere la reference invece all'ideatore originale del metodo, @Gengik84 ed il metodo rimarrà intatto "GENG" 😄

si, posso riprovare, ma ricordo che non funzionava lo stesso in ogni caso ho allegato il dsdt su discord per eventuali modifiche ad hoc per BigSur

lo allego in PM?

Non riesco a spiegarmi sul fatto che: Il controller SATA già non andava con il DSDT normale senza modifiche lato SATA (poi sono state applicate le modifiche negli screenshot, niente kext aggiuntivi) e il controller funzionava Upgrade a BigSur, quello che funzionava da Catalina, non funzionava più su BigSur (mantenendo le modifiche precedenti) ok quindi va modificato il DSDT e non serve CtlnaAHCIPort.kext?

quelli presenti in download

L'ho trovata confrontando il prima e dopo di quando avevamo aggiustato

Questa era la modifica che è stata applicata per fare in modo che catalina riconoscesse anche lei il controller sata

da inserire in alto sul topic per gli utilizzatori di BigSur e successivi che XhciPortLimit è deprecato su 11.3 e successivi

yes, ma su catalina serviva solo un _DSM to ZDSM e andava senza altro Su BigSur credo abbiano droppato dei controller, tra cui qualcosa che prima su catalina era presente Il disco non viene proprio visto quando si avvia la USB per installare

you have XhciPortLimit enabled in your config.plist, which is now unsupported in Big Sur.

Non ho parlato di raid, il disco è impostato come lo era su catalina, e lì era nativo

Si era l'ultimo AppleALC... comunque ho pensato che siccome aveva appena finito di aggiornare all'ultimo security update beta, per risolvere ho clonato il disco su uno USB esterno (typec) e ho riavviato dal disco USB per avere piena libertà di reinstallare sul disco principale Nel mentre che provavo se il backup era avvenuto con successo, ho riavviato sul disco esterno (con la stessa EFI, con ScanPolicy adattata per avviare dischi collegati via USB) e stranamente il problema se n'è andato, (prima di clonare avevo pure optato per un ciclo sleep/wake, riavvio, non so quanto avesse potuto incidere, ma apparentemente non ha cambiato nulla) Alla fine mi sono detto che era venuto il momento per piallare il disco interno e ripartire con una installazione da zero (anche se non ho mai toccato /S/L/E o /L/E) e ho messo 11.2.1 Altra novità, alla iGPU di questo portatile serve: <key>enable-backlight-registers-fix</key> <data> AQAAAA== </data> da copiare e incollare sotto PciRoot(0x0)/Pci(0x2,0x0) perché altrimenti BigSur avvia con lo schermo quasi completamente nero (ho dovuto usare una torcia al posto della retroilluminazione del display, e tra un riavvio e l'altro ho dovuto usare il mouse alla cieca per raggiungere l'angolo in alto a sinistra e la freccia in basso per selezionare a memoria "Reboot") mi son detto di non aggiornare alle developer beta dei security update (neanche quelli di catalina) per evitare che ci siano problemi di questo tipo (mai riscontrati da mesi e mesi di utilizzo delle precedenti versioni di catalina con layout-id 13) Per comodità allego una versione aggiornata della sezione "DevicesProperties" di OpenCore - con l'aggiunta dell'opzione per modificare il country code e non "castrare" la velocità teoretica della scheda wifi (già ridotta per colpa del fatto che è presente una sola antenna) Ultima cosa, il kext AppleAHCIPort.kext non ha più il supporto del controller SATA che è presente in questo laptop, ho provato injector di ogni tipo ma il problema rimane, l'unica per ora è mettere in /EFI/OC/Kext questo, come da guida

Buongiorno... Dopo un security update l'audio dagli speaker non funziona più con layout 13 o 77, com'è possibile che funzioni solo dall'uscita con il jack audio?

Ho fatto finire la prima fase di avvio, al secondo nel bootpicker non vede la voce "macOS installer..." Comunque ho una novità, in uno dei test precedenti panicava su AppleCPUPowerManagement.... dopo alcuni tentativi par far avviare la seconda fase di installazione si è fermato qua

È capitato uno di quei rari avvii in cui le USB vanno alla grande, intanto installo... Ri-posto la EFI che "ogni tanto" si comporta bene.. itlwm e vesa non sono un problema per ora (quando va bene...) EFI-ultima-test.zip

stessa cosa provata con SMBIOS MacBookPro7,1, blocco identico a quello descritto sopra

Ho caricato il DSDT aggiustando la EFI con le cose dette sopra (cambio smbios + rename tolti) almeno non panica come prima... dopo il blocco, se si aspetta qualche secondo...

si sono già in AHCI... vedo il controller con lshw cambio anche SMBIOS prima? Disabilito anche i rename correlati all'ssdt che dicevi di disabilitare

Al fatto che le USB ad esempio sono definite come OHC1, OHC2 etc, con OperationRegion e Field "PMCR" tuttavia non ho l'esperienza per dire in che modo presentare le USB a macOS per fare in modo che le accetti Forse l'unica sarebbe andare a tentativi finché ad un avvio il sistema (installato) non panica, e mandare ioreg quella sola volta rarissima in cui le USB vanno (ancora non si è capito perché) No è quello della macchina originale, era per studiare cosa si aspetta El Capitan da una macchina con quell'smbios, infatti ho capito che rinominare USB1 to UHC1 non aveva senso per quell'SMBIOS proprio perché UHC1 non è presente né nel DSDT né su ioreg del macbookpro7,1 originale

Volevo assicurarmi che fosse tutto ok anche dopo il riavvio, per evitare lo scherzetto che era capitato anche prima, in cui solo 1 volta ho avviato senza il disabler attivo e con il DSDT quella volta (questa volta invece con SSDT-HPET) e volevo vedere se era ripetibile Questo non mi preclude di installare certo, il trackpad va anche con il disabler delle USB attivo...