
RetroBSD: Unix for microcontrollers - fanf2
http://retrobsd.org/
======
unwind
Pretty cool.

Made me wonder if it would make sense on these SoC targets to dynamically load
a program from external storage and write into internal flash for execution,
then start running it without a reboot.

Since such flashes are typically only erasable in pretty big blocks
("sectors") it would require some interesting design choices, but it should be
doable. :)

~~~
okl
There are several runtimes for microcontrollers that feature an elf/hex loader
for static binaries, or a bootloader that retrieves a program and executes it
in RAM. Sometimes you can re-enter the bootloader from your application
software. On some embedded systems (satellite OBSW comes to mind) you can
actually hot-patch the code function-by-function while running. You
compile/link the software with some extra space before and after your
functions for future modifications. Then when you patch, you have to make sure
that the modified code is locked out and that the variables used by the
functions being patched are in an acceptable state as well as the cache.
Whether all of that extra effort makes sense? - it depends. But in most
embedded projects you can just flash a new firmware and avoid the overhead of
executing from RAM. (Depending on your target, flash might have a separate
memory bus and could be one or two clock cycles faster.)

Edit: Hot-patching in flash is totally possible as well.

~~~
ramzyo
Sounds interesting - any runtimes in particular you could point out?
Interested to read more about them.

------
ris
As interesting as this is, I'm not really sure what this gets you over a
regular RTOS that might be used with these sorts of microcontrollers apart
from easy porting of existing unix software (though with 2.2BSD it would have
to be very restricted in its use of syscalls - does it even have sockets?)

------
iuguy
I have this running on a Fubarino. It's nice to fiddle with but not quite
useful to be serious. I have an ethernet module that at some point I need to
hook up to it.

What I really want is a DIP version of the PIC32 with enough RAM and flash to
run this or the 4.4-based LiteBSD[1] by the same people.

[1] - [https://github.com/sergev/LiteBSD](https://github.com/sergev/LiteBSD)

~~~
squarefoot
I wonder why there's no port for the ESP32 boards family. Plenty of RAM/Flash
(compared to PIC32), lots of I/O ports and peripherals and built in WiFi/BT.
It just seems to me the perfect target, or am I missing something?
[https://en.wikipedia.org/wiki/ESP32](https://en.wikipedia.org/wiki/ESP32)

~~~
VectorLock
I think its because the PIC32 uses the MIPS 4k CPU architecture which a
compiler that can build this RetroBSD exists for. I'm not sure what kind of
CPU architecture the ESP32 uses-- I think its some proprietary DSP core.

~~~
shakna
Xtensa.

For most compilers: xtensa-esp32-elf will work, so long as the ESP-IDF
toolchain is available.

------
dvfjsdhgfv
PIC32 is one of the the most underestimated MCU architectures; you get a small
powerful computer for a fraction of the cost of one. I think it's doomed
because of Cortex-M, but what you can do with it in that price range still
amazes me. If only the Chinese picked it up... The boards by Olimex are nice
to work with but could be a bit cheaper.

------
btashton
If you want to checkout a POSIX RTOS for microcontrollers, I would checkout
Nuttx. I have built some commercial products with it.

[0] nuttx.org

------
erric
The hardware looks pretty limited right now, but I have to wonder if this can
be used as a base for replacing closed source Lights out Management such as
iLO, DRAC, and LoM

~~~
exikyut
Interesting idea; but this is 2.11BSD, not OpenBSD, so the attack surface/weak
links are mostly unknown for this majorly obscure kernel configuration/port.

IMO I'd generally want OOB management kit to be Very Very™ secure, and
especially if it lets me near any secure boot keys. In any case this kind of
thing will categorically have the ability to reboot the system, so if I can
tinker with configuration I definitely want to have some degree of confidence
in the auth process etc.

Completely outside the scope of a microcontroller, what would a reasonable
10-year target for video capture be within a "server console/admin" context?
1080p? 2K? DisplayPort? HDMI? (Obviously VGA)

I'm guessing HDMI and maybe 2K. Hm.

~~~
cat199
> 2.11BSD, not OpenBSD, so the attack surface/weak links are mostly unknown
> for this majorly obscure kernel configuration/port.

They're actually probably pretty well known for most things, just buried under
decades of literature and commits.

Starting off with a 4BSD would probably be better though since 32bit vax bsd
unix got a lot more traction (and more direct code lineage to the modern
ports).

But yes, if going 32bit with enough ram, might as well just port
OpenBSD/NetBSD and get on with it.

~~~
loeg
Any idea what the minimum RAM requirements of something like Open or NetBSD
is?

I know that modern FreeBSD can _boot_ to a single user process with something
like 32M RAM on 32-bit systems with a very stripped down kernel configuration.
64M gives a little more breathing room. But those are both many orders of
magnitude larger than 128kB.

It wouldn't surprise me if OBSD or NBSD can fit in a little less RAM, but it
also wouldn't surprise me if they still need at least a handful of MB, i.e.,
32-64x Retro's 128 kB.

~~~
nils-m-holm
> I know that modern FreeBSD can bootI to a single user process with something
> like 32M RAM on 32-bit systems with a very stripped down kernel
> configuration.

Wow! My first BSD box (386BSD) had 8 megabytes of RAM and that was plenty! You
could even compile moderately large programs without any swapping. But then,
feeping creaturism has always been a BSD tradition! :)

~~~
loeg
> But then, feeping creaturism has always been a BSD tradition! :)

In general, living software adapts to the constraints of the hardware
developers use and care about. The most visible case of this is probably web
browsers (and web sites).

If BSD developers were interested in a minimal memory configuration, they
could make it happen. It just hasn't been anyone's priority, and machines have
many orders of magnitude more RAM today than they did in ~1992.

~~~
nils-m-holm
My comment was not intended as criticism, but merely as an "oh, look how times
have changed!". If anything, it was intended as an expression of affection. I
have used BSD ever since as my only OS.

That being said, software development in general is in a desolate state these
days with unnecessary layers of abstraction and bloat all over the place. The
featurism of ancient BSD looks pretty harmless today.

------
ishikawa
This can be pretty interesting for inexpensive IoT and IIoT devices.

~~~
TickleSteve
No, this is jut a toy, it would never be used for real IoT or IIoT devices.

There is no need to dynamically load any code on these type of devices, you
would generally just use eXecute-In-Place (XIP). The type of applications you
develop for these devices simply do not require UNIX like features (multi-
user, etc). Many more appropriate OS'es exist for this to be taken seriously.

~~~
okl
> No, this is jut a toy, it would never be used for real IoT or IIoT devices.

There's lots of outrageous stuff inside today's consumer products. What makes
you so sure that this won't be used in a real (whatever that means) IoT or
IIoT device by someone?

~~~
TickleSteve
Because I design this sort of stuff for a living and have done for over twenty
years. As a realistic product solution, this has no benefits over existing
widely supported solutions that are more targeted at this level of device.

For example... it can work in 128KB RAM. If you're using 128KB just to run the
OS, thats completely wasted RAM that could be used by your application. This
really counts when you're making 100'000 of these devices and are paying for
every byte. You don't waste valuable resources on desktop-level abstractions.
That would make for a very expensive product.

~~~
nickpsecurity
Many people might think you're talking figuratively about paying for every
byte. I'll add for others that 8-16-bit MCU's still sell billions of dollars
of volume specifically to increase profit per unit by using tinier, cheaper
chips. Likewise, stuff like eCos lets you include just the software you need
in the RTOS to further shave off ROM or RAM needs. This helps per unit since
suppliers often charge extra for extra RAM/ROM on a specific chip. Finally,
reliability and security can improve a bit by simply having less software or
hardware to screw up.

