Linux auf einem 286?

Ich besitze keinen 286 und habe auch nicht vor, Linux auf einem zu betreiben. Da der 286 jedoch über einen geschützten Modus verfügt, wird häufig angegeben, dass Linux eine 386-CPU oder höher benötigt.

Von http://tuxmobil.org/286_mobile.html scheint es, dass die ELKS-Version von Linux auf einem 286 laufen kann, ist das richtig? Welche (eventuellen) Änderungen wurden vorgenommen, damit der Kernel auf der 286-CPU ausgeführt werden kann?

Jetzt verstehe ich natürlich, dass ein Kernel, der für einen 386 kompiliert wurde, nicht auf einer 286-CPU ausgeführt werden kann, die 16-Bit ist. Meine Frage ist also, warum kann der Standard-Linux-Kernel nicht für einen 286 kompiliert und dann auf einem 286 ausgeführt werden? Benötigt Linux Hardware-VM86-Unterstützung?

Der 286 Protected Mode (PM) unterscheidet sich grundlegend von dem, was der 386 bietet. Stellen Sie sich den 286 PM als einen Prototyp vor, der so viele Mängel aufwies, dass fast niemand ihn jemals benutzte, und das Ganze wurde für den 386 von Grund auf neu gestaltet.

Es wurde kein flaches Speichermodell verwendet, sondern ein segmentiertes Modell wie der Real-Modus, was bedeutete, dass Sie durch Rahmen springen mussten, um auf Speicher in Blöcken zuzugreifen, die größer als 64 KB sind.

Es war vollständig inkompatibel mit allen zu diesem Zeitpunkt verfügbaren (MS-DOS-) Programmen. Wenn Sie sich also in PM befanden, konnten Sie keines der Programme verwenden, an die Sie gewöhnt waren.

Sie konnten den geschützten Modus auch erst wieder verlassen, wenn Sie den PC neu gestartet haben. Die Hersteller entwickelten kreative Lösungen wie das Setzen eines Flags im RAM und das Schreiben eines magischen Werts auf den Tastaturcontroller, der den Reset-Pin auf der CPU zum Neustart des Computers auslöst Maschine. Das erste, was das BIOS tun würde, ist, das zuvor gesetzte Flag zu erkennen, wobei es dann zum ursprünglichen Programm zurückspringt, anstatt die POST-Routine auszuführen, so dass das ursprüngliche Programm weiter ausgeführt werden kann, nachdem PM "beendet" wurde.

Dies bedeutete, dass Sie mit dem 286 PM keine normalen DOS-Programme ohne eine große Anzahl von Tricks ausführen konnten. In einer Zeit, in der es nur DOS-Programme gab, hat sich die Verwendung von PM überhaupt nicht gelohnt.

Die Arbeit mit dem 286 PM war also komplizierter als nur das Leben ohne ihn, und der Zugriff auf den zusätzlichen Speicher erfolgte mithilfe von EMS und XMS. Eine Reihe von 286 Motherboards unterstützten den EMS-Chipsatz, sodass Sie den gesamten zusätzlichen Systemspeicher nutzen konnten, ohne PM zu benötigen.

Intel hat diese Mängel erkannt und im 386 eine brandneue, völlig andere PM produziert. Das flache Speichermodell vereinfacht den Zugriff auf Speicher in einem Block von bis zu 4 GB. Die CPU kann mit ein paar Anweisungen in PM ein- und aussteigen, sodass keine umständlichen Neustart-Protokolle erforderlich sind. VM86 bedeutet, dass Sie die meiste Zeit, in der Sie PM nicht beenden müssen, DOS-Programme ausführen können, während Sie sich noch in PM befinden.

All diese Verbesserungen führten dazu, dass der 386 PM nicht nur funktionaler, sondern auch wesentlich kompatibler war.

Mit anderen Worten, das einzige gemeinsame Merkmal zwischen dem geschützten Modus 286 und 386 ist der Name. Aus diesem Grund sind PM-Betriebssysteme in der Regel 386 oder neuer. Das Hinzufügen von Unterstützung für die 286 PM wäre ein völlig unabhängiger Vorgang, bei dem nur wenig oder kein Code für die völlig anderen 386 PM freigegeben werden kann.

Im Gegensatz dazu funktioniert der 386 PM bis zur letzten 32-Bit-CPU auf die gleiche Weise, und sogar darüber hinaus, wenn Sie 32-Bit-Software auf 64-Bit-CPUs ausführen.

Es gibt Teile im Kernel, die in Assembly geschrieben wurden, und sie müssten neu geschrieben werden, um 286 zu unterstützen.

In Bezug auf ELKS geben sie in ihren FAQ an, dass es sich um eine Teilmenge des Linux-Kernels handelt, sodass sie möglicherweise nur das Notwendigste portiert haben.

Ich denke, die eigentliche Antwort auf meine Frage lautet:

Jede Haupt-CPU-Architektur (oder Hauptrevision davon) erfordert zusätzlich zum C-Code einen Assembler-Support-Code.

Selbst wenn Sie GCC zum Kompilieren des Linux-Kernels in 16-Bit-286-Maschinencode veranlassen würden, würde der wesentliche 16-Bit-286-kompatible Assembler-Code fehlen.

Mit anderen Worten, der Kernel würde bestenfalls nur teilweise erstellt. Ein architekturspezifischer Assemblycode kann nicht zusammengestellt werden, da er für diese Architektur einfach nicht geschrieben wurde.

Auf dieser Basis gehe ich davon aus, dass genau dies z. B. ELKS und ähnliche Projekte tun, wenn sie Linux auf dem 286 oder anderen Architekturen implementieren - sie implementieren den fehlenden Assembler-Support-Code.

Der 80386 unterstützt Paging zusätzlich zur Speichersegmentierung, während der 286 nur die Speichersegmentierung unterstützt. Linux ist stark von der Unterstützung von Paging abhängig, dh es verwendet ein flaches Speicherschema, das im Grunde alle Segmentregister auf 0 setzt und Paging zum Verwalten von Anwendungen verwendet. Um Linux auf den 286 zu portieren, muss der grundlegende Speichermanager komplett überarbeitet werden, um im segmentierten Modus ohne Paging arbeiten zu können, was wahrscheinlich viel Arbeit bedeutet.

Benötigt Linux Hardware-VM86-Unterstützung?

Ich bin nicht Montage Typ, aber nach dieser :

Da bei der ursprünglichen Implementierung der 32-Bit-Erweiterung der 8086-Architektur der 80386-Befehlssatz, das Programmiermodell und die Binärcodierungen immer noch der gemeinsame Nenner für alle 32-Bit-x86-Prozessoren sind, wird dies als x86, IA-32 oder i386 bezeichnet -Architektur, je nach Kontext.

Der 386 stellt einen erweiterten Befehlssatz des 286 dar, also wer weiß, wie schwer der Port sein würde. Offensichtlich genug, dass sich fast niemand die Mühe gemacht hat, es zu versuchen ... Ich denke, Sie können die ELKS-Leute danach fragen.

Der Hauptgrund dafür ist, dass sich das ursprüngliche GNU-Projekt auf 32-Bit-Maschinen (wie Unix-Workstatons Mitte der 1980er Jahre) konzentrierte und sich nicht darum kümmerte, etwas Kleineres zu unterstützen. Daher war die gesamte GNU-Toolchain für die 16-Bit-Codegenerierung ungeeignet. Das Portieren des frühen, assemblierungsintensiven, segmentverwendenden Linux-Kernels auf den 286 wäre einfacher gewesen als jedes andere Portierungsziel - wenn GCC die Fähigkeit gehabt hätte, 286-Code im geschützten Modus zu erzeugen. Es wäre jedoch ein großes Projekt gewesen, GCC auf den geschützten Modus 286 auszurichten, um einen veralteten Prozessor zu unterstützen.

Vor kurzem hat der Linux-Kernel den 386 als unterstützte Plattform aufgegeben und der Linux-Kernel unterstützt KEINE Intel 286-Prozessoren. 80286 ist keine 32-Bit-CPU, die zum Booten erforderlich ist.

Linux x86 kann nicht einfach auf den 80286 zurückportiert werden, da es sich um einen 16-Bit-Prozessor handelt und Linux x86 einen 32-Bit-Prozessor erfordert.

Insbesondere waren die Register auf dem 286 immer noch nur 16 Bit breit. Keines der EX-Register war verfügbar. Außerdem waren Speichersegmente und Offsets immer noch nur 16 Bit lang. Programme mussten sich noch mit Near / Far-Code und Daten auseinandersetzen.

Dies bedeutet, dass Linux / 286 eine völlig andere Kernel- und Benutzer-API als Linux / 386 benötigt. Jede Assembly-Quelldatei und viele C-Quelldateien müssten neu geschrieben werden. Es wäre wie der Unterschied zwischen der Programmierung für Win16 und Win32.

Kurz gesagt, Sie können GCC nicht einfach anweisen, für eine andere CPU zu kompilieren. Für eine 16-Bit-Umgebung müsste jedes Codebit neu geschrieben werden.

Nach dem, was ich gelesen habe, besteht die kanonische Möglichkeit, Linux auf dem 80286 zum Laufen zu bringen, darin, es in einer virtuellen Maschine auszuführen. Das hat Fabrice Bellard hier getan . Sie müssten die virtuelle Maschine selbst implementieren oder eine portieren.