Hackintosh Skylake : USB El Capitan, Sierra

J'imagine que c'est la veille. Mais ça ne concerne que l'utilisation exclusive de l'Intel HD 530 il me semble donc avec ta GTX 960, ça ne devrait pas poser de problème.

L'autre défaut, c'est le problème d'écran noir dont on a parlé plus haut et qui se règle avec l'AGDPfix (ou le patch Clover si @gradou nous le confirme).



En principe, lorsque tu as lancé l'application ADGPfix, elle t'a fait une copie de sauvegarde du kext AppleGraphicsDevicePolicy.kext (ou de celui qui le contient : AppleGraphicsControl.kext) sur ton bureau.

Donc tout ce que tu as à faire, c'est de le réinstaller avec Kext Wizard ou autre dans S/L/E et de mettre le patch dans Kernel and Kexts Patches :

Name : AppleGraphicsDevicePolicy
Find : 626F6172642D6964
Replace : 626F6172642D6978
Comment : AppleGraphicsDevicePolicy (board-id) Patch (c) Pike R. Alpha
OK, j'vais faire ça, mais c'est quoi l'objectif ? Régler le pb de veille que j'ai avec le bluetooth de la carte ou bien quoi (par exemple éviter de relancer AGDPfix à chaque MàJ de système) ? Et qu'est ce que je dois vous dire ? Là j'avoue que je suis un peu paumé !! :kiss:
 
Parce que si c'est avec "notre" kext, utiliser tel quel le patch "instant wake" de RehabMan risque de ne pas donner grand chose, vu qu'on a renommé le contrôleur…

En principe non car on s'en moque un peu d'avoir renommé le contrôleur XHC1 en XHC. Le patch va porter sur autre chose (les Method (_PWR) pour ceux qui y pige quelque chose - ce qui n'est pas mon cas :P).

Bloc de code:
#Maintained by: RehabMan for: Laptop Patches
#usb_prw_0x6d_xhc_skl.txt

# remove _PRW methods to prevent instant wake

# delete any existing XHC1 device
into device label XHC1 name_adr 0x00140000 remove_entry;

# if _PRW objects are methods
into method label _PRW parent_adr 0x00140000 remove_entry;
into method label _PRW parent_adr 0x00140001 remove_entry;
into method label _PRW parent_adr 0x001F0003 remove_entry;
# some other LAN cards use 0x00190000
into method label _PRW parent_adr 0x00190000 remove_entry;
into method label _PRW parent_adr 0x001F0006 remove_entry;

# if _PRW methods are stuffed into a separate scope
into method label _PRW parent_label _SB.PCI0.EHC1 remove_entry;
into method label _PRW parent_label _SB.PCI0.EHC2 remove_entry;
into method label _PRW parent_label _SB.PCI0.XHC remove_entry;
into method label _PRW parent_label \_SB.PCI0.EHC1 remove_entry;
into method label _PRW parent_label \_SB.PCI0.EHC2 remove_entry;
into method label _PRW parent_label \_SB.PCI0.XHC remove_entry;

# if _PRW objects are names
into device name_adr 0x00140000 code_regex Name.*_PRW.*\n.*\n.*\n.*\n.*\}\) remove_matched;
into device name_adr 0x00140001 code_regex Name.*_PRW.*\n.*\n.*\n.*\n.*\}\) remove_matched;
into device name_adr 0x001F0003 code_regex Name.*_PRW.*\n.*\n.*\n.*\n.*\}\) remove_matched;
into device name_adr 0x00190000 code_regex Name.*_PRW.*\n.*\n.*\n.*\n.*\}\) remove_matched;
# some _PRW have three entries in the Package
into device name_adr 0x00140000 code_regex Name.*_PRW.*\n.*\n.*\n.*\n.*\n.*\}\) remove_matched;
into device name_adr 0x00140001 code_regex Name.*_PRW.*\n.*\n.*\n.*\n.*\n.*\}\) remove_matched;
into device name_adr 0x001F0003 code_regex Name.*_PRW.*\n.*\n.*\n.*\n.*\n.*\}\) remove_matched;
into device name_adr 0x00190000 code_regex Name.*_PRW.*\n.*\n.*\n.*\n.*\n.*\}\) remove_matched;

# seems to work better if _PRW is present, but returns 0 (original was 3) for sleep state
# Note: These are methods because some Skylake DSDT call _PRW as a method for no reason
into device name_adr 0x00140000 insert begin Method(_PRW) { Return(Package() { 0x6D, 0 }) } end;
into device name_adr 0x00140001 insert begin Method(_PRW) { Return(Package() { 0x6D, 0 }) } end;
into device name_adr 0x001F0003 insert begin Method(_PRW) { Return(Package() { 0x6D, 0 }) } end;
into device name_adr 0x00190000 insert begin Method(_PRW) { Return(Package() { 0x6D, 0 }) } end;
into device name_adr 0x001F0006 insert begin Method(_PRW) { Return(Package() { 0x6D, 0 }) } end;

# Insert Apple USB properties into USB 3.0 XHC
into method label _DSM parent_adr 0x00140000 remove_entry;
into device name_adr 0x00140000 insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
    If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }\n
    Return (Package()\n
    {\n
        "subsystem-id", Buffer() { 0x70, 0x72, 0x00, 0x00 },\n
        "subsystem-vendor-id", Buffer() { 0x86, 0x80, 0x00, 0x00 },\n
        "AAPL,current-available", 2100,\n
        "AAPL,current-extra", 2200,\n
        "AAPL,current-extra-in-sleep", 1600,\n
        "AAPL,device-internal", 0x02,\n
        "AAPL,max-port-current-in-sleep", 2100,\n
    })\n
}\n
end;

Bref, de toute manière on s'en moque parce que la DSDT ne possède pas de device XHC1 et que dans ce cas précis, le patch de renommage (ouch !) ne sert à rien :). Comme je le disais plus haut, on le donne sur MacBidouille au cas où mais dans les faits, c'est rare que le contrôleur soit en XHC1.

@gradou

Essaye cette DSDT (à mettre dans EFI/CLOVER/ACPI/patched) et regarde si le problème de veille persiste.
 
OK, j'vais faire ça, mais c'est quoi l'objectif ? Régler le pb de veille que j'ai avec le bluetooth de la carte ou bien quoi (par exemple éviter de relancer AGDPfix à chaque MàJ de système) ? Et qu'est ce que je dois vous dire ? Là j'avoue que je suis un peu paumé !! :kiss:

Précisément. Et accessoirement, laisser le SIP activé en permanence puisqu'aucun kext n'aura été modifié (et ça, @Barijaona y tient :)).
 
Vous voulez que je vous dise ? Je suis bien content de ne pas avoir de temps à consacrer au hackintosh ces jours-ci, comme ça je vous laisse déblayer le terrain pour moi… :D

Ça, je veux bien te croire :).

Garde à l'esprit que si on cogite autant, c'est principalement parce que Skylake n'est pas encore bien maîtrisé mais comme tu vois, des solutions existent et à terme, ça sera tout aussi simple qu'avec Haswell…

À moins qu'Apple nous refasse le coup de "je change toute la gestion de l'USB" :P.
 
Bon ayé, j'ai tout fait : remis le kext original, mis la "formule" dans kernel et kexts..., mis la dsdt dans ACPI/patched, réparé les autorisations, nettoyé le cache, lavé la cuisine, fait la vaisselle... et maintenant, qu'est ce que je fais ? o_O:cyclops::rolleyes:
 
Bon, ben, comme y'a plus personne, j'ai redémarré, j'ai pas eu d'écran noir (bien que j'ai remis l'ancien AGC.kext, le SIP est évidemment activé), est ce que ça va ça ?

Mais il veut plus se mettre en veille (juste l'écran s'y met, mais pas la bécane :( )
Et de toute façon le bluetooth s'active pas... Mourf...

Par contre, si je débranche la carte Wifi-Bluetooth de l'USB, la gestion de la veille est normale. J'ai toujours le Wifi et, évidemment toujours pas de Bluetooth...
 
Dernière édition:
Par contre, si je débranche la carte Wifi-Bluetooth de l'USB, la gestion de la veille est normale. J'ai toujours le Wifi et, évidemment toujours pas de Bluetooth...

Ça n'a peut-être rien à voir, mais quand je branche le câble USB interne pour le Bluetooth, j'ai des erreurs qui s'affichent en permanence dans la Console, toutes en rapport avec une énumération et de l'USB. Toi aussi ?
 
C'est quoi comme erreur, parce que comme j'ai pas regardé, je peux pas te dire comme ça, mais si tu mets copie d'une ligne d'erreurs je pourrais peut être vérifier...
 
La bonne nouvelle, c'est que visiblement le patch de Pike R. Alpha fonctionne. C'est toujours ça de moins à surveiller en cas de MÀJ d'OS X :).

La moins bonne nouvelle, c'est que la DSDT patchée pour l'Instant wake provoque des problèmes au lieu de les régler… Mais étant donné mes compétences en la matière, c'est pas vraiment surprenant :P.

il va falloir creuser un peu plus…

Et oui, je pense que ça a bien un rapport direct avec l'USB.

L'IOReg que tu as posté, c'était avec le BT connecté sur un des ports USB ?

Ces commandes terminal donnent quoi ?

Bloc de code:
pmset -g
pmset -g assertions
 
Oui, c'était avec le BT de la carte PCI dont le Wifi fonctionne connecté sur un des ports USB internes.
Les commandes donnent ça :

Non, attends, j'avais débranché le bluetooth de l'Usb avant de rentrer les commandes. Je recommence !!
Voilà la "bonne":

Capture d’écran 2016-09-06 à 00.21.55.webp
 
Dernière édition:
DSDT v2 (vire l'ancienne).
Ce que je peux dire :

Deux premiers essais successifs de mise en veille : en veille 2,3" puis réveil.
3ème essai veille tenue...
J'avais aussi essayé avec Jettison qui l'a bien fait dormir lui (entre nous y'a bien que l'ordi qui dort à c't'heure !!!!)
-----------------------------------------------------------------------------------------------------------------------------
Après avoir écrit la 1ère partie de ce post (jusqu'aux tirets), je l'ai remis en veille et ça a tenu !!!!
Mais toujours pas de bluetooth ("bluetooth non disponible")
-----------------------------------------------------------------------------------------------------------------------------

En veille programmée, la 1ère fois : pas plus de 2"

La fois suivante, ça a tenu...
 
Dernière édition:
Bonjour à tous,

Je reviens un peu au début : le header USB sur lequel tu branches la carte Bluetooth a-t-il fait l'objet d'une identification (par exemple en y branchant provisoirement les ports du haut du boitier) et est-il bien déclaré dans le kext ? Je ne sais pas trop si la carte a besoin d'un port USB2 ou d'un port USB3, mais je parierai sur du USB2.

Vérifie que Multibeast ne t'a pas installé des patches kext qui parlent de Airport, de Handoff, de BT4 ou de Handoff…

Ensuite, vérifier avec kextstat quel .kext se charge. Je parie sur AirPortBrcm4360.kext (en plus de IO80211Family.kext)
 
Je reviens un peu au début : le header USB sur lequel tu branches la carte Bluetooth a-t-il fait l'objet d'une identification (par exemple en y branchant provisoirement les ports du haut du boitier) et est-il bien déclaré dans le kext ? Je ne sais pas trop si la carte a besoin d'un port USB2 ou d'un port USB3, mais je parierai sur du USB2.

Je me suis fait exactement la même réflexion en relisant les premiers posts :).

Et effectivement, il me semble qu'à aucun moment les ports internes n'ont été identifiés. Il n'y a que les ports externes qui l'ont été sur ton schéma ! Sauf les ports en haut du boîtiers qui eux, doivent bien être connectés sur l'un d'entre eux.

Donc à mon avis, il faudrait remettre USBInjectAll.kext + le patch pour faire sauter la limite, vérifier que la carte WIFI/BT est bien connectée à l'un des headers internes (je rejoins @Barijaona, 1 header USB2 suffira amplement) et repérer où elle apparaît dans IORegistry Explorer. Il restera ensuite à ajouter son adresse dans l'injecteur.

En revanche, il faudra probablement sacrifier un port USB…
 
Mes chers amis j'avais déjà posé cette question, au tout début de ce sujet :
* Troisième interrogation : faut il ou non renseigner le port USB20hub qui apparait en HS08 mais sur lequel on peut rien brancher !!?"
Personne ne s'y est intéressé et ensuite on a ignoré ce HS08. Ce n'est peut être pas celui là mais j'ai de fortes présomptions quand même...
La carte Wifi-BT est reliée à un USB 2 interne ça c'est sûr et ce qui est sûr c'est que tout ça a disparu avec la détermination du nombre de ports limite de 15. Ce port, si c'est bien lui, et son p'tit frère (parce qu'il y en a deux) seront, je pense, indiqués en 255 ?
 
sur lequel on peut rien brancher !!?"

C'est à dire ? Que tu ne peux pas brancher le connecteur de la carte WIFI/BT dessus ?

Et sinon, c'est quoi son adresse ? En principe, ça devrait être 08000000 mais il faudrait vérifier. En attendant, tu peux toujours essayer de l'ajouter dans l'info.plist (UsbConnector sur 255) et voir ce que ça donne…
 
Bon, me voilà reviendu.J'ai eu quelques déboires, le Hack ne bootait plus (pb de SIP) etc.

Bien donc, je suis revenu à ma config avec USBinjectAll et désormais, le bluetooth est activé et se trouve sur le port HS14 (0e000000). Je me propose donc de modifier le kext qui va bien en intégrant ce port (255) et en restant dans la limite.
Par contre je ne détermine pas l'autre port interne USB 2 (qui est branché, sinon j'aurais pas d'USB 2 sur le boitier, non ?), je ne vois pas plus le port interne USB 3 qui sert le boitier également, non ?.
 
Justement, ce sont les ports externes qui sont identifiés, je suppose…
Oui, il faut qu'ils soient renseignés, mais il faut bien qu'ils soient connectés à la carte via un port USB interne qu'à un moment donné j'ai vu sur HS08 pour l'USB 2, or ce sont ceux là que je ne vois pas...
 
Dernière édition: