Marcus Folkesson

Embedded Linux Artist

UBI volumes in Yocto

UBI volumes in Yocto These days, managed NAND flash memories such as eMMC or SD-cards has become more common in the embedded Linux systems as they abstract (or hide..) the complicated raw NAND memory under the hood. Even if raw NAND memories are more complicated to handle, they are still used in many new products out there. When working with raw NAND flashes, UBI [1] with UBIFS on top of that is the way to go. cover

Flattened Image Tree (FIT) with Yocto

Flattened Image Tree (FIT) with Yocto Long time ago, I wrota a post [1] that compared the legacy Image format against Flattened Image Tree Format (FIT) [2] and highlighted the benefits of using it. The benefits is still valid and FIT images is my preferred way to boot a Linux kernel. Dispite that, I almost never see that FIT images is used in examples nor Board Support Packages (BSPs). cover

Working on U-boot from Yocto (iMX8)

Working on U-boot from Yocto (iMX8) I have been asked a couple of times how to quickly make changes for U-Boot in Yocto. Those who asked have used to rebuild and flash an entire image each time, which takes an unnecessarily which is not a fast procedure. To rebuild U-Boot is`nt significantly different from any other recipe, but one difference is that imx-mkimage must also be built to generate a bootable image.

Skip flashing unused blocks with UUU

Skip flashing unused blocks with UUU TL;DR: UUU does now (or will shortly) support blockmaps for flashing images. Use it. It will shorten your flashing time *a lot.* It will soon be time to manufacture circuit boards for a project I'm currently working on. After manufacturing, it will need some firmware for sure, but how do we flash it in the most efficient way? The board is based on an i. cover

kas-container and QEMU

kas-container and QEMU KAS KAS [1] is a setup tool for bitbake based projects such as Yocto. There are many similiar alternatives out there and I've tried most of them, but my absolute favorite is KAS. In order to use KAS, you have to setup a YAML file to contain information about your machine, distribution, meta layers and local configuration. Here is a small example configuration copied from the KAS documentation: cover

meta-readonly-rootfs-overlay

meta-readonly-rootfs-overlay meta-readonly-rootfs-overlay [1] is a meta layer for the Yocto project [2] originally written by Claudius Heine. I took over the maintainership in May 2022 to keep it updated with recent Yocto releases and keep add functionality. I've implemented it in a couple of industrial products so far and think it needs some extra attention as I find it so useful. Why does this exists? Having a read-only root file system is useful for many scenarios: cover