Has anyone managed to get a minimal Linux install onto an ESP8266 board?
Starhawk wrote 03/19/2020 at 03:53 • -2 pointsNOT THE ESP32. I don't have those and I don't want them. Yet.
I *do* have a couple ESP-12E boards. I don't have much (okay, any) experience with them yet, but I cant imagine an 80MHz almost-ARM-ish microcontroller would let its butt be kicked by something on the order of a 1st-gen Pentium CPU -- and I have indeed run Linux on exactly that (it was an obscure low-power version of Puppy Linux, for the record... I have one picture, archived somewhere).
I'd like to see if it's doable... video would be uhm interesting, but a pair of PS/2 ports for mouse & keyboard shouldn't be too much overhead. If it could work, a video coproc consisting of an ATMega328 running the TVOut library, plus a serial-drive character ROM (SPI works for me) would probably suffice... I just want to drive an 800x480 screen... 40 rows of 100 characters each (100x40 character resolution) works if you use 8x12 px characters (8 pixels/px wide, 12 high), which is a standard character size but not a standard screen size.
All I really want is to be able to drive Links2 in a bash session, with the built-in WiFi, plus keyboard mouse and screen. The ability to use a USB keyboard/mouse combo would be nice but not strictly speaking required... I'd really like to use this in a wrist PC I'm planning, if that's possible, but that would indeed require USBHID input support for keyboard/mouse, because the one I'm planning to use there is a gutted Bluetooth mobile phone keyboard with a "nub" mouse bodged on (consisting of the four-button 'nub' joystick from a Toshiba T3400CT* and two tact-switch inputs for the left/right "click" buttons). The screen for that unit, for the record, would be a composite-in LCD intended for automotive backup camera applications from eBay. I can power it from a power bank for uhm a very long time, or a real laptop battery if someone can throw in an SMBus driver somewhere (that would be awesome!)... ;)
I'll politely note that I am by nature NOT a programmer -- my best effort to date is a four-room text adventure written in MS QuickBASIC, that I'm currently rewriting when I get in the mood, partly to exercise my Amstrad PPC640 (lol) that I got recently and partly because the original version was so awful as to essentially avoid the use of a text input parser (don't ask, you *really* don't want to know!). While I'm *technically* open to learning, my last two concentrated efforts at learning C++ ended spectacularly badly, so I hope you will forgive me for being rather hesitant!
That said, I'm more than happy to help test... ;)
* I feel the same way most folks here do about that stuff -- that's treading on hallowed ground because old PC / computer history, but I have THREE essentially complete but not-entirely-functional-at-best parts machines in a cardboard Banker's Box in addition to the one that works ;) so I think I can take the mouse 'nub' part out of one of the busted ones for this...!
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Yes, i know it's too late now....but for anyone interested: Take a look at Accelerated Linux for non-MMU devices. Might be able to get that to work....maybe.
Are you sure? yes | no
You aren't late, I'm just older :) alas, I have a hard enough time compiling drivers... I don't even want to THINK about the 'make' errors I'd get trying to compile an OS!
Great idea, tho! By way of explanation... I'm just one of those weird people who wants to see how much they can do with how little.
Are you sure? yes | no
Yes, i completely understand.....i am very much the same way, too. It's curiosity driven.
Are you sure? yes | no
I've just ported Fuzix to it, if you're interested. Still rather buggy, binaries are limited to 64kB data / 32kB code, and without an MMU you can only have one process in memory at a time, but it makes a perfectly serviceable Unix system. No networking, though (no space for the wifi stack). http://cowlark.com/2021-02-09-esp8266-fuzix
Are you sure? yes | no
I have a new reason for wanting linux on an ESP32 (not ESP8266): https://www.crowdsupply.com/e-radionica/inkplate-6 They already added the e-ink, uses the ESP-32 WROVER 8MB. The refresh rate isn't great, but isn't bad either. One could even use one of these displays, which has a programmable refresh https://www.j-display.com/product/reflective.html video: https://www.youtube.com/watch?v=S1MM8y0zOPw
Are you sure? yes | no
I know you want to use an 8266, but from my knowledge of these controllers, you would be FAR better off using an ESP32. In contrast to the ESP8266, this one has the possibility to map external SPI RAM into the CPUs address space. Without this, I think all attempt to run an actual Linux on one of those would be futile as you will be limited to the internal memory only. Adding external memory as you proposed would just be impossible, because without a proper MMU, you can't implement paging.
WITH the external memory interface of the ESP32 however, you could do exactly as you proposed and add an external controller as MMU. Also, you could run the kernel on the second CPU core so it can run natively and you don't have to somehow run the kernel as application.
I you decide to give it a go, please let us know. This would be a truly epic hack.
Are you sure? yes | no
In my experience as a programmer, the 8266 barely runs FreeRTOS well, and already with this slim of an OS it is hard to do anything hard without screwing up the wifi. It works fine as an application processor for a small application IF the application has no realtime needs at all, OR the app can turn off wifi while it does its main work.
If you're already adding coprocessors and things, you're better off just using the 8266 as a communication subsystem, and choosing a cheap ARM processor with an MMU.
If you want to get linux on the 8266 the end result will be gimmicky, not a real linux system.
Are you sure? yes | no
OK, thank you :)
Are you sure? yes | no
look for minix
Are you sure? yes | no
I think it would be a heroic hack but you could get glory if you succeed. But what are you really after? Something that works adequately? You'd do better crowdfunding a suitable SBC. Something Unix-like and feasible? FUZIX might fit the bill. Something to pass the time? Sure, and be sure to write it up, Good luck.
Are you sure? yes | no
I'm looking to show that it can be done. If I wanted a simple and expedient solution I'd stick with the Pi Zero as described below... which, honestly, is probably what will end up happening in the end, as I am many things, but programmer is very much not one of them!
Also, apologies for how long it took me to respond. Life is a thing that complicates other things sometimes.
Are you sure? yes | no
Go find your inner hero then.
Are you sure? yes | no
If you want to do something that's really heroic (and maybe even of some practical use) go revive uClinux. The amount of RAM might be a bit on the smallish side even for a flat no-MMU approach. Probably there won't be a way to run any kind of useful binary (besides maybe a trimmed down busybox) but at least the (complicated) uClinux dependencies would have been revisited ;-)
Otherwise I'd go for one of the tiny POSIX-like embedded OS (but wait, Mongoose-OS is already there....https://www.osrtos.com/rtos/mongoose-os/ )
Are you sure? yes | no
is Linux strictly required? Or just 'something unixian'? RetroBSD might be a closer match (it is derived from an ancient pre-mmu-era BSD), though to wit even it has a 128 KiB RAM minimum requirement, which exceeds the 80 KiB on the ESP8266 (not to mention it's non-uniform separation of duties of that RAM into executable/data-only). But it might be a starting point.
That being said, I suspect irrespective of the OS, that the attempt to run Links2 as the user-mode application will be an even bigger ram concern, but I admit I am not intimately familiar with it.
Even /that/ being said, if you /were/ to try to use a modded RetroBSD, and because your project seems to be application specific (i.e. 'run links 2 over a terminal session'), you might be able to realize some savings by ROM-ing all your executable code, and preserving the precious RAM for data only.
You had mentioned elsewhere video, and were open to using a separate chip for that. If you are able to relax that constraint there, then you might consider a beefier processor for your unixian stuff (and ps2, video, etc), and keep the ESP for your networky stuff. Just a thought. I myself have used a PIC32MX to synthesize VGA from SPI and do the PS2 stuff, though you surely can do similar with one of the ARMs out there (probably more cheaply, possibly with more RAM). And if you are doing video, don't forget about your RAM needs for the frame buffer.
Are you sure? yes | no
Sorry for the late reply... as my grandmother often said: "life is what happens when you're making other plans" ;)
Please do re-read my earlier hardware comment -- the ATMega was to be used as an external MMU with a 30pin SIMM, with a RasPi-style "BIOS substitute" (config.txt sort of thing, plus support files) taking care of making the kludge operational within the OS (which would of course need to support virtual memory or something very much like it -- although that was left to be inferred before). The video was to be handled by a dedicated VLSI (brand) chip with a 1meg onboard RAM getup of its own, which was in this case to be dedicated VRAM. The VLSI chip communicates over SPI. I've just learned of a successor chip, the VLSI VS23S040D, which has 4meg onboard RAM and would be a likely substitute for the previously-mentioned device.
Are you sure? yes | no
why not https://wiki.debian.org/TheHurd
Are you sure? yes | no
[this comment has been deleted]
Sorry, nope, I like challenges ;) besides. This can be done. Look at my last post, right below this one. It's doable, just tricky.
Are you sure? yes | no
@Kosma Thank you for your remarks -- you clearly have NO IDEA what I'm up to (understandable, I've not explained it properly). The contrast between the end-goal of the project and the last paragraph of your comment made me chuckle... which I desperately needed because I'm just as much artist as nerd, and I just accidentally poured Diet Sunkist orange soda all over a partially-completed personal work that was super important and incredibly difficult for me to work out for a number of reasons... and now it's completely ruined.
As for *this* thing -- the original plan was to put a Raspberry Pi Zero 1.3 in a weatherproof box with a HubWiPi Blue (3x USB2 + WiFi + BT daughterboard) and the necessary voltage regulation for it and the rest of the system, bolt on a dual USB port weatherproof extension and a Dell D630 knockoff battery (they're cheap) such that that part could hang off a belt clip or whatever, and run the remaining USB port + the "TV Out" (composite video) port from the Pi to a forearm-mounted module consisting of a 5" 800x480 LCD and a homemade keyboard/mouse module -- one of those 49-key Bluetooth smartphone keyboards (the kind without a mouse) with a custom controller (Teensy 2.0 + QMK Firmware) that splices in the 'nub' mouse from a Toshiba T3400CT (I have one working one and three parts machines -- this example comes from a parts sys) and a pair of 12mm tact buttons with caps for the left/right mouse buttons. The keyboard/mouse bit would fold over the LCD to protect it when the system was out of service or off or whatever.
So the idea was to shove an ESP8266 in there instead of the Pi Zero, hub, etc -- I don't necessarily need the extra USB ports, I definitely never need Bluetooth (I've used it like once ever, and that was with one of Mom's incredibly ancient Blackberries and a folding keyboard from when USBHID support on phones was kind of a new thing). I *certainly* don't need a full-on desktop Linux distro with all the bells and whistles and pops and feeps and whatnot -- just enough brainage to pull up a network connection and throw a browser session at it, drive the keyboard/mouse module, and monitor the battery.
Are you sure? yes | no
Just had a thought that might enable this to be done. This is a very low-level issue. You need a few things here... but this is ultimately a /very/ low-level issue.
First, the ESP8266 has no proper MMU. Fine, let's give it one. This will need a "software shim" to work -- i.e., a driver, through the OS, that makes an external MMU and RAM-config usable to the system. Dmitry Grinberg laid the foundations of this, indirectly, with his "Worst Linux Computer" -- we need an ATMega1284 programmed to operate as an MMU, and a 30pin SIMM.
Second, for video output we also need additional hardware, a chip of the sort that, in the old days, was called a "video display processor", or VDP. Famous examples of this include the TMS9918 and its successors for MSX-spec computers, and the VIC and VIC-II in the Commodore VIC-20 and the Commodore 64. These are notably different from the old "CRT Controllers" such as the Motorola MC6845 -- the 6845 was more of a reconfigurable sequencer sort of a thing. It never processed anything, and was only responsible for generating timing signals and stepping through VRAM addresses for additional external circuitry (which could be quite extensive indeed, as you'll know if you've ever seen a real IBM MDA card -- I have one :D) to interpret and deal with. But we need not be nearly so crude -- or so laborious. Go take a look at the VS23S010D-L ;) it's an SPI VDP with an integrated 1meg RAM setup inside, which is also accessible over SPI as well as internally to its VDP. This is easy. "Shim" it as the display controller, let it use its integrated memory as VRAM, and Bob's yer uncle ;)
Third, we need a replacement for the PC BIOS. Those "software shims" really has to be at the BIOS level. Also, the system needs to know how to interact with its hardware. This is NOT an IBM-compatible PC of *any* lineage. This is more like a 1st-gen Raspberry Pi that someone's gone and clobbered a few times with something large, blunt, and heavy -- it doesn't think very well any more. Funny mentioning Raspberry Pis, though ;) since their /boot/config.txt trick is almost exactly what we need here!
Fourth and last, we need a custom bootloader. The bootloader does what it needs to...
(1) Loads the basic functions for external MMU, display controller, USB host support for input devices, hubs, and mass storage devices (MAX3421E-based), and WiFi.
(2) A simple POST (Power On Self Test. I know, I know -- this is traditionally the FIRST step. But if you do it that way there's nothing to test, because the necessary support to access them has not been provided yet. Also: beep on errors.
(3) Init the hardware, bring up the input/output interfaces, and enable the external RAM.
(4) Put up a RAMDrive in the external RAM, then init the custom bootloader and start it going.
(5) Either chain-load eg GRUB2 or SYSLINUX from storage (the SD card) and then bootstrap the OS from there, or directly bootstrap the OS, establishing a RAMDrive for the kernel at the same time.
Are you sure? yes | no
Just quick googling and here is your start point: https://unix.stackexchange.com/questions/190350/mmu-less-kernel#190358
Are you sure? yes | no
If it has RAM it has an MMU of some sort, just not exposed to the outside world... otherwise, how would the CPU Core know how much RAM is there (etc)...? ;)
That just means it needs swapspace. Not a big deal to hang an SD card off that SPI interface...
Are you sure? yes | no
How much RAM did your Pentium machine have? And how much is inside that tiny chip?
Are you sure? yes | no
IIRC I maxed that Pentium board out at like 24 megs. I don't remember for sure, it was literally years ago. But it wasn't running anything like this -- that was a full-on graphical shell. IIRC it was a clumsy backport of JWM to GTK1 stuff, along with the same treatment for the rest of the apps -- emelFM file manager, Dillo browser, etc. The point being that this was a waaaaay heavier load than I'm picturing here, which would be (again) Links2 in a console session.
OK, so we've only got 80kB to work with for userdata and 32-64kB for instructions, depending on how you count it. Fine. I'll pull the SPI ROM off and stick on an SD card. Boom! Swap memory. Yes, it's slow. But it's not going to be nearly as slow as eg a mechanical hard drive with that Pentium box (which, BTW, didn't have swapspace set up, but if it'd had that... ow).
Dude, I know you're trying to scare me off and all, but... one, look up XWOAF aka X Windows On A Floppy. I have a copy (it doesn't boot, it's corrupted :( or claims it is, anyhow -- but it's there...) and it's supposed to be able to boot on a friggin 486 with no coproc (it has emulation support in the kernel) with... I don't remember, 16mb RAM? Basically barely anything, is the point. Two, I have a Compaq Portable III that I'm restoring. When I'm done it's getting DOS 3.3, a DOS-compat Links2 port, and an ESP8266 wired up as a WiFi COMport modem. Yes, I know I'll probably need a DOS Extender to get Links2 up and running -- trust me when I tell you I've got that covered. If I can't get the internal 16450 serial UART chip to do 115200 baud to the modem reliably, I'll piggyback a spare 16550 I have onto it. Now go look up the specs of that system, and come back here and tell me how come I can do what I'm talking about on *it* but not on an ESP8266 that's obviously considerably more powerful.
Are you sure? yes | no
Not trying to scare you off. Only helping you save a little time to reach the inevitable conclusion about Linux memory usage.
Then again, who knows, maybe you'll find a way to make it work? If you do, I'm sure you'll be a hero to many. Hackaday will very likely cover it with a longer format article too, since getting Linux running on this hardware is something widely considered to be impossible due to the limited RAM.
And fwiw, I ran Linux as my primary desktop system back in 1994 on a low-end 486 machine lacking the FPU. Those were the days when most low-end PCs came with 2 megs, because that's what was needed to run Windows 3.1 pretty well. Linux needed 4 megs to run without extreme trickery, but it took at least 8 megs to have a usable system back in those early days. Memory use has grown tremendously since then.
Good luck and don't give up just because I pointed this out. Go forth and surprise me and the rest of the world!
Are you sure? yes | no
@Paul Stoffregen -- you didn't even *address* the swapspace idea. I have to say I'm disappointed here.
Are you sure? yes | no
Last reply here - specifically on your swap space idea... *you* should go look at the Linux source code and try to get an idea of how much fixed allocation RAM just the memory management and block devices need merely to implement memory swapping (not to mention how well it can be done without a MMU).
This is your project, not mine. I applaud your enthusiasm. But when it comes to figuring out the feasibility of your ideas, you are the one who needs to dive into the Linux source code and discover these realities of memory usage.
I sincerely hope (regardless of how incredibly unlikely it is) you find a way to make this work. Even if utterly impractical, I and pretty much everyone will be very impressed if you can pull it off. Now go forth and explore. Do not let my lack of responsiveness to any idea or question be the reason you didn't accomplish this project!
Are you sure? yes | no
[this comment has been deleted]
Right, but... then how is the external ROM handled? Especially since IIRC the ESP8266 boards cannot boot without it.
I'm not arguing, I promise -- I just want to understand.
Are you sure? yes | no
I know what it is, @Kosma... I dabble in 80s homebrews. That doesn't answer my question at all.
Are you sure? yes | no