15

I don't own a 286 nor do I intend to run Linux on one. However since the 286 has protected mode, why is it frequently stated that Linux requires a 386 CPU or higher?

From http://tuxmobil.org/286_mobile.html it seems that the ELKS version of Linux can run on a 286, is this correct? What (if any) modifications have been made to allow the kernel to run on the 286 CPU?

Now obviously I understand that a kernel compiled for a 386 cannot execute on a 286 CPU, which is 16-bit. So my question is, why cannot the standard Linux kernel be compiled for a 286, and then executed on a 286? Does Linux require hardware VM86 support?

  • 6
    16-bit is overkill. 8-bit are enough to run Linux. See the project of Dmitry Grinberg. – Marco Jan 14 '13 at 14:21
  • 3
    See stackoverflow.com/questions/5045819/… – ott-- Jan 14 '13 at 15:22
  • Minix ran on 8086 (8 bit, 128KiB RAM IIRC). Microsoft's Xenix did run on 80286. Some demented soul tried to shoehorn Linux into 8086 too (with some success). But no, the "full Linux experience" won't be possible on such a limited machine. – vonbrand Jan 15 '13 at 14:42
  • You can shoehorn Linux to run on very limited devices. But this is not going to be very useful as an e.g. desktop machine. Unless you state your goals it's hard to tell if 'Linux on 286' is viable for you. – 9000 Oct 28 '14 at 13:42
4

286 protected mode (PM) is fundamentally different to what the 386 offers. Think of the 286 PM as a prototype, which had so many shortcomings that almost nobody ever used it, and the whole thing was completely redesigned from the ground up for the 386.

It did not use a flat memory model, it used a segmented model like real mode, which meant you had to jump through hoops to access memory in blocks larger than 64kB at a time.

It was completely incompatible with all the (MS-DOS) programs available at the time, so once you were in PM you couldn't use any of the programs you were used to.

You also could not leave protected mode again unless you rebooted the PC, so manufacturers came up with creative solutions like putting a flag in RAM, then writing a magic value to the keyboard controller, which would flick the reset pin on the CPU to reboot the machine. The first thing the BIOS would do is detect the flag set earlier, where it would then jump back to the original program instead of running the POST routine, allowing the original program to continue running having "exited" PM.

This meant that using the 286 PM prevented you from running normal DOS programs without a large number of tricks. At a time when there only were DOS programs, it was not worth the effort of using PM at all.

So it ended up being more complicated to work with the 286 PM than just living without it, and relying on EMS and XMS to access the extra memory. A number of 286 motherboards had chipset support for EMS so that you could use all the extra system memory without the need for PM.

Intel recognised these shortcomings and produced a brand new completely different PM in the 386. The flat memory model makes accessing memory in a chunk of up to 4GB simple. The CPU can go in and out of PM with a couple of instructions so no clumsy reboot protocols are needed. VM86 means that most of the time you don't even need to exit PM, you can run DOS programs while still in PM.

All these improvements meant that the 386 PM was not only more functional, but significantly more compatible as well.

In other words, the only thing in common between the 286 and 386 protected mode is the name. This is why PM operating systems are typically 386 or newer. Adding support for the 286 PM would be an entirely independent effort, with little or no code able to be shared with the completely different 386 PM.

By contrast, the 386 PM works in much the same way right up until the last of the 32-bit CPUs, and even beyond if you run 32-bit software on 64-bit CPUs.

3

There are parts in the kernel written in assembly and they would have to be rewritten to support 286.

Regarding ELKS, in their FAQ they indicate it's a subset of the Linux kernel, so perhaps they ported only the absolute necessities.

  • 1
    There was a math coprocessor for the 286, the 80287. – Renan Jan 14 '13 at 16:05
3

I think the real answer to my question is this:

Every major CPU architecture (or major revision thereof) requires some assembly support code in addition to the C code.

Even if you got GCC to compile the Linux kernel into 16-bit 286 machine code, there would still be missing the essential 16-bit 286 compatible assembly code.

In other words, the kernel would at best only partially be built. Any architecture specific assembly code would fail to assemble as it is simply not written for that architecture.

Based on this I'm assuming that this is exactly what e.g. ELKS and similar projects do when the implement Linux on the 286 or other architectures -- they implement that missing assembly support code.

3

The 80386 supports paging in addition to memory segmentation while the 286 supports only memory segmentation. Linux heavily depends on paging support i.e., uses a flat memory scheme which basically sets all the segment registers to 0 and uses paging to manage applications. In order to port Linux to the 286, the fundamental memory manager needs a complete redesign to work in segmented mode without paging which is probably a lot of work.

2

Does Linux require hardware VM86 support?

I'm not an assembly guy, but according to this:

As the original implementation of the 32-bit extension of the 8086 architecture, the 80386 instruction set, programming model, and binary encodings are still the common denominator for all 32-bit x86 processors, this is termed x86, IA-32, or i386-architecture, depending on context.

The 386 represents an expanded instruction set from the 286, so who know how hard the port would be. Evidently enough that almost no one has bothered to try it...I guess you can ask the ELKS people about that.

2

The biggest reason is that the original GNU project aimed itself at 32-bit machines (like mid-1980s Unix workstatons) rather than bothering to support anything smaller, so the whole GNU toolchain was unsuitable for 16-bit code generation. Porting the early, assembly-heavy, segments-using Linux kernel to the 286 would have been easier than any other porting target -- if GCC had had the ability to produce 286 protected-mode code. But aiming GCC at 286 protected mode would have been a huge project to support an obsolete processor.

1

Recently the linux kernel has abandoned the 386 as a supported platform and Linux kernel does NOT support Intel 286 processors..80286 is not a 32bit cpu, which is required to boot.

  • 5
    Linux was originally written on a 386 in 1991. By then 286's were already old, and the main kernel tree never had any backported code to support 286. – Flukas88 Jan 14 '13 at 14:04
  • That may be, but the question was still why is this the case? Not why the decision was made to drop support for 286/386 (which is obvious) but what are the technical reasons that supporting such an old processor cannot easily be done. I.e. why does the kernel REQUIRE a 32-bit CPU? Why cannot the kernel be compiled for a 286? – ioctlvoid Jan 14 '13 at 14:09
  • Didn't the kernel also have the arithmetic co-processor as it's requirements? – Bonsi Scott Jan 14 '13 at 15:52
  • No, the kernel supports math emulation, at least it did that before. Hence you could even run the Linux kernel on a CPU with a broken FPU. However, the 286 still supported a math co-processor, the 80287. – ioctlvoid Jan 24 '13 at 16:30
  • In an edited out part of my answer I did indicate that emulation is implemented in the Linux kernel. It was even used to port Linux to S/390 (a.k.a IBM Mainframe) as it did not have a floating point unit at the time it was ported. – Didi Kohen Jun 26 '14 at 16:35
1

Linux x86 cannot be easily back-ported to the 80286 because it is a 16-bit processor and Linux x86 requires a 32-bit processor.

More specifically, the registers on the 286 were still only 16-bits wide. None of the EX registers were available. Also, memory segments and offsets were still only 16-bits long. Programs still had to deal with near/far code and data.

This means that Linux/286 would need a radically different kernel and user API than Linux/386. Every assembly source file and many C source files would need to be rewritten. It would be like the difference between programming for Win16 versus Win32.

In short, you can't just tell GCC to compile for a different CPU. Every bit of code would need to be rewritten for a 16-bit environment.

  • 1
    Please consider the use of markdown for increased legibility. – lord.garbage Oct 16 '14 at 8:29
0

From what I've read the canonical way to get Linux to run on the 80286 would be to run it inside a virtual machine. This is what Fabrice Bellard did here. You'd have to implement the virtual machine yourself, or port one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.