# Hackintosh Skylake : USB El Capitan, Sierra



## gradou (3 Septembre 2016)

Bonjour à toutes et tous !

Tout d'abord mon matériel : Gigabyte Z170X-Gaming 5; Gigabyte Nvidia Geforce GTX 960; Skylake i7 *SMBIOS : iMAC 14,2*

Disposer de ports USB 2 et USB 3 fonctionnels, c'est quand même mieux, non ? Pourtant ce n'est pas forcément aussi évident pour quelqu'un qui comme moi, utilise depuis 1989 des "vrais" Macs et n'a jamais eu au fil du temps à se soucier de ces "détails".

Là, ça marche pas tout de suite, mais il y a des solutions.

(1) Une solution qui fonctionne sur ce matériel mais sujette à des déboires éventuels au fil des mises à jour de l'OS...

(2) Une (des) solution(s) qui devrai(en)t fonctionner mais que j'arrive pas à mettre en oeuvre !! (c'est d'ailleurs toute la raison de ce sujet.

Tout d'abord le (1) Je me dis que ça peut toujours aider :

a) Utiliser le kext Rehabman USBinjectAll (l'installer avec kext utility qui pour moi va bien : il répare les permissions L/E et S/L/E, met à jour le cache système et bien sûr installe le(s) kext(s))... Veiller à ce que config.plist ait bien en rtvariables : csr-active-config 0x67 = SIP Disabled completely ((désactivation du SIP). Ce kext est utile pour disposer dans un premier temps de ports USB 2 et 3 fonctionnels et , en principe (!!), dans un 2ème temps, à mettre en oeuvre une solution (2) plus pérenne...

b) Pour El Capitan 10.11.6, à l'aide de cloverconfigurator (c'est ce que j'utilise pour modifier le config.plist (il y a d'autres moyens)), aller section : Kernel and Kext Patches et "rentrer" :

Name : AppleUSBXHCIPCI, Find : 83BD8CFEFFFF10, Replace : 83BD8CFEFFFF1F, Comment :
Increase 15 port limit to 30 in AppleUSBXHCIPCI

c) Pour Sierra (beta publique 7 au 1/09/2016) idem ci dessus mais :

Name : AppleUSBXHCIPCI, Find : *83BD74FFFFFF10*, Replace : *83BD74FFFFFF16*, Comment :
10.12 DP5 change 15 port limit to 20 in AppleUSBXHCIPCI

Voilà c'est, à ce jour ce que j'ai trouvé de plus simple et de plus rapide pour que ça fonctionne (sous Sierra y'a même l'USB-C et l'USB 3.1 qui fonctionnent !)

Bien entendu c'est soumis à vos critiques, corrections, etc.

La première critique à faire, si l'on peut dire c'est : d'accord mon gars ça fonctionne mais pas dans la durée, et puis le kext USBinjectAll, Rehabman nous avertit lui même n'est pas la solution pérenne et on ne sait pas les influences négatives que cela peut avoir sur le système. Bon, pas très rassurant ça quand même. Alors que faire et ben essayer une solution 2.

2) Il y en a plusieurs, mais vu la complexité de la chose (pour moi en tout cas) j'en suis à celle là :

http://www.tonymacx86.com/threads/10-11-0-10-11-3-skylake-starter-guide.179221/.  (en particulier le § "7. USB Fix")

Et là, c'est pas tout simple !!!!! Et c'est là dedans que j'ai besoin de vos lumières !!!

J'ai essayé de tout bien suivre la procédure, me suis cassé le(s) cou(i---s) à mettre dans chaque port USB de la carte et du boitier une clé USB 2 puis une clé USB 3 pour "bien" repérer les ports comme c'est dit... Je me suis ensuite recassé les mêmes choses pour rentrer les données collectées dans MaciASL, fabriquer un "machin" nommé SSDT-USB que j'ai mis à l'endroit qu'y dit le gars... Je dis tout de suite qu'y fonctionne pas mon machin que je me suis cassé plein de choses à le faire !!

Pourquoi qu'y marche pas, c'est toute la raison de ce post !!

* Première interrogation : pourquoi, alors qu'il est dit que l'extension du fichier qui sort de MaciASL devrait être .asl se trouve être .aml, hein pourquoi ? Est ce que c'est grave docteur ?

* Deuxième interrogation : les ports du boitier sont ils à renseigner comme ceux de la carte mère UsbConnector :

0 if it's a regular USB2 connector ("Type A") or a USB2 motherboard header
3 if it's a regular USB3 connector ("Type A") or a USB3 motherboard header
ou bien :

255 if it's an internal Bluetooth device or *other "proprietary" type of connector *(moi n'a pas compris... et n'a mis pour les ports du boitier comme pour la CM)
* Troisième interrogation : faut il ou non renseigner le port USB20hub qui apparait en HS08 mais sur lequel on peut rien brancher !!?

* Quatrième interrogation : pourquoi, dans mon cas, les HS01, HS02, SS01 et SS02 n'existent pas ?

* Cinquième interrogation : concernant le port count : pourquoi dois je indiquer le chiffre le plus élevé du port SS** qui est ici 19, alors que je n'ai "repéré" que 17 ports ? Devrais je avoir 19 ports renseignés ?

* Sixième interrogation : que garde-je : USBinjectAll dans clover/kexts; l'enlève-je, s'il s'y trouve, de L/E et (ou) de S/L/E ? Et si je dois le garder à tel ou tel endroit : pourquoi ?

Enlève-je les patches d'augmentation de la limite des ports dans kernel and kext patches ?

Voilà, j'en suis là !!!! Bon, je ne cache pas que tout cela me passionne même si je suis un peu (!!) glandu quand même !

Pour les lecteurs nombreux (!!) que cela peut intéresser je mets une t'ite photo (en 3 parties, excusez je sais pas comment faire autrement pour charger le fichier sur ce forum (7ème interrogation !!)  du machin SSDT-USB :


----------



## Barijaona (3 Septembre 2016)

Quelques questions/remarques :

as-tu testé la solution (1) avec un SMBIOS 17,1 ? ça me parait plus rentable à terme, car c'est une machine Skylake. En effet, l'une des différences importantes de ta config par rapport à pas mal de tutos qu'on trouve à gauche et à droite, c'est que dans les chipsets Intel pour Skylake, il n'y a plus de contrôleur EHCI mais uniquement un contrôleur XHCI
sous Sierra, la solution (1) devrait en principe continuer à marcher si, au lieu de remplacer par *83BD74FFFFFF16*, tu remplaces par *83BD74FFFFFF1F*. Ça permettrait d'avoir la même limite que sous El Capitan, et ça devrait permettre de tester tous les ports effectivement présents sur ta carte mère sans buter sur la limite.
tu dis que tu arrives à avoir l'USB 3.1 qui fonctionne avec la solution (1) : je suppose que la limite de vitesse reste celle de USB 3.0 (5 Gb/s) ? si l'on branche un accessoire USB2 dessus, il fonctionne ?
je crois comprendre que tu n'as testé que les ports présents sur l'arrière de la carte mère, mais pas les ports internes (ce que l'on appelle _internal headers_ dans le manuel utilisateur de la carte mère)
la distinction entre 0 et 3 d'une part et 255 d'autre part n'est pas fondamentale sur le plan fonctionnel : elle permet juste de mieux distinguer entre ports externes et internes ; si tu te trompes, ça ne devrait pas empêcher les ports de fonctionner
je suppose notamment que ton USB20hub doit être lié à ce qui est décrit comme suit dans le manuel utilisateur de la carte mère : 
_Chipset+GENESYS LOGIC USB 2.0 Hub:  2 x USB 2.0/1.1 ports (available through the internal USB header)_
je te suggère d'utiliser comme point de départ le SSDT-5.aml de la configuration d'origine que tu m'as envoyé par mail plutôt que de partir de zéro, 

concernant le SIP, csr-active-config 0x3 devrait suffire = SIP Partially Disabled (Loads unsigned kexts)
sur ce forum, on ne peut charger que des images. Pour autre chose, il faudra passer par Dropbox ou une solution similaire…


----------



## gradou (3 Septembre 2016)

Barijaona a dit:


> Quelques questions/remarques :
> 
> as-tu testé la solution (1) avec un SMBIOS 17,1 ? ça me parait plus rentable à terme, car c'est une machine Skylake. En effet, l'une des différences importantes de ta config par rapport à pas mal de tutos qu'on trouve à gauche et à droite, c'est que dans les chipsets Intel pour Skylake, il n'y a plus de contrôleur EHCI mais uniquement un contrôleur XHCI
> sous Sierra, la solution (1) devrait en principe continuer à marcher si, au lieu de remplacer par *83BD74FFFFFF16*, tu remplaces par *83BD74FFFFFF1F*. Ça permettrait d'avoir la même limite que sous El Capitan, et ça devrait permettre de tester tous les ports effectivement présents sur ta carte mère sans buter sur la limite.
> ...


*Tout d'abord ça fait plaisir cette réponse : *MERCI* !!  
*Je n'ai pas testé avec 17,1 : faut il que j'modifie tout ou bien il suffit de cliquer dans smbios de clover sur la config qui va bien ?
*Je vais essayer 1F
*Vitesse USB-C et USB 3-1 : 5gb/s (version de base ... !!)
*Comment tester les ports internes et dois je le faire ? (j'ai testé les ports de la carte et du boitier) photo jointe
	

		
			
		

		
	



*Qu'est ce que je fais avec "Genesys logic... "?
*Je vais utiliser SSDT-5 (houla, j'ai regardé et je ne sais pas quoi faire avec  !! )


----------



## polyzargone (3 Septembre 2016)

@Barijaona

Excellent résumé de la situation et des pistes à explorer  !



gradou a dit:


> pourquoi, alors qu'il est dit que l'extension du fichier qui sort de MaciASL devrait être .asl se trouve être .aml, hein pourquoi ? Est ce que c'est grave docteur ?



C'est une boulette de l'auteur (c'est d'ailleurs tès étonnant de sa part, le mec n'est pas un débutant). Le format de sortie est bien .aml comme tu le soupçonnes.

En gros :

• .dsl est le format "brut", non compilé.

• .aml est le format décompilé. Qu'il soit patché ou pas. À noter que les fichiers que tu trouveras dans EFI/CLOVER/ACPI/origin sont aussi en .aml. Il est recommandé de les décompilé *ensembles* (v. ici).

NB : En règle générale, il ne faut jamais travailler sur des fichiers .aml/.dsl extraits *après avoir démarré*. En effet, le bootloader (et plus particulièrement Clover) est susceptible d'avoir déjà injecté des paramètres (comme pour l'audio ou les cartes graphiques par exemple - les fameux Inject NVIDIA, Intel ou ATI).

Par conséquent, ces fichiers risquent fortement d'êtres biaisés et dans les faits, inutilisables. En clair, il est préférable d'utiliser systématiquement les fichiers de EFI/CLOVER/ACPI/origin et surtout pas par MaciASL > Save as… .

Cela étant dit, ne te préocuppe pas trop de ça si tu  pars sur la SSDT-USB-Template.dsl

J'ajoute que la décompilation des fichiers .aml n'est pas toujours nécessaire. Ça dépend de ce que tu veux faire en fait.



gradou a dit:


> concernant le port count : pourquoi dois je indiquer le chiffre le plus élevé du port SS** qui est ici 19, alors que je n'ai "repéré" que 17 ports ? Devrais je avoir 19 ports renseignés ?



C'est une un emploi malheureux de la part d'Apple. Le port-count n'a rien à voir avec le nombre de ports mais il se détermine en fonction de l'adresse la plus haute. Dans ton cas, la plus haute (SS09) est de 19000000. Donc le port-count est de 19000000, même si tu n'as que 17 ports.



gradou a dit:


> que garde-je : USBinjectAll dans clover/kexts; l'enlève-je, s'il s'y trouve, de L/E et (ou) de S/L/E ? Et si je dois le garder à tel ou tel endroit : pourquoi ?



En principe, une fois que tous tes ports et toutes tes adresses sont identifiés, il faut le retirer pour éviter de fausser les résultats.



gradou a dit:


> Enlève-je les patches d'augmentation de la limite des ports dans kernel and kext patches ?



Idem.


----------



## Barijaona (3 Septembre 2016)

gradou a dit:


> *Comment tester les ports internes et dois je le faire ? (j'ai testé les ports de la carte et du boitier)
> *Qu'est ce que je fais avec "Genesys logic... "?


Je comprends que tu as, lors du montage de ton boitier, utilisé certains des headers internes pour les relier aux ports mis à disposition sur le dessus de ton boitier. Ce serait bien d'indiquer lesquels (cf. dessin de la carte mère dans le manuel : tu as F_USB30_1, F_USB30_2, F_USB1 et F_USB2).

Je suppute que F_USB1 et F_USB2 sont ceux qui sont reliés au GENESYS LOGIC USB 2.0 Hub. Il faudrait les connecter provisoirement pour en être sûr, afin que nous ayons à la fin un guide complètement exhaustif. Mais si c'est trop fastidieux pour toi, laisse tomber : vu qu'on dépasse allègrement la limite des 15, ils feront partie des ports à sacrifier dans ta configuration.

Pour mon usage futur, je serais par contre intéressé de savoir à quel port physique @nicolasf a relié sa carte Wifi/Bluetooth.



polyzargone a dit:


> • .aml est le format décompilé. Qu'il soit patché ou pas. À noter que les fichiers que tu trouveras dans EFI/CLOVER/ACPI/origin sont aussi en .aml. Il est recommandé de les décompilé *ensembles* (v. ici).



Petite rectification, AML n'est pas décompilé, c'est du binaire machine (_ACPI Machine Language_)



polyzargone a dit:


> J'ajoute que la décompilation des fichiers .aml n'est pas toujours nécessaire. Ça dépend de ce que tu veux faire en fait.



Effectivement, au vu du SSDT-5 de la GA-Z170X-Gaming 5, adapter en fonction des besoins le X99_Injector.kext de fljagd semble plus simple ! (supprimer les contrôleurs EHCI, adapter au SMBIOS iMac17,1 et à la liste des ports que l'on veut activer)

@gradou, peux tu poster une copie d'écran de l'onglet "PCI List" dans DPCI Manager ?


----------



## polyzargone (3 Septembre 2016)

Barijaona a dit:


> Petite rectification, AML n'est pas décompilé, c'est du binaire machine (_ACPI Machine Language_)



Absolument, j'ai écris trop vite . En plus, c'est contradictoire avec ce que j'ai écris juste au dessus  :



polyzargone a dit:


> • .dsl est le format "brut", non compilé.
> 
> • .aml est le format décompilé.



En fait, le .aml est la version compilée du .dsl et non la version décompilée (ça, c'est le .dsl). Le format .aml est bien en langage machine et c'est le seul format qu'un bootloader sait lire. C'est d'ailleurs pour cette raison que Clover peut patcher "à la volée" la DSDT.aml.


----------



## polyzargone (3 Septembre 2016)

gradou a dit:


> Je n'ai pas testé avec 17,1 : faut il que j'modifie tout ou bien il suffit de cliquer dans smbios de clover sur la config qui va bien ?



Attention si tu utilises déjà iMessage ! Si c'est le cas, prend bien soin de conserver ces 3 valeurs :

• Serial Number
• SmUUID
• Board Serial Number


----------



## gradou (3 Septembre 2016)

Bon, ben là avec les contributions des deux "chefs" : Barijaona et Polyzargone, j'ai du boulot !! Rendez vous dans xx heures pour vous dire où j'en suis (j'adoooooore l'ambiance !!)


----------



## gradou (3 Septembre 2016)

Bon, je suis passé à iMac 17,1 ( Barijaona) et j'ai bien gardé tout ce qu'il faut pour conserver iMessage et tutti quanti ( polyzargone) : pas glop , black screen au redémarrage, bloqué... C'est grave de rester en 14,2 ?

J'ai modifié, pour Sierra, F16 par F1F ( Barijaona) : OK apriori

@ Barijaona : le port interne utilisé pour connecter les ports du boitier est : F_USB2; qu'est ce que j'en fais de ce F_USB2 ? Dois je le renseigner ou bien c'est juste pour savoir... Est ce que je continue avec les seuls ports que j'ai montré sur le croquis de la carte mère et indiqué pour le boitier ou bien est ce que je rajoute ce F_USB2 
	

		
			
		

		
	



	

		
			
		

		
	
 et d'autres encore?
Tu me dis d'utiliser *SSDT-5.aml *mais je sais pas l'utiliser pour faire comme avec SSDT-USB-Template.dsl .

Tu veux une copie d'écran de l'onglet "PCI List" dans DPCI Manager, la v'là :


----------



## polyzargone (3 Septembre 2016)

gradou a dit:


> Bon, je suis passé à iMac 17,1 ( Barijaona) et j'ai bien gardé tout ce qu'il faut pour conserver iMessage et tutti quanti ( polyzargone) : pas glop , black screen au redémarrage, bloqué... C'est grave de rester en 14,2 ?





J'ai rien dit mais c'était prévisible .

C'est le problème avec ce SMBios et les CG additionnelles !

Heureusement, la solution est ici (en revanche, il faudra repasser le CsrActiveConfig en 0x67 sinon, il va râler comme quoi le SIP n'est pas désactivé, ce qui est en partie faux ).


----------



## gradou (3 Septembre 2016)

polyzargone a dit:


> J'ai rien dit mais c'était prévisible .
> 
> C'est le problème avec ce SMBios et les CG additionnelles !
> 
> Heureusement, la solution est ici (en revanche, il faudra repasser le CsrActiveConfig en 0x67 sinon, il va râler comme quoi le SIP n'est pas désactivé, ce qui est en partie faux ).



Non mais, dis moi qu'c'est pas vrai : ça marche !! Qu'est ce que je pourrais bien te demander encore polyzargone ? TROP FOOOOORT !!!

Bon, ceci étant je sais plus trop quoi faire maintenant :
 Je recommence avec ioregistry pour repérer les ports (ce que j'ai déjà fait mais avec smbios 14,2), je repère quoi comme ports : ceux de la carte mère à l'arrière et ceux du boitier situés sur le dessus (comme je l'ai déjà fait), ou bien en faut il d'autres ? Est ce que je garde le F_USB2 (HS08), est ce que j'utilise MacIasl avec  SSDT-USB-Template.dsl comme base en regard de mon croquis ci dessus de la carte mère et de la désignation des ports du boitier?
Si c'est oui, je mets bien le fichier .aml obtenu dans Clover -->ACPI-->Patched, j'enlève de partout USBinjectAll ainsi que le patch d'augmentation de la limite des ports, j'enlève 1 ou 2 ports (si USB_2 renseigné) (ou plus s'il faut que j'en renseigne encore d'autres !) pour arriver à 15 ?


----------



## nicolasf (3 Septembre 2016)

Je sens que ce sujet va bien me servir, il faut encore que je me plonge dans les joies de l'USB sur mon Hackintosh…

@Barijaona : pour répondre à ta question, sur l'un de ces deux ports USB : 






L'autre est déjà occupé, de mémoire pour les ports USB à l'avant. Mais ça ne marche pas pour le moment, il faut que je trouve le temps de bricoler pour activer tous les ports.


----------



## Barijaona (3 Septembre 2016)

polyzargone a dit:


> J'ai rien dit mais c'était prévisible .
> 
> C'est le problème avec ce SMBios et les CG additionnelles !
> 
> Heureusement, la solution est ici (en revanche, il faudra repasser le CsrActiveConfig en 0x67 sinon, il va râler comme quoi le SIP n'est pas désactivé, ce qui est en partie faux ).



Le patch clover de Pike R. Alpha peut être une autre solution (du moins si on a une seule carte graphique additionnelle) qui permet d'éviter de désactiver SIP (je sais, je suis obsédé  ).



gradou a dit:


> Je recommence avec ioregistry pour repérer les ports (ce que j'ai déjà fait mais avec smbios 14,2), je repère quoi comme ports : ceux de la carte mère à l'arrière et ceux du boitier situés sur le dessus (comme je l'ai déjà fait), ou bien en faut il d'autres ? Est ce que je garde le F_USB2 (HS08), est ce que j'utilise MacIasl avec  SSDT-USB-Template.dsl comme base en regard de mon croquis ci dessus de la carte mère et de la désignation des ports du boitier?
> Si c'est oui, je mets bien le fichier .aml obtenu dans Clover -->ACPI-->Patched, j'enlève de partout USBinjectAll ainsi que le patch d'augmentation de la limite des ports, j'enlève 1 ou 2 ports (si USB_2 renseigné) (ou plus s'il faut que j'en renseigne encore d'autres !) pour arriver à 15 ?



Tu ne gardes que les ports dont tu as réellement besoin en respectant la limite de 15 (en n'oubliant pas que les ports USB3 compteront double si tu y actives également l'USB2).

Tu as le choix entre :
a) construire un SSDT à partir du template SSDT-USB-Template.dsl (méthode TonyMacX86)
ou b) construire un kext assez basique, en t'inspirant de la fin des méthodes de fjlagd et de Macbidouille (le principe est le même pour les deux, sauf que Macbidouille renomme le contrôleur XHCI en XHC pour éviter tout conflit avec un éventuel injecteur d'Apple). Le kext obtenu remplacera USBInjectAll.

Personnellement, je trouve l'option b) plus sympa.


----------



## Barijaona (3 Septembre 2016)

@gradou : je peux essayer de bâtir le kext injecteur, si tu publies des copies d'écrans de l'onglet "PCI List" de DPCIManager.


----------



## gradou (3 Septembre 2016)

Barijaona a dit:


> @gradou : je peux essayer de bâtir le kext injecteur, si tu publies des copies d'écrans de l'onglet "PCI List" de DPCIManager.


Et ben je l'ai publié, plus haut, regarde dans une de mes réponses !! 
http://forums.macg.co/threads/hackintosh-skylake-usb-el-capitan-sierra.1284304/#post-13058718
Sinon que pensez vous de la méthode de l'exclusion de ports, *sans* construire de patch SSDT, *en éliminant* les patches genre : AppleUSBXHCIPCI, Find : 83BD8CFEFFFF10, Replace : 83BD8CFEFFFF1F  dans "kernel & kext patches"  de clover et en conservant USBinjectAll dans EFI-->Clover-->Kexts -->OSXXXX ?


----------



## polyzargone (3 Septembre 2016)

Barijaona a dit:


> Le patch clover de Pike R. Alpha peut être une autre solution (du moins si on a une seule carte graphique additionnelle) qui permet d'éviter de désactiver SIP (je sais, je suis obsédé  ).



Il se trouve qu'un membre a eu le même problème et que le patch de Pike R. Alpha n'a pas fonctionné.

Et en fait, quand on regarde le patch en question, c'est plutôt logique puisqu'il ne concerne que le SMBios d'un MacPro6,1 et qu'il consiste à chercher/remplacer board-id par board-ix *dans le binaire AppleGraphicsDevicePolicy* alors qu'en ce qui concerne l'iMac17,1, il faut chercher/remplacer Config2 par none dans le champ Mac-B809C3757DA9BB8D *de l'info.plist*.

Et là où board-id n'est présent qu'une seule fois dans le binaire AppleGraphicsDevicePolicy; il existe plusieurs occurrences de Config2 dans l'info.plist (en fonction du champ Mac-xxxxxxxxxxxxxxxx).

AGDPfix cible précisément ces multiples occurrences en fonction du SMBios et donc de son Board-ID.

Donc le patch est de nature différente.

En revanche, il doit être possible de régler ça par un autre patch DSDT Clover ou mieux, via un patch DSDT ou SSDT.

Ça pourrait donner ça avec Clover :


```
Comment : GFX0 > GFX1
Find : 47465830
Replace : 47465831
```

@gradou

J'ai oublié de le préciser mais il faudra refaire la manipulation après chaque MÀJ d'OS X.



Barijaona a dit:


> Personnellement, je trouve l'option b) plus sympa.



Moi aussi . Une fois qu'on a identifié les ports/adresses, la méthode de l'injecteur est plus simple à réaliser qu'avec une SSDT.


----------



## polyzargone (3 Septembre 2016)

gradou a dit:


> Sinon que pensez vous de la méthode de l'exclusion de ports, *sans* construire de patch SSDT, *en éliminant* les patches genre : AppleUSBXHCIPCI, Find : 83BD8CFEFFFF10, Replace : 83BD8CFEFFFF1F  dans "kernel & kext patches"  de clover et en conservant USBinjectAll dans EFI-->Clover-->Kexts -->OSXXXX ?



Que tu ne feras que contourner le problème sans le régler .

Ne désespère pas. En fait tu as fait le plus dur en identifiant tes ports et tes adresses. Il reste juste l'injecteur à faire et les tests.


----------



## gradou (3 Septembre 2016)

Barijaona a dit:


> Le patch clover de Pike R. Alpha peut être une autre solution (du moins si on a une seule carte graphique additionnelle) qui permet d'éviter de désactiver SIP (je sais, je suis obsédé  ).
> 
> 
> 
> ...



L'option a) : je l'ai essayée (c'est tout mon discours du début de ce topic...) et je n'arrive pas à un patch ssdt fonctionnel, y marche pas et je ne sais toujours pas pourquoi...
Si l'option b) est plus sympa je n'en doute pas, je l'ai essayée avec fjflag lui même, et ça n'a pas fonctionné cf :
http://forums.macg.co/threads/et-si-je-montais-un-hackintosh.1283051/page-15#post-13054420


----------



## Barijaona (3 Septembre 2016)

Bon, ce n'est pas testé (j'attends toujours mon matériel !), mais je me suis aventuré à bâtir un injecteur à partir des discussions de ce fil.

https://www.dropbox.com/s/aa09z1qsfvej6uq/Z170_Injector.kext.zip?dl=0

@gradou : j'ai mis dans l'Info.plist tous les ports que tu as identifié, ce qui fait 16 et dépasse donc la limite de 15. Donc soit tu modifies le fichier Info.plist pour en sacrifier un, soit tu maintiens provisoirement le patch Kernel qui augmente le nombre de ports, le temps du test.

Dans l'optique de contourner les éventuels injecteurs spécifiques à l'iMac17,1, il faut mettre un patch Clover dans la rubrique ACPI > DSDT fixes :
Comment : Rename XHC1 to XHC
Find : 58484331
Replace : 584843

En théorie, cette extension devrait marcher si on la place dans le dossier kexts de Clover (en enlevant USBInjectorAll que ce truc a pour objectif de remplacer). Mais tu peux aussi tenter de la placer dans System/Library/Extentions avec kext utility ou équivalent.

Quoi qu'il en soit, je suis intéressé par ce que donnerait le log…


----------



## gradou (4 Septembre 2016)

Bon, et bien, ça fonctionne, et même très, très bien : tout est OK !!!
Bravo, t'es un CHEF !!
C'est quoi le log que tu veux ?


----------



## polyzargone (4 Septembre 2016)

Barijaona a dit:


> b) construire un kext assez basique, en t'inspirant de la fin des méthodes de fjlagd et de Macbidouille (le principe est le même pour les deux, sauf que Macbidouille renomme le contrôleur XHCI en XHC pour éviter tout conflit avec un éventuel injecteur d'Apple).



En fait, le patch pour renomme XHC*I* en XHC, c'est pas pour éviter un éventuel conflit avec un injecteur Apple, c'est pour les cas où le contrôleur est défini comme tel dans certaines DSDT.

L'injecteur d'Apple, c'est celui-ci : /System/Library/Extensions/IOUSBHostFamily.kext/Contents/PlugIns/*AppleUSBXHCIPCI.kext* (parce que oui, Apple se sert elle aussi d'un injecteur pour ses propres Mac, marrant non  ?) et lui, il va chercher un XHC*1*.


----------



## polyzargone (4 Septembre 2016)

Je me joins à @gradou !

Excellent boulot @Barijaona  !


----------



## gradou (4 Septembre 2016)

Fonctionne parfaitement avec Sierra, mais pas avec El Capitan, pourtant même SMBIOS, mêmes réglages, bizarre, non ?
Affaire à suivre...


----------



## polyzargone (4 Septembre 2016)

Tu l'as installé où finalement ? Dans L/E, S/L/E ou EFI/CLOVER/kexts/10.11 et EFI/CLOVER/kexts/10.12 (auquel cas, il faudrait plutôt le mettre dans Other qui est commun à toutes les versions d'OS X) ?

Si tu permets, je voudrais essayer une version légèrement différente de l'injecteur pour voir…


----------



## gradou (4 Septembre 2016)

polyzargone a dit:


> Tu l'as installé où finalement ? Dans L/E, S/L/E ou EFI/CLOVER/kexts/10.11 et EFI/CLOVER/kexts/10.12 (auquel cas, il faudrait plutôt le mettre dans Other qui est commun à toutes les versions d'OS X) ?
> 
> Si tu permets, je voudrais essayer une version légèrement différente de l'injecteur pour voir…


Je l'ai mis dans les deux 10.11 et 10.12 (et dans les deux EFI) pour qu'il soit disponible depuis partout mais t'as raison, le plus simple c'est de le mettre dans "other"...


----------



## gradou (4 Septembre 2016)

polyzargone a dit:


> Si tu permets, je voudrais essayer une version légèrement différente de l'injecteur pour voir…



Bon, et ben avec ton kext *polyzargone*, TOUT FONCTIONNE PARTOUT : El Capitan, Sierra !!!

 BRAVO et merci 

(Je vais revérifier la version de Barijoana avec 10.11); revérification faite, elle fonctionne (!!!!!), j'avais dû m---er quelque part... m'enfin !!

Je te remercie de m'avoir poussé à ouvrir ce sujet parce que vos réalisations vont, je crois, rendre service à nombre d'entre nous. 

Maintenant j'ai cependant une requête pour que la fête soit complète : celle que vous contribuiez tous les deux à l'autonomie des Hackintosheurs en voie de "développement" !!

Pour ma part j'avais utilisé une méthode et des outils qui ne m'ont pas permis d'aller au bout 
Pourriez vous l'un et l'autre nous expliquer comment vous avez procédé (à moins qu'il ne s'agisse de secrets de fabrication !!!!) ? Et puis aussi, pour satisfaire les curieux : c'est quoi la différence entre les 2 versions ?

Mais encore merci !!!

Ai je des renseignements à vous fournir ?


----------



## Barijaona (4 Septembre 2016)

wow, les nouvelles de la nuit sont assez fantastiques ! Je n'ai pas bâti un seul hackintosh de ma vie, mais j'ai déjà l'impression de commencer à comprendre deux ou trois choses essentielles !

Sauf que je ne suis pas sûr de tout comprendre ! @polyzargone, je suis preneur d'explications sur ton kext, car les valeurs numériques que j'y trouve ne correspondent pas à la copie d'écran fournie par @gradou : http://forums.macg.co/attachments/dpci-capture-png.110545/

Pour ma part, je n'ai pas grand mérite, car en partant de ladite copie d'écran et des adresses de port, je n'ai fait qu'appliquer la déclaration de ports qu'a découvert fljagd (qui au départ n'arrivait pas à faire marcher l'USB3 de sa carte X99), en y ajoutant le renommage de XHC1 à XHC évoqué chez macbidouille.

La seule vrai nouveauté, c'est la suppression de tout ce qui faisait référence à EHCI, car je me suis dit que dans un contexte Skylake, ça ne servait à rien ou risquait de mettre le bazar.

Concernant plus particulièrement le renommage de contrôleurs/ports, ma compréhension de la chose est celle qui est décrite dans la partie _Summary_ de ce guide chez Tonymac. En traduisant et en simplifiant pour notre cas :

le DSDT contient des informations sur les ports USB intégrés et les ports des hubs USB intégrés
le DSDT peut être erroné
Apple a peut-être trouvé des erreurs DSDT dans des produits Apple, donc ils mis en place un mécanisme pour remplacer les DSDT (les injecteurs de port)
Les injecteurs de port Apple sont basés sur les noms ACPI des contrôleurs  et sur le SMBIOS
Les injecteurs de port Apple vont remplacer votre DSDT (que celui-ci soit correct ou non) si les critères correspondent
Renommer les contrôleurs pour éviter une correspondance peut être un moyen d'éviter les injecteurs de port Apple, ce qui fait que le système retombe sur le DSDT (qui peut cependant être lui même erroné)
Après le renommage de ports, si le DSDT fournit des détails erronés sur la topologie des ports USB, on peut créer un injecteur de port comme Apple l'a fait pour ses propres ordinateurs


----------



## gradou (4 Septembre 2016)

Barijaona a dit:


> Pour ma part, je n'ai pas grand mérite, car en partant de ladite copie d'écran et des adresses de port, je n'ai fait qu'appliquer la déclaration de ports qu'a découvert fljagd (qui au départ n'arrivait pas à faire marcher l'USB3 de sa carte X99), en y ajoutant le renommage de XHC1 à XHC évoqué chez macbidouille.



J'avais essayé aussi la méthode flagd, sauf que ça n'avait pas fonctionné. Comment as tu fait, avec quels outils pour, à partir des éléments fournis sur les adresses des ports et de la copie d'écran PCI-list, fabriquer le kext ?
Pourrais tu faire un p'tit tuto là dessus ?


----------



## Barijaona (4 Septembre 2016)

Pour compléter les explications sur mon kext, les noms de ports sont ceux qui figurent d'origine dans le fichier SSDT-5.aml de EFI/CLOVER/ACPI/origin : HS01 à HS14 (USB2), SS01 à SS10 (USB3) et USR1 à USR2 (USB3.1)

Pour répondre à gradou : si tu regardes le contenu du kext, celui-ci est pratiquement vide, il ne contient qu'un Info.plist. Je suis juste parti du modèle pour X99 de fjlagd et je l'ai édité avec PlistEdit Pro, en adaptant les IDs des contrôleurs AHCI et USB 3.0 xHCI.

Plutôt qu'un tutorial, je vais poster le kext sur Github avec des explications détaillées.
À la réflexion, les différents usages du mot injecteur rendent le rôle du kext ambigu : je vais sans douter changer le nom du kext. (Z170X_USBEnabler ?)


----------



## gradou (4 Septembre 2016)

Barijaona a dit:


> Pour répondre à gradou : si tu regardes le contenu du kext, celui-ci est pratiquement vide, il ne contient qu'un Info.plist. Je suis juste parti du modèle pour X99 de fjlagd et je l'ai édité avec PlistEdit Pro, en adaptant les IDs des contrôleurs AHCI et USB 3.0 xHCI.
> Plutôt qu'un tutorial, je vais poster le kext sur Github avec des explications détaillées.
> À la réflexion, les différents usages du mot injecteur rendent le rôle du kext ambigu : je vais sans douter changer le nom du kext. (Z170X_USBEnabler ?)



Oui, c'est bien comme nom, tu nous diras quand t'auras fait ça sur Github (un p'tit lien).


----------



## Barijaona (4 Septembre 2016)

gradou a dit:


> Oui, c'est bien comme nom, tu nous diras quand t'auras fait ça sur Github (un p'tit lien).



Ce ne sera pas pour tout de suite, car je préfère attendre ma machine pour vérifier/compléter les explications. En attendant, considère toi comme mon bêta-testeur !


----------



## gradou (4 Septembre 2016)

Testeur, je veux bien, mais ballot, non alors !!


----------



## Barijaona (4 Septembre 2016)

Est-ce que l'explication graphique ci-après des valeurs que j'ai reporté dans pListEdit est un peu plus claire ?

Identifiants des périphériques PCI








Adresses des ports






Compares ce que j'ai fait avec ce qu'a fait @fljagd avec sa X99 et tu comprendras que l'on reste dans la même logique. Sauf que je n'ai que du XHCI et pas de EHCI.


----------



## polyzargone (4 Septembre 2016)

gradou a dit:


> Je l'ai mis dans les deux 10.11 et 10.12 (et dans les deux EFI) pour qu'il soit disponible depuis partout mais t'as raison, le plus simple c'est de le mettre dans "other"...



Deux dossiers EFI ? Hmm… Non . C'est inutile voire même problématique.

Quelque soit le nombre de version d'OS X que tu utilises sur ton Hack, un seul dossier EFI pour les gérer est largement suffisant.

C'est (encore) une autre raison de ne pas utiliser MultiBeast puisque si on place les kexts dans EFI/CLOVER/kexts/10.x ou Other et non pas dans le L/E ou S/L/E de chaque partition OS X, on peut parfaitement gérer chaque OS individuellement avec ses propres kexts et ses propres patchs.

Ex :

Sur ma H97-HD3, j'ai actuellement 4 versions d'OS X : Mavericks, Yosemite, El Capitan et Sierra (et 1 Windows + 1 Linux).

Je n'ai qu'un seul dossier EFI/CLOVER sur mon disque El Capitan et je mets les kexts communs à tous dans Other et ceux qui sont spécifiques dans 10.9, 10.10, 10.11 et 10.12. J'ai donc ces 3 kexts dans 10.11 et 10.12 (je n'ai rien de spécifique dans 10.9 et 10.10) :

• FakePCIID_XHCIMux.kext
• FakePCIID.kext
• USB_Injector.kext

Et le reste dans Other :

• AppleALC.kext
• FakeSMC.kext
• RealtekRTL8111.kext

Idem pour le config.plist : je n'en utilise qu'un avec des Kernel and Kexts Patches spécifiques à chaque version (le cas échéant) + des patchs communs (comme le TRIM par exemple).

C'est donc beaucoup plus simple à gérer et ça me permet de brancher n'importe quel disque équipé d'OS X sans avoir à installer Clover à chaque fois sur chaque disque. Ainsi, l'année prochaine, je n'aurais qu'à ajouter un dossier 10.13 dans EFI/CLOVER/kexts et éventuellement, des patchs spécifiques à ce nouvel OS (pour faire sauter la limite de l'USB par exemple même si personnellement, je n'en ai pas besoin) et c'est tout.

Dans le même ordre idée, si j'installe OS X sur un disque externe, je n'ai qu'à le brancher et mon Clover situé sur la partition EFI El Capitan se chargera de le démarrer. C'est très pratique quand il s'agit de tester des bêtas par exemple .

Bref, revenons à nos moutons 



gradou a dit:


> Pourriez vous l'un et l'autre nous expliquer comment vous avez procédé (à moins qu'il ne s'agisse de secrets de fabrication !!!!) ? Et puis aussi, pour satisfaire les curieux : c'est quoi la différence entre les 2 versions ?



Le secret, c'est d'abord d'utiliser les bons outils :

• MaciASL pour tout le bazar avec les fichiers ACPI
• IORegistry Explorer pour repérer/vérifier que ce qu'on trafique avec le bootloader, les DSDT/SSDT ou les kexts est bien appliqué
• PlistEdit Pro pour faire mumuse avec les fichiers .plist (il y en a quasiment partout et pour tout dans OS X)
• Du temps et beaucoup de patience 

Personnellement, si je devais te donner un point de départ, je dirais que la maîtrise de PlistEdit Pro (y a un outil similaire dans XCode mais faut se coltiner les 3,80 Go de téléchargement) est essentielle.

Elle te sera bien plus utile que la compréhension de MaciASL et de la norme ACPI (c'est vraiment hardcore comme truc). Mais si tu te sens à l'aise ou curieux d'en apprendre plus, alors fonce car si tu arrives à piger comment ça marche, tu peux faire des merveilles avec ça !

Pour l'injecteur en question, tu avais déjà fait le plus gros du boulot et en fait, il te suffisait "simplement" de modifier les valeurs de l'injecteur de fjlagd pour qu'elles correspondent à tes adresses de ports (elles étaient incorrectes dans la version qu'il t'a fourni).

Donc si c'était à refaire ou si c'était pour une autre carte-mère, il faudrait là aussi commencer par identifier les ports/adresses avec IORegistry Explorer + USBInjectAll.kext + patch Clover pour faire sauter la limite et ensuite, éditer l'info.plist et mettre ses propres valeurs HSxx/SSxx avec les bonnes adresses.
*
C'est ça le tuto* .



Barijaona a dit:


> Sauf que je ne suis pas sûr de tout comprendre ! @polyzargone, je suis preneur d'explications sur ton kext, car les valeurs numériques que j'y trouve ne correspondent pas à la copie d'écran fournie par @gradou : http://forums.macg.co/attachments/dpci-capture-png.110545/[
> 
> (…)
> 
> Pour répondre à gradou : si tu regardes le contenu du kext, celui-ci est pratiquement vide, il ne contient qu'un Info.plist. Je suis juste parti du modèle pour X99 de fjlagd et je l'ai édité avec PlistEdit Pro, en adaptant les IDs des contrôleurs AHCI et USB 3.0 xHCI.



En ce qui concerne les différences entre les deux versions :

Même si je doute un peu que ça ait changé grand chose, je ne suis pas parti sur l'injecteur de fjlagd (qui contient un champ "IntelC610/X99SeriesAHCI" dont je ne m'explique pas la présence) mais en me basant sur /System/Library/Extensions/IOUSBHostFamily.kext/Contents/PlugIns/*AppleUSBXHCIPCI.kext*.

Je n'ai conservé que les champs "AppleUSBXHCIxxxxx" dans *IOKitPersonalities *et je les ais tout simplement copier/coller à la place de ce qu'il y avait dans l'injecteur de fjlagd et de @Barijaona tout en conservant le champ iMac17,1-XHC avec les adresses définies par @gradou et intégrées par @Barijaona.

Du coup, je n'ai pas utilisé les IDs des contrôleurs AHCI (pourquoi faire ? C'est l'USB qui nous intéresse ici) ni des contrôleur USB 3.0 XHCI. Par conséquent, l'injecteur ne se fie qu'à ce qui est défini dans la DSDT.

Ça me semble plus cohérent et plus propre mais encore une fois, je ne suis pas certain que ça ait changé quoique ce soit puisque tu nous dis que finalement, la version de @Barijaona a fonctionné.

Cela étant, le kext v2 est normalement plus en adéquation avec le propre injecteur d'Apple, l'AppleUSBXHCIPCI.kext qu'il est sensé remplacer. Et donc, je pense qu'il devrait se comporter exactement pareil. Moins on s'éloigne de ce qu'Apple propose en standard, plus on a de chance d'éviter des comportements inattendus.

Pour l’anecdote; c'est comme ça que j'ai résolu un problème de manque d'alimentation des ports USB 2 de mon portable (genre le Finder qui se plaint que le périphérique n'est pas assez alimenté alors que c'est une simple clé USB). Il manquait tout simplement des champs dans l'injecteur .


----------



## polyzargone (4 Septembre 2016)

Barijaona a dit:


> Est-ce que l'explication graphique ci-après des valeurs que j'ai reporté dans pListEdit est un peu plus claire ?
> 
> Identifiants des périphériques PCI
> 
> ...



Tu noteras que l'identifiant PCI *A12F* est déjà présent dans l'info.plist de l'AppleUSBXHCIPCI.kext dans IOKitPersonalities > *AppleUSBXHCISPT1* mais pas dans IOKitPersonalities >  *AppleUSBXHCILPTH* comme c'est le cas dans l'injecteur de fjlagd .


----------



## gradou (4 Septembre 2016)

@ "chef" polyzargone :

Non, mais mes OS 10.11 et 10.12 sont sur des disques différents (et non sur des partitions du disque) : that's the reason why j'ai deux efi, et puis j'aime bien (par habitude) démarrer en sélectionnant le disque souhaité via le bios. Il n'y a que pour windows 10 que je navigue dans le menu clover (dispo avec la temporisation du disque El Capitan)... Mais pour le disque Sierra, je n'ai pas mis de temporisation, donc pas de menu clover. tout ça c'est un peu ma soupe, mais j'en conviens c'est pas le plus simple... mais j'm'en va étudier de près ce que tu préconises qui m'a l'air bien, bien propre !!

Comme j'ai été un bon élève (lol) j'ai fait un kext pour ma Z170-M Plus... et ça marche... parce que j'ai seulement adapté avec Xcode votre Kext pour la Z170X...

Bon, je vais regarder le tuto (vous êtes déchainés les mecs !!!, J'arrive plus à suivre avec vous deux, mais quel PIED !!!!) Faudrait peut-être faire un peu la sieste parce qu'on va finir sur les genoux, nous autres !!- en parlant de pied-)

@ "chef" Barijaona :
Ils sont très explicites tes tableaux et on voit bien la manip, une question cependant : c'est quel info.plist que t'édites avec Plistedit pro (qu'est pas gratuit, c'est pour ça que je préfère XCode


----------



## polyzargone (4 Septembre 2016)

gradou a dit:


> Non, mais mes OS 10.11 et 10.12 sont sur des disques différents (et non sur des partitions du disque)





Non mais j'avais bien compris que c'était des disques différents ! Moi c'est pareil, mes OS X sont sur des disques différents (sauf Mavericks et Yosemite qui se partage le même). Mais ça ne change strictement rien à l'affaire . Ce que je veux dire, c'est que c'est inutile d'avoir des Clover partout dans chaque partition EFI de chaque disque.

M'enfin, comme tu dis, c'est ta soupe  !



gradou a dit:


> c'est quel info.plist que t'édites avec Plistedit pro



Celui de l'injecteur de fjlagd j'imagine ? Après, on va pas se mentir et personne ici n'a créé les injecteurs . Ils viennent tous plus ou moins de là .


----------



## gradou (4 Septembre 2016)

J'suis convaincu j'vais boire ma soupe et en préparer une meilleure à ta sauce, j'ai regardé ça pose en effet aucun pb et c'est bien plus simple !!

Et un kext pour ASUS Z170M-Plus, bon d'accord c'était pas le plus compliqué à faire avec la matière que vous aviez fournie !!

https://www.dropbox.com/s/8cw9dsn35l1g845/AsusZ170M_Injector.kext.zip?dl=0

Ayé, j'ai pigé avec l'édition de l'info.plist de l'x99_injector.kext : merci pour toutes ces explications, ça s'éclaircit sérieusement et, je l'espère, pour ceux qui s'intéressent au sujet !!


----------



## polyzargone (4 Septembre 2016)

gradou a dit:


> Et un kext pour ASUS Z170M-Plus, bon d'accord c'était pas le plus compliqué à faire avec la matière que vous aviez fournie !!
> 
> https://www.dropbox.com/s/8cw9dsn35l1g845/AsusZ170M_Injector.kext.zip?dl=0
> 
> Ayé, j'ai pigé avec l'édition de l'info.plist de l'x99_injector.kext : merci pour toutes ces explications, ça s'éclaircit sérieusement et, je l'espère, pour ceux qui s'intéressent au sujet !!



En fait, le plus long et le plus pénible, c'est surtout d'identifier les ports et les adresses. Ensuite, c'est pas si compliqué que ça en à l'air .

En revanche, je serais d'avis de partir sur la v2 pour créer son propre injecteur parce que la version X99_Injector.kext, il lui manque des trucs et je n'ai toujours pas compris pourquoi il y était question d'AHCI…


----------



## gradou (4 Septembre 2016)

polyzargone a dit:


> En revanche, je serais d'avis de partir sur la v2 pour créer son propre injecteur parce que la version X99_Injector.kext, il lui manque des trucs et je n'ai toujours pas compris pourquoi il y était question d'AHCI…



A partir de la V.2 :

https://www.dropbox.com/s/lx9fxvbdas74c9u/AsusZ170-M_Injector_v2.kext.zip?dl=0


----------



## Barijaona (4 Septembre 2016)

Réglons d'abord la question des outils :
- IOJones est une bonne alternative à IO Registry Explorer, qui est développé par Apple. Je cite IOJones car IO Registry Explorer n'est plus fourni d'office avec Xcode et est désormais inclus dans un téléchargement séparé réservé aux développeurs enregistrés. Utiliser un logiciel acquis légalement pour faire un hackintosh me parait défendable, mais redistribuer sans autorisation un logiciel Apple ne l'est sûrement pas…
-  effectivement, on peut utiliser Xcode plutôt que pListEditPro. Il faut juste se souvenir du click droit permettant d'accéder à l'option "Show Row Keys/Values" 

D'accord avec @polyzargone : inclure un contrôleur AHCI ne sert pas à grand chose dans notre affaire.

Par contre, non, non, il n'est absolument pas nécessaire de chercher à dupliquer tout ce qu'il y a dans AppleUSBXHCIPCI.kext ! Pour utiliser le vocabulaire de la programmation objet, tout ce que nous faisons, c'est définir une sous-classe de AppleUSBXHCIPCI, donc nous héritons de tous les comportements de la classe mère et du coup il est inutile et potentiellement contre-productif de redéfinir ceux-ci…

Du coup, voici une version simplifiée du kext. @gradou, peux-tu confirmer qu'elle fonctionne tout aussi bien ?

Complément d'information pour ceux qui suivent cette discussion et pourraient se demander de quel AppleUSBXHCIPCI on parle : l'Info.plist de notre kext obéit à la même structure que celui de celui situé à /System/Library/Extensions/IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBXHCIPCI/Contents/Info.plist


----------



## Barijaona (4 Septembre 2016)

gradou a dit:


> *Vitesse USB-C et USB 3-1 : 5gb/s (version de base ... !!)
> *Comment tester les ports internes et dois je le faire ? (j'ai testé les ports de la carte et du boitier) photo jointe
> 
> 
> ...



@gradou, tu n'as pas mis sur ton schéma l'adresse des deux ports USB3.1 : y avait-il une difficulté particulière pour les identifier ?


----------



## nicolasf (5 Septembre 2016)

J'ai essayé ce matin de débrancher tous les ports USB sauf celui, en interne, du Bluetooth et ça ne marche pas mieux. Je pensais m'en tirer avec un bricolage de ce genre, mais il va falloir mettre les mains dans le cambouis.


----------



## gradou (5 Septembre 2016)

Barijaona a dit:


> Réglons d'abord la question des outils :
> 
> -  effectivement, on peut utiliser Xcode plutôt que pListEditPro. Il faut juste se souvenir du click droit permettant d'accéder à l'option "Show Row Keys/Values"
> 
> ...


----------



## gradou (5 Septembre 2016)

Barijaona a dit:


> @gradou, tu n'as pas mis sur ton schéma l'adresse des deux ports USB3.1 : y avait-il une difficulté particulière pour les identifier ?



Oui, je sais pas où y sont dans ioregistry; ils fonctionnent (avec Sierra) cependant à la vitesse de l'USB3 5Gb/s et n'acceptent pas l'USB 2


----------



## gradou (5 Septembre 2016)

Je viens de tester la V.3, tout bien sauf un port USB 3 de la carte : le SS05-HS05... qui ne fonctionne qu'en USB2... alors que, je viens de vérifier il fonctionne correctement avec ta v.1...
Finalement je viens de redémarrer avec le disque USB 3 branché et là il est reconnu en USB 3 avec la v.3 ....
Je l'ai débranché, rebranché et il est bien toujours là.
Signé le stakhanoviste-testeur (j'rigole, bien sûr, en fait j'suis bien content !!   )


----------



## gradou (5 Septembre 2016)

Barijaona a dit:


> Réglons d'abord la question des outils :
> Utiliser un logiciel acquis légalement pour faire un hackintosh me parait défendable, mais redistribuer sans autorisation un logiciel Apple ne l'est sûrement pas…



C'est sûr, t'as raison, surtout que fabriquer du Hackintosh(s), ça c'est VRAIMENT légal ça !!!!!


----------



## gradou (5 Septembre 2016)

*Là, maintenant,* j'ai envie de faire un petit point à l'attention de ceux qui disposent d'une Z170 et qui, comme moi, ont rencontré des problèmes avec le fonctionnement des ports USB de leur machine.

Si vous le souhaitez donc :

*  Tout d'abord mettre en oeuvre le (1°) d'ici : http://forums.macg.co/threads/hackintosh-skylake-usb-el-capitan-sierra.1284304/) c'est pour aider à repérer les ports USB de la machine;

*  Ensuite, à l'aide de IoRegistryExplorer (ou ioJones), repérer les ports physiques de la machine (carte et boitier). Pour cela il faut se positionner sur XHC@14 (ne pas hésiter à descendre assez bas dans les lignes de IoRegistry.. ou iojones). Il y a des indications du style HS01(02,03...), SS01(02,03...) qui, lorsque vous aurez placé votre device USB 2 puis USB 3 successivement dans un des ports , seront respectivement renseignés. Notez quelque part le nom du port repéré, par ex : HS03, et en cliquant dessus, les data du port dans la fenêtre à droite : ici : 03000000 
	

		
			
		

		
	





Bon, c'est marrant à faire, hein, et ben puisque ça vous a amusé, vous allez le faire pour tous les ports de la machine... Ouarfff !!!

Mais là où on a de la chance, c'est que, grâce à nos deux chefs : *Barijaona et Polyzargone,* on dispose maintenant de kexts tout cuits. Y'a qu'à les télécharger et à les adapter avec pListEditPro :

*   Pour cela on clique droit sur le kext-->afficher le contenu du paquet--->contents-->clic-droit Info.plist et choisir l'appli qui va bien plistedit ou Xcode (avec pour ce dernier la remarque de Barijaona plus haut : _"effectivement, on peut utiliser Xcode plutôt que pListEditPro. Il faut juste se souvenir du click droit permettant d'accéder à l'option "Show Row Keys/Values"_ )

On ouvre un document qui a cette bouille :




On déroule la ligne cochée IOKitPersonalities et ensuite celle cochée : iMac17,1-XHC, ensuite on clique sur la ligne cochée IOProviderMergeProperties. Là on a une ligne port-count : on clique sur le chiffre le plus à droite et on renseigne avec la valeur "data" la plus élevée que l'on aura trouvé en repérant les ports comme indiqué ci-dessus.

En dessous il y a la ligne "ports". On se souvient que l'on a le droit de ne conserver que 15 ports au max (c'est expliqué pourquoi plus haut). c'est là qu'on renseigne les ports que l'on a repérés (les USB 2 en HS--, les USB 3 en SS--) pour chaque port on renseigne sa valeur "Data" (port data 0xxxxxxx) et la caractéristique du port : UsbConnector : 1 pour les ports qui ne sont qu'USB2, 3 pour les autres qu'ils soient USB2 sur USB3 (HS--) ou USB 3 (SS--). Y'en a d'autres mais bon, pas sûr qu'ils nous soient utiles...

Normalement, vous sauvegardez le machin et vous avez un "kext" personnalisé à votre machine.

*  Vous le mettrez dans le clover-->kexts-->qui va (vont) bien : 10.11, 10.12, others...). Vous aurez enlevé, s'il y était, USBinjectAll de partout, : des Clover-->kexts, de S/L/E, de L/E... de la lune etc.

* Et puis vous *configurerez* votre config.plist (que j'ouvre avec cloverconfigurator pour ma part) :

           On est sur un *SMBIOS iMac 17,1* et il faut suivre les recommandations de *Polyzargone ici :

http://forums.macg.co/threads/hackintosh-skylake-usb-el-capitan-sierra.1284304/#post-13058680*
et là :
* http://forums.macg.co/threads/hackintosh-skylake-usb-el-capitan-sierra.1284304/#post-13058723*

*  Et pis on vire les Kernel and Kext Patches correspondant aux modifications des limites de ports *genre* : "Name : AppleUSBXHCIPCI, Find : xxxxxxxxx, Replace : xxxxxxxxx, Comment : Increase xx port limit to xx in AppleUSBXHCIPCI *" ou autre de ce genre.
*
*  Et pis on fait ça : de *Barijaona* :
"  Dans l'optique de contourner les éventuels injecteurs spécifiques à l'iMac17,1, il faut mettre un patch Clover dans la rubrique *ACPI > DSDT fixes :
Comment : Rename XHC1 to XHC
Find : 58484331
Replace : 584843*    "

*  On "save".

Voilà (de toute façon les 2 chefs veillent au grain et diront ce qui ne va, éventuellement, pas dans ce texte...)

Ce message est sans doute un peu trop détaillé pour ceux qui sont accoutumés à farfouiller dans tous ces outils, qu'ils ne prennent donc pas ce texte comme "non mais, y nous prend pour des nazes ce gradou  !!", mais pour faciliter la tâche (j'espère) de ceux qui démarrent un projet...

Pour ma part j'ai adopté cette démarche pour adapter ces kexts à deux cartes Asus (Asus Z170M-Plus et H170i-plus D3) et ça fonctionne ! (et j'suis pas un lion !!)

*MERCI A BARIJOANA ET POLYZARGONE*


----------



## polyzargone (5 Septembre 2016)

gradou a dit:


> En dessous il y a la ligne "ports". On se souvient que l'on a le droit de ne conserver que 15 ports au max (c'est expliqué pourquoi plus haut). c'est là qu'on renseigne les ports que l'on a repérés (les USB 2 en HS--, les USB 3 en SS--) pour chaque port on renseigne sa valeur "Data" (port data 0xxxxxxx) et *la caractéristique du port : UsbConnector : 1 pour les ports qui ne sont qu'USB2, 3 pour les autres qu'ils soient USB2 sur USB3 (HS--) ou USB 3 (SS--)*. Y'en a d'autres mais bon, pas sûr qu'ils nous soient utiles...



Il y a une petite confusion là . Les valeurs 0, 3 ou 255 (pas de 1) de l'UsbConnector n'ont rien à voir avec la nature du port ni sa vitesse (USB 2 ou USB 3 voire USB-C).

Pour compléter ce que disais @Barijaona :



Barijaona a dit:


> la distinction entre 0 et 3 d'une part et 255 d'autre part n'est pas fondamentale sur le plan fonctionnel : elle permet juste de mieux distinguer entre ports externes et internes ; si tu te trompes, ça ne devrait pas empêcher les ports de fonctionner



• 0 et 3 = externes : ceux qu'on trouve sur les connecteurs arrières de la carte mère.

• 255 = Internes : ceux qu'on trouve sur les connecteurs internes - les internal USB headers - de la carte mère.

Dans le cas de la Z170X-Gaming 5, il s'agit des F_USB30_1, F_USB30_2, F_USB1 et F_USB2.

Et effectivement comme le disais @Barijaona, si tu te trompes ça n'est pas bien grave, tu auras juste ce genre de surprise .


----------



## Barijaona (5 Septembre 2016)

gradou a dit:


> C'est sûr, t'as raison, surtout que fabriquer du Hackintosh(s), ça c'est VRAIMENT légal ça !!!!!



Pour un usage privé sans but lucratif, à condition d'avoir obtenu légalement le soft (tu as un vrai Mac par ailleurs ou tu es abonné au programme développeur), on est dans une zone grise : https://openclassrooms.com/forum/sujet/la-legalite-de-l-hackintosh

Par contre, redistribuer à des tiers un soft sans avoir l'autorisation des ayant-droits, c'est du piratage et les tribunaux ne te louperont pas.


----------



## polyzargone (5 Septembre 2016)

Si ça peut vous "détendre", il suffit d'aller ici : https://developer.apple.com/download/more/

N'importe qui peut s'inscrire *gratuitement* et y télécharger le Hardware_IO_Tools_for_Xcode_7.3.dmg qui contient (entre autres) IORegistry Explorer .


----------



## gradou (5 Septembre 2016)

*(Modification du post précédent intégrant en* *gras* *les premières motifs apportées)*

*Là, maintenant,* j'ai envie de faire un petit point à l'attention de ceux qui disposent d'une Z170 et qui, comme moi, ont rencontré des problèmes avec le fonctionnement des ports USB de leur machine.

Si vous le souhaitez donc :

*  Tout d'abord mettre en oeuvre le (1°) d'ici : http://forums.macg.co/threads/hackintosh-skylake-usb-el-capitan-sierra.1284304/) c'est pour aider à repérer les ports USB de la machine;

*  Ensuite, à l'aide de IoRegistryExplorer (ou ioJones), repérer les ports physiques de la machine (carte et boitier). Pour cela il faut se positionner sur XHC@14 (ne pas hésiter à descendre assez bas dans les lignes de IoRegistry.. ou iojones). Il y a des indications du style HS01(02,03...), SS01(02,03...) qui, lorsque vous aurez placé votre device USB 2 puis USB 3 successivement dans un des ports , seront respectivement renseignés. Notez quelque part le nom du port repéré, par ex : HS03, et en cliquant dessus, les data du port dans la fenêtre à droite : ici : 03000000 
	

		
			
		

		
	

Voir la pièce jointe 110572


Bon, c'est marrant à faire, hein, et ben puisque ça vous a amusé, vous allez le faire pour tous les ports de la machine... Ouarfff !!!

Mais là où on a de la chance, c'est que, grâce à nos deux chefs : *Barijaona et Polyzargone,* on dispose maintenant de kexts tout cuits. Y'a qu'à les télécharger et à les adapter avec pListEditPro :

*   Pour cela on clique droit sur le kext-->afficher le contenu du paquet--->contents-->clic-droit Info.plist et choisir l'appli qui va bien plistedit ou Xcode (avec pour ce dernier la remarque de Barijaona plus haut : _"effectivement, on peut utiliser Xcode plutôt que pListEditPro. Il faut juste se souvenir du click droit permettant d'accéder à l'option "Show Row Keys/Values"_ )

On ouvre un document qui a cette bouille :

Voir la pièce jointe 110573


On déroule la ligne cochée IOKitPersonalities et ensuite celle cochée : iMac17,1-XHC, ensuite on clique sur la ligne cochée IOProviderMergeProperties. Là on a une ligne port-count : on clique sur le chiffre le plus à droite et on renseigne avec la valeur "data" la plus élevée que l'on aura trouvé en repérant les ports comme indiqué ci-dessus.

En dessous il y a la ligne "ports". On se souvient que l'on a le droit de ne conserver que 15 ports au max (c'est expliqué pourquoi plus haut). c'est là qu'on renseigne les ports que l'on a repérés (les USB 2 en HS--, les USB 3 en SS--) pour chaque port on renseigne sa valeur "Data" (port data 0xxxxxxx) et la caractéristique du port : UsbConnector :  *0 et 3 = externes : ceux qu'on trouve sur les connecteurs arrières de la carte mère et ceux du boitier. *
*•*_* 255 = Internes : ceux qu'on trouve sur les connecteurs internes - les internal USB headers - de la carte mère. (Dans le cas de la Z170X-Gaming 5, il s'agit des F_USB30_1, F_USB30_2, F_USB1 et F_USB2.)   (cf rectifications apportées par polyzargone)*_

Normalement, vous sauvegardez le machin et vous avez un "kext" personnalisé à votre machine.

*  Vous le mettrez dans le clover-->kexts-->qui va (vont) bien : 10.11, 10.12, others...). Vous aurez enlevé, s'il y était, USBinjectAll de partout, : des Clover-->kexts, de S/L/E, de L/E... de la lune etc.

* Et puis vous *configurerez* votre config.plist (que j'ouvre avec cloverconfigurator pour ma part) :

           On est sur un *SMBIOS iMac 17,1* et il faut suivre les recommandations de *Polyzargone ici :

http://forums.macg.co/threads/hackintosh-skylake-usb-el-capitan-sierra.1284304/#post-13058680*
et là :
* http://forums.macg.co/threads/hackintosh-skylake-usb-el-capitan-sierra.1284304/#post-13058723*

*  Et pis on vire les Kernel and Kext Patches correspondant aux modifications des limites de ports *genre* : "Name : AppleUSBXHCIPCI, Find : xxxxxxxxx, Replace : xxxxxxxxx, Comment : Increase xx port limit to xx in AppleUSBXHCIPCI *" ou autre de ce genre.
*
*  Et pis on fait ça : de *Barijaona* :
  "  Dans l'optique de contourner les éventuels injecteurs spécifiques à l'iMac17,1, il faut mettre un patch Clover dans la rubrique *ACPI > DSDT fixes :
Comment : Rename XHC1 to XHC
Find : 58484331
Replace : 584843*    "

*  On "save".

Voilà (de toute façon les 2 chefs veillent au grain et diront ce qui ne va, éventuellement, pas dans ce texte...)

Ce message est sans doute un peu trop détaillé pour ceux qui sont accoutumés à farfouiller dans tous ces outils, qu'ils ne prennent donc pas ce texte comme "non mais, y nous prend pour des nazes ce gradou  !!", mais pour faciliter la tâche (j'espère) de ceux qui démarrent un projet...

Pour ma part j'ai adopté cette démarche pour adapter ces kexts à deux cartes Asus (Asus Z170M-Plus et H170i-plus D3) et ça fonctionne ! (et j'suis pas un lion !!)

*MERCI A BARIJOANA ET POLYZARGONE*


----------



## nicolasf (5 Septembre 2016)

Ouah, merci pour votre boulot tous les trois ! 

Voilà qui devrait me simplifier le travail, pour mon hackintosh et pour le futur article qui ira avec.

Petite question, je suis actuellement sur un Mac Pro3,1 et non sur un iMac 17,1. Ça change quelque chose ? Je ferais mieux de changer ?


----------



## gradou (5 Septembre 2016)

Barijaona a dit:


> Pour un usage privé sans but lucratif, à condition d'avoir obtenu légalement le soft (tu as un vrai Mac par ailleurs ou tu es abonné au programme développeur), on est dans une zone grise : https://openclassrooms.com/forum/sujet/la-legalite-de-l-hackintosh
> 
> Par contre, redistribuer à des tiers un soft sans avoir l'autorisation des ayant-droits, c'est du piratage et les tribunaux ne te louperont pas.


Quel soft par exemple ? Bien sûr pas les softs genre Final Cut ou autres c'est évident, mais pour ce qui nous occupe, pour  lesquels c'est pas bien ?


----------



## gradou (5 Septembre 2016)

nicolasf a dit:


> Ouah, merci pour votre boulot tous les trois !
> 
> Voilà qui devrait me simplifier le travail, pour mon hackintosh et pour le futur article qui ira avec.
> 
> Petite action, je suis actuellement sur un Mac Pro3,1 et non sur un iMac 17,1. Ça change quelque chose ? Je ferais mieux de changer ?



Les chefs vont sûrement te répondre, mais moi y m'ont fait changer mon iMac 14,2 pour un 17,1, alors ils ont *intérêt* à dire la même chose pour toi, sinon... Je crois que vu que dans les kexts qu'ils ont fabriqués, c'est basé sur du iMac 17,1 faudra p'têt y passer sauf s'il est possible d'adapter le kext à ton smbios... m'enfin on va voir ce qu'ils disent...


----------



## gradou (5 Septembre 2016)

polyzargone a dit:


> I
> • 255 = Internes : ceux qu'on trouve sur les connecteurs internes - les internal USB headers - de la carte mère.
> 
> Dans le cas de la Z170X-Gaming 5, il s'agit des F_USB30_1, F_USB30_2, F_USB1 et F_USB2.
> ...


Ah oui OK pour la surprise ! Mais ceci étant, avec le pote nicolasf on a mis une carte Wifi-Bluetooth dans le machin. Et il faut, pour avoir le bluetooth la connecter à un port USB interne (enfin c'est ce que j'ai compris), mais l'inconvénient c'est que le HSH ne tenait alors la mise en veille qu'une seconde et ainsi en boucle, pénible donc... Est ce que ce pb a à voir avec la configuration des ports internes ou non ? Si oui, comment qu'on les repère ceux ports là (j'avais bien quelque chose de ce genre en HS08 : *USB20hub*, mais maintenant je l'ai plus : viré !), et qu'est ce qu'on leur fait subir ? Sinon, et ben, j'sais pas !!


----------



## Barijaona (5 Septembre 2016)

gradou a dit:


> Quel soft par exemple ? Bien sûr pas les softs genre Final Cut ou autres c'est évident, mais pour ce qui nous occupe, pour  lesquels c'est pas bien ?



Publier sur un site une version modifiée d'OS X ou d'un autre logiciel Apple serait de la contrefaçon


----------



## mp_ (5 Septembre 2016)

Une mine d'or ce sujet, voilà qui pourrait bien régler mes problèmes d'USB !


----------



## gradou (5 Septembre 2016)

polyzargone a dit:


> Il y a une petite confusion là . Les valeurs 0, 3 ou 255 (pas de 1) de l'UsbConnector n'ont rien à voir avec la nature du port ni sa vitesse (USB 2 ou USB 3 voire USB-C).


Ma confusion doit provenir de cela, non ?
"

Change the name before the Package entry to match the port you're defining here
Change the comment alongside the entry to describe what port it's for
Change the code after "UsbConnector" to be one of the following:
0 if it's a regular USB2 connector ("Type A") or a USB2 motherboard header
3 if it's a regular USB3 connector ("Type A") or a USB3 motherboard header
10 if it's a USB3 Type C connector
255 if it's an internal Bluetooth device or other "proprietary" type of connector
There are more values in the ACPI specification, but I'd be surprised if you needed them.

Source : http://www.tonymacx86.com/threads/10-11-0-10-11-3-skylake-starter-guide.179221/ *§7.7.2*

De toute façon comme tu dis on s'en fout, à preuve dans les kexts que vous avez fait y'a que du 3 et que dans un kext modifié pour Asus, croyant bien faire j'ai mis du 0 pour des ports uniquement USB 2 et qu'il n'y a pas de pb pour autant, sans doute y'en aurait il si on mettait du 255 au mauvais endroit !!


----------



## polyzargone (5 Septembre 2016)

nicolasf a dit:


> Petite question, je suis actuellement sur un Mac Pro3,1 et non sur un iMac 17,1. Ça change quelque chose ? Je ferais mieux de changer ?



Oui, ça change beaucoup de chose !

C'est principalement au niveau de la gestion d'énergie en fait mais aussi, comme on a pu le constater, sur la bonne reconnaissance des cartes graphiques.

En règle générale, il vaut mieux avoir un SMBios qui colle au mieux avec sa configuration. Le site everymac.com ou bien l'excellent MacTracker sont de bonnes sources d'informations pour faire son choix.

Par exemple, les MacPro3,1 utilisent des sockets LGA775 (Ceux des Core2Duo et de certains Pentium 4) alors que les MacPro6,1 (ceux de 2013 "tube") ont des LGA2011. Du coup, les processeurs attendus sur ces configurations ne sont pas les mêmes et OS X adapte la gestion de l'énergie en conséquence.

Alors utiliser un SMBios de MacPro3,1 sur une architecture Skylake… le moins que l'on puisse dire c'est que c'est pas top  !

C'est encore plus vrai sur les portables, notamment en ce qui concerne les cartes graphiques. Un MacBookPro5,1 est sensé utiliser une GeForce 9600 GT alors forcément, si on a une Intel HD 5300, ça coince .

Une dernière chose mais pas des moindre cher Nicolas : tu risques d'être bien embêté si tu tentes d'installer Sierra sur ta config Skylake en utilisant un SMBios de MacPro3,1.

Tu n'ignores pas que ces modèles ne sont plus supportés, n'est-ce pas  ?

Donc oui clairement, tu ferais mieux d'en changer .



gradou a dit:


> Je crois que vu que dans les kexts qu'ils ont fabriqués, c'est basé sur du iMac 17,1 faudra p'têt y passer sauf s'il est possible d'adapter le kext à ton smbios.



En ce qui concerne l'injecteur, si pour une raison ou une autre il doit être utilisé avec un SMBios différent de celui d'un iMac17,1, il faudra changer ces valeurs dans l'info.plist :

• IOKitPersonalities > iMac17,1-XHC par "SMBios choisi"-XHC

• IOKitPersonalities > model par "SMios choisi"

Exemple :

• IOKitPersonalities > iMac14,2-XHC

• IOKitPersonalities> model : iMac14,2

Cela étant dit, le SMBios d'un iMac17,1 est le meilleur choix pour une config en Skylake et l'iMac14,2 est généralement le plus adapté pour celles en Haswell.



gradou a dit:


> Ah oui OK pour la surprise ! Mais ceci étant, avec le pote nicolasf on a mis une carte Wifi-Bluetooth dans le machin. Et il faut, pour avoir le bluetooth la connecter à un port USB interne (enfin c'est ce que j'ai compris), mais l'inconvénient c'est que le HSH ne tenait alors la mise en veille qu'une seconde et ainsi en boucle, pénible donc... Est ce que ce pb a à voir avec la configuration des ports internes ou non ?



Ça ressemble beaucoup à un "Instant wake" et ça doit pouvoir se régler en patchant la DSDT…


----------



## gradou (5 Septembre 2016)

polyzargone a dit:


> Ça ressemble beaucoup à un "Instant wake" et ça doit pouvoir se régler en patchant la DSDT…



Et c'est r'parti pour un tour !!!!!!!!!


----------



## Barijaona (5 Septembre 2016)

gradou a dit:


> ceci étant, avec le pote nicolasf on a mis une carte Wifi-Bluetooth dans le machin. Et il faut, pour avoir le bluetooth la connecter à un port USB interne (enfin c'est ce que j'ai compris), mais l'inconvénient c'est que le HSH ne tenait alors la mise en veille qu'une seconde et ainsi en boucle, pénible donc...





polyzargone a dit:


> Ça ressemble beaucoup à un "Instant wake" et ça doit pouvoir se régler en patchant la DSDT…



Je n'ai pas très bien compris : le problème de sortie de veille se manifeste-t-il sur la configuration de Nicolas bâtie avec Multibeast ou cette carte Wifi-Bluetooth a-t-elle été testée sur la configuration actuelle de gradou ?

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…

Dans un cas comme celui-là, en tout cas, cela vaut le coup de mettre 255 comme type de UsbConnector dans le kext


----------



## gradou (5 Septembre 2016)

Barijaona a dit:


> Je n'ai pas très bien compris : le problème de sortie de veille se manifeste-t-il sur la configuration de Nicolas bâtie avec Multibeast ou cette carte Wifi-Bluetooth a-t-elle été testée sur la configuration actuelle de gradou ?
> 
> 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…
> 
> Dans un cas comme celui-là, en tout cas, cela vaut le coup de mettre 255 comme type de UsbConnector dans le kext



C'est sur celle de Gradou...(Nicolas a, je crois d'autres pb avec).
Je le mets sur quel port le 255 parce que les ports internes je ne sais pas les repérer...


----------



## Barijaona (5 Septembre 2016)

Dans IOJones, la vue IOService ne montre pas à quel port le Bluetooth est rattaché ?


----------



## gradou (5 Septembre 2016)

Voilà ce que j'ai :




Tiens je me rends compte que bluetooth n'est plus activé... (?) Le wifi qui est sur la même carte fonctionne tout bien, lui...


----------



## nicolasf (5 Septembre 2016)

polyzargone a dit:


> Donc oui clairement, tu ferais mieux d'en changer .



Bon OK, OK, je changerais.

Il suffit de changer dans la config de Clover, c'est bien ça ? 


Je ne sais plus pourquoi j'avais fait ce choix, sans doute parce que c'est un défaut quelque part. Et comme ça marchait comme ça… Pour Sierra, je me disais que ce n'était pas un souci, vu que ce n'est pas un vrai Mac. Mais si iMac17,1 est mieux adapté, alors pourquoi pas. Au fond, je m'en fiche


----------



## Barijaona (5 Septembre 2016)

@gradou : je n'avais pas vu qu'il y avait un filtre sur ta copie d'écran…  Regarde dans la partie USB, tu devrais trouver que la carte (Broadcom) est rattachée à un port USB.


----------



## gradou (5 Septembre 2016)

Dans PCList DPCIManager j'ai ça :


La partie USB, c'est ça ?


----------



## gradou (5 Septembre 2016)

nicolasf a dit:


> Bon OK, OK, je changerais.
> 
> Il suffit de changer dans la config de Clover, c'est bien ça ?


Oui, dans cloverconfigurator, SMBIOS, tu cliques sur la baguette magique et après tu choisis iMac et après le 17,1. Si avec ton smbios MacPro tu étais configuré pour iMessage, il faudra que tu conserves ton serial number, ton smuuid et ton board serial number, et après, avant de redémarrer (sinon écran noir) il faudra lancer ce que dit polyzargone ici :
http://forums.macg.co/threads/hackintosh-skylake-usb-el-capitan-sierra.1284304/#post-13058723


----------



## Barijaona (5 Septembre 2016)

J'ai un peu du mal à suivre là…En principe, tu devrais avoir AppleBroadcomBluetoothHostController qui apparaît dans l'arborescence IOBluetoothHCIController.

Ta carte Wifi-BT est bien installée dans un port PCI Express x1 ? (il paraît qu'il y a des problèmes si on l'installe sur des ports plus rapides).
Les dongles usb wifi et bluetooth qui figurent dans ta signature ont bien été enlevés ?


----------



## polyzargone (5 Septembre 2016)

@gradou 

L'idéal serait que tu poste un lien avec ton dossier EFI/CLOVER + une sortie IOJones (File > Save as…). Pense juste à retirer les infos sensibles de ton SMBios .


----------



## gradou (5 Septembre 2016)

@chef Barijaona :
Ouarff  sur le :  "j'ai un peu de mal à suivre là..." Mon pauvre, faut reconnaitre que je suis un peu spéc...


Sinon la réponse est oui aux deux questions.


----------



## polyzargone (5 Septembre 2016)

En fait, j'imaginais que tu avais fait F4 au menu de boot de Clover et que tu avais des fichiers dans EFI/CLOVER/ACPI/origin .

C'est plutôt ça qui m'intéresse .

PS : Ça sent bien le MultiBeast tout ça mais bon, c'est pas le sujet …


----------



## polyzargone (5 Septembre 2016)

Barijaona a dit:


> Le patch clover de Pike R. Alpha peut être une autre solution (du moins si on a une seule carte graphique additionnelle) qui permet d'éviter de désactiver SIP (je sais, je suis obsédé  ).





polyzargone a dit:


> blablablabla
> 
> (…)
> 
> ...



N'empêche, je serais curieux de savoir si ce patch fonctionne ou pas…

Comme je disais, un membre a eu le même problème et pour lui, ça n'a pas marché mais je ne suis pas du tout certain ça été correctement fait. Et malgré ce que j'ai pu écrire plus haut quant à la différence de nature du patch et le fait qu'il soit destiné aux configs utilisant un SMBios de MacPro6.1, j'ai quand même un doute.

Si tu as un peu de temps @gradou, ce serait pas mal de l'essayer (en remettant l'original de /System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AppleGraphicsDevicePolicy.kext) pour voir ce que ça donne…


----------



## polyzargone (5 Septembre 2016)

nicolasf a dit:


> Je ne sais plus pourquoi j'avais fait ce choix, *sans doute parce que c'est un défaut quelque part*. Et comme ça marchait comme ça…



MultiBeast  !



nicolasf a dit:


> Pour Sierra, je me disais que ce n'était pas un souci, vu que ce n'est pas un vrai Mac.



Le matos n'est pas Apple mais l'installeur de macOS l'est à 100% lui. FakeSMC.kext permet à un Hackintosh de se faire passer pour un Mac, le SMBios que tu choisis sert à lui donner une "identité". Et c'est cette identité que l'installeur va vérifier.

C'est d'ailleurs pour ça qu'on peut très facilement installer Sierra sur du matos qui n'est officiellement pas supporté, sachant qu'avec Sierra, cette limitation porte quasi exclusivement sur le type de CPU et son support ou non des instructions SSE4.1.

En tout cas, ça l'est sur un Hackintosh. Sur un Mac c'est un peu plus compliqué…


----------



## gradou (5 Septembre 2016)

@ polyzargone
En fait c'est plutôt celui là que tu voulais :
https://www.dropbox.com/s/15d8xemy0plznb8/EFI.zip?dl=0


----------



## nicolasf (5 Septembre 2016)

polyzargone a dit:


> Le matos n'est pas Apple mais l'installeur de macOS l'est à 100% lui. FakeSMC.kext permet à un Hackintosh de se faire passer pour un Mac, le SMBios que tu choisis sert à lui donner une "identité". Et c'est cette identité que l'installeur va vérifier.



Oui, c'est logique. Je vais changer alors, mais je crois me souvenir de défauts avec les profils d'iMac. J'ai lu tellement de choses que je sais plus quoi/comment/pourquoi…


----------



## gradou (5 Septembre 2016)

polyzargone a dit:


> Si tu as un peu de temps @gradou, ce serait pas mal de l'essayer (en remettant l'original de /System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AppleGraphicsDevicePolicy.kext) pour voir ce que ça donne…


Attends une seconde, tu veux que je fasse quoi et pourquoi ?
Ce /System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AppleGraphicsDevicePolicy.kext il existe déjà dans mon S/L/E...
Faudrait me faire commencer par le début, non ? 
Est ce que tu veux dire que je remplace le kext en question qui est dans mon système par celui qui se trouve dans un dossier AGCKextBackUp sur mon bureau ? Mais après je vais me retrouver avec un écran noir.... 
Et j'essaye quoi, moi le stakhanoviste-testeur un peu bêta !


----------



## polyzargone (5 Septembre 2016)

nicolasf a dit:


> je crois me souvenir de défauts avec les profils d'iMac



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).



gradou a dit:


> Attends une seconde, tu veux que je fasse quoi ?
> Ce /System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AppleGraphicsDevicePolicy.kext il existe déjà dans mon S/L/E...
> Faudrait me faire commencer par le début, non ?



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


----------



## gradou (5 Septembre 2016)

nicolasf a dit:


> Oui, c'est logique. Je vais changer alors, mais je crois me souvenir de défauts avec les profils d'iMac. J'ai lu tellement de choses que je sais plus quoi/comment/pourquoi…


+1


----------



## gradou (5 Septembre 2016)

polyzargone a dit:


> 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).
> 
> ...


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é !!


----------



## polyzargone (5 Septembre 2016)

Barijaona a dit:


> 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 ).


```
#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.


----------



## nicolasf (5 Septembre 2016)

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…


----------



## polyzargone (5 Septembre 2016)

gradou a dit:


> 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é !!



Précisément. Et accessoirement, laisser le SIP activé en permanence puisqu'aucun kext n'aura été modifié (et ça, @Barijaona y tient ).


----------



## polyzargone (5 Septembre 2016)

nicolasf a dit:


> 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…



Ç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" .


----------



## gradou (5 Septembre 2016)

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 ?


----------



## gradou (5 Septembre 2016)

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...


----------



## nicolasf (5 Septembre 2016)

gradou a dit:


> 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 ?


----------



## gradou (6 Septembre 2016)

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...


----------



## polyzargone (6 Septembre 2016)

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 .

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 ?


```
pmset -g
pmset -g assertions
```


----------



## gradou (6 Septembre 2016)

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":


----------



## polyzargone (6 Septembre 2016)

DSDT v2 (vire l'ancienne).


----------



## gradou (6 Septembre 2016)

polyzargone a dit:


> 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...


----------



## Barijaona (6 Septembre 2016)

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)


----------



## polyzargone (6 Septembre 2016)

Barijaona a dit:


> 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…


----------



## gradou (6 Septembre 2016)

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 ?


----------



## polyzargone (6 Septembre 2016)

gradou a dit:


> 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…


----------



## gradou (6 Septembre 2016)

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 ?.


----------



## nicolasf (6 Septembre 2016)

gradou a dit:


> qui est branché, sinon j'aurais pas d'USB 2 sur le boitier, non ?



Justement, ce sont les ports externes qui sont identifiés, je suppose…


----------



## gradou (6 Septembre 2016)

nicolasf a dit:


> 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...


----------



## gradou (6 Septembre 2016)

Alors que, comme de juste, avec USBinjectAll le port supportant le bluetooth était visible, il ne l'est plus avec le kext modifié... et bien sûr le bluetooth n'est plus activé. Je suis bien resté dans la limite. Est ce parce que je l'ai renseigné 255... Je vais essayer avec 3, non ?, ce qui m'ennuie c'est le tarif de PlistEditPro...


----------



## gradou (6 Septembre 2016)

polyzargone a dit:


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


Ce que je voulais dire au début, c'est que en testant les ports externes, je n'arrivais pas à "activer" ce port HS08, d'où l'expression "sur lequel on peut rien brancher" en externe !!! Je me suis ensuite douté que c'était un port interne dont on ne s'est plus soucié par la suite... Voici, voilà...


----------



## gradou (6 Septembre 2016)

Barijaona a dit:


> 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.
> 
> ...



Multibeast n'est pas si méchant que cela : il m'a permis, au début de disposer d'injectusball et du patch qui va bien, sans lesquels je n'aurais pour ma part jamais réussi à déclarer les ports, ni même à les faire fonctionner. Après ce que m'a ou non installé multibeast l'a été selon mon bon vouloir (je ne suis pas très expert mais je ne suis pas non plus complètement idiot) surtout en ce qui concerne L/E et a fortiori S/L/E et rien de ce que tu indiques n'est installé à quelque endroit que ce soit....  
Et puis pour installer Sierra je n'ai pas du tout utilisé Multibeast (qui n'existe pas pour Sierra) mais plutôt cela : http://www.insanelymac.com/forum/files/file/572-macos-sierra-hd/#commentsStart
Je pense néanmoins qu'il faut arrêter de dénigrer, même gentiment, et même si c'est dans le vent, multibeast  car il rend bien service pour démarrer et cela n'empêche pas ensuite de chercher à évoluer pour résoudre des problèmes qui de toute façon, Multibeast ou autres, ne sont pas résolus...
Après on peut avoir ou non un regard critique sur les pratiques commerciales qui accompagnent la démarche de ce site, et regretter que des kexts puissent être installés à des endroits où l'on préfèrerait qu'ils ne soient pas mais bon voilà... Multibeast permet de faire fonctionner un HackIntosh, ensuite à chacun de gérer ce qui empêche par exemple de démarrer avec le SIP activé...
Mais je m'éloigne (un peu) du sujet qui nous rassemble et je ne vais donc pas tarder à sortir


----------



## Barijaona (6 Septembre 2016)

@gradou : peux tu faire des sauvegardes avec IOJones et les poster ici en ce qui concerne les deux configurations :
- avec InjectUSBall
- avec le kext hacké par nos soins ?

Ajoute aussi le kext en son état actuel.


----------



## gradou (6 Septembre 2016)

J'ai donc ajouté le port HS14 (0e000000) avec 0 comme UsbConnector dans le kext_v2 de polyzargone modifié pour mon Asus170M-Plus (dans lequel se trouve ma carte Wifi-BT - celle dont dispose également Nicolasf) , suis resté dans la limite des 15, j'ai enlevé dans ACPI > DSDT fixes :
Comment : Rename XHC1 to XHC
Find : 58484331
Replace : 584843
Remis la V.1 de la DSDT de polyzargone.
Résultat :
Le bluetooth est fonctionnel, la mise en veille est, pour le moment normale; par contre, peut être parce que lors de la mise en veille les ports USB sont "fermés", je ne peux le "réveiller" qu'avec le bouton de démarrage du Hack (pas par le clavier-souris filaire)

Le kext modifié :

https://www.dropbox.com/s/xxmmgitwf1d10d8/AsusZ170-M_Injector_v2.kext.zip?dl=0

Sauvegarde ioRegistry avec Kext modifié

https://www.dropbox.com/s/45kb5sflz32deol/Asus iMac 17,1.zip?dl=0

(je ne le laisse pas longtemps, ne sera plus accessible à partir de 14h45)


----------



## polyzargone (6 Septembre 2016)

gradou a dit:


> Je pense néanmoins qu'il faut arrêter de dénigrer, même gentiment, et même si c'est dans le vent, multibeast car il rend bien service pour démarrer et cela n'empêche pas ensuite de chercher à évoluer pour résoudre des problèmes qui de toute façon, Multibeast ou autres, ne sont pas résolus...



Mouais… Non, désolé mais il faut continuer à dire quelles sont ses limites et pourquoi il est préférable de s'en passer .

Mais ça, c'est valable pour tous les outils de ce genre, pas uniquement pour MultiBeast …

M'enfin, t'as raison, c'est pas le sujet.



gradou a dit:


> 'ai donc ajouté le port HS14 (0e000000) avec 0 comme UsbConnector dans le kext_v2 de polyzargone modifié pour mon Asus170M-Plus (dans lequel se trouve ma carte Wifi-BT - celle dont dispose également Nicolasf) , suis resté dans la limite des 15, j'ai enlevé dans ACPI > DSDT fixes



Là, je pige pas vraiment parce que ce port était déjà déclaré dans les différents injecteurs qu'on a vu ici… Du coup, je comprends pas ce qui a changé. Et logiquement, c'est 255 que tu aurais dû mettre.

Mais si j'ai bien compris, ta carte WIFI/BT n'était pas branchée sur la GA-Z170X mais sur l'Asus170M-Plus ? Pourtant, c'est bien de la Gigabyte dont on parle depuis le début ?

Et fais gaffe parce que la DSDT, elle est prévue pour la Z170X et pas pour la Z170M (enfin si le dossier EFI/CLOVER/ACPI/origin est le bon)…



gradou a dit:


> Sauvegarde ioRegistry avec Kext modifié
> 
> https://www.dropbox.com/s/45kb5sflz32deol/Asus iMac 17,1.zip?dl=0
> 
> *(je ne le laisse pas longtemps, ne sera plus accessible à partir de 14h45)*



Ah ben tant pis .


----------



## gradou (6 Septembre 2016)

Si je ne laisse pas longtemps la sauvegarde ioregistry c'est parce que je ne sais pas si c'est embêtant qu'on voit (d'autres que vous bien sûr) le N° de série du matériel. Si tu me dis que y'a pas de pb je laisserai le truc bien sûr.

Concernant les embrouilles dont je suis responsable, et je m'en excuse auprès de vous, cela s'explique parce que, concernant le problème du bluetooth, c'est la Z170M que cela concerne, je suis désolé de ne pas l'avoir précisé. Cependant le port interne de la Z170X était bien, du moins je le pense ainsi, le HS08. Pour la Z170M, le port qui supporte le bluetooth est indiqué sur le HS14 qui est branché sur de l'USB 2 interne. Mais j'ai essayé le 255 et je ne voyais pas le port et puis j'ai mis du 0 et là je l'ai vu !!!

C'est donc le kext de la Z170M que j'ai adapté. Pour la DSDT, c'est depuis le début que je la teste sur la Z170M, je suis con(fus).

En fait sur la Z170X, j'en suis resté à l'utilisation de ton kext v.2 ou la v.3 de Bari. Je n'ai pas utilisé le patch du gars dont je me souviens plus le nom mais qui permet d'espérer qu'avec ça on sera exempté de procédure "black screen" pour une prochaine mise à jour (je ne l'ai utilisé que sur la Z170M). En effet, pour le moment je trouve que tout va très bien sur ce matos avec le Kext "made in Barizargone", et je n'ai aucun pb de veille ou autre sur ce Hack, je voulais juste faire propre et utile concernant la gestion de l'USB.

Mais peut être n'est ce pas votre point de vue, et je suis bien disposé à travailler encore avec vous pour contribuer à améliorer les choses jusqu'à ce que vous soyez satisfaits l'un et l'autre 

Pour ma part ce qui m'apparait, c'est que vos kexts USB vont bien sur les différentes Z170 où j'ai pu les tester.

Quant à la SSDT (sur la Z170M), l'inconvénient d'appuyer sur le bouton de démarrage pour réveiller la bête est relatif. Des fois c'est plus embêtant de le réveiller juste en bougeant involontairement la souris, alors, question de point de vue. En effet l'EFI/CLOVER/ACPI/origin transmis est bien celui de la Z170... 

Mais le temps investi est utile de toute façon, non ?

A mon avis donc ceux qui ont une Z170 peuvent trouver leur bonheur avec votre kext usb skylake et suivre la procédure indiquée ici :

http://forums.macg.co/threads/hackintosh-skylake-usb-el-capitan-sierra.1284304/page-3#post-13059366

PS : concernant tonymacx86 ma réaction est uniquement motivée par le profond respect  que j'ai pour tous ceux qui font quelque chose qui m'épate, donc respect pour l'équipe tonymacx !! Et toi et Barijaona vous m'épatez : donc respect !!


----------



## polyzargone (6 Septembre 2016)

À mon avis et pour que les lecteurs comprennent bien de quoi on parle, tu devrais te concentrer uniquement sur la Gigabyte Z170X Gaming 5.

Parce que là, j'y comprends plus rien et j'ai un peu la flemme de tout relire depuis le début .

Bref, je sais pas comment ça pourrait se goupiller, mais tu devrais mettre ça au propre et faire un post où tu récapitules les étapes en ce qui concerne la Z170X *uniquement* avec les infos/fichiers que tu as utilisés (schéma de la carte mère, ports/adresses, injecteur et DSDT) et comment tu as procédé.

Peut-être qu'un modérateur pourrait ensuite faire le ménage histoire qu'on ait pas 36 posts qui parlent de cartes-mères différentes avec des problèmes/solutions tout aussi différents.



gradou a dit:


> PS : concernant tonymacx86 ma réaction est uniquement motivée par le profond respect que j'ai pour tous ceux qui font quelque chose qui m'épate, donc respect pour l'équipe tonymacx !!



Il n'y a rien d'épatant dans ce que fait Tonymacx86 et c'est bien là le problème . Tout ce que font Unibeast/MultiBeast et leurs copains, c'est juste appliquer des scripts sans aucune intelligence ni optimisation derrière.

Maintenant, il faut bien distinguer leurs outils de leurs forums où je suis le premier à le reconnaître, on trouve d'excellentes informations et des gens extrêmement compétents .


----------



## polyzargone (6 Septembre 2016)

gradou a dit:


> Si je ne laisse pas longtemps la sauvegarde ioregistry c'est parce que je ne sais pas si c'est embêtant qu'on voit (d'autres que vous bien sûr) le N° de série du matériel. Si tu me dis que y'a pas de pb je laisserai le truc bien sûr.



Non. Je ne crois pas que ce genre d'info y figure. En tout cas, pas que je sache.


----------



## gradou (6 Septembre 2016)

polyzargone a dit:


> Non. Je ne crois pas que ce genre d'info y figure. En tout cas, pas que je sache.


Et ben si justement regarde bien !!!


----------



## polyzargone (6 Septembre 2016)

Ah oui effectivement 

Bon après, le seul Serial Number ne suffit pas pour "pirater" ton SMBios. Il faut également le SmUUID et le Board Serial Number.


----------



## Barijaona (6 Septembre 2016)

gradou a dit:


> En fait sur la Z170X, j'en suis resté à l'utilisation de ton kext v.2 ou la v.3 de Bari. Je n'ai pas utilisé le patch du gars dont je me souviens plus le nom mais qui permet d'espérer qu'avec ça on sera exempté de procédure "black screen" pour une prochaine mise à jour (je ne l'ai utilisé que sur la Z170M). En effet, pour le moment je trouve que tout va très bien sur ce matos avec le Kext "made in Barizargone", et je n'ai aucun pb de veille ou autre sur ce Hack, je voulais juste faire propre et utile concernant la gestion de l'USB.



Et bien tant mieux, car c'est la Z170X qui m'intéresse en priorité  J'espère que cela résoudra aussi le problème de connexion de la carte Bluetooth de @nicolasf et ne polluons pas davantage ce fil consacré à l'USB avec des problèmes autres.

@gradou, je te suggère de modifier ta signature en listant séparément tes deux hacks, ça aidera ceux qui cherchent des solutions à leurs problèmes.


----------



## gradou (6 Septembre 2016)

*Dernière mise au point concernant la procédure pour se faire un kext skylake-usb perso :*

Il est nécessaire, tout d'abord, de repérer les ports USB de la machine :

1-a) Utiliser le kext Rehabman USBinjectAll (l'installer avec kext utility qui pour moi va bien : il répare les permissions L/E et S/L/E, met à jour le cache système et bien sûr installe le(s) kext(s))... Veiller à ce que config.plist ait bien en rtvariables : csr-active-config 0x67 = SIP Disabled completely ((désactivation du SIP). Ce kext est utile pour disposer dans un premier temps de ports USB 2 et 3 fonctionnels et , en principe (!!), dans un 2ème temps, à mettre en oeuvre une solution (2) plus pérenne...


1-b) Pour El Capitan 10.11.6, à l'aide de cloverconfigurator (c'est ce que j'utilise pour modifier le config.plist (il y a d'autres moyens)), aller section : Kernel and Kext Patches et "rentrer" :


Name : AppleUSBXHCIPCI, Find : 83BD8CFEFFFF10, Replace : 83BD8CFEFFFF1F, Comment :

Increase 15 port limit to 30 in AppleUSBXHCIPCI


1-c) Pour Sierra (beta publique 7 au 1/09/2016) idem ci dessus mais :


Name : AppleUSBXHCIPCI, Find : *83BD74FFFFFF10*, Replace : *83BD74FFFFFF1F*, Comment :

10.12 DP5 change 15 port limit to 20 in AppleUSBXHCIPCI



2) Ensuite, à l'aide de IoRegistryExplorer (ou ioJones), repérer les ports physiques de la machine (carte et boitier). Pour cela il faut se positionner sur XHC@14 (ne pas hésiter à descendre assez bas dans les lignes de IoRegistry.. ou iojones). Il y a des indications du style HS01(02,03...), SS01(02,03...) qui, lorsque vous aurez placé votre device USB 2 puis USB 3 successivement dans un des ports , seront respectivement renseignés. Notez quelque part le nom du port repéré, par ex : HS03, et en cliquant dessus, les data du port dans la fenêtre à droite : ici : 
	

		
			
		

		
	






Bon, c'est marrant à faire, hein, et ben puisque ça vous a amusé, vous allez le faire pour tous les ports de la machine... Ouarfff !!!




3) Mais là où on a de la chance, c'est que, grâce à  *Barijaona et Polyzargone,* on dispose maintenant d'un kext tout cuit. Y'a qu'à les télécharger et à les adapter avec pListEditPro
:
Il est ici :https://www.dropbox.com/s/1niqnoh8lr5qxrv/Z170_Injector_v3.kext.zip?dl=0

* Pour cela on clique droit sur le kext-->afficher le contenu du paquet--->contents-->clic-droit Info.plist et choisir l'appli qui va bien plistedit ou Xcode (avec pour ce dernier la remarque de Barijaona plus haut : "effectivement, on peut utiliser Xcode plutôt que pListEditPro. Il faut juste se souvenir du click droit permettant d'accéder à l'option "Show Row Keys/Values" )

On ouvre un document qui a cette bouille :





On déroule la ligne cochée IOKitPersonalities et ensuite celle cochée : iMac17,1-XHC, ensuite on clique sur la ligne cochée IOProviderMergeProperties. Là on a une ligne port-count : on clique sur le chiffre le plus à droite et on renseigne avec la valeur "data" la plus élevée que l'on aura trouvé en repérant les ports comme indiqué ci-dessus.


En dessous il y a la ligne "ports". On se souvient que l'on a le droit de ne conserver que 15 ports au max (c'est expliqué pourquoi plus haut). c'est là qu'on renseigne les ports que l'on a repérés (les USB 2 en HS--, les USB 3 en SS--) pour chaque port on renseigne sa valeur "Data" (port data 0xxxxxxx) et la caractéristique du port : UsbConnector : *0 et 3 = externes : ceux qu'on trouve sur les connecteurs arrières de la carte mère et ceux du boitier. *

*• 255 = Internes : ceux qu'on trouve sur les connecteurs internes - les internal USB headers - de la carte mère. (Dans le cas de la Z170X-Gaming 5, il s'agit des F_USB30_1, F_USB30_2, F_USB1 et F_USB2.) (cf rectifications apportées par polyzargone)*


Normalement, vous sauvegardez le machin et vous avez un "kext" personnalisé à votre machine.


3) Vous le mettrez dans le clover-->kexts-->qui va (vont) bien : 10.11, 10.12, others...). Vous aurez enlevé, s'il y était, USBinjectAll de partout, : des Clover-->kexts, de S/L/E, de L/E... de la lune etc.


* Et puis vous *configurerez* votre config.plist (que j'ouvre avec cloverconfigurator pour ma part) :

On est sur un *SMBIOS iMac 17,1* et il faut suivre les recommandations de *Polyzargone ici :*
*http://forums.macg.co/threads/hackintosh-skylake-usb-el-capitan-sierra.1284304/#post-13058680*

et là :

*http://forums.macg.co/threads/hackintosh-skylake-usb-el-capitan-sierra.1284304/#post-13058723*

On remarquera qu'un dossier est alors créé sur le bureau, il contient le kext original remplacé. Celui ci sera utile pour être remis dans S/L/E si l'on décide par la suite d'utiliser le patch ci dessous.

On peut en effet aussi essayer, par la suite, ce patch qui devrait éviter de refaire la procédure décrite dans le lien ci dessus à chaque mise à jour du système. :

* Mettre dans Kernel and Kexts Patches :

Name : AppleGraphicsDevicePolicy
Find : 626F6172642D6964
Replace : 626F6172642D6978
Comment : AppleGraphicsDevicePolicy (board-id) Patch (c) Pike R. Alpha

NB de Polyzargone : En ce qui concerne l'injecteur, si pour une raison ou une autre il doit être utilisé avec un SMBios différent de celui d'un iMac17,1, il faudra changer ces valeurs dans l'info.plist du kext :

• IOKitPersonalities > iMac17,1-XHC par "SMBios choisi"-XHC

• IOKitPersonalities > model par "SMios choisi"

Exemple :

• IOKitPersonalities > iMac14,2-XHC

• IOKitPersonalities> model : iMac14,2

Cela étant dit, le SMBios d'un iMac17,1 est le meilleur choix pour une config en Skylake et l'iMac14,2 est généralement le plus adapté pour celles en Haswell.

* Ensuite on vire les Kernel and Kext Patches correspondant aux modifications des limites de ports *genre* : "Name : AppleUSBXHCIPCI, Find : xxxxxxxxx, Replace : xxxxxxxxx, Comment : Increase xx port limit to xx in AppleUSBXHCIPCI *" ou autre de ce genre.*


* Et pis on fait ça : de *Barijaona* : _FACULTATIF (J'l'avais mis, ça marchait, j'l'ai enlevé ça marche aussi_ )

" Dans l'optique de contourner les éventuels injecteurs spécifiques à l'iMac17,1, il faut mettre un patch Clover dans la rubrique *ACPI > DSDT fixes :*

*Comment : Rename XHC1 to XHC*

*Find : 58484331*

*Replace : 584843* "


* On "save".

Voilà, bon courage !!

PS : ailleurs dans ce topic il y a des pistes pour régler des problèmes de veille, bonne lecture (faut être patient et un "peu" de temps)


----------



## polyzargone (6 Septembre 2016)

gradou a dit:


> Je n'ai pas utilisé le patch du gars dont je me souviens plus le nom mais qui permet d'espérer qu'avec ça on sera exempté de procédure "black screen" pour une prochaine mise à jour (je ne l'ai utilisé que sur la Z170M).



Eh bien tu devrais  ! Parce qu'avec un SMBios d'iMac17,1, ça risque fort d'arriver…


----------



## polyzargone (6 Septembre 2016)

gradou a dit:


> Ils sont ici :
> 
> version Barijaona :
> https://www.dropbox.com/s/1niqnoh8lr5qxrv/Z170_Injector_v3.kext.zip?dl=0
> ...



Ah ben me v'la obligé d'héberger le fichier ad vitam æternam  !

Plus sérieusement, celle de @Barijaona suffira. Inutile d'embrouiller les lecteurs avec deux versions .



gradou a dit:


> " Dans l'optique de contourner les éventuels injecteurs spécifiques à l'iMac17,1, il faut mettre un patch Clover dans la rubrique *ACPI > DSDT fixes :*
> 
> *Comment : Rename XHC1 to XHC*
> 
> ...



Ça, ce n'est pas nécessaire sur la Z170X Gaming 5 puisque le device (XHC) est déjà correctement nommé dans la DSDT.


----------



## nicolasf (6 Septembre 2016)

Si vous avez un fichier qui convient, faites-moi signe et on l'hébergera jusqu'à la fin des temps sur les serveurs de MacG. Je l'utiliserai dans mon futur article (il viendra, promis), avec votre permission bien entendu.

Et permettez-moi encore une fois de vous remercier pour votre travail.


----------



## polyzargone (6 Septembre 2016)

nicolasf a dit:


> faites-moi signe et on l'hébergera jusqu'à la fin des temps sur les serveurs de MacG.



Alors ça c'est sympa. Du coup, longue vie à Macg  !


----------



## gradou (6 Septembre 2016)

polyzargone a dit:


> Alors ça c'est sympa. Du coup, longue vie à Macg  !


Bon, ben ça veut dire quoi, j'y comprends rien : quel fichier ?


----------



## polyzargone (6 Septembre 2016)

gradou a dit:


> Mais là où on a de la chance, c'est que, grâce à *Barijaona et Polyzargone,* on dispose maintenant d'un kext tout cuit. Y'a qu'à les télécharger et à les adapter avec pListEditPro
> :
> Il est ici :
> 
> https://www.dropbox.com/s/1niqnoh8lr5qxrv/Z170_Injector_v3.kext.zip?dl=0



Celui-ci j'imagine.

À condition qu'il soit complet et que tous les ports/adresses y soient correctement identifiés et définis, quitte à en supprimer quelques uns pour rester dans la limite des 15 ports.

C'est pour ça qu'il faudrait qu'on sache à quoi correspondent les headers internes USB 2 et USB 3.


----------



## gradou (6 Septembre 2016)

T'as vérifié pour ce que je t'ai dit au sujet de mes réticences concernant ioregistryexplorer ?

Sinon j'ai ça avec USBinjectAll et le patch pour Sierra installés :







Au fait je viens d'essayer le patch du père Pike R. Alpha avec Sierra (Z170X, j'ai pas mis Sierra sur la Z170M) : il ne fonctionne pas... El Capitan 10.11.6 (Z170X et Z170M) : oui.


----------



## Barijaona (7 Septembre 2016)

gradou a dit:


> Mais là où on a de la chance, c'est que, grâce à  *Barijaona et Polyzargone,* on dispose maintenant d'un kext tout cuit. Y'a qu'à les télécharger et à les adapter avec pListEditPro
> :
> Il est ici :https://www.dropbox.com/s/1niqnoh8lr5qxrv/Z170_Injector_v3.kext.zip?dl=0





polyzargone a dit:


> Celui-ci j'imagine.
> 
> À condition qu'il soit complet et que tous les ports/adresses y soient correctement identifiés et définis, quitte à en supprimer quelques uns pour rester dans la limite des 15 ports.
> 
> C'est pour ça qu'il faudrait qu'on sache à quoi correspondent les headers internes USB 2 et USB 3.



Si l'on en croit le manuel Gigabyte, il n'est pas complet et il nous manque 3 ports USB2, 2 ports USB3, ainsi que les 2 ports USB3.1

soit (en supposant que le SSDT-5.aml est bon et que MacIASL n'a pas de problème à le lire) : HS01, HS02, HS08, SS01, SS02, USR1 et USR2

je subodore que les groupes :
- HS01 + SS01 (adresses Hexa <01000000> et <11000000> ?)
- HS02 + SS02 (adresses Hexa <02000000> et <12000000> ?)
occupent chacun un header interne (F_USB30_1 et F_USB30_2 ?)

et que l'on a les groupes  :
- SS07 + USR1 sur le port USB-C rouge
- HS08 + SS08 + USR2 sur le port USB-A rouge
sans que nous ayons encore la possibilité d'accéder à USR1 et USR2, vu que macOS ne supporte que USB3.1 rev A…

Je pourrais regarder tout cela de plus près lors du montage de ma machine.


----------



## Barijaona (7 Septembre 2016)

gradou a dit:


> Au fait je viens d'essayer le patch du père Pike R. Alpha avec Sierra (Z170X, j'ai pas mis Sierra sur la Z170M) : il ne fonctionne pas... El Capitan 10.11.6 (Z170X et Z170M) : oui.



C'est le risque avec les patches kext… Si Apple change le kext, ils peuvent devenir inopérants.
Je ne sais pas si ça marche, mais je pense que patcher le DSDT pour renommer GFX0 en GFX1 (et éventuellement PEGP en IGPU) pourrait être une solution plus pérenne.

Rappel à destination de ceux qui n'ont pas tout lu jusqu'ici : ce point ne concerne pas l'USB proprement dit, mais le problème d'écran noir avec le SMBIOS iMac17,1.


----------



## gradou (7 Septembre 2016)

Barijaona a dit:


> Si l'on en croit le manuel Gigabyte, il n'est pas complet et il nous manque 3 ports USB2, 2 ports USB3, ainsi que les 2 ports USB3.1
> 
> soit (en supposant que le SSDT-5.aml est bon et que MacIASL n'a pas de problème à le lire) : HS01, HS02, HS08, SS01, SS02, USR1 et USR2
> 
> ...



Je ne sais pas si ça peut aider, à tout hasard...




Source : http://www.tonymacx86.com/threads/10-11-0-10-11-3-skylake-starter-guide.179221/


----------



## polyzargone (7 Septembre 2016)

Barijaona a dit:


> C'est le risque avec les patches kext… Si Apple change le kext, ils peuvent devenir inopérants.
> Je ne sais pas si ça marche, mais je pense que patcher le DSDT pour renommer GFX0 en GFX1 (et éventuellement PEGP en IGPU) pourrait être une solution plus pérenne.



J'ai regardé /System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AppleGraphicsDevicePolicy.kext/Contents/MacOS/*AppleGraphicsDevicePolicy* d'El Capitan et Sierra et la valeur board-id (en hexadécimal) que le patch est sensé remplacé par board-ix est présente dans les deux. Donc normalement, le binaire n'a pas changé sur ce point.

@gradou : es-tu bien sûr que le patch n'a pas fonctionné (il faut parfois redémarrer plusieurs fois) ? As-tu reconstruit le cache système entre temps ?

Sinon au pire, l'AGDPfix fonctionne sur Sierra, ça a été confirmé.

Concernant le patch DSDT, j'ai déjà changé GFX0 par IGPU dans celle que j'ai posté donc soit c'est à cause de ça (mais je ne vois pas pourquoi), soit c'est à cause du PEGP que j'ai laissé tel quel. Mais là aussi, comme il n'en est pas fait mention dans l'info.plist de *AppleGraphicsDevicePolicy*, ça ne devrait pas entrer en jeu.

Cela dit, cette DSDT est peut-être issue d'une Asus Z170M et pas d'une Gigabyte Z170X .


----------



## gradou (7 Septembre 2016)

polyzargone a dit:


> J'ai regardé /System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AppleGraphicsDevicePolicy.kext/Contents/MacOS/*AppleGraphicsDevicePolicy* d'El Capitan et Sierra et la valeur board-id (en hexadécimal) que le patch est sensé remplacé par board-ix est présente dans les deux. Donc normalement, le binaire n'a pas changé sur ce point.
> 
> @gradou : es-tu bien sûr que le patch n'a pas fonctionné (il faut parfois redémarrer plusieurs fois) ? As-tu reconstruit le cache système entre temps ?
> 
> ...



Je vais réessayer dans la soirée... Je pense en effet que la DSDT que j'ai utilisé pour la Z170X était celle que j'avais au préalable essayé avec la Z170M. Mais avec la Z170M je ne l'ai essayée qu'avec 10.11, pas avec Sierra. Et cette DSDT fonctionne également avec la Z170X 10.11 (je note toutefois une petite hésitation de la résolution à l'ouverture de session...) Ai je quelque chose à faire par rapport à ce problème ? ( Par exemple je pourrais apprendre à modifier une DSDT, si quelqu'un de gentil voulait bien me l'enseigner, mais peut être qu'il n'y en a pas ici des gentils !!!! )


----------



## polyzargone (7 Septembre 2016)

gradou a dit:


> Je pense en effet que la DSDT que j'ai utilisé pour la Z170X était celle que j'avais au préalable essayé avec la Z170M. Mais avec la Z170M je ne l'ai essayée qu'avec 10.11, pas avec Sierra.



Petite précision au cas où mais tous les fichiers placés dans EFI/CLOVER/ACPI/patched sont appliqués, quelque soit la version d'OS X.



gradou a dit:


> je pourrais apprendre à modifier une DSDT, si quelqu'un de gentil voulait bien me l'enseigner, mais peut être qu'il n'y en a pas ici des gentils !!!



C'est pas une question de gentillesse . C'est juste que personnellement, je n'ai jamais trouvé de guide clair, complet et relativement accessible sur le sujet. En français, n'en parlons même pas ! Et le sujet est tellement vaste et demande tellement de connaissances de la norme ACPI que résumer tout ça est impossible.

Il faut en plus avoir de sérieuses notions en développement pour comprendre comment tout ça fonctionne. Et très honnêtement, je n'y connais absolument rien (et j'avoue que même si c'est intéressant, c'est pas ce qui me passionne le plus dans le Hackintosh ).

Donc il faut lire le plus possible, faire des essais (perso, j'ai commencé "petit" en faisant des patchs pour les cartes graphiques non supportées) et se constituer une base de dépôts de patchs tout fait à utiliser dans MaciASL.

Je t'invite à lire ceci pour commencer.


----------



## gradou (7 Septembre 2016)

polyzargone a dit:


> Petite précision au cas où mais tous les fichiers placés dans EFI/CLOVER/ACPI/patched sont appliqués, quelque soit la version d'OS X.
> Je t'invite à lire ceci pour commencer.



Ce que je veux dire c'est que Sierra n'est pas installé sur la Z170M... donc y peut pas lire le patch 
Sinon merci pour ta réponse, je vais examiner ça de près, de toute façon c'est passionnant même si ça fait mal à la tête !!!


----------



## polyzargone (7 Septembre 2016)

gradou a dit:


> Sinon merci pour ta réponse, je vais examiner ça de près, de toute façon c'est passionnant même si ça fait mal à la tête !!!








 !​


----------



## gradou (7 Septembre 2016)

polyzargone a dit:


> J'ai regardé /System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AppleGraphicsDevicePolicy.kext/Contents/MacOS/*AppleGraphicsDevicePolicy* d'El Capitan et Sierra et la valeur board-id (en hexadécimal) que le patch est sensé remplacé par board-ix est présente dans les deux. Donc normalement, le binaire n'a pas changé sur ce point.
> 
> @gradou : *es-tu bien sûr que le patch n'a pas fonctionné (il faut parfois redémarrer plusieurs fois) ? As-tu reconstruit le cache système entre temps* ?
> 
> Sinon au pire, l'AGDPfix fonctionne sur Sierra, ça a été confirmé.



 Tout bien fait comme il faut, redémarré 5 ou 6 fois, et je confirme que sur mon matériel et sous Sierra : ne fonctionne pas !


----------



## ScOo'J (7 Septembre 2016)

j'essaye de vous suivre les gars mais c'est chaud (je suis plus que novice) 
mais vous faite du bon boulot continuez comme ça !!!


----------



## polyzargone (7 Septembre 2016)

ScOo'J a dit:


> j'essaye de vous suivre les gars mais c'est chaud



Te laisse pas impressionner non plus. Là, c'est pour avoir une config aux petits oignons mais il reste toujours ça :



gradou a dit:


> (1) Une solution qui fonctionne sur ce matériel mais sujette à des déboires éventuels au fil des mises à jour de l'OS...



Même si je suis d'accord pour dire que c'est pas la meilleure solution, je suis moins inquiet sur ces éventuels déboires au fil des MÀJ. C'est pas le top, mais je ne pense pas qu'on risque vraiment grand chose en s'en contentant .



gradou a dit:


> Tout bien fait comme il faut, redémarré 5 ou 6 fois, et je confirme que sur mon matériel et sous Sierra : ne fonctionne pas !



Bon ben il faudra probablement attendre un nouveau patch alors…

Sur ce, je vous laisse car apparemment, la Golden Master de Sierra est dispo  !!!


----------



## nicolasf (7 Septembre 2016)

polyzargone a dit:


> C'est pas le top, mais je ne pense pas qu'on risque vraiment grand chose en s'en contentant .



Je me faisais la réflexion : qu'est-ce qui peut se passer en utilisant cette solution et uniquement celle-ci ? Parce que sa simplicité me tente bien…


----------



## polyzargone (7 Septembre 2016)

nicolasf a dit:


> Je me faisais la réflexion : qu'est-ce qui peut se passer en utilisant cette solution et uniquement celle-ci ? Parce que sa simplicité me tente bien…



Ben honnêtement, je n'ai pas les compétences techniques nécessaires pour te répondre catégoriquement donc je vais te répondre sur ce que j'ai pu constater (ou pas) depuis que cette solution existe (soit un peu plus d'1 an maintenant) et la réponse est :

Personne ne s'est jamais plaint ou n'a eu de problèmes particuliers en l'utilisant. Que ce soit sur le plan des MÀJ ou sur le plan matériel (genre endommagement des ports USB).

Donc même si je suis persuadé que l'auteur du USBInjectALL.kext a d'excellentes raisons de recommander de ne l'utiliser que comme une solution provisoire, je crois qu'il faut relativiser .

Cela dit avec l'injecteur, tu devrais avoir une solution propre, pérenne et adaptée à ta configuration. Ce serait dommage de s'en passer .


----------



## nicolasf (8 Septembre 2016)

Aujourd'hui est le grand jour !

En attendant l'arrivée des nouveautés, je consacre un peu de temps au hackintosh. Et je vais commencer avec l'USB… souhaitez-moi bonne chance !



@polyzargone : je vais voir si j'arrive à utiliser l'injecteur alors. En fonction, je verrai ce que je recommande aux lecteurs.


----------



## nicolasf (8 Septembre 2016)

Alors, premier bilan à mi-parcours : 

- J'ai changé le SMBios pour l'iMac17,1, j'avais oublié le fix pour la carte graphique, mais heureusement que Clover peut modifier à la volée le paramètre au démarrage.
- J'ai installé le kext de RehabMan et levé la limite de 15 ports USB dans CloverConfigurator.
- Au redémarrage, je n'ai toujours pas de Bluetooth et le Magic Trackpad jusque-là relié via le port USB du clavier ne fonctionne plus.

Dans la console, j'ai ces messages qui apparaissent en permanence : 


```
08/09/2016 11:55:57,000 kernel[0]: 000633.578557 AppleUSB20HubPort@14820000: AppleUSBHostPort::disconnect: persistent enumeration failures
```


Du coup, je ne comprends pas : est-ce que je ne suis pas censé avoir tous les ports USB actifs ? 

J'ai essayé de comprendre l'étape suivante, mais dans le kext fourni ici, je n'ai pas tous les ports USB dans la liste. Je dois les ajouter ? J'hésite à avancer, puisque la première étape n'est pas bonne.

Des conseils ?


----------



## nicolasf (8 Septembre 2016)

Je viens de tester : en branchant l'USB du Bluetooth sur un port USB externe, l'erreur disparaît dans la Console et le Bluetooth est immédiatement fonctionnel. 

Bon, reste à savoir comment le faire fonctionner avec le port USB en interne maintenant…


----------



## nicolasf (8 Septembre 2016)

Dans la série « Je comprends pas ce qui se passe, mais ça marche » : j'ai inversé les deux ports USB 2 sur la carte-mère, celui qui va au Bluetooth et celui qui va à l'avant. Et là, même si ça n'a aucun sens : ça marche !

Je suis tenté d'en rester là : le kext USB Inject All en iMac17,1 et voir si ça marche bien. Pour l'instant, j'ai du Bluetooth et les ports USB, donc…


----------



## polyzargone (8 Septembre 2016)

À ce stade et puisque tous les ports semblent fonctionner (?), il faudrait que tu regardes dans IORegistry Explorer à quoi correspond chaque port de manière à déterminer les bonnes adresses. Ensuite, il faudrait adapter le kext en conséquence.



nicolasf a dit:


> J'ai essayé de comprendre l'étape suivante, mais dans le kext fourni ici, je n'ai pas tous les ports USB dans la liste. Je dois les ajouter ?



C'est pour ça que j'avais préconisé d'avoir un injecteur comprenant toutes les adresses .

Par ailleurs, il ne faut pas oublier que le kext en question dépasse déjà la limite des 15 ports. Il faudra donc soit en sacrifier, soit continuer à utilise le patch en plus (mais du coup, on perd tout l'intérêt de cette méthode ).



nicolasf a dit:


> Je viens de tester : en branchant l'USB du Bluetooth sur un port USB externe, l'erreur disparaît dans la Console et le Bluetooth est immédiatement fonctionnel.


`
Comment tu as fait pour connecter un port interne sur un port externe ? Les connecteurs ne devraient pas êtres les mêmes en principe, non ?



nicolasf a dit:


> Dans la série « Je comprends pas ce qui se passe, mais ça marche » : j'ai inversé les deux ports USB 2 sur la carte-mère, celui qui va au Bluetooth et celui qui va à l'avant. Et là, même si ça n'a aucun sens : ça marche !



Ouais, ça c'est bizarre…

Enfin bref . Pourrais-tu poster ton dossier EFI (en enlevant les infos sensibles de ton SMBios) + un IOReg ou IOJones ?


----------



## gradou (8 Septembre 2016)

polyzargone a dit:


> `
> Comment tu as fait pour connecter un port interne sur un port externe ? Les connecteurs ne devraient pas êtres les mêmes en principe, non ?


Simplement parce que le connecteur USB qui part de la carte PCI est un connecteur mini USB sur lequel on peut brancher un cable USB "normal" (et non pas seulement le câble fourni qui permet le raccordement au connecteur USB interne) qui permet de se connecter sur un port externe.


----------



## gradou (8 Septembre 2016)

@nicolasf : as tu identifié chaque port (externe déjà) de ton matériel (carte mère et boitier) en insérant dans chacun une clé USB 2 (ports seulement USB2), et une clé USB2 et ensuite une USB 3 dans les ports physiques USB 3 ?
Il faut que tu repères, avec ioregistry, quel N° de port est renseigné (HS--, SS--, etc.) à chaque introduction de clé, cela te donnera la liste de tes ports physiques. Sur la carte mère Z170X tu as : 4 USB2,  3 USB3 (qui comptent double puisque renseignés en USB2 également) : soit 10 ports, (il y a également un USB-C et un USB 3.1 : on s'en fout pour le moment y comptent pas..., y marchent pas avec 10.11), sur le boitier tu as 2 ports USB2 et 2 ports USB3, soit : 6 ports à renseigner = 16 ports au total + ton port USB interne Bluetooth = 17. Dans le kext tu rentres 15 ports (ceux qui te sont les plus pratiques) parmi ceux que tu as identifiés.
Le kext "fabriqué" ici n'est pas un kext universel comme peut l'être celui de rehabman, mais il est plus précis et, s'il est adapté à sa machine par l'utilisateur, plus pérenne.
Par exemple pour que USBinjectAll fonctionne il faut un patch dans kernel and kexts patches et ces patches ne sont pas les mêmes sous El Capitan ou sur Sierra, et il faut les trouver (pas si simple), et il en faudra sans doute de nouveaux lors d'ultérieures mises à jour.
L'idée est donc d'être moins dépendant... Vive la LIBERTE !!!! 
PS : avec Sierra les ports USB-C et USB 3.1 fonctionnent (à 5Gb/s) mais indépendamment du kext donc pas de pb !!


----------



## polyzargone (8 Septembre 2016)

gradou a dit:


> Simplement parce que le connecteur USB qui part de la carte PCI est un connecteur mini USB sur lequel on peut brancher un cable USB "normal" (et non pas seulement le câble fourni qui permet le raccordement au connecteur USB interne) qui permet de se connecter sur un port externe.



Ah OK ! Merci, j'ignorais ce détail .


----------



## nicolasf (8 Septembre 2016)

gradou a dit:


> Dans le kext tu rentres 15 ports (ceux qui te sont les plus pratiques) parmi ceux que tu as identifiés.



Je n'ai pas suivi toute cette procédure, mais là je suis perdu. Pourquoi se limiter à 15 ? Je pensais que l'idée était justement de lever la limite…


----------



## polyzargone (8 Septembre 2016)

nicolasf a dit:


> Pourquoi se limiter à 15 ?



Ça, c'est la faute d'Apple . C'est la nouvelle gestion de l'USB qu'elle a imposé sur El Capitan qui fait qu'on est tous limité à 15. Par tous, j'entends aussi bien les Hack que les Mac.

La procédure n'a pas pour but de faire sauter cette limite, elle sert juste à configurer correctement les bonnes adresses des ports USB de sorte que ceux-ci fonctionnent comme prévu et à la bonne vitesse.

Sur un Mac, ça n'est pas un problème en principe (tant qu'on utilise pas de cartes additionnelles avec/ou sans des contrôleurs un peu exotiques) mais sur un Hack, non seulement les adresses ne sont pas les mêmes mais en plus, les types de connecteurs sont différents (il n'y a plus de ports USB 2 depuis l'iMac 21,5" fin 2011 si je ne dis pas de bêtises) ce qui a pour conséquence qu'avec les kexts standards d'OS X, certains ports sont vus comme des USB 2 alors que ce sont des USB 3 ou même qu'ils ne sont pas vu du tout.

Sans parler du fait qu'il y a généralement plus de ports USB x sur les cartes mères des PC que sur celles des Mac.



nicolasf a dit:


> Je pensais que l'idée était justement de lever la limite…



Pour faire sauter la limite, il n'y a pas d'autres solutions que d'utiliser le patch ad hoc.


----------



## nicolasf (9 Septembre 2016)

polyzargone a dit:


> La procédure n'a pas pour but de faire sauter cette limite, elle sert juste à configurer correctement les bonnes adresses des ports USB de sorte que ceux-ci fonctionnent comme prévu et à la bonne vitesse.



Mais au début du récap de @gradou, on modifie le kernel pour augmenter la limite. Non ?

Je pensais précisément à ce passage : 



gradou a dit:


> 1-b) Pour El Capitan 10.11.6, à l'aide de cloverconfigurator (c'est ce que j'utilise pour modifier le config.plist (il y a d'autres moyens)), aller section : Kernel and Kext Patches et "rentrer" :
> 
> 
> Name : AppleUSBXHCIPCI, Find : 83BD8CFEFFFF10, Replace : 83BD8CFEFFFF1F, Comment :
> ...


----------



## Barijaona (9 Septembre 2016)

nicolasf a dit:


> Mais au début du récap de @gradou, on modifie le kernel pour augmenter la limite. Non ?
> 
> Je pensais précisément à ce passage :



Dans l'objectif d'une config finale ultra-stable même en cas de mise à jour, on augmente la limite provisoirement pour permettre l'identification exhaustive.

Mais ensuite, on sacrifie quelques ports  pour revenir dans la limite de 15 et on supprime le hack de dépassement de la limite


----------



## nicolasf (9 Septembre 2016)

Barijaona a dit:


> Dans l'objectif d'une config finale ultra-stable même en cas de mise à jour, on augmente la limite provisoirement pour permettre l'identification exhaustive.
> 
> Mais ensuite, on sacrifie quelques ports  pour revenir dans la limite de 15 et on supprime le hack de dépassement de la limite



Ah là d'accord, c'est ça que j'avais compris. Mais honnêtement, je trouve la suite bien compliquée et je m'en fiche d'appliquer la même augmentation de limite à chaque mise à jour. 

J'ai tort ?


----------



## polyzargone (9 Septembre 2016)

nicolasf a dit:


> Ah là d'accord, c'est ça que j'avais compris. Mais honnêtement, je trouve la suite bien compliquée et je m'en fiche d'appliquer la même augmentation de limite à chaque mise à jour.
> 
> J'ai tort ?



C'est plutôt que tu n'as pas bien compris .

On s'en fiche des mise à jour !

Ce que @Barijaona veut dire, c'est pas qu'on ré-applique le patch à chaque fois mais qu'on s'en sert *une fois* pour déterminer quels sont les ports dont on a besoin et du coup… quels ports on peut se permettre de sacrifier.

Dans tous les cas, MÀJ ou pas, l'objectif est bien de rester dans la limite des 15 ports fixée par Apple. Ce qui, in fine, devrait garantir une config stable.

En clair, tu ne peux pas avoir le beurre et l'argent du beurre sur ce coup-là .

Soit tu dépasses la limite avec le patch et tu conserves tous tes ports, soit tu sacrifies des ports.

Cela étant dit, rien ne t'empêche d'utiliser un Hub USB3 connecté à un de tes port USB 3. Ça permettrait de dépasser cette limite sans avoir à utiliser de patch .







nicolasf a dit:


> on modifie le kernel pour augmenter la limite. Non ?



Petite précision : c'est pas le Kernel qui est patché dans ce cas. C'est un kext. Plus précisément, c'est le fameux /System/Library/Extensions/IOUSBHostFamily.kext/Contents/PlugIns/*AppleUSBXHCIPCI.kext* dont on parle si souvent depuis le début .

Et si on veut vraiment pinailler, c'est le binaire /System/Library/Extensions/IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBXHCIPCI.kext/Contents/MacOS/AppleUSBXHCIPCI qui est


----------



## nicolasf (9 Septembre 2016)

polyzargone a dit:


> Soit tu dépasses la limite avec le patch et tu conserves tous tes ports, soit tu sacrifies des ports.



Mais précisément, c'est ça que je veux : le patch et tous les ports. Quel problème pourrais-je bien avoir ?


----------



## polyzargone (9 Septembre 2016)

Le problème du patch, c'est qu'il ne sert qu'à lever la limite. Il ne permet pas forcément de faire fonctionner tous les ports à la bonne vitesse.

Ça, c'est justement le rôle de l'injecteur.

Donc l'idéal, ça serait d'utiliser les deux si tu tiens à conserver tous tes ports et que ceux qui ont été identifiés, fonctionnent comme ils doivent.

Mais le truc, c'est que je ne sais pas si ça peut fonctionner ensemble… Il faudrait tester.

Mais il va falloir se faire une raison, l'injecteur est nécessaire quelque soit le cas de figure si tu veux que tout fonctionne correctement.


----------



## Barijaona (9 Septembre 2016)

Personnellement, je ne m'y fierais qu'à moitié : on voit bien qu'entre 10.11 et 10.12 l'adresse à modifier n'est pas la même, donc ce sera toujours plus risqué qu'une solution plus "respectueuse" de l'OS. Pour la GA-Z170X-Gaming 5, il ne reste à compléter que quelques ports, vu que @gradou a déjà fait le gros du travail, donc ce serait dommage d'en rester là (même si je comprends que toi et beaucoup d'autres préfériez ne pas vous lancer vous-même dans ces expérimentations)


----------



## Barijaona (9 Septembre 2016)

Oups, mon message et ceux de polyzargone se sont croisés. Mais je suis complètement d'accord avec lui : on ne peut pas avoir le beurre, l'argent du beurre et le sourire de la crémière (du moins par des moyens honorables ;-) ). En ce qui me concerne, je préfère la stabilité, surtout que je n'ai guère l'usage de tous ces ports.


----------



## polyzargone (9 Septembre 2016)

Petit HS et question aux modérateurs : la limite pour pouvoir éditer un message est de combien de temps et serait-il possible de l'augmenter ? Parce que là, c'est vraiment court, on ne peut plus éditer un post 2h après .


----------



## polyzargone (9 Septembre 2016)

Je reviens sur un point qui peut éventuellement prêter à confusion :

Il faut bien distinguer le patch Clover qui permet de faire sauter la limite des 15 ports et le USBInjectAll.kext qui permet d'activer tous les ports.

Si @gradou a pu déterminer ses adresses dans IORegistry Explorer, c'est pas grâce au patch Clover mais bien grâce à USBInjectAll.kext.

Autrement dit, n'utiliser que *le patch Clover* sans aucun kext (que ce soit USBInjectAll.kext ou un injecteur) *n'est pas suffisant pour que les ports fonctionnent correctement*.


----------



## nicolasf (9 Septembre 2016)

Oh, ça explique peut-être mon problème…

Je viens de me rendre compte que les deux ports USB 3 à l'avant, ceux que j'utilise le plus souvent, fonctionnent en USB 2, mais pas en USB 3. Dans ce dernier cas, le périphérique est alimenté, mais il ne "monte" pas sur le Mac.

Donc là j'ai pas le choix, faut que je me replonge dans les kext. Snif.



La bonne nouvelle, c'est que j'ai pas encore fini l'article d'installation, donc au moins je n'ai pas à tout réécrire.


----------



## polyzargone (9 Septembre 2016)

nicolasf a dit:


> mais il ne "monte" pas sur le Mac.



Choix de mot intéressant .


----------



## gradou (9 Septembre 2016)

M'enfin, c'est  quand même pas si compliqué !! J'y suis arrivé, donc n'importe qui un tant soit peu opiniâtre doit y arriver. Surtout que tout le boulot a été fait par nos deux amis, ce serait dommage de se priver de ce qu'ils ont fait. Et puis donc, pour ma part je me retrouve avec 5 ports usb3 parfaitement fonctionnels (donc 5 Usb2 itou) + 4 ports qui ne sont qu'usb2, sur un Mac "normal" y'en a combien (sur mon Mac Pro 2013 : 4; bon d'accord y'a 6 thunderbolt - tiens au fait c'est une bonne question ça le Thunderbolt sur un hack : résolue par quelqu'un ?  ) ? Et puis j'ai un moniteur Asus qui fait hub usb3 (3 ports), ça en fait quand même du matos à brancher, non ?
Je vais te dire Nicolas, moi ce qui m'a décidé c'est quand j'ai "galéré" pour trouver le bon patch pour faire "sauter la limite" avec Sierra et USBinjectAll. Maintenant bien sûr, je l'ai trouvé (enfin plutôt, un pote brésilien d'insanelymac me l'a indiqué) , mais néanmoins cette incertitude sur le bon fonctionnement du matériel en cas de MàJ importante c'est quand même pas rien.
Le kext des deux cadors fonctionne sur les deux systèmes (10.11, 10.12 betas) pour des cartes Z170X, Z170M, Z170i : il faut juste jouer un peu avec ses clés usb pour identifier ses ports usb avec le patch qui fait sauter la limite, USBinjectAll et ioregistry.
Bon, il faut sans doute le compléter, mais quand Barijaona aura son matos, y va nous régler ça aux p'tits oignons  !!
En tout cas pour ton article tu ne peux pas te contenter de conseiller la seule utilisation d'USBinjectAll et du patch, ça fera des déçus aux mises à jour importantes sur Skylake. (cf ton "angoisse" pour la tite màj de sécurité d'El Capitan avec les drivers Nvidia !!)
Non, moi ce qui m'ennuie le plus actuellement c'est que le patch de Pike R. Alpha ne fonctionne pas sous Sierra... Certes on peut toujours s'en sortir mais faut rien oublier parce que le black screen lui y t'loupe pas !!


----------



## flotow (10 Septembre 2016)

gradou a dit:


> M'enfin, c'est  quand même pas si compliqué !! J'y suis arrivé, donc n'importe qui un tant soit peu opiniâtre doit y arriver. Surtout que tout le boulot a été fait par nos deux amis, ce serait dommage de se priver de ce qu'ils ont fait. Et puis donc, pour ma part je me retrouve avec 5 ports usb3 parfaitement fonctionnels (donc 5 Usb2 itou) + 4 ports qui ne sont qu'usb2, sur un Mac "normal" y'en a combien (sur mon Mac Pro 2013 : 4; bon d'accord y'a 6 thunderbolt - tiens au fait c'est une bonne question ça le Thunderbolt sur un hack : résolue par quelqu'un ?  ) ? Et puis j'ai un moniteur Asus qui fait hub usb3 (3 ports), ça en fait quand même du matos à brancher, non ?
> Je vais te dire Nicolas, moi ce qui m'a décidé c'est quand j'ai "galéré" pour trouver le bon patch pour faire "sauter la limite" avec Sierra et USBinjectAll. Maintenant bien sûr, je l'ai trouvé (enfin plutôt, un pote brésilien d'insanelymac me l'a indiqué) , mais néanmoins cette incertitude sur le bon fonctionnement du matériel en cas de MàJ importante c'est quand même pas rien.
> Le kext des deux cadors fonctionne sur les deux systèmes (10.11, 10.12 betas) pour des cartes Z170X, Z170M, Z170i : il faut juste jouer un peu avec ses clés usb pour identifier ses ports usb avec le patch qui fait sauter la limite, USBinjectAll et ioregistry.
> Bon, il faut sans doute le compléter, mais quand Barijaona aura son matos, y va nous régler ça aux p'tits oignons  !!
> ...



pour l'instant je fonctionne avec USBInjectAll et tout les ports fonctionnent correctement.
même l'USB 3… enfin, presque, par moment ça se déconnecte lorsque je transfère (pendant !) des photos. Cela dit, ça s'est amélioré avec 10.11.5. Je ne peut pas tester mon APN sur une autre machine USB 3 non plus


----------



## Barijaona (13 Septembre 2016)

Je commence à "jouer" avec les injecteurs, même si côté matériel, il me manque encore les connecteurs permettant de tester les headers internes USB3.

@gradou, tu dis que chez toi, avec USBInjectAll, les ports USB3.1 marchent et fonctionnent à la vitesse du USB3.0
Peux-tu poster une copie d'écran de ce qui passe en vert dans IOJones lorsque tu connectes à ces ports un périphérique USB3 ?

Chez moi, ces ports (du moins celui avec un connecteur USB-A, vu que je n'ai pas de périphérique avec une fiche USB-C) ne reconnaissent que les périphériques USB2.
La différence est peut-être liée à la version de BIOS (je suis sur la version F4)


----------



## nicolasf (13 Septembre 2016)

N'écoutant que mon courage, je me suis décidé pour revenir sur ce point et essayer de le régler une bonne fois pour toute. Sans compter que j'ai noté des comportements bizarres, genre le Mac qui redémarre après extinction, ou des ports USB 3 qui ne fonctionnent plus très bien.

Bref, j'ai lancé IORegistryExplorer, mais bizarrement, il n'affiche de l'USB 2 :





C'est cohérent avec les ports USB 3 non fonctionnels, mais que dois-je faire du coup ?

Dans le Rapport Système, voici ce que j'ai :





À ce stade, j'ai le kext pour activer tous les ports USB et la modification dans Clover pour lever la limite.

Merci pour votre aide !


EDIT : j'ai réglé mon problème en changeant la modification appliquée par Clover pour la limite de 15 ports. Par rapport au guide que vous avez mis en place ici, j'ai suivi le guide de tonymacx86 et ça marche mieux.

Je vais maintenant identifier tout ça.

EDIT 2 : voilà, j'ai ma liste ! Malheureusement, si je comprends bien, je dois en sacrifier un maintenant… :-(

*Boîtier :*

- Deux ports USB 2 façade : HS08 <08 00 00 00>
- Deux ports USB 3 façade :
    - USB 2 droite : HS01 <01 00 00 00>
    - USB 2 gauche : HS02 <02 00 00 00>
    - USB 3 droite : SS01 <11 00 00 00>
    - USB 3 gauche : SS02 <12 00 00 00>

*Carte-mère :*

- Port 1 USB 2 : HS13 <0d 00 00 00>
- Port 2 USB 2 : HS14 <0e 00 00 00>
- Port 3 : ignoré
- Port 4 :
    - USB 2 : HS09 <09 00 00 00>
    - USB 3 : SS09 <19 00 00 00>
- Port 5 : ignoré
- Port 6 USB 2 : HS10 <0a 00 00 00>
- Port 7 USB 2 : HS07 <07 00 00 00>
- Port 8 :
    - USB 2 : HS06 <06 00 00 00>
    - USB 3 : SS06 <16 00 00 00>
- Port 9 :
    - USB 2 : HS05 <05 00 00 00>
    - USB 3 : SS05 <15 00 00 00>


- Port USB 2 interne Bluetooth : HS11 <0b 00 00 00>






EDIT 3 : après redémarrage, cela semble fonctionner correctement. Je n'ai que les ports USB définis dans le kext et a priori, ils fonctionnent à la bonne vitesse. Je vais voir si cela règle mes autres problèmes maintenant.


----------



## Barijaona (13 Septembre 2016)

Selon la doc, la carte mère dispose de 3 chipsets :
- Chipset de base Intel
- Chipset GENESYS LOGIC USB 2.0 Hub
- Chipset Intel Thunderbolt 3 Controller

Le gros des ports est sur le premier chipset
Le deuxième est connecté au port HS08 du premier et gère un hub 2 ports
Pour l'instant, je vais faire l'impasse sur le troisième chipset, celui qui gère les deux USB3.1. Je comprends qu'il est entièrement indépendant des deux premiers

Je confirme le schéma de @NicolasF.
(@gradou, il semble que tu aies interverti les deux ports USB2 à l'arrière de couleur jaune HS13 et HS14…)

J'ajoute que :
- l'emplacement marqué F_USB1 sur la carte mère correspond au hub relié à HS08
- l'emplacement marqué F_USB2 sur la carte mère correspond à HS11 et HS12

Pour l'heure, je ne sais pas lequel des deux headers USB3 sur la carte mère (marqués respectivement F_USB_30_1 et F_USB30_2) correspond à HS01/SS01/HS02/SS02 et lequel correspond à HS03/SS03/HS04/SS04. Si @nicolasf ou @gradou peuvent préciser le branchement physique qu'ils ont utilisé pour connecter le boitier…

@nicolasf : à quel(s) port(s) physique(s) as-tu branché tes écrans ?


----------



## nicolasf (13 Septembre 2016)

Barijaona a dit:


> Selon la doc, la carte mère dispose de 3 chipsets :
> - Chipset de base Intel
> - Chipset GENESYS LOGIC USB 2.0 Hub
> - Chipset Intel Thunderbolt 3 Controller
> ...




Je pensais à un truc, le HS08 qui sert aux ports USB 2 à l'avant doit être marqué comme un connecteur interne aussi ? Ça pourrait expliquer mes problèmes de redémarrage quand j'essaie d'éteindre le hackintosh…


Sinon pour répondre à ta question, j'utilise celui du haut : 








Les écrans sont reliés sur la carte graphique. Pour le souci d'USB, c'était de ma faute, j'ai retiré…


----------



## Barijaona (13 Septembre 2016)

J'ai eu le problème de redémarrage après extinction rien qu'avec le clavier Apple USB. Pour l'instant, j'ai contourné via la config BIOS (de mémoire : ErP enabled dans gestion de l'énergie)


----------



## nicolasf (13 Septembre 2016)

Barijaona a dit:


> J'ai eu le problème de redémarrage après extinction rien qu'avec le clavier Apple USB. Pour l'instant, j'ai contourné via la config BIOS (de mémoire : ErP enabled dans gestion de l'énergie)



Ah, je ne connaissais pas du tout cette astuce ! Ça a d'autres conséquences ?


----------



## Barijaona (13 Septembre 2016)

D'après l'écran d'aide du BIOS, ça empêche entre autres le "Wake on LAN" et les démarrages programmés.


----------



## nicolasf (13 Septembre 2016)

Barijaona a dit:


> D'après l'écran d'aide du BIOS, ça empêche entre autres le "Wake on LAN" et les démarrages programmés.



Même si je ne les utilise pas pour le moment, c'est un peu pénible… Cela dit, le problème est réglé chez toi ?


----------



## Barijaona (13 Septembre 2016)

Pas un problème pour moi de ne pas avoir ces fonctions, si c'est mieux pour la planète et la facture d'électricité. Mais j'ai remarqué que la LED du port Ethernet continue de clignoter tant qu'on ne retire pas la prise électrique…


----------



## nicolasf (13 Septembre 2016)

Barijaona a dit:


> Pas un problème pour moi de ne pas avoir ces fonctions, si c'est mieux pour la planète et la facture d'électricité. Mais j'ai remarqué que la LED du port Ethernet continue de clignoter tant qu'on ne retire pas la prise électrique…



Ce n'est plus vraiment le sujet, mais mon hackintosh en veille n'est jamais vraiment en veille. Les ventilateurs tournent toujours les LED de la carte graphique et de la carte-mère sont toujours allumées. En fait, c'est surtout l'écran qui est en veille.


----------



## polyzargone (13 Septembre 2016)

nicolasf a dit:


> Ce n'est plus vraiment le sujet, mais mon hackintosh en veille n'est jamais vraiment en veille. Les ventilateurs tournent toujours les LED de la carte graphique et de la carte-mère sont toujours allumées. En fait, c'est surtout l'écran qui est en veille.



Ça a quand même un rapport avec l'USB, enfin peut-être…

Donne nous le résultat de ça dans le terminal :


```
pmset -g
```


```
pmset -g assertions
```


```
syslog |grep -i "Wake reason"
```


----------



## nicolasf (13 Septembre 2016)

Voici, dans le même ordre : 


```
Active Profiles:
AC Power               -1*
Currently in use:
 hibernatemode        0
 womp                 1
 networkoversleep     0
 sleep                90 (sleep prevented by iTunes, coreaudiod)
 Sleep On Power Button 1
 ttyskeepawake        1
 hibernatefile        /var/vm/sleepimage
 disksleep            10
 displaysleep         10
```




```
2016-09-13 17:05:37 +0200
Assertion status system-wide:
   BackgroundTask                 0
   ApplePushServiceTask           0
   UserIsActive                   1
   PreventUserIdleDisplaySleep    0
   PreventSystemSleep             0
   ExternalMedia                  0
   PreventUserIdleSystemSleep     1
   NetworkClientActive            0
Listed by owning process:
   pid 327(iTunes): [0x000011ca00010a1d] 00:13:23 PreventUserIdleSystemSleep named: "com.apple.iTunes.playback"
   pid 99(hidd): [0x00000026000901e1] 01:28:39 UserIsActive named: "com.apple.iohideventsystem.queue.tickle"
          Timeout will fire in 588 secs Action=TimeoutActionRelease
   pid 203(coreaudiod): [0x000011ca000101fb] 00:13:23 PreventUserIdleSystemSleep named: "com.apple.audio.AppleHDAEngineOutput:1F,3,0,1,2:0.context.preventuseridlesleep"
          Created for PID: 327.
Kernel Assertions: 0x104=USB,MAGICWAKE
   id=500  level=255 0x4=USB mod=01/01/1970 01:00 description=com.apple.usb.externaldevice.14300000 owner=USB2137B
   id=501  level=255 0x4=USB mod=01/01/1970 01:00 description=com.apple.usb.externaldevice.14a00000 owner=Keyboard Hub
   id=502  level=255 0x4=USB mod=01/01/1970 01:00 description=com.apple.usb.externaldevice.14600000 owner=USB2.0 Hub
   id=503  level=255 0x4=USB mod=01/01/1970 01:00 description=com.apple.usb.externaldevice.14d00000 owner=USB5537B
   id=504  level=255 0x4=USB mod=01/01/1970 01:00 description=com.apple.usb.externaldevice.14b00000 owner=DataTraveler 3.0
   id=505  level=255 0x4=USB mod=01/01/1970 01:00 description=com.apple.usb.externaldevice.14700000 owner=IOUSBHostDevice
   id=506  level=255 0x4=USB mod=01/01/1970 01:00 description=com.apple.usb.externaldevice.14620000 owner=iTrack Solo
   id=507  level=255 0x100=MAGICWAKE mod=01/01/1970 01:00 description=en3 owner=en3
   id=508  level=255 0x100=MAGICWAKE mod=01/01/1970 01:00 description=en2 owner=en2
   id=510  level=255 0x4=USB mod=01/01/1970 01:00 description=com.apple.usb.externaldevice.14310000 owner=Magic Trackpad 2
Idle sleep preventers: IODisplayWrangler
```

Le dernier est trop long pour les forums, donc ce sera dans ce fichier : https://files.macg.co/macgupload/1473779248-5469476322023.txt


----------



## gradou (13 Septembre 2016)

Barijaona a dit:


> @gradou, tu dis que chez toi, avec USBInjectAll, les ports USB3.1 marchent et fonctionnent à la vitesse du USB3.0
> Peux-tu poster une copie d'écran de ce qui passe en vert dans IOJones lorsque tu connectes à ces ports un périphérique USB3 ?
> Chez moi, ces ports (du moins celui avec un connecteur USB-A, vu que je n'ai pas de périphérique avec une fiche USB-C) ne reconnaissent que les périphériques USB2.
> La différence est peut-être liée à la version de BIOS (je suis sur la version F4)



Tout d'abord ces ports ne sont reconnus que sous Sierra (et même avec TON kext) et fonctionnent à 5Gb/s.

La copie d'écran indique l'emplacement ou ma clé USB3 (microSD RDR) est branchée : à un hub USB-C que j'utilise avec mon MacBook USB-C pour connecter une clé (ou un disque) USB3.


----------



## gradou (13 Septembre 2016)

QUOTE="Barijaona, post: 13062305, member: 10349"]
- l'emplacement marqué F_USB1 sur la carte mère correspond au hub relié à HS08
[/QUOTE]

C'est, je crois, ce que je dis depuis le début !!!! (Je cite : "* Troisième interrogation : faut il ou non renseigner le port USB20hub qui apparait en HS08 mais sur lequel on peut rien brancher !!?")
Sauf que moi c'est le port F_USB2

Effectivement j'ai interverti HS13 et HS14 !!

Tiens j'te mets une autre image pour le USB-C :


Voir la pièce jointe 110710

	

		
			
		

		
	
 [


----------



## polyzargone (13 Septembre 2016)

@nicolasf

Les résultats de la dernière commande indiquent que la cause est *Wake reason: XDCI*

Et je soupçonne que tu as le même problème que @gradou : *Instant wake*

Donc même cause, même solution .

Par conséquent, il faudrait que tu postes ton dossier EFI/CLOVER/ACPI/origin . Tu peux l'obtenir en tapant F4 au menu de boot de Clover (il ne se passera rien mais c'est normal).


----------



## gradou (13 Septembre 2016)

Encore une t'ite image pour Barijaona (je sais qu'il aime bien ça), cette fois la clé est sur le port USB 3.1


----------



## Barijaona (13 Septembre 2016)

gradou a dit:


> Tout d'abord ces ports ne sont reconnus que sous Sierra (et même avec TON kext) et fonctionnent à 5Gb/s.



Etant sur un chipset indépendant, ils sont comptés à part en ce qui concerne la limite de 15 ports.



gradou a dit:


> C'est, je crois, ce que je dis depuis le début !!!! (Je cite : "* Troisième interrogation : faut il ou non renseigner le port USB20hub qui apparait en HS08 mais sur lequel on peut rien brancher !!?")



Nuance : on ne peut pas se brancher sur le HS08, mais on peut bien se brancher sur les deux ports du hub.

Bizarre que chez toi, c'est le F_USB2. J'ai vérifié à nouveau, sur ma carte mère, c'est le F_USB1 (en bas, à droite)


----------



## gradou (13 Septembre 2016)

Barijaona a dit:


> Etant sur un chipset indépendant, ils sont comptés à part en ce qui concerne la limite de 15 ports.
> 
> *Oui, pis comme ça, ça nous en fait 2 de plus des USB 3 avec Sierra, ils ne fonctionnent pas en USB2*
> 
> ...



Ce qui est sûr c'est que le hub USB2 de mon boitier est branché sur le F_USB2 (le plus à gauche des deux !!)


----------



## Barijaona (14 Septembre 2016)

nicolasf a dit:


> mon hackintosh en veille n'est jamais vraiment en veille. Les ventilateurs tournent toujours les LED de la carte graphique et de la carte-mère sont toujours allumées. En fait, c'est surtout l'écran qui est en veille.



Même souci ici.
J'ai vu cité sur macbidouille l'installation d'un certain nombre de patches, mais comme je ne les comprends pas (je ne retrouve pas dans les DSDT/SSDT d'origine certains des éléments cités), je me tâte avant d'appliquer.

D'autant que chez moi, pour le moment :

```
syslog | grep -i "wake reason"
```
n'affiche rien. Ce qui laisse penser que ce n'est pas un réveil prématuré qui est à mettre en cause, mais un état de sommeil trop "léger"


----------



## Barijaona (14 Septembre 2016)

Récapitulatif des courses et nouvelle version de l'injecteur pour Gigabyte Z170X-Gaming 5

Il faut :
- choisir un maximum de 15 ports à partir des schémas ci-après,
- modifier le Info.plist de GA_Z170X_G5_Injector.kext pour ne garder que les ports qui vous intéressent,
- placer le .kext ainsi modifié dans EFI/CLOVER/kexts/Other









Par rapport à la version précédente, les types de ports ont été revus. Je ne sais pas si ça peut améliorer les problèmes de veille.

@nicolasf , es-tu d'accord pour héberger le fichier sur les serveurs de MacG, pour que je puisse libérer ma Dropbox ? Sinon, je peux le mettre sur Github


----------



## nicolasf (14 Septembre 2016)

Merci pour ton schéma plus complet, je peux l'utiliser dans l'article ?

Je mettrai un lien vers ton zip, avec les deux images, c'est parfait ! 

Et en le voyant, je me dis que c'est pour cette raison que la carte Bluetooth ne fonctionnait pas sur le F_USB1 alors qu'elle n'a aucun problème sur le F_USB2. Ils sont en fait différents…


----------



## Barijaona (14 Septembre 2016)

nicolasf a dit:


> Merci pour ton schéma plus complet, je peux l'utiliser dans l'article ?
> 
> Je mettrai un lien vers ton zip, avec les deux images, c'est parfait !



Bien sûr, tu peux utiliser les schémas

Plutôt que le lien Dropbox, mieux vaut un lien vers Github. Je le mettrais ici dès qu'il sera en ligne.


----------



## gradou (14 Septembre 2016)

nicolasf a dit:


> Merci pour ton schéma plus complet, je peux l'utiliser dans l'article ?
> 
> Je mettrai un lien vers ton zip, avec les deux images, c'est parfait !
> 
> Et en le voyant, je me dis que c'est pour cette raison que la carte Bluetooth ne fonctionnait pas sur le F_USB1 alors qu'elle n'a aucun problème sur le F_USB2. Ils sont en fait différents…



Peut être me trompe je, mais s'il ne fonctionnait pas sur le port interne F_USB1, n'était ce pas parce que le port HS08 n'était pas renseigné ?
@Barijaona : merci beaucoup pour tous ces éléments très clairs et cette dernière réalisation !!
Voilà ce que cela donne sur mon Hack une fois adapté à la limite des 15 ports, cela te semble t'il correct ? (Mes ports internes connectés sont : F_USB2 et F_USB30_2, rien de connecté sur le F_USB1 (HS08 !!))


J'ai supprimé un port fonctionnel : le HS07...
Pour ma part je conserve le problème du black screen sous Sierra GM avec le SMBIOS 17,1, le patch ne fonctionnant, semble t il, que sous 10.11; après installation 10.12, obligé donc de faire la manip AGDPFIX en redémarrant le système avec un autre SMBIOS, de rechanger, une fois redémarré, le SMBIOS en 17,1 et de remettre les valeurs (serial number...) pour qu'imessage fonctionne..., un peu contraignant. !!


----------



## nicolasf (14 Septembre 2016)

Barijaona a dit:


> Plutôt que le lien Dropbox, mieux vaut un lien vers Github. Je le mettrais ici dès qu'il sera en ligne.



Je voulais dire, un lien hébergé par MacG. Le voici, d'ailleurs : https://files.macg.co/macgupload/1473833650-16437614854540.zip


----------



## gradou (14 Septembre 2016)

polyzargone a dit:


> @nicolasf
> 
> Les résultats de la dernière commande indiquent que la cause est *Wake reason: XDCI*
> 
> ...


Moi je veux bien un patch pour la Z170X (l'autre c'était pour la Z170M)   
Voilà mon "origin", si tu veux bien !
https://www.dropbox.com/s/i3zcw71j7g4el9a/origin.zip?dl=0


----------



## polyzargone (14 Septembre 2016)

gradou a dit:


> Pour ma part je conserve le problème du black screen sous Sierra GM avec le SMBIOS 17,1, le patch ne fonctionnant, semble t il, que sous 10.11; après installation 10.12, obligé donc de faire la manip AGDPFIX en redémarrant le système avec un autre SMBIOS, de rechanger, une fois redémarré, le SMBIOS en 17,1 et de remettre les valeurs (serial number...) pour qu'imessage fonctionne..., un peu contraignant. !!



Pas la peine de redémarrer avec un autre SMBios.

Tu oublies le boot-arg *nv_disable=1* qui a le gros avantage de ne pas démarrer le Hack en safe mode (où il n'est pas possible d'accéder à la partition EFI) mais dans un mode où tout fonctionne… sauf la carte NVIDIA .

Donc reste en iMac17,1 tout le temps, et quand tu as besoin d'appliquer/ré-appliquer l'ADGPfix, tu as juste à utiliser ce boot-arg.

C'est exactement le même principe que pour les webdrivers d'ailleurs. Si une MÀJ d'OS X les rend incompatibles, c'est pas non plus la peine de changer de SMBios, de démarrer en safe mode, de passer par un clone, ou je ne sais quelle autre méthode radicale.
*
nv_disable=1* est votre ami et il vous sortira de toutes ces situations  !



Barijaona a dit:


> Même souci ici.
> J'ai vu cité sur macbidouille l'installation d'un certain nombre de patches, mais comme je ne les comprends pas (je ne retrouve pas dans les DSDT/SSDT d'origine certains des éléments cités), je me tâte avant d'appliquer.



Il faut que tu ailles dans les préférences de MaciASL > Sources et que tu colle l'adresse du dépôt de patch. En l'occurrence, celle-ci : http://raw.github.com/RehabMan/Laptop-DSDT-Patch/master

En ce qui concerne les patchs et avant de faire n'importe quoi, une lecture de ce guide s'impose : http://www.tonymacx86.com/threads/guide-patching-laptop-dsdt-ssdts.152573/



gradou a dit:


> Moi je veux bien un patch pour la Z170X (l'autre c'était pour la Z170M)



Essaie celle-là.


----------



## gradou (14 Septembre 2016)

Merci beaucoup pour le rappel de nv_disable=1, je ne savais pas que ça fonctionnait aussi dans ce cas !!   (pour les webdrivers, je savais). Ça va bien simplifier la vie quand y'aura des mises à jour !!
Pour ce qui est du patch, houla !! L'a tout cassé : plus rien de bon au redémarrage sous Sierra, comme l'impression que plus rien s'est chargé (ethernet, video, autres disques...) et a fallu brancher une souris filaire !


----------



## polyzargone (14 Septembre 2016)

gradou a dit:


> Pour ce qui est du patch, houla !! L'a tout cassé : plus rien de bon au redémarrage sous Sierra, comme l'impression que plus rien s'est chargé (ethernet, video, autres disques...) et a fallu brancher une souris filaire !



Tu parles de la DSDT j'imagine ?

Tu peux la zapper en allant dans le menu de Clover au  démarrage > DSDT fix mask > DSDT name : *là tu tape n'importe quoi sauf DSDT.aml*.


----------



## gradou (14 Septembre 2016)

polyzargone a dit:


> Tu parles de la DSDT j'imagine ?
> 
> Tu peux la zapper en allant dans le menu de Clover au  démarrage > DSDT fix mask > DSDT name : *là tu tape n'importe quoi sauf DSDT.aml*.


Oui, je parlais de la DSDT, OK je vais faire ça et pis après je la vire, alors ? (Snif !!)


----------



## polyzargone (14 Septembre 2016)

Essaie celle-ci.


----------



## gradou (14 Septembre 2016)

polyzargone a dit:


> Essaie celle-ci.


Cette fois y'a tout après redémarrage, la mise en veille tient, mais ça se réveille pas (il dort très, très profondément !!!!) : planté !


----------



## Barijaona (14 Septembre 2016)

Barijaona a dit:


> Même souci ici.
> J'ai vu cité sur macbidouille l'installation d'un certain nombre de patches, mais comme je ne les comprends pas (je ne retrouve pas dans les DSDT/SSDT d'origine certains des éléments cités), je me tâte avant d'appliquer.





polyzargone a dit:


> Il faut que tu ailles dans les préférences de MaciASL > Sources et que tu colle l'adresse du dépôt de patch. En l'occurrence, celle-ci : http://raw.github.com/RehabMan/Laptop-DSDT-Patch/master



Mon problème est moins de trouver la source des patches, que de savoir lesquels sont pertinents ! Il y en a en quantité industrielle 

Tes essais avec @gradou intégraient quels patches, et pourquoi ?


----------



## gradou (14 Septembre 2016)

Barijaona a dit:


> Mon problème est moins de trouver la source des patches, que de savoir lesquels sont pertinents ! Il y en a en quantité industrielle
> 
> Tes essais avec @gradou intégraient quels patches, et pourquoi ?



Ils concernent les problèmes de veille justement ce sur quoi tu bosses je crois ?


----------



## polyzargone (14 Septembre 2016)

Barijaona a dit:


> Mon problème est moins de trouver la source des patches, que de savoir lesquels sont pertinents ! Il y en a en quantité industrielle
> 
> Tes essais avec @gradou intégraient quels patches, et pourquoi ?



Lis le guide dont j'ai donné l'adresse plus haut. Certains sont "génériques" comme HPET fix, IRQ fix ou encore RTC fix. Ceux que j'ai utilisés sont ceux préconisés par RehabMan dans ce guide :



> *Common Patches*
> 
> Generally, a DSDT patch should only be applied after finding a need for that specific fix. But *there are several patches that are commonly needed and that have only a small chance of causing a problem*. They are in my laptop repo and are listed here:
> 
> ...



J'ai ajouté celui-ci qui est normalement sensé réglé le problème de l'Instant wake :

"USB3_PRW 0x6D Skylake (instant wake)"

Mais comme ça n'a pas fonctionné, je me suis contenté d'appliquer uniquement ce dernier dans la seconde version que j'ai proposé à @gradou. Visiblement, ça n'est pas encore parfait…

Quant à savoir à quoi ils servent, il n'y a malheureusement pas de secret et il faut faire des recherches au cas par cas pour savoir/comprendre dans quels cas ils sont utilisés et si ça peut éventuellement régler le problème auquel on est confronté.

C'est très difficile à déterminer, surtout quand on y connaît pas grand chose comme moi et que par dessus le marché, on a pas la possibilité de tester soi-même .

Donc là, j'y vais un peu au pif pour être honnête .

Du coup, je pense qu'il serait plus sage et plus efficace de soumettre directement le problème au type le plus compétent : RehabMan .


----------



## Barijaona (14 Septembre 2016)

polyzargone a dit:


> Quant à savoir à quoi ils servent, il n'y a malheureusement pas de secret et il faut faire des recherches au cas par cas pour savoir/comprendre dans quels cas ils sont utilisés et si ça peut éventuellement régler le problème auquel on est confronté.



Et comme Clover peut lui même appliquer un certain nombre de correctifs, on n'est pas sorti de l'auberge ! Le nombre de combinaisons et de conflits possibles est… intéressant


----------



## polyzargone (14 Septembre 2016)

Barijaona a dit:


> Et comme Clover peut lui même appliquer un certain nombre de correctifs, on n'est pas sorti de l'auberge ! Le nombre de combinaisons et de conflits possibles est… intéressant



Absolument.

Et d'ailleurs et en règle générale, il est conseillé de ne pas utilisé les fonctions ACPI > Fixes lorsque justement, on utilise une DSDT patchée. Et c'est même encore plus vicieux que ça puisque la DSDT prévaut sur les autres correctifs qu'on peut appliquer dans Devices ou Graphics notamment.

Par exemple, si dans Devices > Audio > Inject on rentre *1* mais que dans la DSDT le layout-id est défini en tant que 0x03, 0x00, 0x00, 0x00 (soit *3*), c'est bien *3* qui sera injecté et pas le réglage défini dans le config.plist.

Idem, si dans Graphics > ig-platform-id on rentre 0x19*12*0000 (pour les Intel HD *530* des CPU Skylake) mais que dans la DSDT, cette valeur est définie en tant que 0x00, 0x00, 0x*16*, 0x19 (pour les Intel HD *520* des CPU Skylake), il y aura comme un problème  !

Moralité : il ne faut pas combiner plusieurs méthodes d'injection en même temps. Ou alors, il faut bien savoir ce qu'on fait.


----------



## fljagd (15 Septembre 2016)

polyzargone a dit:


> En ce qui concerne les différences entre les deux versions :
> 
> qui contient un champ "IntelC610/X99SeriesAHCI" dont je ne m'explique pas la présence


Bonjour, je rentre juste de vacances
Cette partie est purement cosmétique


----------



## fljagd (15 Septembre 2016)

polyzargone a dit:


> Ils viennent tous plus ou moins de là .


Oui, c'est vrai


----------



## gradou (16 Septembre 2016)

@Barijaona :
Je m'en doutais un peu mais j'ai quand même voulu essayer de brancher un disque USB-C sur le port ad'hoc : si le disque monte, par contre il s'avère impossible d'écrire dessus, de le partitionner, etc.


----------



## gradou (17 Septembre 2016)

Nouvelle version d'USBinjectAll ici :

https://bitbucket.org/RehabMan/os-x-usb-inject-all/downloads

(en date du 7/09/2016 : add "model" for internal hub IOKitPersonality (IOKit matching has changed on 10.12)


----------



## Barijaona (25 Septembre 2016)

ça va sans dire, mais ça va (beaucoup) mieux en le disant : si vous utilisez un autre SMBIOS que iMac17,1, il faut adapter en conséquence "notre" kext…


----------



## Barijaona (26 Septembre 2016)

nicolasf a dit:


> j'ai noté des comportements bizarres, genre le Mac qui redémarre après extinction.



@nicolasf : as-tu encore des redémarrages après extinction ? chez moi, il semble que la seule cause soit la carte Wifi/Bluetooth.

Lorsque le connecteur USB n'est pas branché, l'extinction se passe bien, même avec ErP disabled.
Du coup, je regarde cette carte d'un œil suspicieux pour tous les problèmes de veille / sortie de veille…

Comme le problème se manifeste y compris au niveau du BIOS, je me dis que ça n'a pas grand chose à voir avec macOS et je ne sais pas si on va pouvoir trouver facilement une solution…


----------



## gradou (26 Septembre 2016)

Barijaona a dit:


> @nicolasf : as-tu encore des redémarrages après extinction ? chez moi, il semble que la seule cause soit la carte Wifi/Bluetooth.
> 
> Lorsque le connecteur USB n'est pas branché, l'extinction se passe bien, même avec ErP disabled.
> Du coup, je regarde cette carte d'un œil suspicieux pour tous les problèmes de veille / sortie de veille…
> ...



Bien que cela ne me soit pas adressé je réponds quand même ceci   :

Avec la GA Z170 G5 j'ai une carte Wifi installée qui n'intègre pas le BT et j'ai le même problème de redémarrage immédiat après extinction... (que ce soit 10.11 ou 10.12)
Par contre avec la même carte que la vôtre installée sur la Asus Z170-M-Plus je n'ai pas ce pb tant sur 10.11 que sur 10.12 (je précise que le BT est connecté via un des ports USB internes)... Il faut dire que concernant cette dernière j'ai bénéficié d'une Polyzargonade SSDT (voir plus haut) mais elle ne fonctionne pas sur "ma" GA Z170...

PS : je viens d'essayer d'éteindre après avoir enlevé le "dongle" BT inséré sur un port USB évidemment externe, et bien l'extinction se fait normalement.
Peut on en déduire que la carte n'est pas responsable, mais plutôt la "gestion" du BT avec la GA ?

REPS : Ouarff !! A tout hasard j'ai essayé de cocher "Fixshutdown" dans ACPI et... ça marche (BT installé et que ce soit avec 10.11 ou 12 !!)


----------



## nicolasf (27 Septembre 2016)

@Barijaona J'ai toujours ce problème en effet, je n'ai pas essayé de les régler pour le moment…

S'il suffit de cocher la case FixShutDown, c'est intéressant !


----------



## gradou (8 Février 2017)

nicolasf a dit:


> @Barijaona J'ai toujours ce problème en effet, je n'ai pas essayé de les régler pour le moment…
> 
> S'il suffit de cocher la case FixShutDown, c'est intéressant !


Finalement j'ai, pour ma part, réglé le problème de veille en mettant à jour le Bios en F20. 
Cette mise à jour nécessite de charger le driver "EmuVariableUefi" pour  que les NvdaWeb soient reconnus. Pour le reste, les réglages du Bios sont identiques aux précédentes versions.


----------



## nicolasf (22 Mars 2017)

Petite question aux spécialistes : je n'arrive pas à utiliser le Bluetooth d'une carte AirPort supposée identique à celle d'Apple et je me demande si c'est pas ,un problème lié à la configuration USB.

Dans les Informations Système, il ne reconnaît qu'un bus USB 3.0 avec tout dedans, les ports USB 3 et les USB 2. Est-ce normal ? Si non, comment le régler, sachant que je n'ai pas touché le fichier pour identifier correctement chaque port USB. A priori ce n'est pas Sierra qui casse ça, mais…







Merci pour votre aide !


----------



## polyzargone (22 Mars 2017)

nicolasf a dit:


> Dans les Informations Système, il ne reconnaît qu'un bus USB 3.0 avec tout dedans, les ports USB 3 et les USB 2. Est-ce normal ? Si non, comment le régler, sachant que je n'ai pas touché le fichier pour identifier correctement chaque port USB. A priori ce n'est pas Sierra qui casse ça, mais…



Essaie d'installer FakePCIID.kext & FakePCIID_XHCIMux.kext (dispos ici) dans CLOVER/kexts/Other.

En principe, FakePCIID_XHCIMux.kext va déporter de l'USB 3 (XHCI) tout ce qui concerne l'USB 2 (EHCI).


----------



## nicolasf (22 Mars 2017)

Je peux les installer avec mon kext "maison" qui identifie les ports USB ?


----------



## polyzargone (22 Mars 2017)

Oui .

Cela dit, je tenterai ça sur une clé USB munie de Clover et du contenu du dossier EFI/CLOVER pour commencer. Il n'est pas impossible que certains ports ne fonctionnent plus du tout.

Si tu peux accéder à ton Hack en VNC, ça peut aller aussi sinon.


----------



## nicolasf (22 Mars 2017)

polyzargone a dit:


> je tenterai ça sur une clé USB munie de Clover et du contenu du dossier EFI/CLOVER pour commencer



C'est ça que je devrais me faire pour éviter les problèmes !

Je peux booter avec ma partition principale et le Clover de la clé ?


----------



## polyzargone (22 Mars 2017)

Oui.

Une clé USB munie de Clover prend l'ascendant sur le Clover* installé dans la partition EFI. Ta partition principale sera donc démarrée avec les réglages du config.plist, les kexts et tout le reste de ta clé.

Quant aux kexts "additionnels" installés dans dans S/L/E ou L/E (là MultiBeast aime bien les mettre), ils seront chargés indépendamment de ceux de la clé.

* D'ailleurs, il vaut mieux ne pas la laisser branchée en permanence car elle sera automatiquement utilisée à la place du boot standard sur le disque.


----------



## polyzargone (22 Mars 2017)

Au fait, pour la clé USB, pas besoin de l'installeur complet d'OS X .

Une simple clé de 1 Go ou moins (ce qu'il faut pour Clover quoi) formatée en FAT32 suffira amplement.


----------



## nicolasf (22 Mars 2017)

C'est une super idée ça, je vais même la mettre de côté pour une astuce sur MacG. Merci


----------



## polyzargone (22 Mars 2017)

Puisque tu commences à collectionner les Hackintosh, il y a ça aussi : Créer une clé Clover multi-configurations


----------



## nicolasf (22 Mars 2017)

Du coup, j'ai tenté d'ajouter FakePCIID, mais ça ne change rien… 

C'est peut-être un problème de configuration, mais je ne sais pas trop où chercher.


----------



## polyzargone (22 Mars 2017)

Juste FakePCIID.kext ou les deux ? FakePCIID.kext est indispensable à FakePCIID_XHCIMux.kext au fait.

Que donne cette commande (en ayant démarré depuis la clé) ?


```
kextstat | grep -v com.apple
```

Sinon, tu peux comparer ton injecteur avec celui dispo ici : http://www.legallou.com/HackIntosh/GA-Z170X-G5/p2-portUSB.html

Mais comme il a été réalisé en suivant les indications de ce sujet, il ne devrait pas être différent du tiens normalement.[/code]


----------



## nicolasf (22 Mars 2017)

Oui, j'ai bien mis les deux.

Et la commande en démarrant sans la clé (mais j'ai mis les kext des deux côté maintenant) n'affiche pas FakePCIID. J'imagine que ça veut dire qu'il n'est pas chargé ?


```
14    4 0xffffff7f80c70000 0x12000    0x12000    org.netkas.driver.FakeSMC (1707) 72772B6B-84BC-3EC7-A053-FD8B95505F76 <11 7 5 4 3 1>
   25    0 0xffffff7f8365c000 0xc9000    0xc9000    as.vit9696.AppleALC (1.0.18) 9F7FAD68-907A-3613-AF0A-DE60E0994BA9 <7 5 4 3 2 1>
   26    0 0xffffff7f80caf000 0x5000     0x5000     org.hwsensors.driver.CPUSensors (1707) 92A9DE1E-049C-3CC9-9BF3-6F064AECABC8 <14 7 5 4 3>
   37    0 0xffffff7f80cb6000 0x8000     0x8000     org.hwsensors.driver.ACPISensors (1707) D7761E01-6AA4-337E-8D93-2B3E142914E0 <14 11 7 5 4 3>
   45    0 0xffffff7f80c86000 0xe000     0xe000     org.hwsensors.driver.LPCSensors (1707) DD7AEF15-8549-39F8-A052-DF4867AABECF <14 12 11 7 5 4 3>
   48    0 0xffffff7f80c97000 0x12000    0x12000    org.hwsensors.driver.GPUSensors (1707) 068CFBFC-7921-3664-A41F-ECD2C542BDB0 <14 12 11 7 5 4 3>
   50    0 0xffffff7f80bb3000 0x13000    0x13000    com.insanelymac.IntelMausiEthernet (2.1.0d3) 16FE11D4-CF4D-3975-9B7B-331285521A64 <49 12 5 4 3 1>
   55    0 0xffffff7f80e94000 0x8000     0x8000     com.insanelymac.AtherosE2200Ethernet (2.2.0d0) 0FA6F0F4-9AEA-3CB1-95EE-E323BF7659FC <49 12 5 4 3 1>
  107    0 0xffffff7f80cc3000 0x4000     0x4000     com.intel.driver.EnergyDriver (2.0) 4E0262A2-B79C-3386-8824-C106A5DFAF94 <7 5 4 3>
  113    2 0xffffff7f81055000 0x32a000   0x32a000   com.nvidia.web.NVDAResmanWeb (10.1.5) 836F59D8-E1FB-3D45-8AC0-E2E7AB779F17 <112 108 94 12 7 5 4 3 1>
  115    0 0xffffff7f82a4b000 0xa3000    0xa3000    com.nvidia.web.GeForceWeb (10.1.5) AD5AF458-B682-3154-AA47-9C1DC817A157 <114 113 108 94 12 7 5 4 3 1>
  116    0 0xffffff7f81391000 0x2a6000   0x2a6000   com.nvidia.web.NVDAGM100HalWeb (10.1.5) BEBAB721-B71D-3E29-8FE6-85C8215911B1 <113 12 4 3>
```


----------



## polyzargone (22 Mars 2017)

nicolasf a dit:


> J'imagine que ça veut dire qu'il n'est pas chargé ?



Oui ça m'en a tout l'air.

Tu les as mis où exactement ? Si c'est dans S/L/E ou L/E, pense à reconstruire le cache.

En principe, tu devrais voir ça :


```
MacBook-Optimus:~ polyzargone$ kextstat | grep org.rehabman
   47    1 0xffffff7f82c74000 0x7000     0x7000     org.rehabman.driver.FakePCIID (1.3.6) AFB92C3D-4767-3657-986A-9352CDAB6B15 <12 7 5 4 3 1>
   48    0 0xffffff7f82c7b000 0x3000     0x3000     org.rehabman.driver.FakePCIID.XHCIMux (1.3.6) D458078D-5EA4-3BBE-82CC-E9C7D39DE72E <47 12 7 5 4 3 1>
```


----------



## nicolasf (22 Mars 2017)

polyzargone a dit:


> Tu les as mis où exactement ?



Non, dans le dossier Other de la partition EFI. Je ne fais plus que ça maintenant…

Ce qui m'étonne, c'est que j'ai l'impression qu'il manque aussi le kext USB que j'avais créé. C'est possible qu'il ne charge rien dans ce dossier ?

En fait, j'ai encore des choses de Multibeast dans S/L/E ou L/E. Je pensais que Clover prenait le dessus, mais c'est peut-être l'inverse ?


----------



## polyzargone (22 Mars 2017)

L'injecteur n'est pas visible avec kextstat.

C'est un "faux" kext qui se substitue à celui/ceux d'OS X. En fait, il n'y a que son info.plist qui est chargé à la place de ceux d'OS X.

Mais tu devrais bien voir les deux FakePCIID en revanche.

Regarde dans le log de Clover (tape *bdmesg* dans le terminal) si tes kexts sont bien injectés depuis l'EFI.

Normalement, tu devrais avoir quelque chose comme ça à la fin :


```
4:695  0:001  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\Other
4:703  0:008    Extra kext: EFI\CLOVER\kexts\Other\USB_Injector.kext
4:721  0:017    Extra kext: EFI\CLOVER\kexts\Other\Shiki.kext
4:743  0:022    Extra kext: EFI\CLOVER\kexts\Other\FakeSMC.kext
4:765  0:021      Extra PlugIn kext: EFI\CLOVER\kexts\Other\FakeSMC.kext\Contents\PlugIns\FakeSMC_ACPISensors.kext
4:784  0:019      Extra PlugIn kext: EFI\CLOVER\kexts\Other\FakeSMC.kext\Contents\PlugIns\FakeSMC_CPUSensors.kext
4:793  0:009      Extra PlugIn kext: EFI\CLOVER\kexts\Other\FakeSMC.kext\Contents\PlugIns\FakeSMC_GPUSensors.kext
4:795  0:002      Extra PlugIn kext: EFI\CLOVER\kexts\Other\FakeSMC.kext\Contents\PlugIns\FakeSMC_LPCSensors.kext
4:832  0:036    Extra kext: EFI\CLOVER\kexts\Other\FakePCIID.kext
4:842  0:009    Extra kext: EFI\CLOVER\kexts\Other\FakePCIID_XHCIMux.kext
4:844  0:002    Extra kext: EFI\CLOVER\kexts\Other\FakePCIID_Intel_HDMI_Audio.kext
4:846  0:002    Extra kext: EFI\CLOVER\kexts\Other\FakePCIID_Intel_HD_Graphics.kext
4:849  0:002    Extra kext: EFI\CLOVER\kexts\Other\BCM5722D.kext
4:879  0:030    Extra kext: EFI\CLOVER\kexts\Other\ApplePS2SmartTouchPad.kext
4:915  0:035      Extra PlugIn kext: EFI\CLOVER\kexts\Other\ApplePS2SmartTouchPad.kext\Contents\PlugIns\ApplePS2Controller.kext
4:919  0:004      Extra PlugIn kext: EFI\CLOVER\kexts\Other\ApplePS2SmartTouchPad.kext\Contents\PlugIns\ApplePS2Keyboard.kext
4:930  0:010    Extra kext: EFI\CLOVER\kexts\Other\AppleALC.kext
4:958  0:028      Extra PlugIn kext: EFI\CLOVER\kexts\Other\AppleALC.kext\Contents\PlugIns\PinConfigs.kext
5:071  0:112    Extra kext: EFI\CLOVER\kexts\Other\ACPIBatteryManager.kext
5:122  0:051    Extra kext: EFI\CLOVER\kexts\Other\Lilu.kext
5:137  0:014    Extra kext: EFI\CLOVER\kexts\Other\IntelGraphicsFixup.kext
```


----------



## nicolasf (22 Mars 2017)

J'ai bien ça ! Les deux apparaissent bien.


----------



## polyzargone (22 Mars 2017)

Ben c'est bizarre ça !

Est-ce que tu as Yes/No ou Detect dans System Parameters > Inject Kexts ?


----------



## nicolasf (22 Mars 2017)

J'ai Yes.


----------



## polyzargone (22 Mars 2017)

Il y a quoi d'autre dans ton dossier Other ? Et le CsrActiveConfig, il est sur quoi au fait ?

Sinon au pire, installe-les dans S/L/E et reconstruit le cache…


----------



## nicolasf (22 Mars 2017)

Alors :






Pour CsrActiveConfig, sur 0x67.

Et OK, je vais tester ça.


----------



## polyzargone (22 Mars 2017)

Je crois que j'ai pigé d'où vient le problème .

Le FakePCIID_XHCIMux.kext n'est apparemment pas conçu pour fonctionner avec les séries 100 (Skylake) mais seulement les 7, 8 et 9 et donc il ne se charge pas .

Il va falloir trouver autre chose.


----------



## polyzargone (22 Mars 2017)

nicolasf a dit:


> je n'arrive pas à utiliser le Bluetooth d'une carte AirPort supposée identique à celle d'Apple et je me demande si c'est pas ,un problème lié à la configuration USB.



Elle apparaît dans IOJones ou IORegistry Explorer ? Si oui, où ?


----------



## nicolasf (22 Mars 2017)

polyzargone a dit:


> Elle apparaît dans IOJones ou IORegistry Explorer ? Si oui, où ?



Oui, et elle est identifiée avec le bon port USB :






OK pour les kext, je vais les retirer.


----------



## polyzargone (22 Mars 2017)

J'aurais tendance à penser que ce n'est pas un problème d'USB donc.

En revanche, je serais d'avis de retirer le BrcmBluetoothInjector.kext et de mettre BrcmPatchRAM2.kext et BrcmFirmwareData.kext dans kexts/Other ou BrcmFirmwareRepo.kext dans S/L/E (obligatoire pour celui-ci).

Ils sont dipos ici : https://bitbucket.org/RehabMan/os-x-brcmpatchram/downloads/


----------



## polyzargone (22 Mars 2017)

J'oubliais, c'est BrcmFirmwareData.kext *ou* BrcmFirmwareRepo.kext mais pas les deux.


----------



## nicolasf (22 Mars 2017)

Ah oui, j'avais mis ce kext pendant quelques essais rapides, sans effet.

Je ne me souviens pas du RAM2, donc j'essaie demain. Je te tiens au courant, merci beaucoup pour l'aide !


----------



## nicolasf (24 Mars 2017)

Je viens d'essayer et je n'ai rien de mieux.

Je pense que j'ai un souci quelque part, parce que la liste de kexts chargés ne change jamais et je ne vois pas les deux Brcm ajoutés :


```
Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>
   14    4 0xffffff7f80c70000 0x12000    0x12000    org.netkas.driver.FakeSMC (1707) 72772B6B-84BC-3EC7-A053-FD8B95505F76 <11 7 5 4 3 1>
   25    0 0xffffff7f8365c000 0xc9000    0xc9000    as.vit9696.AppleALC (1.0.18) 9F7FAD68-907A-3613-AF0A-DE60E0994BA9 <7 5 4 3 2 1>
   26    0 0xffffff7f80caf000 0x5000     0x5000     org.hwsensors.driver.CPUSensors (1707) 92A9DE1E-049C-3CC9-9BF3-6F064AECABC8 <14 7 5 4 3>
   35    0 0xffffff7f80cb6000 0x8000     0x8000     org.hwsensors.driver.ACPISensors (1707) D7761E01-6AA4-337E-8D93-2B3E142914E0 <14 11 7 5 4 3>
   43    0 0xffffff7f80c86000 0xe000     0xe000     org.hwsensors.driver.LPCSensors (1707) DD7AEF15-8549-39F8-A052-DF4867AABECF <14 12 11 7 5 4 3>
   45    0 0xffffff7f80e94000 0x8000     0x8000     com.insanelymac.AtherosE2200Ethernet (2.2.0d0) 0FA6F0F4-9AEA-3CB1-95EE-E323BF7659FC <44 12 5 4 3 1>
   46    0 0xffffff7f80bb3000 0x13000    0x13000    com.insanelymac.IntelMausiEthernet (2.1.0d3) 16FE11D4-CF4D-3975-9B7B-331285521A64 <44 12 5 4 3 1>
   55    0 0xffffff7f80c97000 0x12000    0x12000    org.hwsensors.driver.GPUSensors (1707) 068CFBFC-7921-3664-A41F-ECD2C542BDB0 <14 12 11 7 5 4 3>
   87    0 0xffffff7f80fea000 0x3000     0x3000     com.nvidia.NVDAStartupWeb (10.1.5) B27A401E-3A0C-314A-B7A2-41D2499CF78E <12 4 3>
  106    2 0xffffff7f81055000 0x32a000   0x32a000   com.nvidia.web.NVDAResmanWeb (10.1.5) 836F59D8-E1FB-3D45-8AC0-E2E7AB779F17 <105 90 89 12 7 5 4 3 1>
  109    0 0xffffff7f80cc3000 0x4000     0x4000     com.intel.driver.EnergyDriver (2.0) 4E0262A2-B79C-3386-8824-C106A5DFAF94 <7 5 4 3>
  111    0 0xffffff7f82a4b000 0xa3000    0xa3000    com.nvidia.web.GeForceWeb (10.1.5) AD5AF458-B682-3154-AA47-9C1DC817A157 <110 106 90 89 12 7 5 4 3 1>
  115    0 0xffffff7f81391000 0x2a6000   0x2a6000   com.nvidia.web.NVDAGM100HalWeb (10.1.5) BEBAB721-B71D-3E29-8FE6-85C8215911B1 <106 12 4 3>
```


Peut-être est-ce un mauvais réglage de Clover ? Voici mon config.plist complet, sauf la partie SMBIOS : 


```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>ACPI</key>
    <dict>
        <key>DSDT</key>
        <dict>
            <key>Debug</key>
            <false/>
            <key>DropOEM_DSM</key>
            <false/>
            <key>Fixes</key>
            <dict>
                <key>FixShutdown_0004</key>
                <true/>
            </dict>
            <key>Name</key>
            <string>DSDT.aml</string>
            <key>Patches</key>
            <array>
                <dict>
                    <key>Comment</key>
                    <string>change HDAS to HDEF</string>
                    <key>Disabled</key>
                    <false/>
                    <key>Find</key>
                    <data>
                    SERBUw==
                    </data>
                    <key>Replace</key>
                    <data>
                    SERFRg==
                    </data>
                </dict>
            </array>
            <key>ReuseFFFF</key>
            <false/>
        </dict>
        <key>SSDT</key>
        <dict>
            <key>DropOem</key>
            <false/>
            <key>Generate</key>
            <false/>
        </dict>
    </dict>
    <key>Boot</key>
    <dict>
        <key>Arguments</key>
        <string>dart=0</string>
        <key>Debug</key>
        <false/>
        <key>DefaultVolume</key>
        <string>Hackintosh HD</string>
        <key>Legacy</key>
        <string>PBR</string>
        <key>Secure</key>
        <false/>
        <key>Timeout</key>
        <integer>3</integer>
        <key>XMPDetection</key>
        <false/>
    </dict>
    <key>CPU</key>
    <dict>
        <key>UseARTFrequency</key>
        <false/>
    </dict>
    <key>Devices</key>
    <dict>
        <key>Audio</key>
        <dict>
            <key>Inject</key>
            <string>1</string>
        </dict>
        <key>FakeID</key>
        <dict>
            <key>ATI</key>
            <string>0x0</string>
            <key>IMEI</key>
            <string>0x0</string>
            <key>IntelGFX</key>
            <string>0x0</string>
            <key>LAN</key>
            <string>0x0</string>
            <key>NVidia</key>
            <string>0x0</string>
            <key>SATA</key>
            <string>0x0</string>
            <key>WIFI</key>
            <string>0x0</string>
            <key>XHCI</key>
            <string>0x0</string>
        </dict>
        <key>USB</key>
        <dict>
            <key>FixOwnership</key>
            <false/>
            <key>Inject</key>
            <false/>
        </dict>
    </dict>
    <key>GUI</key>
    <dict>
        <key>Hide</key>
        <array>
            <string>Windows</string>
            <string>\EFI\BOOT\BOOTX64.EFI</string>
        </array>
        <key>Language</key>
        <string>fr:0</string>
        <key>Mouse</key>
        <dict>
            <key>DoubleClick</key>
            <integer>500</integer>
            <key>Enabled</key>
            <true/>
            <key>Mirror</key>
            <false/>
            <key>Speed</key>
            <integer>8</integer>
        </dict>
        <key>Scan</key>
        <dict>
            <key>Entries</key>
            <true/>
            <key>Legacy</key>
            <string>First</string>
            <key>Linux</key>
            <false/>
            <key>Tool</key>
            <true/>
        </dict>
        <key>ScreenResolution</key>
        <string>2560x1600</string>
        <key>Theme</key>
        <string>embedded</string>
    </dict>
    <key>Graphics</key>
    <dict>
        <key>Inject</key>
        <dict>
            <key>ATI</key>
            <false/>
            <key>Intel</key>
            <true/>
            <key>NVidia</key>
            <false/>
        </dict>
        <key>NvidiaSingle</key>
        <false/>
    </dict>
    <key>KernelAndKextPatches</key>
    <dict>
        <key>AppleRTC</key>
        <true/>
        <key>AsusAICPUPM</key>
        <true/>
        <key>Debug</key>
        <false/>
        <key>DellSMBIOSPatch</key>
        <false/>
        <key>KernelCpu</key>
        <false/>
        <key>KernelHaswellE</key>
        <false/>
        <key>KernelLapic</key>
        <false/>
        <key>KernelPm</key>
        <true/>
        <key>KextsToPatch</key>
        <array>
            <dict>
                <key>Comment</key>
                <string>External icons patch</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>
                RXh0ZXJuYWw=
                </data>
                <key>Name</key>
                <string>AppleAHCIPort</string>
                <key>Replace</key>
                <data>
                SW50ZXJuYWw=
                </data>
            </dict>
            <dict>
                <key>Comment</key>
                <string>t1-10.12-AppleHDA/Realtek ALC...</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>
                ihnUEQ==
                </data>
                <key>Name</key>
                <string>AppleHDA</string>
                <key>Replace</key>
                <data>
                AAAAAA==
                </data>
            </dict>
            <dict>
                <key>Comment</key>
                <string>t1-AppleHDA/Resources/xml&gt;zml</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>
                eG1sLnps
                </data>
                <key>Name</key>
                <string>AppleHDA</string>
                <key>Replace</key>
                <data>
                em1sLnps
                </data>
            </dict>
            <dict>
                <key>Comment</key>
                <string>t1-10.9-10.12-AppleHDA/Realtek ALC1150</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>
                ixnUEQ==
                </data>
                <key>Name</key>
                <string>AppleHDA</string>
                <key>Replace</key>
                <data>
                AAnsEA==
                </data>
            </dict>
            <dict>
                <key>Comment</key>
                <string>Increase 15 port limit to 30 in AppleUSBXHCIPCI</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>
                g72M/v//EA==
                </data>
                <key>Name</key>
                <string>AppleUSBXHCIPCI</string>
                <key>Replace</key>
                <data>
                g710////Fg==
                </data>
            </dict>
        </array>
    </dict>
    <key>RtVariables</key>
    <dict>
        <key>BooterConfig</key>
        <string>0x28</string>
        <key>CsrActiveConfig</key>
        <string>0x67</string>
        <key>ROM</key>
        <string>UseMacAddr0</string>
    </dict>
    <key>SMBIOS</key>
 
    <key>SystemParameters</key>
    <dict>
        <key>InjectKexts</key>
        <string>Yes</string>
        <key>InjectSystemID</key>
        <true/>
        <key>NvidiaWeb</key>
        <true/>
    </dict>
</dict>
</plist>
```


----------



## polyzargone (24 Mars 2017)

Je ne pense pas que ça ait un rapport mais tu peux déjà faire un peu de ménage dans ton config.plist en virant :

• External icons patch (inutile)
• Tous les patchs AppleHDA (inutile puisque tu utilises AppleALC.kext)
• AppleUSBXHCIPCI (inutile puisque tu utilises un injecteur)

Sinon, je t'ai fait un config.plist un peu plus complet ici : https://drive.google.com/open?id=0B42y5VE51ELcRzNMbWhmQ2FvSTA

Il faudra juste rajouter tes infos SMBios.



nicolasf a dit:


> je ne vois pas les deux Brcm ajoutés :



Tu as essayé les deux entre BrcmFirmwareData.kext (E/C/K/Other) et BrcmFirmwareRepo.kext (S/L/E) ?



nicolasf a dit:


> Je pense que j'ai un souci quelque part, parce que la liste de kexts chargés ne change jamais et je ne vois pas les deux Brcm ajoutés :



Tu pourrais installer kextstatx86 pour voir où sont les kexts non-Apple chargés :


```
sudo cp ~/Downloads/kextstatx86 /usr/local/bin
```


```
kextstatx86 -n
```


----------



## polyzargone (24 Mars 2017)

Il faudrait également regarder dans IOReg s'il y a des traces des Bcrm. Je ne suis pas certain que ces kexts s'affichent dans kextstat mais ils devraient apparaître quelque part dans le registre…


----------



## nicolasf (24 Mars 2017)

Merci pour ton aide !

Pour commencer, rien dans IOReg. Je vais tester kextstatx86 et aussi de mettre le kext dans S/L/E, j'ai testé que Clover.

Je vais également essayer ton config.plist pour voir si ça change quelque chose.

EDIT : bon déjà, je vois que Clover ne prend pas le dessus pour les kexts…


```
GeForceWeb.kext (10.1.5) com.nvidia.web.GeForceWeb /System/Library/Extensions/GeForceWeb.kext
FakeSMC_LPCSensors.kext (1707) org.hwsensors.driver.LPCSensors /Library/Extensions/FakeSMC_LPCSensors.kext
FakeSMC_ACPISensors.kext (1707) org.hwsensors.driver.ACPISensors /Library/Extensions/FakeSMC_ACPISensors.kext
NVDAGM100HalWeb.kext (10.1.5) com.nvidia.web.NVDAGM100HalWeb /System/Library/Extensions/NVDAGM100HalWeb.kext
AppleALC.kext (1.0.18) as.vit9696.AppleALC EFI\CLOVER\kexts\Other\AppleALC.kext
NVDAResmanWeb.kext (10.1.5) com.nvidia.web.NVDAResmanWeb /System/Library/Extensions/NVDAResmanWeb.kext
EnergyDriver.kext (2.0) com.intel.driver.EnergyDriver /Library/Extensions/EnergyDriver.kext
FakeSMC.kext (1707) org.netkas.driver.FakeSMC /Library/Extensions/FakeSMC.kext
IntelMausiEthernet.kext (2.1.0d3) com.insanelymac.IntelMausiEthernet /Library/Extensions/IntelMausiEthernet.kext
AtherosE2200Ethernet.kext (2.2.0d0) com.insanelymac.AtherosE2200Ethernet /Library/Extensions/AtherosE2200Ethernet.kext
FakeSMC_GPUSensors.kext (1707) org.hwsensors.driver.GPUSensors /Library/Extensions/FakeSMC_GPUSensors.kext
FakeSMC_CPUSensors.kext (1707) org.hwsensors.driver.CPUSensors /Library/Extensions/FakeSMC_CPUSensors.kext
```

EDIT 2 : ce que je ne sais pas maintenant, c'est est-ce que je devrais supprimer les extensions dans les bibliothèques pour tout mettre dans Clover…


----------



## nicolasf (24 Mars 2017)

Victoire ! En plaçant le Bcrm qui va bien dans S/L/E, le Bluetooth est actif et Continuité fonctionne correctement.

Merci beaucoup pour ça. J'aimerais bien comprendre pourquoi les kext sont pas chargés dans Clover, mais c'est secondaire.

Merci encore.


----------



## polyzargone (24 Mars 2017)

nicolasf a dit:


> EDIT 2 : ce que je ne sais pas maintenant, c'est est-ce que je devrais supprimer les extensions dans les bibliothèques pour tout mettre dans Clover…



Pour que les choses soient claires pour les éventuels lecteurs et comme expliqué ici :

BrcmPatchRAM2.kext et BrcmFirmware*Data*.kext peuvent êtres installés dans EFI/CLOVER/kexts/Other *ou* dans System/Library/Extensions.

BrcmFirmware*Repo*.kext doit obligatoirement être installé dans *System/Library/Extensions*. Si on l'utilise, on ne doit pas installer BrcmFirmware*Data*.kext. C'est l'un ou l'autre.

Dans tous les cas, il faut BrcmPatchRAM2.kext (10.11+) ou BrcmPatchRAM.kext (10.10-).



nicolasf a dit:


> J'aimerais bien comprendre pourquoi les kext sont pas chargés dans Clover, mais c'est secondaire.



Je ne suis pas développeur mais @Barijaona oui. Il pourrait sûrement t'en dire plus .


----------



## Locke (24 Mars 2017)

En passant, ce ne serait pas intéressant de faire un bilan de ce qui marche à coup sûr, histoire de faire un récapitulatif ?


----------



## ninkasi67 (24 Mars 2017)

Faire une configuration type... le hackinstosh du débutant


----------



## nicolasf (25 Mars 2017)

ninkasi67 a dit:


> Faire une configuration type... le hackinstosh du débutant



C'est toujours compliqué, mais si vous prenez exactement le même matériel que moi, mes articles doivent suffire. Par rapport à la configuration initiale, j'ai changé la carte AirPort et j'ai eu quelques soucis supplémentaires, mais celle que j'avais choisie au départ fonctionne sans effort.


----------



## Barijaona (25 Mars 2017)

Ma config est quasi-exactement la même que celle de @nicolasf . Mais je repartirais plutôt avec une carte graphique à base de Nvidia Kepler, genre GT730 (processeur GK208) ou GTX760 (processeur GK104). Largement suffisant (bien plus puissant que les processeurs graphiques intégrés Intel) et surtout supporté nativement par macOS sans avoir besoin d'installer les drivers spécifiques à Nvidia, ce qui facilite beaucoup de choses…


----------



## Barijaona (25 Mars 2017)

nicolasf a dit:


> Victoire ! En plaçant le Bcrm qui va bien dans S/L/E, le Bluetooth est actif et Continuité fonctionne correctement.
> 
> Merci beaucoup pour ça. J'aimerais bien comprendre pourquoi les kext sont pas chargés dans Clover, mais c'est secondaire.





polyzargone a dit:


> Je ne suis pas développeur mais @Barijaona oui. Il pourrait sûrement t'en dire plus .



Déjà, j'ai du mal à digérer qu'une carte déclarée identique à une carte Apple nécessite l'installation de kexts supplémentaires…
Il faut donc faire attention à la publicité mensongère et distinguer d'un côté les vraies cartes Apple Airport sur lesquelles on a juste rajouté un adaptateur PCI et par ailleurs les cartes utilisant le même chipset mais qui pourraient avoir un programme interne un peu différent.

Pour revenir à la question, il y a quelques kexts qui refusent de se charger à partir de la partition Clover (genre ceux liés à des particularités d'un processeur comme la fonction HWP), mais j'ai bien du mal à comprendre pourquoi un kext réseau ferait partie de cette catégorie.


----------



## polyzargone (25 Mars 2017)

Barijaona a dit:


> Pour revenir à la question, il y a quelques kexts qui refusent de se charger à partir de la partition Clover (genre ceux liés à des particularités d'un processeur comme la fonction HWP), mais j'ai bien du mal à comprendre pourquoi un kext réseau ferait partie de cette catégorie.



J'ai pas l'impression que les kexts ne sont pas chargés mais juste qu'il n'apparaissent pas dans kextstat. Je peux me tromper mais n'est-ce pas parce qu'ils ne sont pas intégrés dans le cache ?

Après, il y a une incertitude en ce qui concerne cette affaire : est-ce qu'après avoir installé BrcmFirmwareRepo.kext dans S/L/E et avoir laissé, à priori, BrcmPatchRAM2.kext dans CLOVER/kexts/Other ils finissent pas apparaître dans kextstat ?

Je me pose la question parce que BrcmPatchRAM2.kext ne contient qu'un info.plist et en ça, il s'apparente à un injecteur (et donc il n'est pas pris en compte) alors que BrcmFirmwareRepo.kext et BrcmFirmwareData.kext contiennent tous les deux des binaires.

Donc si on suit la logique, BrcmFirmwareRepo.kext devrait apparaître dans kextstat maintenant, non ?


----------



## macomaniac (27 Mars 2017)

*polyzargone*

Je me présente : "éventuel lecteur" (_sic_) > contemplateur spéculatif de *macOS* (*OS X*) > sub-ignare en Hackintosh-






Petit aperçu spéculatif (hors-Hackintosh) :

*macOS* démarre régulièrement avec le chargement du *prelinkedkernel* par le *boot_loader* : *boot.efi**. Ce *prelinkedkernel* recèle un clone du code du *kernel* et une liste de *kexts* à charger d'office en pré-boot dans l'espace du *kernel* (but du procédé : accélérer le pré-boot).

Cette liste de *kexts* peut être un tableau conforme ou filtré de la collection des extensions présentes at: */System/Libra-ry/Extensions* & at: */Library/Extensions*.

C'est la commande *kextcache* qui permet de mettre à jour (option *-u* par exemple) le cache *prelinkedkernel* afin qu'il image de manière conforme la collection intégrale des *kexts* citées > ou au contraire qu'il recèle un filtrage des *kexts* à pré-charger dans l'espace du *kernel*.

Quant à la commande *kextstat* (pareil pour *kextstatx86* - je présume ?) > elle retourne la liste de toutes les *kexts* actuellement chargées dans l'espace du *kernel* en bout de démarrage (le Système complètement initialisé). Elle ne me paraît donc pas lire le contenu du cache de pré-boot *prelinkedkernel* > mais l'espace actuel du *kernel* à la fin de démarrage. Citation du *man* :

```
The kextstat utility displays the status of any kexts currently loaded in the kernel.
```

« Currently loaded » = "actuellement chargées" au sens de l'« actuel » aristotélicien : "en acte", "effectivement" (comme distingué de « potentiellement » : "en puissance", "virtuellement").​
Cela spéculé > j'ignore totalement la façon de procéder de Clover en ce qui concerne un Hackintosh.

[* Le *boot_loader* : *boot.efi* peut être devancé par un *boot_loader* alternatif exécuté par l'*EFI* au démarrage - exemple --> le *boot_loader* : *bootx64.efi* de «rEFInd».]


----------



## polyzargone (27 Mars 2017)

*macomaniac*

On ne se connait pas mais j'ai eu l'occasion de lire avec intérêt quelques unes de tes interventions (notamment en ce qui concerne l'outil diskutil en ligne de commande et les subtilités du CoreStorage ).

Autant dire que c'est avec plaisir que je lis ton explication fort intéressante et très claire en ce qui concerne le prelinked kernel et le rôle du boot.efi qui je l'avoue n'ont jamais été très limpides pour moi .

Sans être un spécialiste de la question, je crois pouvoir dire que Clover fonctionne sensiblement sur le même concept que rEFInd. Il me semble même qu'il en est directement inspiré puisque c'est un dérivé de rEFIt, dont rEFInd est lui même un fork.

L'une des tâches de Clover est d'injecter certains kexts avant même le démarrage du boot.efi et donc de "s'ajouter" au prelinked kernel. Cela explique d'ailleurs comment il est possible de démarrer un Hackintosh en ayant le SIP totalement actif puisque le prelinked kernel ne contient alors que des kexts signés et que les kexts non signés sont injectés avant et indépendamment du prelinked kernel. Cela explique également pourquoi il n'est pas nécessaire de mettre à jour le kextcache lorsque l'on ajoute/supprime des kexts dans la partition EFI/EFI/CLOVER/kexts/.

C'est beaucoup plus clair pour moi maintenant . Merci.

Pour en revenir à kextstat, il serait donc logique qu'on y voit apparaître aussi les kexts chargés depuis l'EFI via Clover. C'est d'ailleurs ce que confirme clairement kextstatx86 (qui est effectivement le même outil que kextstat avec un certain nombre d'options en plus) :


```
MacBook-Optimus:~ polyzargone$ kextstatx86 -n
ACPIBatteryManager.kext (1.60.5) org.rehabman.driver.AppleSmartBatteryManager EFI\CLOVER\kexts\Other\ACPIBatteryManager.kext
VBoxDrv.kext (5.1.16) org.virtualbox.kext.VBoxDrv /Library/Application Support/VirtualBox/VBoxDrv.kext
FakePCIID_XHCIMux.kext (1.3.6) org.rehabman.driver.FakePCIID.XHCIMux EFI\CLOVER\kexts\Other\FakePCIID_XHCIMux.kext
FakeSMC_ACPISensors.kext (1737) org.hwsensors.driver.ACPISensors EFI\CLOVER\kexts\Other\FakeSMC.kext\Contents\PlugIns\FakeSMC_ACPISensors.kext
ApplePS2SmartTouchPad.kext (4.6.8) org.emlydinesh.driver.ApplePS2SmartTouchPad EFI\CLOVER\kexts\Other\ApplePS2SmartTouchPad.kext
FakePCIID.kext (1.3.6) org.rehabman.driver.FakePCIID EFI\CLOVER\kexts\Other\FakePCIID.kext
AppleALC.kext (1.1.0) as.vit9696.AppleALC EFI\CLOVER\kexts\Other\AppleALC.kext
VBoxNetFlt.kext (5.1.16) org.virtualbox.kext.VBoxNetFlt /Library/Application Support/VirtualBox/VBoxNetFlt.kext
VBoxNetAdp.kext (5.1.16) org.virtualbox.kext.VBoxNetAdp /Library/Application Support/VirtualBox/VBoxNetAdp.kext
EnergyDriver.kext (2.0) com.intel.driver.EnergyDriver /Library/Extensions/EnergyDriver.kext
ApplePS2Controller.kext (4.6.8) org.emlydinesh.driver.ApplePS2Controller EFI\CLOVER\kexts\Other\ApplePS2SmartTouchPad.kext\Contents\PlugIns\ApplePS2Controller.kext
osxfuse.kext (3.5.5) com.github.osxfuse.filesystems.osxfuse /Library/Filesystems/osxfuse.fs/Contents/Extensions/10.12/osxfuse.kext
BCM5722D.kext (2.3.5) my.name.adlan.BCM5722D EFI\CLOVER\kexts\Other\BCM5722D.kext
FakeSMC.kext (1737) org.netkas.driver.FakeSMC EFI\CLOVER\kexts\Other\FakeSMC.kext
VBoxUSB.kext (5.1.16) org.virtualbox.kext.VBoxUSB /Library/Application Support/VirtualBox/VBoxUSB.kext
IntelGraphicsFixup.kext (1.0.0) as.lvs1974.IntelGraphicsFixup EFI\CLOVER\kexts\Other\IntelGraphicsFixup.kext
ApplePS2Keyboard.kext (4.6.8) org.emlydinesh.driver.ApplePS2Keyboard EFI\CLOVER\kexts\Other\ApplePS2SmartTouchPad.kext\Contents\PlugIns\ApplePS2Keyboard.kext
Lilu.kext (1.0.0) as.vit9696.Lilu EFI\CLOVER\kexts\Other\Lilu.kext
Shiki.kext (2.0.0) as.vit9696.Shiki EFI\CLOVER\kexts\Other\Shiki.kext
FakeSMC_CPUSensors.kext (1737) org.hwsensors.driver.CPUSensors EFI\CLOVER\kexts\Other\FakeSMC.kext\Contents\PlugIns\FakeSMC_CPUSensors.kext
```

Maintenant, la question est : outre le fait qu'il soit chargé au moment de l'exécution de la commande, quelles sont les autres conditions pour qu'un kext apparaisse dans kextstat ?

Faut-il qu'il comporte un binaire, un champ spécifique dans son info.plist (j'ai lu quelque part que *CFBundleIdentifier* pouvait y être pour quelque chose), autre chose ?

Pourquoi certains kexts y apparaissent et d'autres pas ?

Tellement de questions (existentielles évidemment) et si peu de réponses  !


----------



## macomaniac (28 Mars 2017)

*polyzargone*

Alors voici une rallonge « spéculative » (je n'ai aucune formation informatique, mais classique : philosophie > logique aristotélicienne et mathématique => j'applique donc un raisonnement tout ce qu'il y a de non-spécialisé aux objets informatiques).

Le *boot_loader : boot.efi* (localisé at: */System/Library/CoreServices*) est un fichier exécutable de type spécial, en ce qu'il est exécutable par l'*EFI*. On peut donc le considérer comme une « application de l'*EFI* ».

Cette application n'est pas cantonnée mécaniquement au mode d'emploi de son code, mais a la propriété de pouvoir recevoir des instructions supplémentaires de la part de l'*EFI*. En effet, l'*EFI*, après vérification du hardware (*POST*) > commence toujours par visiter la *NVRAM* pour y lire les instructions en place, genre *boot_flags*. Le *SIP*, notamment, consiste en une suite de *6 flags* en *NVRAM* qui sont chargés par l'*EFI*. Par suite, l'*EFI* ne se contente pas de lancer l'application qu'est le *boot.efi* > mais elle « passe » (transmet) à cette application les *flags* de la *NVRAM* => il s'agit donc d'une « implémentation » en amont du code du *boot.efi*.

----------

À présent > une spécificité d'*OS X* > *macOS* est que ce Système ne démarre pas régulièrement sur l'original du *kernel* (at: */System/Library/Kernels/kernel*) > mais sur un clone du code de ce *kernel* recelé dans un cache de démarrage *prelinkedkernel* (at: */System/Library/PrelinkedKernels/prelinkedkernel*). Le *kernel* original sert de paradigme pour la constitution du cache de démarrage.

La fonction basique du *boot.efi* est de démarrer le *kernel* par l'exécution de son code et de déclencher le processus d'injection des *kexts* dans l'espace du *kernel* par transmission du bloc d'adresses d'extensions recelé dans le cache *prelinkedkernel*. Mais > dans la mesure où le *boot.efi*, en tant qu'application de l'*EFI*, a reçu une implémentation de *flags* de la part de l'*EFI* > le *boot.efi* assure le rôle supplémentaire de passation de ces *flags* au *kernel* : c'est donc ici un rôle de « rouage de transmission ». C'est ainsi, par exemple, que les *flags* du *SIP* se trouvent passés au *kernel* au démarrage. Je pense que cette transmission « supplémentaire » s'opère au démarrage du *kernel* par le *boot.efi* > avant même le processus d'injection.

----------

Étant donné ce court aperçu de la séquence de pré-boot > la question spéculative passionnante est : que se passe-t-il quand l'exécution du *boot_loader boot.efi* par l'*EFI* se trouve « interceptée » par le *boot_loader* d'un gestionnaire de démarrage comme le *bootx64.efi* de «rEFInd»  ? Sachant que l'*EFI* quitte classiquement, en tant que processus logiciel, après l'exécution de l'application : *boot.efi* > je présume qu'on peut extrapoler cette séquence à celle de l'exécution du *boot_loader* de «rEFInd» : cette application tierce de l'*EFI* démarrée > l'*EFI* quitte la scène.

Cette analogie fonctionnelle des *boot_loaders* permet d'induire que le *boot_loader* de «rEFInd» est capable, comme le *boot.efi* orthodoxe, de recevoir l'implémentation par l'*EFI* de *flags* de la *NVRAM*. À supposer qu'aucun filtre de ces *flags* ne soit activé dans le programme du *boot_loader* de «rEFInd». Ainsi, dans l'environnement de «Yosemite 10.10» (tristement notoire pour l'introduction des *flags* du *kext_signing* en *NVRAM*) > démarrer cet OS par l'intermédiaire du *boot_loader* de «rEFInd» et pas directement par le *boot.efi* > avait une admirable conséquence : les *flags* du *kext_signing* (supposés présents en *NVRAM*) n'étaient pas reçus de la part de l'*EFI* par le *boot_loader* de «rEFInd» > mais échappés > ce qui fait qu'on pouvait bidouiller des *kexts* Apple sans qu'aucune vérification d'intégrité tâtillonne ne soit opérée.

Ce petit point curieux démontre ceci : un *boot_loader* de tierce partie comme celui de «rEFInd» possède une « autonomie » logicielle relative par rapport au déterminisme strict du *boot_loader boot.efi* orthodoxe. Autonomie confirmée par le fait que, le *boot_loader* de «rEFInd» activé > le choix du mode de démarrage d'un OS ciblé se trouve ouvert (*safe mode*, *single user*, *verbose*  etc.). C'est dans le volume *EFI* de l'*ESP* (*E*FI_*S*ystem_*P*artition : *disk0s1* pour un disque unique) que résident les dossiers de boot de «rEFInd».

----------

Admis l'état de choses : *boot_loader* de «rEFInd» démarré et processus de l'*EFI* quitté > comment va s'opérer le démarrage du Système ciblé  ? - ma faculté spéculative avait envisagé 2 options : soit le *boot_loader* de «rEFInd» adressait directement le *prelinkedkernel* de démarrage > soit le *boot_loader* de «rEFInd» exécutait le *boot.efi* du Système-cible - à charge pour ce dernier de démarrer le *kernel* du *prelinkedkernel* (exclue la possibilité d'une double action > car le *kernel* ne peut pas être démarré 2 fois > mais une seule fois : soit par un *boot_loader* > soit par l'autre).

Je pense que c'est la seconde option qui est vraie : le *boot_loader* de «rEFInd» tient le rôle exécutif de l'*EFI* pour le *boot_loader boot.efi* régulier et ne se susbtitue pas à lui pour charger directement le *prelinkedkernel*. Argument simple : étant donné qu'un même *boot_loader* de «rEFInd» est capable de lancer toute sortes de versions de *macOS* (de «Snow Léopard» à «Sierra» sur mon _MacBook Pro 17" i7 2,5 GHz Late_2011_) > impliquant des *kernels* d'architecture variée (*mach_kernel* > *kernel*) --> il me paraît difficile à concevoir que son code puisse gérer un pareil différentiel. Argument « légaliste » : un *boot_loader* de tierce partie fonctionnant en substitution du *boot_loader* Apple réglementaire > équivaudrait à un remplacement logiciel incriminable.

À supposer donc ma conjecture valide : le *boot_loader* de «rEFInd» jouant le rôle de relai exécutif de l'*EFI* pour l'exécution spécifique du *boot_loader boot.efi* orthodoxe --> on aurait donc la chaîne : *EFI* > *NVRAM* > *boot_loader tiers* > *boot.efi* > *prelinkedkernel*.

----------

Supposons à présent que parmi les ressources de l'application : *boot_loader* tiers dans le volume de l'*ESP* > il y ait des *kexts* à faire injecter dans l'espace du *kernel* > et supposons toujours que le *boot_loader* tiers ait pour cible exclusive l'exécution du *boot_loader boot.efi* orthodoxe qu'il ne peut pas remplacer > et gardons toujours présente à l'esprit l'idée que le *kernel* ne peut pas être démarré 2 fois > mais une seule fois > le seul *kernel* adressable étant le clone du code du *kernel* recelé par le *prelinkedkernel*.

Alors peut se concevoir la séquence suivante : le *boot_loader* tiers (on dira celui de «Clover» dont je ne sais rien mais que je reconstruis en imagination par extrapolation de celui de «rEFInd») > ne peut absolument pas injecter directement et préliminairement les *kexts* supplémentaires qui sont recelées dans ses dossiers de ressources sur l'*ESP* > car pour ce faire > le *kernel* devrait être déjà démarré auparavant > afin qu'elles soient injectées dans son espace. Mais > si c'est bien le *boot_loader boot.efi* qui est en charge de ce lancement du *kernel* > sans avoir encore été exécuté par le *boot_loader* tiers > alors le *boot_loader* tiers ne peut injecter aucune *kext* par lui-même.

Ce qu'il peut faire > c'est : à l'exécution du *boot_loader boot.efi* > lui passer comme implémentation le tableau d'adresses des *kexts* tierces recelées dans le volume de l'*ESP* (NB. savoir qu'au pré-boot > *tous* les volumes montables sur toutes les partitions de disques sont montés et adressables, le volume *EFI* de l'*ESP* compris). Donc le *boot_loader* tiers passerait ce tableau au *boot_loader boot.efi* au même titre que les *flags* reçus de l'*EFI*.

Ledit *boot_loader boot.efi* se trouverait donc implémenté dans son code de *flags* de la *NVRAM* et du tableau d'adresses de *kexts* transmis par le *boot_loader* tiers qui devance son exécution. Conséquence : le *boot_loader boot.efi* ainsi implémenté > démarrerait le *kernel* du *prelinkedkernel* > lui passerait au moment même de ce démarrage les *flags* de la *NVRAM* de provenance *EFI* et le tableau des *kexts* de l'*ESP* de provenance *boot_loader* tiers > puis lirait le bloc des adresses de *kexts* inclus dans le *prelinkedkernel* pour le passer régulièrement au *kernel*.


----------



## polyzargone (28 Mars 2017)

Toujours pas spécialiste de la question (je n'ai aucune formation informatique non plus mais plutôt littéraire/artistique, comme quoi ), je crois que c'est bel bien comme cela que ça se passe (option 2)

Extrait du wiki de Clover :



> When booting or restarting a PC, Clover loads operating system as follows:
> 
> *Option A*: BIOS-based PC (old motherboards)
> 
> ...



Où *OSLoader* est bien le boot.efi de macOS.

Concernant l'injection des kexts, je crois que j'ai fait une confusion entre celle-ci et ce qu'on appelle les "Patchs à la volée" de kext (voire du kernel lui même). Il me semble que c'est cela qui est fait en amont par Clover et qui doit être transmis d'une manière ou d'une autre (le tableau d'adresses ?) au boot.efi puis finalement au kernel et au prelinked kernel.

Mais là, j'avoue que ça devient trop technique pour moi. Et mine de rien, je me rends compte qu'on est totalement hors sujet par rapport à ce fil .

On peut poursuivre la discussion ici si tu le souhaites.

En tout cas, merci pour toutes ces infos  !


----------



## Barijaona (27 Août 2017)

Surprise pour moi en testant les betas récentes de macOS High Sierra : mes ports USB ne marchaient plus (et donc notamment le clavier et la souris, ce qui était plutôt gênant !)… alors qu'ils march(ai)ent parfaitement sous Sierra et les premières versions de High Sierra !

Trouvant peu d'information sur Internet sur ce sujet, j'ai souffert dessus pendant une semaine, mais je vais essayer de vous la faire brève.

1/ J'ai découvert que les ports USB 3.1 restaient fonctionnels, ce qui m'a permis de brancher le clavier et la souris (vive les bons vieux claviers filaires Apple et leur hub intégré !)

2/ Les autres ports apparaissaient bien dans IORegistryExplorer, mais si un périphérique était branché dessus au moment du boot, ils n'étaient pas activés et on avait un message dans le log du genre :

```
kernel IOUSBHostFamily 000060.602753 HS04@14200000: AppleUSBHostPort::disconnect: persistent enumeration failures
```

3/ En regardant de plus près dans IORegistryExplorer, j'ai fini par remarquer que contrairement à l'autre, le contrôleur "non USB 3.1" n'apparaissait pas sous l'arborescence IOService:/IOResources/AppleUSBHostResources/AppleUSBLegacyRoot

4/ Du coup, en fouillant encore un peu, j'ai découvert que ce qui semblait manquer, c'était la propriété _FixOwnership_ dans mon config.plist

5/ Ceci expliquait pourquoi quasiment personne n'avait été confronté au même problème que moi… _FixOwnership : true_ est en effet présent dans quasiment toutes les recommandations en matière de configuration de Clover.
Mais moi, je l'avais désactivé car j'avais été confronté à des impossibilités de sortir d'hibernation, et l'enlever semblait avoir amélioré les choses… Et je me suis malheureusement rendu compte que si le remettre me permettait effectivement d'activer les ports USB sous High Sierra, cela me ramenait aussi ces satanés problèmes de sortie d'hibernation sous Sierra !

6/ Du coup j'ai essayé de regarder un peu le code source dans Clover. Et je ne comprenais pas ce que pouvait bien apporter _FixOwnership : true_, alors que dans le BIOS, tout ce qui était _legacy_ semblait déjà désactivé et que _XHCI Hand-off_ était activé.

7/ Bref, en tripatouillant dans le BIOS, j'ai fini par trouver que la bonne solution était de mettre dans le BIOS* Windows 8/10 Features : Windows 8/10* (au lieu de _Other OS_ comme cela est le plus souvent recommandé) et *CSM Support : Disabled*

Si après avoir changé ce réglage, vous rencontrez un problème pour boooter, pas de panique ! Tentez d'abord un redémarrage en Safe mode pour vider le cache, et cela devrait marcher…


----------



## gradou (28 Août 2017)

Oui, le 7/ est  la configuration bios que j'utilise depuis le début pour avoir un boot avec une bonne résolution. Je n'ai pas non plus de de pb de réveil avec cette config sous Sierra ou HS ni de pb USB sous HS...


----------



## nicolasf (29 Août 2017)

Merci pour ce retour !

Il faudrait que j'essaie cette configuration de BIOS, ne serait-ce que pour le boot à la bonne résolution.


----------



## flotow (8 Janvier 2018)

C'est un copier coller de ce message... mais je me dis que ca a peut être plus ca place ici 

J'ai aussi pose une question sur isanelymac... on ne sait jamais !
http://www.insanelymac.com/forum/topic/331415-mapped-usb-ports-do-not-work-well-with-ipod-io-error/



> J'ai un problème intéressant a vous exposer...
> 
> Quand je branche mon iPod 3G en USB, alors j'ai pleins d'erreurs, le disque n'est pas lisible et iTunes le voit comme corrompu...
> Cette erreur est aléatoire, mais une fois qu'elle est apparue, elle ne disparait pas.
> ...


----------



## flotow (12 Janvier 2018)

Je me reponds....
le problème que j'ai est en fait connu (mais j'étais parti directement sur un problème d'USB...)
https://discussions.apple.com/thread/7353475


```
12/01/18 00:40:12,000 kernel[0]: 000342.756938 HS04@14400000: AppleUSB20XHCIPort::resetAndCreateDevice: failed to create device, disabling port
```

De ce que j'ai lu, ca arrive :
- sur Hackintosh, lors de la premiere installation (solution : augmenter la limite de port)
- sur Mac, si il y a un outil de virtualisation (VirtualBox/Fusion)
- sur Mac, sans rien de particulier... et c'est mon cas (enfin, sur Hackintosh, mais mes ports sont mappés) 

Au moins une personne indique que ca fonctionne derriere un hub...
Je vais voir, j'en ai un qui traine !
Sinon, je mettrai l'iPod a jour sous Windows 

Par contre, il se trouve que j'avais quelques petits trucs incorrects, ce que j'ai corrige.
Je ne vois pas de difference a l'utilisation cela dit.


----------

