Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ELKS: Linux for 16-bit Intel Processors

github.com

Post reply on HN
Print view View original

41–50 of 119 posts

Re: ELKS: Linux for 16-bit Intel Processors

#41

Post by Dwedit »

andix wrote: post #35
Dwedit wrote: post #9

Earlier quoted context omitted.

Some of the Tandy 1000 computers (such as the HX) had MS-DOS 2.11 in ROM. So it's not unheard of for an IBM-Compatible PC to have an operating system in ROM. Also the "Macintosh Classic" had System 6.0.3 in ROM as well, but you had to use a keyboard shortcut to boot from there. It did not run normally.

Are those real ROM-based-systems, that could execute code directly from ROM, without loading it to RAM first? The only ROM-based-systems I worked with are the Atmel AVR microcontrollers. They don't need to load code into RAM for execution, they have the ROM memory mapped into the address space. I think they can't even run instructions from RAM, which makes remote code execution physically impossible.

Even if you can't execute code from RAM, stack corruption and Return-Oriented-Programming (ROP) can still be a thing. It's just far more limited if you can't use ROP to set up regular code.

Re: ELKS: Linux for 16-bit Intel Processors

#42

Post by happycube »

LeFantome wrote: post #39

We are removing 32 bit support from the Linux kernel because nobody uses that hardware anymore. Yet, this 16 bit version has commits from today.

It's a hobby, not big and professional like GNU^H^H^HLinux.

Seriously, I haven't worked on this in a long time (I'm Chad) and I'm very impressed by the changelog! Wouldn't have ever thought it'd run DOOM. ;) (and the use of OS/2 for medium model is clever too)

Re: ELKS: Linux for 16-bit Intel Processors

#43

Post by happycube »

IgorPartola wrote: post #17

I do wonder in today’s landscape of single board computers what the right bit width is. A 64-bit system with like 1-2GB or RAM doesn’t make a ton of sense since your program size and data structure size grows by quite a bit but you don’t need it to since you don’t get to have more than 4GB of RAM. On the other hand there you do have SBCs with 8-16GBs of RAM but that’s a far cry from needing full 64 bits. Would an opt…

For embedded uses, 1GB is certainly big enough to not need to be 32-bit, so it makes sense IMO to use the same 64-bit binaries/toolchains/BSPs as larger platforms, especially since they're better supported by upstreams now.

Re: ELKS: Linux for 16-bit Intel Processors

#44

Post by snvzz »

Tangentially related, DOS is a popular choice in this category of hardware.

Freedos has released 1.4rc1 recently, thus 1.4 is close.

Svardos switched to EDR-DOS kernel, which is derived from DR-DOS. That's a very nice kernel, written in assembly. Notably, Windows 3.1 works with it, including protected mode.

Re: ELKS: Linux for 16-bit Intel Processors

#46

Post by usr1106 »

tengwar2 wrote: post #29
fidotron wrote: post #15

Earlier quoted context omitted.

Less obvious than some of the embedded things: https://en.m.wikipedia.org/wiki/Atari_Portfolio x86 (and licensed derivatives) were a thing in more custom handhelds like the Psion Series 3, and games systems like the Wonderswan. The variants made by NEC alone were: https://en.m.wikipedia.org/wiki/NEC_V20#Variants_and_success...

The Psions could do execute-in-place, including for third party software on ROM SSD - i.e. they did not have any fundamental distinction between working memory and disk storage.

Yes, NOR flash was common in these kind of devices and phones until maybe 2005 or so. So you could run code without loading it to RAM first. However, I believe RAM was still needed for stacks and heaps. Writing them to NOR flash sounds too slow.

Re: ELKS: Linux for 16-bit Intel Processors

#47

Post by ghaerr »

Thanks for the comments! ELKS will run on an 8088, but also runs on any x86 PC using the legacy "real mode" which runs in 16-bit segmented architecture without an MMU or any hardware protection. It can be fun to boot a PC and see a close resemblance to Linux, but run the way things used to be, using only 16-bits.

It'll also run in ROM, e.g. using a 8018x CPU w/onboard PIT and PIC.

The point of ELKS today is about "small is beautiful" and seeing what can be done when limited to 64k code and 64k data, and 640k RAM. It's based on a very old fork of Linux and many of the internal structures are similar to what was found in Linux 2.0, without the changes for SMP support.

We just recently got a native C compiler/assembler/linker toolchain up and running. I must say making that happen provided some vivid comparisons of what programmers had to go through in decades past in both slower speeds and small executable file sizes, versus what we all have and expect today at our fingertips.

Re: ELKS: Linux for 16-bit Intel Processors

#48

Post by helf »

ghaerr wrote: post #47

Thanks for the comments! ELKS will run on an 8088, but also runs on any x86 PC using the legacy "real mode" which runs in 16-bit segmented architecture without an MMU or any hardware protection. It can be fun to boot a PC and see a close resemblance to Linux, but run the way things used to be, using only 16-bits. It'll also run in ROM, e.g. using a 8018x CPU w/onboard PIT and PIC. The point of ELKS today is about "sm…

[dead]

Re: ELKS: Linux for 16-bit Intel Processors

#50

Post by philistine »

LeFantome wrote: post #39

We are removing 32 bit support from the Linux kernel because nobody uses that hardware anymore. Yet, this 16 bit version has commits from today.

There is a temporal element to your statement. 32-bit support is being removed from the kernel of today. No one uses that hardware for a modern OS anymore.

But a small band of hobbyists use old OSes with old machines.

Post reply on HN