Getting the boards online

[extrowerk]

Today evening i started to wondering about the possible ways to get the boards online, but the best option i can think of is using the GPIO pins to bitbang 10mbit ethernet, something similar to this:
https://github.com/osnr/rpi-bitbang-ethernet

What are the other options? Is there any plan to get DiscoBSD online?

[chettrick]

I have thought about the possibility of networking, but it has been low on my priority list for DiscoBSD.

The current state of the matter is:

• 2.11BSD has the classic BSD networking stack, and is full featured for Ethernet and maybe other means.
• RetroBSD had the majority of the networking code from 2.11BSD removed, and it has not yet been re-introduced in DiscoBSD.
• The 2.11BSD networking hardware drivers would be of little value to our embedded development boards.
• Many STM32F4 chips have a built-in Ethernet controller, their development boards have Ethernet hardware, and the HAL library has support code for it. An implementation issue is that most or all of the sample demo code for Ethernet from the HAL library in the Applications subdirectories has an unusable 5-clause license, specifically due to Clause 4.
• A RetroBSD user/developer used a Raspberry Pi as an Ethernet to Telnet bridge/proxy to their PIC32 RetroBSD board. There was a thread about it on the old RetroBSD forum (which is no longer online). Perhaps I can dig it up through the Wayback Machine.
• Bitbanging protocols in DiscoBSD would seem to be riddled with complications on accurate timing, interrupts, and the full swapping nature of process context switching. Not saying it can't be done, but it may prove challenging.
• DiscoBSD being on the local LAN would be fine, but being on the wider Internet makes me nervous in its current state. Dozens or hundreds of CVEs for the other BSDs may exist in DiscoBSD. The whole codebase should be audited before being reachable on the Internet.
• OpenSSH is too big to fit in 96KB of RAM. I haven't yet looked into any of the smaller SSH implementations available, with suitable licenses.

SPI to Wifi and SPI to Bluetooth daughter boards are quite common and may be an easier path forward.
The STM32F413H-DISCO development board has an integrated Wi-Fi module. I own one of these boards, but I haven't done a DiscoBSD port and a kernel Config for it as of yet.

I have not researched the Ethernet or Wi-fi suitability for the PIC32 port, but I am sure it is possible if suitable development boards exist and are readily available.

@extrowerk Do you have a specific use case that you would like to achieve?

[extrowerk]

@chettrick Thanks for the detailed answer!
I don't really have an use case, It was mainly a brain-excercise to collect and rate all the options and to start a discussion to widen my perspective in the embedded platforms and possible communications way in resource constrained systems.

I forgot about the radio (WiFi / BT) enabled boards, thats for sure a nice a simpler solution, I assume one can program it so the host system doesn1t even need to know about the details.

I still like to find a cheap and simpel way to run a general operating system on a handheld device, and DiscoBSD sounds fun, but it would be nice to have any kind of networking support.

[onre]

Random thoughts;

Bit-banging protocols could be a viable option with the RP2040/2350 as they have the programmable I/O state machines on-board, so it is possible to basically off-load processing from the general-purpose CPU(s).

Many boards have multiple UARTs so I would definitely think of SLIP and PPP as options. SLIP is lighter-weight and easier, whereas PPP offers features such as automatic network parameter configuration et cetera. Looks like 2.11 has an in-kernel SLIP driver in sys/net/if_sl.c. With the development board UARTs being capable of megahertz-grade baud rates, this could possibly work rather well.

A more boring but highly reliable UART-based solution would be an RS232-Ethernet "adapter", as point-of-sales folks call them. These are widely used to connect things like older 8-bit cash registers to computers, modern payment terminals and the like. As you probably already guessed, there's a small embedded system trapped in there, talking TCP/IP out one end, RS-232 the other. You could think of it as a terminal server with exactly one (1) RS-232 port. Then again, it might be possible (and even trivial) to make the adapter itself run DiscoBSD...

Regarding ssh, by far the most common lightweight option seems to be dropbear. Here is their license. I've got some experience with it from projects where small footprint was important, but haven't had to fit it into 96 kB yet. However, this sounds like a fun challenge. Now, this makes me wonder if the Cortex-M4 cryptographic processor (MMCAU) could be leveraged here? At the very least I'm planning to write a md5sum that uses it, so I can say I'm getting every penny's worth of features out of the chip.

I have a controversial idea about auditing the codebase. If the network stack revival ever comes to a point where it's usable, then I volunteer to set up a public-IPv4 non-firewalled honey pot with write-only logging over UART. Given the absolutely unheard-of amount of hammering public IPv4 addresses receive today, I'd imagine any potential stack bug to raise its head in a matter of days, if not hours or minutes. (...long gone are the days of the '90s when you saw a portscan in your syslog, looked up the reverse address on the DNS, went "uh-huh", picked up the phone and called the responsible student dorm to thank for contacting and ask whether you could be of further assistance...)

[extrowerk]

Thanks for the detailed answer again, I am sad that we probbaly will never met in RL, I think we could discuss and i could learn a lot from you.

Nevertheless: regarding your audit idea: I fear some of the vulnerabilities would not surface as the script-kiddies targets the most ROI targets, nobody expects to find a relic fromt the past like BSD 2.11 on the open network, but nevertheless, it is a cheap way to get some input. I would however check al lthe related CVEs from the past.

I can't comment on the SSL lib, but if the board supports any kind of crypto-acceleration it should be used in ideal case, but the kode-size is the main pain-point here, if I understood you correctly. I can imagine the necessary algorithms would need a lot of flash space. No idea, how to solve this, but I have seen already some high-specced STM32 dev-boards with 16 M flash with 1 or 2 MB RAM and ~500 Mhz CPU. Those are pretty capable, but extremely overkill as a microcontroller. I expect in some years there will be cheap, good specced boards with many cores, big flash and ram, + some means of connectivity. It would be nice to run DiscoBSD on those.

[onre]

It's not the code size but the working set size. A dropbear server binary is entirely possible to squeeze into less than 200 kB, possibly even under 100 kB, with all the dependencies linked in, but that's not all of it. SSH protocol implementations must support packets of 32 kB length, which could get rather interesting. A zero-copy solution would be trivial if we had a full-fledged MMU, but we don't.

I've thought of setting up something like UUCP over all sorts of rickety transfer paths. Over-the-air UUCP sounds properly exotic, especially combined with something like solar-powered microcontrollers forming a mesh network.

[chettrick]

DiscoBSD does a full swap of each process, so the full user RAM is available when any process is running. Each process executable runs entirely in RAM. There are no shared libraries or ld.so runtime loader.

I have ideas for how to have shared libraries permanently in Flash, but it is cumbersome and potentially a ton of work.

Dropbear sounds good. Even if it can only fit in the larger STM32F4 devices, such as the F412 that has 256kB RAM, then that is a candidate for adding to base once we have networking. 32kB packets is a lot.. And yeah, no MMU. That actually is the defining feature/constraint for DiscoBSD. Once you have MMU and virtual memory, then why not LiteBSD, 4.4BSD, Linux, etc..

Main issue with porting a lot of modern utilities is that 2.11BSD is most of 4.3BSD-Tahoe but on the PDP-11. Tahoe was before POSIX compliance was added to 4.3BSD-Reno, and then 4.4BSD of course. So a significant amount of work is necessary in libc and others to have the POSIX functions available that modern software expects, while still not blowing up the size of libc and every binary.
4.3BSD-Quasijarus exists/existed because of some users not satisfied with the almost doubling in size from Tahoe to Reno due to implementing POSIX compliance.

There are UUCP utilities in DiscoBSD, but I have yet to test or use them. Definitely a short term goal would be to get UUCP working. Would be nice to transfer between RetroBSD and DiscoBSD as the pic32 port and stm32 port.