(Before anyone jumps in with "why don't you use a desktop machine, it'll be faster", this is for fun, not a practical project.)
Though yeah, I doubt it would be very fast regardless, but it's something.
edit: I assume you're aware of the OTG port.
[1]: https://linux-sunxi.org/F1C100s (datasheet)
You won’t be able to bitbang at those speeds, so you’ll definitely have to drop down a layer in your stack/abstractions but since you mentioned I2C I figured you’d probably be OK considering this.
[0]: https://www.winbond.com/resource-files/W25Q128JW_DTR%20RevD%...
I have one I used to build a security cam system. Pretty neat little board.
It's about twice the price though, at least from the brief look[2] I had.
It's hard to imagine this could have been competitive with a $25 million pile of beige PC boxes from the same era, but the PCs would have been starved of I/O (10 Mbps shared thick ethernet anyone?) so only applications which don't need much I/O between the nodes would be possible.
A "modern" CM-5 would ironically look much more like the pile of beige PCs, because it will have much less I/O -- these cheap chips only seem to have at most one or two fast channels (eg. ethernet and SDIO). There's no way to build these into a hypercube. It will be constantly limited by bandwidth and contention addressing other nodes in the cluster.
So I'd only build it for fun, not for practicality :-)
The reason is that with 7 nodes I find I'm still logging into each Raspberry Pi and configuring it by hand. It's a bad habit for sure. With 100 nodes, there's no way I could possibly do that, forcing me to write software to control the nodes automatically.
Mine is more about using FPGAs for the communication fabric and RISC-V for processing, but similar.
I spent $250 of my hard-earned money to buy an 8MB upgrade, and ultimately upgraded that machine to 32MB, at which point it "flew"- no paging during development.
Imagine denouncing Emacs for its runtime size today, relative to the bloat that is VS Code or IntelliJ :)
Even today editor bloat is real. On my netbook VSCode is noticeably laggy sometimes, and it wouldn't take too much more to start paging out the editor! It amazes me that we still can't do instantly responsive editors. Even my dinky notebook still has a gigabyte of RAM and can do a billion integer operations a second. But VSCode can't show text instantly. I guess I'll stick with vi!
For most work programming I still use emacs 20+ years later but that's because of muscle memory. For hobby projects I use VS Code. It runs just fine on my 32-core, 64GB RAM desktop :)
E.g., this hardware has 16MB of RAM and 4MB of flash: https://github.com/freebsd/freebsd-wifi-build/blob/master/bu...
32MB RAM: https://github.com/freebsd/freebsd-wifi-build/blob/master/bu...
But what can it run on top of it? Dotnet? Python? Go?
AFAIK even the latter has a non- negligible runtime overhead.
In general I wonder if it's actually practically usable for common tasks one could imagine.
One advantage over micro-controllers is clear, though: Dynamic loading/execution of binaries, which no microcontroller OS seems to care about (why?).
Python is not as "bad" as dotnet and go I'd think, as most of python is reference counted garbage collection (with a "full" GC just to break up cycles) while go and dotnet use essentially mark-and-sweep GC strategies which require a lot of object moving and thus scratch space.
Running a dotnet hello-world (on x86_64 linux admittedly) gives an RSS of 26MB, most of it mapped libraries and .net assemblies, some libraries shared between processes of course, like libc/libm/ld.so. But it also maps a ton memory for the JIT and the GC (including scratch space to move objects into during gc). With some swap, it may survive on a system with 25MB of free memory, but I'd think there'd be plenty of swap-thrashing and gc thrashing going on, making that less fun.
Running a python3's hello world comes in at 10MB RSS, but a large part of that is the shared libraries like libc/libm/ld.so. With some memory-conserving programming some real python programs may run just fine without excess swapping.
For comparison, a hello world in C maps about 1M RSS, while a rust one maps 2MB RSS, both times a big chunk in shared libraries specially libc.
Nim uses GC by default and uses 512KB of RSS without any tuning.
(With ARC/ORC and without libc it can run on microcontrollers with 1KB of RAM)
For simple command line things like poking around the file system over telnet, it feels pretty much like a contemporary system. It can even run the Python REPL fine, though it takes a good number of seconds to start up. Apache is no problem and it can host a website, though I imagine it would crumple with more than a dozen requests a minute or so. Actually, the only real annoyance for that kind of work is that the machine's too slow to authenticate SSL keys in a reasonable time, so logging in takes forever and you can't host an HTTPS site.
Given this ARM machine is probably ~100x faster, if you're willing to add some swap for flexibility, I imagine it'd be usable for a wide variety of low-memory tasks.
Isn't Dillo (compiled from Mercurial) with mbedtls fast enough? Also, Gopher servers like sdf.org, magical.fish or i-logout.cz would shine on that machine. Fire up lynx and go. Or better, compile sacc with tcc, it will run megafast.
The card is (unsurprisingly) an ISA slot, an Intel EtherExpress 16. I forget exactly where I was with it when last I poked at this earlier this year, but the promising thing is I have it worked in MS-DOS 6.22 without issue. There are some utilities from Intel that I found that write EEPROM on the card to setup its IRQ and all of that, which is how I got it working in DOS.
Perhaps I’ll take another swing at it and document more precisely what the issues are and what I’ve tried so far. I wrote up the acquisition, repair, and resuscitation of the machine on a series of posts on my blog under “Project 386” beginning with https://justinmiller.io/posts/2020/04/26/project-386-part-1/ so I have intentions of adding some more posts.
The resolution is that BasicLinux is pretty old itself:
> BL3 is a mini-Linux designed specifically for old PCs. It provides a slim 2.2.26 kernel
I used to run a mailserver off one and a media box off another.
My nostalgia for it is tempered by knowing that a Raspberry Pi 4B is better in basically every single way and ridiculously cheaper.
I’m not sure if it’s a bug or something I was doing wrong but I gave up and just finished the install on the device.
Getting a buildroot based system to work was fairly easy starting with "make tinyconfig" for the kernel. IDE was a real hangup because there really isn't an IDE controller, it's a legacy IDE interface with no DMA. Disk IO is abysmally slow. Found that libata has experimental support for legacy IDE, rather than use the old IDE drivers. So I've managed to not select any deprecated kernel options.
Booting a current Gentoo stage3 with networking was a major challenge though. Still haven't managed to get IPv6 and all of the standard netfilter modules before the kernel hangs mysteriously between finishing self extract and producing any logs.
I also haven't managed to get ZONE_DMA support working for legacy DMA on ISA (for the PC/104 bus) without it using too much of the remaining DMA'able memory to load the Intel 82559 ethernet driver (e100.ko).
It's rather hilarious seeing a 5.10 Linux kernel complaining that it can't find a 256 KiB contiguous region of physical ram.
Buildroot boots in a matter of seconds on it, Gentoo takes a few minutes.
Bochs has that among i440FX :)
Still, I can't emulate some spin-o-rama (Google Street View like) games fast enough under w95 on my AMD Turion...
https://jaycarlson.net/embedded-linux/
It's been discussed here before, but it's an impressive reminder of what an individual can accomplish with modern small-batch PCB manufacturing.
It also goes a long way to make large-pitch BGA devices and high-speed signal design seem less intimidating to newcomers. Definitely worth a read if you're interested in these kinds of devices.
Also, the Lichee Nano is one of the only freely-available English-language reference designs for the Allwinner FIC100s processor, which is nice.
Progress.
It's quite possible that it did use more than 17 MB temporarily before going back down, but I would expect that it's probably doable in 32 MB + swap.
Configuring a minimal Linux system with Gentoo or Linux From Scratch is a great way to learn how things work (especially learning from mistakes like disabling ATA/IDE in the kernel and having to figure out why it no longer boots :p).
