Linux sur un 286?

Je ne possède pas de 286 et je n'ai pas l'intention d'exécuter Linux sur un seul. Cependant, étant donné que le 286 a un mode protégé, pourquoi est-il souvent indiqué que Linux nécessite un processeur 386 ou supérieur?

D'après http://tuxmobil.org/286_mobile.html, il semble que la version ELKS de Linux puisse fonctionner sur un 286, est-ce correct? Quelles (le cas échéant) modifications ont été apportées pour permettre au noyau de fonctionner sur le CPU 286?

Maintenant, évidemment, je comprends qu'un noyau compilé pour un 386 ne peut pas s'exécuter sur un CPU 286, qui est de 16 bits. Ma question est donc la suivante: pourquoi le noyau Linux standard ne peut-il pas être compilé pour un 286, puis exécuté sur un 286? Linux nécessite-t-il une prise en charge matérielle de VM86?

Le mode protégé 286 (PM) est fondamentalement différent de ce que propose le 386. Considérez le 286 PM comme un prototype, qui avait tellement de lacunes que presque personne ne l'a jamais utilisé, et le tout a été entièrement repensé à partir de zéro pour le 386.

Il n'utilisait pas de modèle de mémoire plat, il utilisait un modèle segmenté comme le mode réel, ce qui signifiait que vous deviez sauter à travers des cerceaux pour accéder à la mémoire dans des blocs de plus de 64 Ko à la fois.

Il était complètement incompatible avec tous les programmes (MS-DOS) disponibles à l'époque, donc une fois dans PM, vous ne pouviez utiliser aucun des programmes auxquels vous étiez habitué.

Vous ne pouviez pas non plus quitter le mode protégé à moins d'avoir redémarré le PC, les fabricants ont donc trouvé des solutions créatives comme mettre un indicateur dans la RAM, puis écrire une valeur magique sur le contrôleur du clavier, qui effleurerait la broche de réinitialisation du CPU pour redémarrer le machine. La première chose que le BIOS ferait serait de détecter l'indicateur défini plus tôt, où il retournerait ensuite au programme d'origine au lieu d'exécuter la routine POST, permettant au programme d'origine de continuer à s'exécuter après avoir "quitté" PM.

Cela signifiait que l'utilisation du 286 PM vous empêchait d'exécuter des programmes DOS normaux sans un grand nombre de trucs. À une époque où il n'y avait que des programmes DOS, cela ne valait pas du tout la peine d'utiliser PM.

Il a donc été plus compliqué de travailler avec le 286 PM que de simplement s'en passer et de s'appuyer sur EMS et XMS pour accéder à la mémoire supplémentaire. Un certain nombre de 286 cartes mères avaient un support de chipset pour EMS afin que vous puissiez utiliser toute la mémoire système supplémentaire sans avoir besoin de PM.

Intel a reconnu ces lacunes et a produit un tout nouveau PM complètement différent dans le 386. Le modèle de mémoire plate facilite l'accès à la mémoire dans un bloc allant jusqu'à 4 Go. Le processeur peut entrer et sortir de PM avec quelques instructions afin qu'aucun protocole de redémarrage maladroit ne soit nécessaire. VM86 signifie que la plupart du temps vous n'avez même pas besoin de quitter PM, vous pouvez exécuter des programmes DOS tout en restant dans PM.

Toutes ces améliorations signifiaient que le 386 PM était non seulement plus fonctionnel, mais aussi beaucoup plus compatible.

En d'autres termes, la seule chose en commun entre le mode protégé 286 et 386 est le nom. C'est pourquoi les systèmes d'exploitation PM sont généralement 386 ou plus récents. L'ajout de la prise en charge du 286 PM serait un effort entièrement indépendant, avec peu ou pas de code pouvant être partagé avec le 386 PM complètement différent.

En revanche, le 386 PM fonctionne à peu près de la même manière jusqu'au dernier des processeurs 32 bits, et même au-delà si vous exécutez un logiciel 32 bits sur des processeurs 64 bits.

Il y a des parties dans le noyau écrites en assembleur et elles devraient être réécrites pour supporter 286.

En ce qui concerne ELKS, dans leur FAQ, ils indiquent qu'il s'agit d'un sous-ensemble du noyau Linux, donc ils n'ont peut-être porté que les nécessités absolues.

Je pense que la vraie réponse à ma question est la suivante:

Chaque architecture CPU majeure (ou révision majeure de celle-ci) nécessite un code de support d'assemblage en plus du code C.

Même si GCC compilait le noyau Linux en code machine 16 bits 286, il manquerait toujours le code d'assemblage compatible 16 bits 286 essentiel.

En d'autres termes, le noyau ne serait au mieux que partiellement construit. Tout code d'assemblage spécifique à l'architecture ne pourrait pas être assemblé car il n'est tout simplement pas écrit pour cette architecture.

Sur cette base, je suppose que c'est exactement ce que font par exemple ELKS et des projets similaires lorsque Linux implémente le 286 ou d'autres architectures - ils implémentent ce code de support d'assemblage manquant.

Le 80386 prend en charge la pagination en plus de la segmentation de la mémoire tandis que le 286 prend uniquement en charge la segmentation de la mémoire. Linux dépend fortement de la prise en charge de la pagination, c'est-à-dire qu'il utilise un schéma de mémoire plate qui définit essentiellement tous les registres de segments à 0 et utilise la pagination pour gérer les applications. Afin de porter Linux sur le 286, le gestionnaire de mémoire fondamental a besoin d'une refonte complète pour fonctionner en mode segmenté sans pagination, ce qui représente probablement beaucoup de travail.

Linux nécessite-t-il une prise en charge matérielle de VM86?

Je ne suis pas un monteur, mais selon cela :

En tant qu'implémentation d'origine de l'extension 32 bits de l'architecture 8086, le jeu d'instructions 80386, le modèle de programmation et les encodages binaires sont toujours le dénominateur commun à tous les processeurs x86 32 bits, c'est ce que l'on appelle x86, IA-32 ou i386. -architecture, selon le contexte.

Le 386 représente un ensemble d'instructions étendu du 286, alors qui sait à quel point le port serait difficile. De toute évidence, presque personne n'a pris la peine de l'essayer ... Je suppose que vous pouvez interroger les ELKS à ce sujet.

La principale raison est que le projet GNU d'origine visait des machines 32 bits (comme les postes de travail Unix du milieu des années 80) plutôt que de prendre la peine de prendre en charge quelque chose de plus petit, de sorte que l'ensemble de la chaîne d'outils GNU n'était pas adapté à la génération de code 16 bits. Porter le premier noyau Linux, lourd en assemblage et utilisant des segments sur le 286 aurait été plus facile que n'importe quelle autre cible de portage - si GCC avait eu la capacité de produire du code en mode protégé 286. Mais viser GCC en mode protégé 286 aurait été un énorme projet pour prendre en charge un processeur obsolète.

Récemment, le noyau linux a abandonné le 386 en tant que plate-forme prise en charge et le noyau Linux ne prend pas en charge les processeurs Intel 286..80286 n'est pas un processeur 32 bits, qui est requis pour démarrer.

Linux x86 ne peut pas être facilement porté en arrière sur le 80286 car il s'agit d'un processeur 16 bits et Linux x86 nécessite un processeur 32 bits.

Plus précisément, les registres du 286 n'avaient encore qu'une largeur de 16 bits. Aucun des registres EX n'était disponible. De plus, les segments de mémoire et les décalages ne faisaient toujours que 16 bits. Les programmes devaient encore traiter le code et les données proches / lointains.

Cela signifie que Linux / 286 aurait besoin d'un noyau et d'une API utilisateur radicalement différents de Linux / 386. Chaque fichier source d'assembly et de nombreux fichiers source C devraient être réécrits. Ce serait comme la différence entre la programmation pour Win16 et Win32.

En bref, vous ne pouvez pas simplement dire à GCC de compiler pour un autre processeur. Chaque bit de code devrait être réécrit pour un environnement 16 bits.

D'après ce que j'ai lu, la manière canonique de faire fonctionner Linux sur le 80286 serait de l'exécuter à l'intérieur d'une machine virtuelle. C'est ce que Fabrice Bellard a fait ici . Vous devez implémenter la machine virtuelle vous-même ou en porter une.