Search the Community

Ciao a tutti, oggi vi propongo un metodo di mappatura porte usb per i chipset intel serie 500 e 600 e 700. Piccola parentesi, si può usare pure su generazioni inferiori cambiando il percorso in ssdt come nella foto allegata sotto: cosa ci occorre : https://github.com/acidanthera/MaciASL/releases https://github.com/benbaker76/Hackintool/releases e questo ssdt : SSDT-XHC.aml.zip come potete vedere nella foto sotto, vi spiego come modificare ogni singola porta ma ricordate che da macos 11.3 si posson aver solo 15 porte massime attive. io nel ssdt sopra ho attivato le 14 hs e la ss01 per rientrare nel limite di 15 porte e iniziare la mappatura. la mobo in cui ho fatto la mappatura è una asrock b760m sonic wifi dove vi sono sul retro 2 porte usb2 (nel mio caso hs04 e hs03) ed in quelle ho messo tastiera e mouse usb. Prima di iniziare la mappatura nei vari step dovete cliccare su scopa e refresh all apertura di hackintool sezione usb dopo ogni riavvio poiché ogni volta che modificate ssdt per attivare o disattivare le porte occorre riavviare. guardando nella foto sotto ho mappato le porte usb2 come vedete hs11 è il led controller della mobo e consiglio di disattivare la porta sia nelle asrock che nelle asus ma nelle gigabyte lo dovrete lasciare attivo e mappare internal sennò perdete la funzione di risveglio da sleep. al secondo step ho disattivato tutte le porte hs tranne hs04 e hs03 essendo porte solo usb2 li ho lasciato mouse e tastiera e ho proseguito attivando le 10 porte ss e ho riavviato e iniziato a inserire dispositivi usb 3.x nelle porte ed ho ottenuto questo risultato infine ho contato le totali porte attive nelle 2 prove e tra hs e ss ho 14 porte totali e ho iniziato a disattivare quelle che non si sono illuminate e definire i connettori di quelle attive ed ho ottenuto questo risultato vi posto il mio ssdt con mappatura ultimata così potete capire meglio la procedura. (per iniziare dovete usare il primo ssdt postato sopra) SSDT-XHC.aml.zip Spero sia comprensibile e che vi aiuti a mappare le vostre porte usb e vi ringrazio per il tempo che avete dedicato alla lettura, per info e chiarimenti commentate pure sotto.

Sui sistemi senza un controller incorporato funzionante, il risveglio da un dispositivo USB potrebbe non riattivare il display. È necessario premere un secondo tasto o fare clic con il mouse per riattivare il display. Questa estensione è una soluzione a questo problema creando un falso dispositivo ACPI con i parametri di riattivazione corretti. Installazione 1 - Compilare e installare SSDT-USBW.dsl nell'iniezione DSDT del bootloader. Potrebbe essere necessario modificarlo per puntare al dispositivo XHC. 2 - Installa il kext. ✅ Info ✅ Download

Buongiorno, non so voi ma io fatico ad entrare nella logica di Open Core. A parte il fatto che mi è capitato di seguire passo passo ogni suggerimento della guida, per ottenere delle EFI che manco partono, forse per pura fortuna sono riuscito anche ad avere delle Beta di Big Sur funzionanti (di certo non in modo ottimale) su dei drive che uso come test, ho delle notevoli lacune... Ho usato le guide di Dortania. Quello che davvero non riesco a capire, per chi le ha lette, è il capitolo sulle ACPI. Insomma ogni generazione di processori (io ho Coffee Lake) ha bisogno di specifiche SSDT. La guida distingue tra: quelle che servono per la post-installazione, quelle che servono solo per laptop, poi ti invita a crearti quella specifica per la tua macchina, ma al contempo ti fornisce quella precompilata da loro, che a quanto pare tanto funziona lo stesso. Oppure ti spiega, come editare la tua con un software usando un file di esempio e delle istruzioni non proprio conformi alla tua situazione. Quindi alla fine non è chiaro se devi usare i loro file o crearti i tuoi, a parte La DSDT che è facile da estrarre tramite vari software. Per pura curiosità ho provato a installare Big Sur su una macchina vecchia (Ivy-bridge, la tengo smontata in uno sgabuzzino per le emergenze). Ho dovuto faticare la metà, ho saltato il capitolo ACPI e ho constatato alla fine che quella funziona meglio della Coffee Lake. Sono il solo che si trova in questo stato confusionale, oppure c'è qualcun altro?

Ciao a tutti, ho sentito parlare molto bene del bootloader OpenCore e vorrei provarlo, ho sempre usato Clover sul mio Hackintosh e mi sono sempre trovato bene ma, come ho già detto, vorrei provare OpenCore. Per fortuna esiste Dortania che mi sta aiutando molto con i suoi articoli (senza di essi non saprei da dove iniziare visto che è la mia prima EFI con OC!), però c'è una cosa che ancora non mi è chiara... ho estratto le ACPI da Clover e devo compilarle per usarle su OC ma non so da dove partire (non capisco niente della guida in merito). Qualche buon anima potrebbe compilarle al posto mio ed eventualmente farmi vedere come fare? Grazie mille a tutti in anticipo per l'eventuale aiuto. origin.zip

Non ho modo di provare e non ho molto seguito la discussione, ma le B550 si sono rivelate mobo ostiche per build hack; ma pare che ora grazie al developer @XLNC e un SSDT che ha messo a punto, sia possibile ottenere hack con soddisfazione anche dalle B550 tratto dal dsl dell'autore: Tutte le schede chipset AMD B550 seguono le specifiche ACPI 5.0 o successive che dichiarano il processore in ACPI come DeviceObj anziché ProcessorObj, con conseguente errore di avvio su macOS. Questo SSDT risolve questo problema dichiarando il nostro processoreObj e chiamando i dispositivi del processore esistente all'interno. SSDT-CPUR.aml.zip

Buongiorno a tutti, mi sono imbattuto in rete in un thread relativo al PMC per Z390 che adesso supporta NVRAM nativa grazie a questo aggiornamento e grazie, a quanto ho capito, agli ultimi BIOS. La domanda è: Qual è la differenza tra: * Original Table Header: * Signature "SSDT" * Length 0x0000008F (143) * Revision 0x02 * Checksum 0x2C * OEM ID "ACDT" * OEM Table ID "PMCR" * OEM Revision 0x00001000 (4096) * Compiler ID "INTL" * Compiler Version 0x20200110 (538968336) */ DefinitionBlock ("", "SSDT", 2, "ACDT", "PMCR", 0x00001000) { External (_SB_.PCI0.LPCB, DeviceObj) // (from opcode) Scope (_SB.PCI0.LPCB) { Device (PMCR) { Name (_HID, EisaId ("APP9876")) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { If (_OSI ("Darwin")) { Return (0x0B) } Else { Return (Zero) } } Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { Memory32Fixed (ReadWrite, 0xFE000000, // Address Base 0x00010000, // Address Length ) }) } } } e * Original Table Header: * Signature "SSDT" * Length 0x000000C6 (198) * Revision 0x02 * Checksum 0xC2 * OEM ID "ACDT" * OEM Table ID "PM" * OEM Revision 0x00001000 (4096) * Compiler ID "INTL" * Compiler Version 0x20180427 (538444839) */ DefinitionBlock ("", "SSDT", 2, "ACDT", "PM", 0x00001000) { External (_SB_.PCI0.LPCB, DeviceObj) // (from opcode) External (_SB_.PCI0.PMCR, DeviceObj) // (from opcode) Device (PPMC) { Name (_ADR, 0x001F0002) // _ADR: Address OperationRegion (PMCB, PCI_Config, Zero, 0x0100) Field (PMCB, AnyAcc, NoLock, Preserve) { VDID, 32, Offset (0x40), Offset (0x41), ACBA, 8, Offset (0x48), , 12, PWBA, 20 } } Scope (_SB.PCI0.LPCB) { Device (PMCR) { Name (_HID, EisaId ("APP9876")) // _HID: Hardware ID Name (_STA, 0x0B) // _STA: Status Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { Memory32Fixed (ReadWrite, 0xFE000000, // Address Base 0x00010000, // Address Length ) }) } } } Ho studiato il codice e vedo che una fa riferimento a PMCR e una a PM però non sono abbastanza esperto per capire fino in fondo le differenze. Qualunque risposta sarà ben accetta, so che la questione è molto "tecnica" ma mi affascina tantissimo 👾. Grazie, K.