Linux on a 286?

Question

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?

Solution 1

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.

Solution 2

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.

Solution 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.

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[Admin]

16-bit is overkill. 8-bit are enough to run Linux. See the project of Dmitry Grinberg.

[Admin]

See stackoverflow.com/questions/5045819/…

[Admin]

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.

[Admin]

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.

[Flukas88]

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.

[Deka]

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?

[Bonsi Scott]

Didn't the kernel also have the arithmetic co-processor as it's requirements?

[Renan]

There was a math coprocessor for the 286, the 80287.

[Deka]

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.

[Razzlero]

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.

[lord.garbage]

Please consider the use of markdown for increased legibility.

[enigment]

@ioctlvoid Kernel FPU emulation for the 386 makes sense it didn't have an on-die FPU, it supported both the 80[23]87 because the 80387 wasn't available when the 386 was launched. Not that most kernels (Linux and non-Linux) tend regularly go around utilizing FPU code much apart from driver things like graphics (software rendering), gps and so on.

[Digital Trauma]

And even the 486sx did not have an FPU