Intel ATOM, XNU et 10.6.2



Une chose est certaine, la sphère des sites de news et les "Mac lecteurs" sont friands des rumeurs venant du monde Apple.
Ce qui peut être compréhensible, dans le sens ou les "vraies" news n'étant pas légion, il faut bien entretenir son lectorat.

Depuis quelques temps déjà, ces sites se font également le relai d'informations venant du Hackintosh, avec plus ou moins de succès. La dernière rumeur en date fait état d'un "retrait" du support des processeurs ATOM au niveau du Kernel. La rumeur viendrait du blog de Stellarola.

Ainsi, ils sont nombreux à s'être jetés sur cette histoire pour affirmer qu' Apple aurait volontairement supprimé le support de ces processeurs pour limiter l'usage des Netbook avec OSX, ces derniers ayant largement contribué à diffuser le "phénomène hackintosh".

Malheureusement, cette théorie n'est fondée sur rien de vérifiable pour le moment, et à notre avis totalement erronée.
Quelqu'un qui connait un peu le système d'Apple, sait que le noyau XNU est open source: ça semble tomber sous le sens que si Apple tente de verrouiller son système, une éventuelle protection n'irait pas se loger dans une portion de code open source, lisible et modifiable par tout le monde, mais plutôt à la manière d'une puce hardware, ou d'un kext, comme c'est déjà le cas.

Mieux encore, XNU n'a jamais officiellement supporté des processeurs Intel ATOM! Ceux qui ont installé OSX sur le Netbook le savent bien, le processeur n'est pas identifié par le système sans l'aide d'un patch.
Ce qui nous amène à la manière dont XNU tient compte du processeur de votre machine. C'est pourquoi nous allons aller à la source, à savoir les sources, plutôt que de répéter les rumeurs venant d'autres blogs.

Dans un premier temps, examinons les processeurs intel "reconnus" par XNU (1456.1.26, le noyau 10.0):
/*
* CPU families (sysctl hw.cpufamily)
*
* These are meant to identify the CPU's marketing name - an
* application can map these to (possibly) localized strings.
* NB: the encodings of the CPU families are intentionally arbitrary.
* There is no ordering, and you should never try to deduce whether
* or not some feature is available based on the family.
* Use feature flags (eg, hw.optional.altivec) to test for optional
* functionality.
*/
#define CPUFAMILY_UNKNOWN 0
#define CPUFAMILY_POWERPC_G3 0xcee41549
#define CPUFAMILY_POWERPC_G4 0x77c184ae
#define CPUFAMILY_POWERPC_G5 0xed76d8aa
#define CPUFAMILY_INTEL_6_13 0xaa33392b
#define CPUFAMILY_INTEL_6_14 0x73d67300 /* "Intel Core Solo" and "Intel Core Duo" (32-bit Pentium-M with SSE3) */
#define CPUFAMILY_INTEL_6_15 0x426f69ef /* "Intel Core 2 Duo" */
#define CPUFAMILY_INTEL_6_23 0x78ea4fbc /* Penryn */
#define CPUFAMILY_INTEL_6_26 0x6b5a4cd2 /* Nehalem */
#define CPUFAMILY_ARM_9 0xe73283ae
#define CPUFAMILY_ARM_11 0x8ff620d8
#define CPUFAMILY_ARM_XSCALE 0x53b005f5
#define CPUFAMILY_ARM_13 0x0cc90e64

#define CPUFAMILY_INTEL_YONAH CPUFAMILY_INTEL_6_14
#define CPUFAMILY_INTEL_MEROM CPUFAMILY_INTEL_6_15
#define CPUFAMILY_INTEL_PENRYN CPUFAMILY_INTEL_6_23
#define CPUFAMILY_INTEL_NEHALEM CPUFAMILY_INTEL_6_26

#define CPUFAMILY_INTEL_CORE CPUFAMILY_INTEL_6_14
#define CPUFAMILY_INTEL_CORE2 CPUFAMILY_INTEL_6_15

Comme expliqué dans l'entête, l'identification des processeurs se fait de manière arbitraire par le noyau: Apple a pris soin de définir une série de processeurs livrés avec leurs machine (d'ailleurs ont voit que les références aux PowerPC n'ont pas été supprimées).
En première ligne, on voit également qu'un Unknown type est défini, qui permet donc une porte de sortie pour des processeurs non enregistrés par Apple. Vient ensuite une petite liste restreinte de modèles produits par Intel et utilisés par Apple (PENRYN, NEHALEM..etc). Ces modèles sont associés à des numéros d'identification (6_14, 6_15..etc) que l'on retrouve dans le bout de code plus bas.

Voyons maintenant comment sont validés les processeurs Intel (toujours le noyau 10.0):
#elif defined (__i386__) || defined (__x86_64__)
mmx_flag = ((_get_cpu_capabilities() & kHasMMX) == kHasMMX)? 1 : 0;
sse_flag = ((_get_cpu_capabilities() & kHasSSE) == kHasSSE)? 1 : 0;
sse2_flag = ((_get_cpu_capabilities() & kHasSSE2) == kHasSSE2)? 1 : 0;
sse3_flag = ((_get_cpu_capabilities() & kHasSSE3) == kHasSSE3)? 1 : 0;
supplementalsse3_flag = ((_get_cpu_capabilities() & kHasSupplementalSSE3) == kHasSupplementalSSE3)? 1 : 0;
sse4_1_flag = ((_get_cpu_capabilities() & kHasSSE4_1) == kHasSSE4_1)? 1 : 0;
sse4_2_flag = ((_get_cpu_capabilities() & kHasSSE4_2) == kHasSSE4_2)? 1 : 0;
x86_64_flag = ((_get_cpu_capabilities() & k64Bit) == k64Bit)? 1 : 0;

/* hw.cpufamily */
switch (cpuid_info()->cpuid_family) {
case 6:
switch (cpuid_info()->cpuid_model) {
case 13:
cpufamily = CPUFAMILY_INTEL_6_13;
break;
case 14:
cpufamily = CPUFAMILY_INTEL_6_14; /* Core Solo/Duo */
break;
case 15:
cpufamily = CPUFAMILY_INTEL_6_15; /* Core 2 */
break;
case 23:
cpufamily = CPUFAMILY_INTEL_6_23;
break;
case 26:
cpufamily = CPUFAMILY_INTEL_6_26;
break;
default:
cpufamily = CPUFAMILY_UNKNOWN;
}
break;
default:
cpufamily = CPUFAMILY_UNKNOWN;
}
On voit dans cette partie de code que le noyau vérifie dans un premier temps les jeux d'instructions du processeur (MMX, SSE3...etc). Ensuite, il vérifie les signatures des processeurs (en partie définies dans le premier bout de code), avec, comme valeur par défault: Unknown.

On voit dans ce code que, si les jeux d'instructions sont trouvés mais pas la signature, le kernel valide tout de même le processeur,avec la signature par défaut "CPUFAMILY_UNKNOWN".

Les ATOM possèdent ces jeux d'instructions, mais n'ont pas de signature dans le Kernel. Ils sont donc acceptés par le kernel et sont affiché ensuite en tant que "unknown" par le système. Ils n'ont donc jamais été "ajoutés" au kernel.

Un patch venant du kernel Voodoo permettait par exemple d'identifier les ATOM en tant que Core Solo, notamment en définissant la taille des caches (une des méthode de vérification du processeur par XNU) de l'ATOM et les associant au modèle Intel Core Solo.
En effet, le système ne reconnait nativement que quelques types de processeurs Intel: Core Solo/Duo/2Duo, Xeon et bientôt ICore (fort à parier que modifications du noyau de la 10.6.2 qui nous intéresse viennent de l'introduction de ces modèles)

Ceci dit, il faudrait qu' Apple modifie la manière dont sont enregistrés les processeurs (les caches, jeux d'instructions...etc) dans XNU, ce qui nous paraît être des modifications relativement lourdes pour pas grand chose. (je n'ai posté ici qu'un partie, mais il y a énormément de code supplémentaire lié aux processeurs).

Reste tout de même à attendre la version finale de la 10.6.2, pour voir de quoi il en retourne exactement. Mais nous avons vu que le blacklistage de l'ATOM au niveau du kernel ne serait pas des plus pertinent.

Reste donc à savoir si Apple en a réellement quelque chose à faire des hackintosh, (depuis le passage aux architectures x86, aucune protection n'a été mise en place en dehors de la puce SMC).
 

Commentaires 

 
0 #1 MowgliBook 04-11-2009 14:12
héhé :D
Citer
 
 
0 #2 04-11-2009 15:25
Merci pour ces précisions !
Citer
 
 
0 #3 04-11-2009 15:26
ça ne fait que confirmer ce que je pensait.Y en a vraiment qui n'ont d'autres choses à faire que du buzz.
Les hackintosh sous AMD ça existe bien et pourtant ça n'a jamais été supporté par apple.CQFD.Merci pour cet article sonotone.
Citer
 
 
0 #4 05-11-2009 08:08
tres bien expliquer comme toujours ;-)
Citer
 
 
0 #5 sonotone 05-11-2009 13:46
Citation en provenance du commentaire précédent de blakken :
Les hackintosh sous AMD ça existe bien et pourtant ça n'a jamais été supporté par apple.CQFD.Merci pour cet article sonotone.

Oui, ça fonctionne, mais pas avec le Kernel fourni par Apple. Là, en l'occurrence avec les Atoms, le kernel est capable de le faire fonctionner, puisque ce dernier requière au minium SSE3, ce que les Atom possèdent, mais ce qui signifie que les processeurs Intel antérieurs (SSE2) ont besoin d'une émulation SSE3 pour fonctionner avec OSX.
Citer
 
 
0 #6 coucou78 05-11-2009 17:48
merci sonotone.
Citer
 
 
0 #7 06-11-2009 11:37
merci pour cette info et votre explication très claire
Citer