TLDR: I wanted to generate an up-to-date disk image for a Rock Pi 4 using Yocto that included CUPS and Docker to both get a better understanding of Yocto and test the new SBOM generation feature.
As with many single-board computers (SBCs) from China, the issue often isn’t the board itself but rather the software. RockPi from Radxa is no exception. If you go and download the latest disk images for this board, you will notice that they are all end-of-life (EoL). However, these boards are still great and work very well for many applications. This should be top of mind if you are building a product that uses any of these devices.
I wanted to use one of the RockPi 4 boards I had for a simple print server. It’s not a customer product, of course, but let’s assume it was. Since it has the option to add eMMC storage, I find it more reliable than Raspberry Pi (I know the Raspberry Pi 5 allows for proper storage). However, given that I neither trust the Radxa disk images nor did I want to set things up on an already EoL Linux distribution, I started doing some digging. As it turns out, the RockPi is supported in Yocto.
Say what you want about Raspberry Pi, but you can still download an up-to-date OS that runs on the Pi 1.
In this article, I will show you not only how to build a disk image with Yocto (in this case for the Rock Pi 4, but it can easily be adjusted for other boards), but we will also talk a bit about how Yocto generates SBOMs (hint: it’s really clever) and where to find your SBOMs.
What is Yocto anyways?
The Yocto Project is an open-source framework for building custom Linux distributions tailored to embedded systems. It provides a flexible, modular build system based on BitBake and OpenEmbedded, enabling developers to create highly optimized and reproducible Linux images for specific hardware. Yocto is widely used in industries like automotive, IoT, and networking due to its ability to support diverse architectures and long-term maintenance needs. With its layered architecture, extensive BSP support, and strong focus on customization, Yocto is a powerful tool for developers looking to build and maintain embedded Linux systems efficiently.
I’ve toyed with it a few times over the years to build images for Raspberry Pis, but never really used it seriously. However, I recently crossed paths with some of the Yocto people in a CISA working group I’m co-chairing on SBOM generation. As it turns out, Yocto is very sophisticated when it comes to generating SBOMs, so I wanted to get some more up-to-date exposure to Yocto. Color me impressed. Not only did Yocto produce a Software Bill of Materials (SBOM) for me – it did so without even asking me.
Since Yocto builds everything from source and is essentially a package manager, it is able to capture all the dependencies into an SBOM. Moreover, since Yocto maintains detailed infor
13 Comments
lukeh
Love Yocto! It has a learning curve but it took about a week from nothing to an embedded image including Swift and Flutter apps, U-Boot, etc. A curve worth climbing.
Palomides
>you can’t run “apt update”
if you want to get a little weird, you can tell yocto to compile everything into deb packages and host them yourself with something like aptly
palata
Yocto is pretty great! Unfortunately I feel like it gets a lot of criticism, but usually from people who haven't gotten to learn it. Like "I had to spend 2h on Yocto and this thing suuuuucks, I threw a docker image there and called it a day".
Which is a pity, because when used correctly it's really powerful!
From the article, I can't help but mention that one third of the "key terminology" is about codenames. What do people have with codenames? I can count and easily know that 5 comes after 4. But I don't know how to compare Scarthgap and Dunfell (hell, I can't even remember them).
dgfitz
I read just the title and wondered if this was a yocto post.
I have (accident) become the yocto SME at my $dayjob. Probably the biggest positive has been free SBOM generation, and cooking things like kSLOC counts into recipes.
The learning curve stinks, the build suite is very powerful.
kierank
It's crazy that you have to use this custom "embedded" tooling when the vendor should be implementing support in vanilla Linux distros.
dgfitz
This toolchain is about half my dayjob.
Bitbake is a meta-compiler, and the tool suite is very powerful. Just realize to this means you need to be an expert error-message debugger, and able to jump into (usually c/c++) code to address issues and flow patches upstream.
It really is gratifying when you finally kick out a working image.
bootloop
I am actually scared of switching jobs in case my next job doesn't involve yocto.
How would I make use of the countless hours I have already invested in this piece of software? Countless keywords and the dark magic of the ever changing syntax.
But when it works it works..
codetrotter
Last time I tried Yocto, some people here on HN suggested that I try Buildroot instead.
I don’t see so many mentions of Buildroot in this thread yet.
If you are interested in Yocto it might be worth having a look at Buildroot as well. I liked it a lot when I tried it.
My thread from years ago, where people told me about Buildroot:
https://news.ycombinator.com/item?id=18083506
The website of Buildroot:
https://buildroot.org/
msarnoff
The one thing I still don't like about Yocto is the setup process. You need to check out multiple layer repositories, make sure you check out the right commit from each repository (need reproducibility!), put everything in the correct directory structure, and then set up `bblayers.conf` and `local.conf`.
I've got a script that does all this, but it's still a pain.
I've been thinking about putting everything in a monorepo, and adding poky, the third-party layers, and my proprietary layers as submodules. Then, when the build server needs to check out the code or a new developer needs to be onboarded, they just `git clone` and `git submodule update`. When it's time to update to the latest version of Yocto, update your layer submodules to the new branch. If you need to go back in time and build an older version of your firmware image, just roll back to the appropriate tag from your monorepo.
Anyone else have another solution to this issue?
Oh yeah, and the build times. It's crazy disk I/O bound. But if you're using something like Jenkins on an AWS instance with 96GB of RAM, set up your build job to use `/tmp` as your work directory and you can do a whole-OS CI build in minutes.
fathermarz
As someone in the Software Supply Chain business. Yocto SBOMs are considered low quality because they include things that do and do not exist in the final compiled artifact. When you compare what exists inside, physically from a binary perspective, what is included in the manifest, and what is generated in the build root, you will find they will never align unless you get creative and map artifacts together. Today they are accepted as meeting the compliance checkbox, but once the industry matures, they will need to adjust their approach.
klysm
I think long term yocto and build root are going to be replaced by container tooling. Theres not that big of a difference between compiling an OS image and building a container image.
jcalvinowens
Yocto can be incredibly simple, this is my favorite example: https://github.com/bootlin/simplest-yocto-setup/
Only the kernel and bootloader usually need to be specialized for most modern arm boards: the userland can be generic. Most of the problems people have with yocto are due to layers from hardware vendors which contain a lot of unnecessary cruft.
vlovich123
Ah BitBake and OpenEmbedded. That’s what Palm used for WebOS. It was simultaneously amazing and a nightmare. In 2024 you should not be using it. There are better alternatives.