Rolling your own minimal embedded Linux for the Raspberry Pi(kevinboone.me) |
Rolling your own minimal embedded Linux for the Raspberry Pi(kevinboone.me) |
For production-grade custom Linux firmware, two of the most popular options are Buildroot and OpenEmbedded (Yocto). I’d recommend that anyone interested in this space get started with Buildroot. It’s really easy to make a basic image and customize it to your needs, plus you’ll learn a lot along the way. Yocto is much more powerful and customizable, but the learning curve is far more difficult. It’s great for more advanced situations where you need to support multiple boards or bring in 3rd-party layers.
BuildRoot is much easier to work with IMO and gives equivalent or better results.
https://buildroot.org build the whole Linux system from source
https://gokrazy.org pure-Go userland for your Raspberry Pi 3/4 appliances
Performance Options > Overlay File System
Assuming you're not going to be rebuilding the whole lot manually each time, you're also going to have to go through the rather cute experience of building (and maintaining) your own automation tooling around maintaining your minimal embedded Linux.
If I were developing an embedded project, I don't know about you, but I would suggest focusing on the project itself might be a nice idea, not wasting time on things like a custom OS.
Custom OS is fine if you've got a large team working along side you. But if its a one-man-band (or small team) then all the cuteness will soon evaporate.
If you think all Linux distros are too bloated, why not go BSD instead ?
For example, OpenBSD is famous for a minimal default install, and guess what, they maintain ready-to-go builds for Pine 64/64+, Raspberry Pi 3 and Raspberry Pi 4.[1]
Maybe we will see improvements in this space once other secure alternative operating systems and kernels designed for running on embedded systems are available.
https://www.arm.com/resources/education/books/operating-syst...
also, busybox doesn't demand symlinks: you can use hardlinks.
Imagine having the entire output of `top` fit in a terminal window with empty space at the bottom.
link is not work, domain is for sale...
> If I were developing an embedded project, I don't know about you, but I would suggest focusing on the project itself might be a nice idea, not wasting time on things like a custom OS
Using an off the shelf distribution is ideal your goal is rapid prototyping, but most real-world embedded projects end up requiring custom distributions sooner or later. Distributions tailored to interactive use tend not to be so great for distributing and upgrading predictable firmware. You really want all of your devices in a known state, not a random mix of package versions depending on when they last ran ‘apt-get upgrade’, for example.
In production-grade products, the OS is often built with tools like Buildroot or OpenEmbedded (Yocto), not from scratch. However, doing a tutorial like this once is a good learning exercise.
And that's why you're probably not working on embedded. Minimal environments with almost zero footprint is a must in almost all cases. If you're rolling a custom board, you simply have to go custom, which is where OpenBSD will fall short on you. Check Variscite's or Toradex websites and see if you find any BSD in there.
To build NetBSD/aarch64 on most Unix / Linux OSes (replace -j 8 with a suitable number for however many processor cores / threads you have):
curl "https://cdn.netbsd.org/pub/NetBSD/NetBSD-current/tar_files/src.tar.gz" -o src.tar.gz
curl "https://cdn.netbsd.org/pub/NetBSD/NetBSD-current/tar_files/xsrc.tar.gz" -o xsrc.tar.gz
tar xzf src.tar.gz ; tar xzf xsrc.tar.gz
cd src
./build.sh -m evbarm -a aarch64 -x -U -j 8 -D ../dest -O ../obj -T ../tools -R ../sets tools release
git clone git://git.yoctoproject.org/poky
cd poky
git checkout -b hardknott -t origin/hardknott
source oe-init-build-env
MACHINE=qemuarm64 bitbake core-image-sato
There's a lot going for Yocto, it has a deep learning curve but does a pretty good job of taming the complexity of managing an entire OS distro.
1 The "NetBSD way" would be to study the NetBSD source tree and then modify certain files to suit one's needs. For example, I like to create custom crunched binaries; this requires editing a list. By comparsion, with Linux, I have never read any advice to study the Debian source tree and then modify files to suit one's needs. Rather, the advice one finds directs readers to Yocto, buildroot, etc.
It’s interesting to think about the different markets for the rpi. I would never consider the rpi for learning. I only look at it as an inexpensive system to run my favorite distro. I want it to run CentOS or NetBSD, etc. rpi OS is meaningless to me. I want it to run the stuff I use every day.
It is miles better than SysV or monit. I haven't needed to try the 'suggested' replacements like runit or openrc.
Not every nail needs to be hut by the systemd hammer. We've had really fantastic and light weight init systems for decades without all the bloat and creep of systemd.
And why would I want to remove the SD card after boot? Now I can't reboot the system, and it won't reboot if it crashes?
This isn't guaranteed, depending on many factors.
> why would I want to remove the SD card after boot
It's unnecessary to remove it. It's more about reliability. SD cards are notoriously unreliable, and it could potentially fail after boot. Coupled with the previous point, it has happened multiple times that I wanted to login to troubleshoot the system, but cannot because the basic system binaries like `ls` are not cached in RAM (as you said these are not used for the normal operation of these unattended systems).
This is when RAM disk is very helpful: as long as the system is powered on, I have reasonable confidence that I can login and see what's going wrong. It's mostly because RAM is way more reliable, faster, and cheap enough to "waste" a few dozens megabytes for the entire base OS.
Also there're diskless PXE systems where you just load the OS from network only once upon boot.
There is also TinyGo for microcontrollers. https://tinygo.org
Perhaps buildroot does the closest thing. I'll have to give it a go.
Everything is customizable, every file, every compiler flag and option of every package, with easy overrides in your own layer which only 'appends' to the original instructions, or adding and removing packages as you see fit in the base install.