Les sources de XNU 1486.2.11 (le kernel de la 10.6.2) ont été publiées par Apple. L'occasion d'aller voir d'un peu plus près ce qu'il a été fait au niveau de la reconnaissance des processeurs.

Nous avions publié une petite partie de la manière dont le kernel vérifie les processeurs en fonction de leur enregistrement dans xnu.
reprenons ces parties dans les dernières sources, et voyons ce qui a changé:

#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_YONAH 0x73d67300
#define CPUFAMILY_INTEL_MEROM 0x426f69ef
#define CPUFAMILY_INTEL_PENRYN 0x78ea4fbc
#define CPUFAMILY_INTEL_NEHALEM 0x6b5a4cd2
#define CPUFAMILY_ARM_9 0xe73283ae
#define CPUFAMILY_ARM_11 0x8ff620d8
#define CPUFAMILY_ARM_XSCALE 0x53b005f5
#define CPUFAMILY_ARM_13 0x0cc90e64

/* The following synonyms are deprecated: */
#define CPUFAMILY_INTEL_6_14 CPUFAMILY_INTEL_YONAH
#define CPUFAMILY_INTEL_6_15 CPUFAMILY_INTEL_MEROM
#define CPUFAMILY_INTEL_6_23 CPUFAMILY_INTEL_PENRYN
#define CPUFAMILY_INTEL_6_26 CPUFAMILY_INTEL_NEHALEM

#define CPUFAMILY_INTEL_CORE CPUFAMILY_INTEL_YONAH
#define CPUFAMILY_INTEL_CORE2 CPUFAMILY_INTEL_MEROMOn voit ici, comparé au précédent kernel, qu'Apple tend à modifier ce processus, en semblant abandonner peu à peu la signature numérotée au profit d'une signature par nom de modèle.

Plus intéressant, bien qu'ici il n'y ait pas de référence à l'ATOM (ces signature servent essentiellement aux application pour identifier le processeur via hw.cpufamily), cette référence existe mantenant bel et bien dans une autre partie du noyau:

#define CPUID_MODEL_YONAH 14
#define CPUID_MODEL_MEROM 15
#define CPUID_MODEL_PENRYN 23
#define CPUID_MODEL_NEHALEM 26
#define CPUID_MODEL_ATOM 28
#define CPUID_MODEL_FIELDS 30 /* Lynnfield, Clarksfield, Jasper */
#define CPUID_MODEL_DALES 31 /* Havendale, Auburndale */
#define CPUID_MODEL_NEHALEM_EX 46
ATOM s'est donc bien invité dans le noyau, non pas à priori pour un support spécifique. Également, ce n'est pas une surprise, les processeurs icore5/7 font leur entrée.
Un peu plus surprenant par contre, les processeurs de la familles des "Dales" sont aussi introduits, alors que, selon ce qui l'on pouvait lire un peu partout sur le net, Intel a abandonné ces processeurs (45nm) au profit d'une gravure en 32nm (les processeurs Arrandale / Clarkdale).
On note également une nouvelle génération de Nehalem, les Nehalem EX, qui vous vous en doutez, ne seront pas destinés aux Mac Mini...

Les commentaires induisent en erreurs sur les processeurs concernés, et il y a fort à parier qu'Apple prévoit d'équiper les MacBook Pro avec des processeurs de la famille Dale en 32nm.
Précisons que ces processeurs sont destinés aux machines portables (avec un chipset graphique intégré), et devraient être disponibles en début d'année prochaine. Affaire à suivre...

A titre de comparaison, voici comment se présentait cette liste dans le précédent noyau:
#define CPUID_MODEL_YONAH 14
#define CPUID_MODEL_MEROM 15
#define CPUID_MODEL_PENRYN 23
#define CPUID_MODEL_NEHALEM 26

Egalement, ce qui a changé au sein du processus d'acquisition de la famille des processeurs:
static uint32_t
cpuid_set_cpufamily(i386_cpu_info_t *info_p)
{
uint32_t cpufamily = CPUFAMILY_UNKNOWN;

switch (info_p->cpuid_family) {
case 6:
switch (info_p->cpuid_model) {
case 13:
cpufamily = CPUFAMILY_INTEL_6_13;
break;
case 14:
cpufamily = CPUFAMILY_INTEL_YONAH;
break;
case 15:
cpufamily = CPUFAMILY_INTEL_MEROM;
break;
case 23:
cpufamily = CPUFAMILY_INTEL_PENRYN;
break;
case CPUID_MODEL_NEHALEM:
case CPUID_MODEL_FIELDS:
case CPUID_MODEL_DALES:
case CPUID_MODEL_NEHALEM_EX:
cpufamily = CPUFAMILY_INTEL_NEHALEM;
break;
}
break;
}
Comparé au précédent Kernel, il n'y a plus de case "Default". De même, mis à part pour les processeurs intel-core..etc (6_13), les familles sont données par leur nom, en accord avec les changements vu plus haut.
A ce stade, il est probable que d'ajouter ici une condition pour les processeurs ATOM pourrait régler le problème, ou bien en réintroduisant une condition pour les processeurs flagués UNKNOWN. (notez ici que les Dales sont quant à eux pris en considération)

En allant voir un peu plus loin dans le code, voici comment le précédent kernel réagissait à l'acquisition des cpu_family:
/* verify we are running on a supported CPU */
if ((strncmp(CPUID_VID_INTEL, cpuid_cpu_info.cpuid_vendor,
min(strlen(CPUID_STRING_UNKNOWN) + 1,
sizeof(cpuid_cpu_info.cpuid_vendor)))) ||
(cpuid_cpu_info.cpuid_family != 6) ||
(cpuid_cpu_info.cpuid_model < 13))
panic("Unsupported CPU");Nous avons mis en gras les conditions, qui signifient que si la famille est différente de 6 (cf: Intel) ou le model inférieur à 13 (processeurs minium avec SSE3), Darwin ne se lance pas.

Maintenant, voici comment procède le nouveau kernel:
/* verify we are running on a supported CPU */
if ((strncmp(CPUID_VID_INTEL, info_p->cpuid_vendor,
min(strlen(CPUID_STRING_UNKNOWN) + 1,
sizeof(info_p->cpuid_vendor)))) ||
(cpuid_set_cpufamily(info_p) == CPUFAMILY_UNKNOWN))
panic("Unsupported CPU");Les choses semblent beaucoup plus restrictives, puisque les familles non enregistrés avec le code précédent sont exclues, et les ATOM font parti du lot.


Il faudrait aller un peu peu plus en profondeur pour savoir si une petite modification dans ce processus permettrait de faire "avaler" les ATOM par XNU, compiler le noyau et tester s'il n'y a pas d'autres verrous. Mais à priori, étant donné qu'un patch du binaire existe déjà pour les ATOM, celui-ci doit sans doute porter sur cette partie de code relativement simple à modifié, vu la rapidité avec laquelle ce patch est sorti. (cf. Mise à jour 10.6.2)

Cependant, il est difficile de lire les intentions d'Apple en la matière: les modifications présentées ne portent pas spécifiquement sur l'ATOM mais font partie d'un mise à jour plus générale de la relation noyau/processeurs; malgré tout, l'ATOM est enregistré dans le fichier relatif aux cpuid alors qu'Apple ne produit pas de machine avec de type de processeur.
D'un autre côté, si verrouillage de l'ATOM il devait y avoir, on aurait pu s'attendre à quelque chose d'un peu plus difficile à contourner. A moins qu'il s'agisse de compliquer juste un peu plus l'installation à partir d'un DVD original sur les Netbook avec un minimum d'effort.

Bref, à priori Apple ne communiquera pas sur cette question, et comme toujours déterminer ce qu'il s'est passé reste de la spéculation.
Nous essayerons de suivre au fil des mises à jour l'évolution dans laquelle le noyau est engagé, peut-être les choses deviendrons un peu plus claires.


MaJ:
On a réussi à lancer le système avec un mini équipé d'un ATOM en faisant une micro modification du code source:
switch (info_p->cpuid_family) {
case 6:
switch (info_p->cpuid_model) {
case 13:
cpufamily = CPUFAMILY_INTEL_6_13;
break;
case 14:
case CPUID_MODEL_ATOM:
cpufamily = CPUFAMILY_INTEL_YONAH;
break;
case 15:
cpufamily = CPUFAMILY_INTEL_MEROM;
break;
case 23:
cpufamily = CPUFAMILY_INTEL_PENRYN;
break;
case CPUID_MODEL_NEHALEM:
case CPUID_MODEL_FIELDS:
case CPUID_MODEL_DALES:
case CPUID_MODEL_NEHALEM_EX:
cpufamily = CPUFAMILY_INTEL_NEHALEM;
break;
}
break;
}
Le case 14 correspond aux "intel core solo". Nous avons donc rangé l'ATOM avec pour que XNU l'accepte.

Malheureusement, on a un peu de mal à faire fonctionner les sources de manière normale, même sans aucune modification et sur un processeur supporté. Il semblerait que le couple DarwinBuild / 10C540 ne fonctionne encore pas très bien, puisque le noyau obtenu à partir des sources ne fait pas la même taille que celui fourni par Apple (18 Mo contre 18,7 Mo), et présente des bugs. C'est la première fois que l'on rencontre ce problème.

Merci à PM! et son mini pour avoir fait les cobayes :)

Bientôt un Forum sur DarwinX86.org		Psystar publie les sources de leur DUBL