Tag Archive for: konsulko group

IMA-measurement with Yocto Project and OpenEmbedded

Integrity Measurement Architecture (IMA-measurement) is a subsystem in the Linux kernel designed to provide a framework for maintaining the integrity of files on a system. The primary purpose of IMA is to ensure that only trusted code and data are executed on a system and that the integrity of critical system components is maintained.

IMA was merged into the mainline Linux kernel in 2004 with the release of version 2.6.30. It evolved over time, adding features such as TPM integration, extended support, and continued maintenance, becoming a key component for ensuring the integrity of files in Linux-based systems. IMA works by calculating cryptographic hashes of files at various points in their lifecycle, such as when they are accessed, executed, or modified.

This article shares the exacts steps to build a minimal Linux distribution with IMA support for QEMU x86-64 using the Yocto Project and OpenEmbedded. The Yocto Project is an open-source collaboration project that enables developers to create lightweight, optimized, and customizable Linux distributions for embedded devices while maintaining control over the software components and configurations included in the system. To enable IMA, we use Yocto/OpenEmbedded layers meta-security and meta-integrity. These layers offer a comprehensive suite of security tools and hardening utilities designed for Linux kernels, along with libraries that facilitate the implementation of robust security mechanisms.

Building a Linux Distribution with IMA

Recently Leon Anavi, Konsulko Group Senior Engineer, contributed a couple of patches to the upstream of meta-security/meta-integrity to simplify using integrity-image-minimal. This is a small image provided as an example to demonstrate IMA support.

The following steps outline the process of building an image with Integrity Measurement Architecture (IMA) using the Yocto Project and OpenEmbedded. This demonstration uses the default debug keys provided in the “data” directory of layer meta-integrity. Because everyone has access to these private keys, for devices in production you must create your own private keys and use them instead. Enabling the audit kernel subsystem provides additional informational integrity auditing messages useful for debugging any appraisal issues that may arise during the development process.

Kindly be aware that this article utilizes source code derived from the primary branches of associated Yocto/OE layers. Consequently, we are selecting specific git commits that have been confirmed to function reliably. These commits will be part of the next long-term support (LTS) release of the Yocto Project which is version 5.0 with codename Scarthgap. It is scheduled for release in April 2024 and will be supported for 4 years until April 2028.

  • Download the source code:
git clone git://git.yoctoproject.org/poky poky-qemu
cd poky-qemu
git checkout e31be0b0e6ed6855787ebfbacc15bdbf1b9e511c
git clone git://git.yoctoproject.org/meta-security
cd meta-security
git checkout 30e755c59204cbd64c3aa12e64ab33041f6f02c0q
git clone git://git.openembedded.org/meta-openembedded
cd meta-openembedded
git checkout 57db42741df341718b9bb4b1b8f20d2e2fcf7010
  • Initialize the built envieronment:
source oe-init-build-env
  • Include additional layers:
bitbake-layers add-layer ../meta-openembedded/meta-oe
bitbake-layers add-layer ../meta-security
bitbake-layers add-layer ../meta-security/meta-integrity
  • Append the following configurations to conf/local.conf:
DISTRO_FEATURES:append = " integrity ima"

IMAGE_CLASSES += "ima-evm-rootfs"

IMA_EVM_KEY_DIR = "${INTEGRITY_BASE}/data/debug-keys"
IMA_EVM_PRIVKEY = "${IMA_EVM_KEY_DIR}/privkey_ima.pem"
IMA_EVM_X509 = "${IMA_EVM_KEY_DIR}/x509_ima.der"
IMA_EVM_ROOT_CA = "${IMA_EVM_KEY_DIR}/ima-local-ca.pem"

IMA_EVM_POLICY = "${INTEGRITY_BASE}/recipes-security/ima_policy_hashed/files/ima_policy_hashed"

SRC_URI:append:pn-linux-yocto = " file://audit.cfg"

QB_KERNEL_CMDLINE_APPEND:remove:pn-integrity-image-minimal = "ima_policy=tcb ima_appraise=fix"
QB_KERNEL_CMDLINE_APPEND:append:pn-integrity-image-minimal = " ima_appraise=log ima_appraise_tcb integrity_audit=1"
  • Built an image with IMA for QEMU x86-64:
bitbake integrity-image-minimal

Testing IMA

After building the image, we can launch it. QEMU, short for Quick Emulator, is an open-source virtualization software that allows users to emulate various hardware platforms and run operating systems on different host systems. We will use it to run and test the image. By utilizing the “nographic” option, QEMU disables the video console, setting the console to “ttys0”. This feature is particularly beneficial when remotely accessing a build server over SSH. To verify the effectiveness of the appraisal process, attempt modifying a file, then confirm that the verification of the altered file subsequently fails.

  • Launch the image in QEMU:
runqemu nographic
  • Login and root and verify the integrity of file /etc/hostname using evmctl:
evmctl ima_verify /etc/hostname

The expected output should resemble:

Poky (Yocto Project Reference Distro) 4.3+snapshot-e31be0b0e6ed6855787ebfbacc15bdbf1b9e511c qemux86-64 /dev/ttyS0

qemux86-64 login: root
root@qemux86-64:~# evmctl ima_verify /etc/hostname
key 1: 6730eefd /etc/keys/x509_evm.der
/etc/hostname: verification is OK
  • Modify /etc/hostname:
echo test > /etc/hostname
  • Verify the integrity of file /etc/hostname again:
evmctl ima_verify /etc/hostname

Now the verification fails because the file has been modified. The anticipated output should be similar to:

root@qemux86-64:~# echo test > /etc/hostname
root@qemux86-64:~# evmctl ima_verify /etc/hostname
key 1: 6730eefd /etc/keys/x509_evm.der
/etc/hostname: verification failed: 0 ((null))

This simple example serves as a demonstration of how Linux IMA operates, using QEMU as a platform. However, to implement Linux IMA on real-world devices, Konsulko Group offers assistance with hardware bring-up and integration of the suitable Yocto/OE BSP (Board Support Package) layers.

Since the inception of OpenEmbedded and the Yocto Project, Konsulko engineers have actively contributed to the community and provided guidance for developing commercial products. We specialize in U-Boot, Linux kernel, RAUC, Mender, and various other open source projects for embedded Linux devices. Contact us to explore how Konsulko engineers can assist with your embedded product development endeavors.

Integrating RAUC with Yocto Project on BeagleBone Black

Konsulko Group has made many upstream contributions to OTA (over-the-air) update solutions for embedded Linux devices. RAUC is a popular open source option as it has been meticulously developed with a keen emphasis on stability, security, and adaptability. Notably, RAUC seamlessly integrates with major build systems such as Yocto Project/OpenEmbedded, Buildroot, and PTXdist.

Functioning across diverse usage scenarios, one of RAUC’s elementary yet impactful functionalities is the A/B update mechanism. In this setup, two identical root filesystems, denoted as A and B, are maintained. The device boots from one of these, while the other serves as the target for updates.

Post-update completion, the bootloader directs the system to boot from the freshly updated partition during the subsequent system startup. RAUC incorporates the ‘verity’ update bundle format. It extends the capabilities of RAUC by introducing built-in support for HTTP(S) network streaming, adaptive delta-like updates, and comprehensive update bundle encryption.

In previous blog posts, Konsulko Group engineers have demonstrated RAUC on Raspberry Pi and NXP devices such as SolidRun Cubox-i and HummingBoard. Recently Leon Anavi, Konsulko Group Senior Engineer and maintainer of meta-rauc-community ported RAUC to BeagleBone Black.

This article provides, as an example, the exact steps how to integrate RAUC with Yocto Project and OpenEmbedded for booting from a microSD card on BeagleBone Black.

Released in 2013, BeagleBone Black is a single-board computer (SBC) developed by the BeagleBoard.org Foundation. It was certified by the Open Source Hardware Association with OSHWA UID US000236. The chipset on BeagleBone Black is Texas Instruments Sitara AM3358 with 1GHz ARM Cortex-A8 CPU and SGX 3D graphics engine. Because of this the demonstrated integration is a suitable reference for other embedded devices equipped Texas Instruments chipsets.

Required Hardware

The hardware used for this step by step tutorial is:

Building a Linux Distribution with RAUC

RAUC, a robust and powerful open-source solution, demands advanced skills for initial integration. In general, to incorporate RAUC in a Yocto Project and OpenEmbedded image for BeagleBone Black the following actions have to be performed:

  • Use U-Boot as a bootloader
  • Enable SquashFS in the Linux kernel configuration
  • Use ext4 root file system
  • Design specific storage partitioning for the certain use case and configure RAUC accordingly
  • Provide a custom U-Boot script to properly switch between RAUC slots
  • Prepare a certificate and keyring to use for signing and verifying RAUC update bundles.

Leon Anavi has already done all these actions for core-image-minimal in Yocto/OpenEmbedded layer meta-rauc-community/meta-rauc-beaglebone. The layer is available at GitHub. Please follow the steps below to build core-image-minimal for BeagleBone Black with it:

  • Download the long term support (LTS) release Kirkstone reference Yocto distribution, Poky:
git clone -b kirkstone https://git.yoctoproject.org/poky poky-rauc-bbb
cd poky-rauc-bbb
  • Download the meta-rauc layer:
git clone -b kirkstone https://github.com/rauc/meta-rauc.git
  • Download meta-rauc-community layers, including meta-rauc-beaglebone:
git clone https://github.com/rauc/meta-rauc-community.git
  • Download the meta-openembedded layer as it provides a recipe for nano which will be used for the demonstration:
git clone -b kirkstone git://git.openembedded.org/meta-openembedded

Initialize the build environment:

source oe-init-build-env
  • Include all layers in conf/bblayers.conf:
bitbake-layers add-layer ../meta-openembedded/meta-oe
bitbake-layers add-layer ../meta-rauc
bitbake-layers add-layer ../meta-rauc-community/meta-rauc-beaglebone
  • Adjust conf/local.conf by appending the following configurations to the end of the file:
MACHINE = "beaglebone-yocto"

# Use systemd as init manager
INIT_MANAGER = "systemd"

# Add RAUC to the image
IMAGE_INSTALL:append = " rauc"
DISTRO_FEATURES:append = " rauc"
  • Build a minimal bootable image:
bitbake core-image-minimal

The image creation process from scratch is time-consuming, encompassing various Yocto/OpenEmbedded recipes and configurations. Kindly await completion as bitbake diligently executes each tasks.

  • Flash tmp/deploy/images/beaglebone-yocto/core-image-minimal-beaglebone-yocto.wic.xz to microSD card.
  • Attach the USB-to-UART adapter to BeagleBone Black, plug the ethernet cable and the microSD card.

Press and hold button S2 while plugging in the 5V DC power supply to turn on BeagleBone Black and boot from microSD card.

BeagleBone black board has an onboard button labeled as S2. It is situated near the microSD card slot. Press and hold it while powering the board to boot from microSD card.

  • Verify that the system boots successfully, log in as user root without a password and check RAUC status:
rauc status

On the screenshot BeagleBone Black has been booted from RAUC slot rootfs.0 (A) on the microSD card.

NOTE: The meta-rauc-beaglebone layer includes a core-image-minimal.bbappend file, housing essential configurations for RAUC functionality. Apply these configurations similarly to other images intended for use in your embedded Linux device.

Creating a RAUC Update Bundle

RAUC update bundle comprises the file system image(s) or archive(s) designated for system installation, accompanied by a manifest detailing the images for installation, encompassing options and meta-information. Additionally, it may include scripts designated for execution before, during or after the installation process. To sign and verify the update bundles RAUC uses SSL keys. Layer meta-rauc-beaglebone contains a keyring containing all keys and a recipe for a simple RAUC update bundle for demonstration purposes only.

Follow the steps below to create RAUC update bundle that extends the system by adding the popular text based editor nano:

  • Add to conf/local.conf:
IMAGE_INSTALL:append = " nano"
  • Build the RAUC update bundle:
bitbake update-bundle

Following a successful execution, bitbake will produce the update-bundle-beaglebone-yocto.raucb file.

Updating BeagleBone Black with RAUC

Follow the steps below to update core-image-minimal running from a microSD card on BeagleBone Black:

  • Start a Python 3 web server on the build machine or another computer where the RAUC update bundle (aka update-bundle-beaglebone-yocto.raucb) is available and within the same network as BeagleBone Black, for example:
cd tmp/deploy/images/beaglebone-yocto/
pip3 install --user rangehttpserver
python3 -m RangeHTTPServer
  • On BeagleBone Black replace <IP> with the actual IP address of the computer on which the HTTP server is running and execute the following command to install the update:
rauc install http://<IP>:8000/update-bundle-beaglebone-yocto.raucb

The screenshot show successful installation of the RAUC updated bundle on BeagleBone Black.

  • Reboot BeagleBone Black to load the updated version:

NOTE: As alternative, instead of using an HTTP server, you can transfer the update bundle to BeagleBone Black and install it from local storage.

  • Verify that nano was added to the system:
which nano
  • Check RAUC status to confirm the system have booted from the second partition:
rauc status

On the screenshot, after sucessful installation of the RAUC update bundle, BeagleBone Black has been booted from RAUC slot rootfs.1 (B) on the microSD card. This slot contains nano.

In real-world product development, the Yocto Project and OpenEmbedded workflow can be enhanced with a few commands for easy implementation of continuous integration (CI).

From the dawn of OpenEmbedded and the Yocto Project, Konsulko engineers have been community contributors and guides for crafting commercial products. Our expertise spans RAUC, Mender, and various open-source solutions for top-notch software updates. Please get in touch with us to discuss how Konsulko engineers can help your own embedded product development.

What to do when your commercial Linux goes away

How do you move forward with your software development when the commercial embedded Linux you’ve used to build your products is no longer available? Customers often come to Konsulko Group for help, particularly when a commercial Linux is phased-out or end-of-lifed.

Konsulko is in a unique position as many of our engineers have 25+ years experience with embedded Linux, and some were instrumental in building the now-discontinued Linux products we are helping our customers replace. We know well what needs to be done (and what doesn’t) and where to look for potential problems along the way. 

We take a three-step approach for our customers. 

  • First, we rebuild their software stack outside the dependencies of the commercial distribution. 
  • This is not a simple task, but when it is done, we have a “clean” software stack that we can update with the latest open source components. 
  • Finally, we systematically address security, OTA and other customizations required by our customer.

The result is customer-specific, fully maintainable embedded Linux that is free of the dependancies of the marketplace. If you would like some help moving forward with your current and future embedded Linux needs, please contact us.

Konsulko Group: The Year in Review 2023

Konsulko Group has had another great year. We’ve helped our customers build new breakthrough embedded products of all sizes, from semiconductors to medical devices to automotive to heavy equipment.

We continue strong relationships with the Linux Foundation, Yocto Project and Automotive Grade Linux. We work with our partners mender.io and PHYTEC, providing support and development for their customers.

Konsulko is growing

We’ve expanded our footprint across the US and Europe, welcoming three outstanding engineers to the team: George McCollister, Darko Alavanja and Bryan Cisneros.

George McCollister has over 25 years of experience in Embedded Systems development. Starting with 8051 microcontrollers and quickly adopting Linux, he has worked on a wide range of technologies from network switches and storage appliances to automated utility fault restoration and process automation. He was a key designer and architect of an industry leading utility automation platform.

Darko Alavanja was deeply involved with robotics as a student, competing in several teams in the Eurobot contest. He designed mechanical components, PCBs, sensor electronics, actuator systems and software used for creating mobile robots. Darko has developed embedded systems for industrial devices such as FPGA-based hardware-in-the-loop equipment, controllers for industrial machinery and protocols for communication gateways.

Bryan Cisneros has developed embedded software, UIs, and test code across various industries, including medical devices, RF modules, and AI-enabled cameras. Before joining Konsulko, Bryan worked in the defense industry developing networked applications for weapons and information systems, focusing on redesigning outdated UIs and programs, and implementing CI/CD pipelines.

Committed to the Open Source community

In addition to our consulting work for our customers, Konsulko Group continues to actively participate in the Open Source community and its conferences around the world.

Konsulko’s senior leadership have been contributors in the Linux kernel and other OSS communities since the late 1990s. The entire Konsulko team has been involved in a number of Open Source projects including U-Boot, Yocto Project, OpenEmbedded and Automotive Grade Linux (AGL).

Konsulko principal engineer Tim Orling serves on OpenEmbedded Board of Directors. He co-presented Maintaining a Community BSP Layer: Updating Meta-Tegra with Ilies Chergui (Medtronic) at Embedded Open Source Summit in June 2023, and Customize your CROPS containers with crops-generator with Eilís ‘pidge’ Ní Fhlannagáin (BayLibre) at Yocto Project Developer Day.

Principal engineer Denys Dmytriyenko and the Yocto Project Technical Steering Committee were instrumental in helping Yocto Project secure important new funding from the Sovereign Tech Fund. Denys also wrote about some of the technical highlights from the 2023 Linux Plumbers Conference.

Principal engineer Scott Murray presented Vehicle Signaling Specification and KUKSA.val at Automotive Grade Linux All Member Meeting Berlin, a “lightning talk” on VSS Updates in AGL at Automotive Linux Summit, Evolving VSS Usage in AGL at AGL AMM Japan, and Automotive Grade Linux: Status and Roadmap at Embedded Recipes Paris.

Senior engineer Leon Anavi spoke about RDP with Wayland, Weston & Yocto at FOSDEM, and Integrating VNC/Weston with the Yocto Project/OpenEmbedded at Yocto Project Virtual Summit 2023.

Vitaly Wool, principal engineer and General Manager, Konsulko AB presented Implementing secure boot for AOSP running U-Boot at the Lund Linux Conference 2023.

Finally, Konsulko Group intern Atanas Bunchev demonstrated remote updates and troubleshooting of connected embedded Linux devices using Mender.io at TuxCon 2023. The presentation (in Bulgarian) spread the word about the Yocto Project, OpenEmbedded and various Mender features among the local community. Atanas also co-wrote (with Leon Anavi) RAUC on CuBox-I/HummingBoard for Software Updates and Mender Add-ons: Remote Troubleshooting Devices in the Field.

Some of the Highlights from Linux Plumbers Conference 2023

In November, Konsulko Group Principal Software Engineer Denys Dmytriyenko attended The Linux Plumbers Conference (LPC), a developer conference for the open source community, held this year in Richmond, Virginia. Here is his report on the highlights of the conference.

LPC brings together the top developers working on the “plumbing” of Linux – kernel subsystems, core libraries, windowing systems, etc. – and gives them three days to work together on core design problems. The conference is divided into several working sessions focusing on different “plumbing” topics, as well as a general paper track.

Usually there are several main tracks and many Microconferences all fit into 3 days. And this year the list included Refereed Track, Kernel Summit, Toolchains Track and BoF. As well as Microconferences on Kernel Testing & Dependability, Real-time and Scheduling, RISC-V, Compute Express Link, Containers and Checkpoint/Restore, Android, Build Systems, Linux Kernel Debugging, KVM, Confidential Computing, Power Management and Thermal Control, Tracing, VFIO/IOMMU/PCI, Live Patching, Rust and Internet of Things.

Due to the number of parallel tracks and Microconferences with a high number of interesting topics, it’s quite impossible to attend all the talks one would like.

Here are just a few that I was able to attend.

Resolve and standardize early access to hardware for automotive industry with Linux

Khasim Syed Mohammed, Texas Instruments

SoC manufacturers are adopting heterogeneous architectures, using MCU cores for safety-critical tasks with RTOS and MPU running Linux for general purpose. Key use cases in the automotive industry, such as quick boot times, early display response, and predictable access to hardware, pose challenges for Linux-based systems. The current solutions of employing heterogeneous processors lack scalability, standardization, and Linux friendliness.

Khasim explored the specific challenges faced by the automotive industry and the existing solutions, addressing the standardization of “Linux late attach” with heterogeneous SoCs. He invited collaboration between automotive OEMs, SoC manufacturers, and Linux kernel/user space maintainers to establish “Linux automotive” standards, enhance the Linux kernel and drivers to meet performance requirements.

Securing build platforms

Joshua Lock, Verizon

Historically, Open Source Software was always built on trust – you trusted the sources, the recipe, the builder to produce the resulting artifacts for a given distro that many use. But with a growing number of attacks on the software supply chain, securing build platforms and providing a verifiable way to link packages back to their sources, as well as specific build instructions used to package and publish them, is becoming very important these days.

Joshua listed several of the big and famous recent supply chain attacks and talked about build provenance being adopted by different players in this field to battle such attacks. He then delved into adoption of the Supply-chain Levels for Software Artifacts, or SLSA (“salsa”) architecture in the Yocto Project and its Autobuilder CI framework – generating provenance during the build as L1 level requirement and signing said provenance at L2 level. While this definitely helps with detecting such attacks, fully securing the software supply chain needs more work.

Improving UAPI Compatibility Review with Automated Tooling

John Moon, Qualcomm

Preserving Linux Userspace API (UAPI) compatibility has been crucial for enabling smooth kernel upgrades without breaking userspace programs. Traditionally, kernel devs relied on code review and testing to catch UAPI-breaking changes.

John showed a new tool they developed at Qualcomm that uses libabigail, letting developers analyze patches for UAPI issues before executing them. This tool could integrate into build systems like OpenEmbedded and the Yocto Project, providing immediate feedback and solidifying the kernel’s UAPI stability policy.

The talk also delved into other interfaces like sysfs and module parameters. However, since libabigail can’t analyze these interfaces directly due to the lack of a clean C API, a couple proposals were presented and sparked a lively discussion with Greg KH and other attendees.

kernel: build system outputs and workflows (and how to balance them)

Bruce Ashfield, AMD

Bruce talked about all the complexities around maintaining and building the Linux kernel in OpenEmbedded and the Yocto Project. All the various inputs, such as vendor BSPs vs. upstream mainline kernel, latest version vs. LTS, different patches, configurations, policies, etc. It gets complicated by additional product requirements, like reproducibility, flexibility, maintenance and support, build speed and so on. And the variety of output end results only adds overhead, when one has to deal with kernel images, modules, DTBs, firmware images, binary packages, debug information, licensing, SBoM manifests, CVE reports, boot components, containers and VMs, SDKs, libc headers, etc. It also differs a bit based on the persona or workflow of one’s building the kernel – developer (kernel vs. userspace), integrator, distributor, contributor or a release engineer.

Trying to keep everyone happy at the same time is almost impossible. Still, linux-yocto, the reference kernel in OpenEmbedded-Core, tries to cover most of the bases and solve as many of the outlined challenges. Bruce talked a bit more about how he maintains linux-yocto, how things are improving over time, where we are heading and opened the floor to discussion.

How big of a problem are Un-upstreamed patches?

Jon Mason, ARM

Build Systems and Distros accumulate local changes against individual components in the form of patches that either fix newly found issues or customize component’s behavior to suit their own requirements. How should those patches be handled and what to do with them? Upstreaming them to be integrated into the future releases of corresponding components is, of course, the best approach. What if it’s not possible or doesn’t happen for other reasons? Is there any structure or process for that? Jon looked at these problems and tried answering the questions from the perspective of the Yocto Project, Buildroot, Debian and other distros.

Building for Heterogeneous Systems

Alejandro Hernandez Samaniego, Microsoft

Heterogeneous systems are widely used in embedded products for better performance, safety, etc. While using different operating systems on various core architectures in a single device is beneficial, each OS has unique dependencies and developer workflows. To optimize development, a single build system should be able to cross-compile different OSs for different architectures simultaneously and Bitbake offers this through its multiconfig feature. Unifying the developer workflow and enhancing the usability of features like multiconfig would significantly improve teams efforts in creating new products.

Alejandro went over examples of setting up multiconfig in the Yocto Project for building bare metal and/or RTOS components along with the general purpose LInux system and integrating final results into a single filesystem image. At the end we discussed some of the remaining challenges and open defects with some of the aspects of multiconfig, like separating temp directories, SDK coverage, etc.

A kernel documentation update

Jonathan Corbet, LWN.net

Jonathan provided an update on the recent changes in the Linux kernel documentation – restructuring of architecture-specific docs, new Rust documentation, added new translations, new theme for HTML-rendered pages, texinfo support, lots of new docs were added, rework of the top-level index.rst, etc. He also commented on some of the future plans, such as reworking of device-related docs, which are now spanned across 31 subdirectories, and adding more structure to the rest of areas in the documentation.

A lively debate was sparked around plain text vs. HTML and format of the docs in general, e.g. plain text is still preferred by some kernel maintainers over HTML, but adding RST markup to the input text files makes them less readable. Sphinx and tooling were then discussed, build-time improvements, support for partial builds to speed things up, etc.

Embedded Linux BoF

Tim Bird, Sony

Tim led an open discussion session covering different aspects of embedded Linux, such as Architectures, Bootloaders, Boot time, Filesystems, Networking, Security, Testing, Tools, Toolchains, Tracing, System Size and Build Tools and Distros. He mentioned latest updates to U-boot, referenced earlier talk by Khasim on reducing boot time by offloading some tasks to MCUs and deferring non-critical device probing to later time in user-space.

For size reduction he listed removal of SLOB and planned removal of SLAB. But as Arnd Bergmann, kernel developer and arm-soc tree maintainer commented, system size may no longer be relevant, as memory becomes cheaper and ARM manufacturers actively switching from 32-bit to 64-bit solutions, while small footprint systems are relegated to Zephyr. On the other hand, nolibc allows building very small statically-linked binaries for Linux.

Finishing up with closing remarks about the Embedded Linux Community with shoutouts for mailing lists, different Organizations and Projects operating in this field, popular upcoming events and the state of eLinux wiki losing its funding soon.

Zephyr Retro-and-Prospective: Project Growth, Long Term Support, and Linux Interoperability

Chris Friedt, Meta

Chris’ lightning talk quickly went over Zephyr’s brief, but very rich and rapidly-changing history. Added new architectures, 64-bit support, new protocols, new boards, Device Tree API, TF-M, LLVM and other toolchains, Power Management, USB-C/PD, DSP subsystem and many more features and improvements. Many bugs were fixed, new maintainers and contributors joined. All in all Zephyr enjoyed tremendous growth in recent years.

Challenges in Device Tree Sync – kernel, Zephyr, U-boot, System DT

Nishanth Menon, Texas Instruments

These days Device Tree is commonly used to describe the hardware in different ecosystems, such as Linux kernel, U-boot and Zephyr. But each ecosystem has its own goals and limitations and along with limited standardization of Device Tree description of hardware that results in very different user/developer experiences and challenges keeping them in sync.

With a BeaglePlay board using TI AM625 heterogeneous SoC, Nishanth was hoping to blink one LED from A53 core running Linux and blink another LED from M4F core running Zephyr, all described by the same Device Tree. But it wasn’t as simple – he showed examples of different Device Trees describing the same hardware from the perspective of Linux kernel, U-boot bootloader and Zephyr RTOS. The Linux kernel has A53-centric view, while U-boot also focuses on R5F core taking care of the initial boot, along with binman and bootph specifics, where Zephyr diverges from both of them due to its focus on performance and resource constraints, utilizing C headers generated from the Device Tree.

There are some other differences between ecosystems using Device Tree, such as licensing, bindings, firmware usage and tooling. But one of the proposed solutions to unify the above inconsistencies was a lopper tool and the use of a common/canonical System Device Tree with personality overlays that produces required device-specific views.

Konsulko Group engineer to speak at Yocto Project Summit

Konsulko Group senior engineer Leon Anavi will be presenting at the Yocto Project Virtual Summit, Tuesday, November 28 through Thursday, November 30, 2023.

Formerly known as the Yocto Project Developer Day, the Summit has an expanded scope to include both workshops for engineers building customized Linux distributions and applications, as well as an open forum where maintainers, trainers and users present papers on how the project is evolving and how they are using it.

On Wednesday, November 29, Leon will present Integrating VNC in Weston with the Yocto Project and OpenEmbedded. Weston 12 introduces Virtual Network Computing (VNC) support, allowing remote connection and control through graphical desktop sharing.

Leon will examine the technical aspects — dependance on Neat VNC and AML libraries, TLS support and user authentication — followed by a step by step tutorial to demonstrate remote connection from another computer.

The presentation aims to simplify the process of setting up the VNC backend in Weston and empower developers to utilize this powerful feature seamlessly within their projects.

We hope you will join us for this presentation, and all of this new edition of Yocto Project Virtual Summit.

Helping Yocto Project secure important new funding from STF

Yocto Project has received major funding from the Sovereign Tech Fund to aid and drive significant transformation. The funded work improves the long-term sustainability of the project by attracting a new generation of developers.

Konsulko Group is proud of the work done by principal engineer Denys Dmytriyenko and the Yocto Project Technical Steering Committee to help secure the funding. Together, they spent many hours over several months to identify development areas that can be self-contained and measured, then estimated required efforts for the proposal so the funding might be approved.

The work the Sovereign Tech Fund (STF) is commissioning aims to improve the Yocto Project’s efficiency, security, user experience, and developer engagement in these specific areas:

Build Process and Workflow

  • Core workflow improvements, including enhancements to build tooling and workflows.
  • Development of the Yocto Project Reference Binary Distribution, focusing on workflow improvements and policies.
  • Introduction of Patchtest, an automated testing tool for code patches submitted via mailing lists.

Security and Quality Improvements

  • Strengthening security processes and the security team.
  • Advancing Software Bill of Materials (SBOMs) for improved transparency.
  • Addressing tooling issues and enhancing quality-of-life features in Devtool, Recipetool, and Pseudo.

Integration and Usability Enhancements

  • Updates and improvements to Toaster, a web-based UI for BitBake.
  • Integration of VSCode with Yocto Project for enhanced developer features and usability.

Layer Management Standardization

  • Integration of OpenEmbedded Core best practices into Meta-OpenEmbedded.
  • Development of standard tools for managing Yocto layers, promoting layer tooling standardization.

STF is funded by the German Federal Ministry of Economics and Climate Action (BMWK) and supported by the German Federal Agency for Disruptive Innovation GmbH (SPRIND).

Konsulko Group in Paris at Embedded Recipes 2023

Three Konsulko engineers traveled to Paris (left to right, in créatif senior Frank Tizzoni‘s great caricature): António Oliveira came from Portugal, Darko Alavanja from Serbia, Scott Murray from Canada.

Embedded Recipes was held over two days in late September at Fondation Biermans Lapotre. The event had a nice format: single room, single track. That meant everyone stayed together for its duration which made it easier to meet people.

We talked a little about everything: kernel internals, prototyping tools, software updates, Yocto Project, machine learning…

Scott gave a nice overview of the Automotive Grade Linux project, its history, current work and future plans.

Konsulko Group a sponsor of Embedded Recipes 2023 in Paris

Now in its fifth edition, Embedded Recipes is a small, technically-focused, informal conference about embedded software and hardware, held in Paris, France on September 28 and 29, 2023.

With two days, 15+ presentations and lightning talks, Embedded Recipes takes a deep dive into the developments, contributions, tools and platforms that Open Source developers use to create solutions.

Konsulko Group is proud to be a supporter sponsor of Embedded Recipes 2023. We hope you will join our engineers, together with some of the main contributors of the embedded world from throughout Europe and North America, at the Fondation Biermans Lapotre in Paris for this event.

Konsulko Group updates Embedded Linux devices at TuxCon 2023

Held on June 10th and 11th, 2023 in the beautiful city of Plovdiv (Bulgaria), TuxCon 2023 marked the 10th anniversary of this annual local two-day conference. Organized by dedicated volunteers, the event aims to advocate the adoption of open source hardware and foster the use of free and open source software.

Konsulko Group intern Atanas Bunchev participated as a speaker, and demonstrated remote updates and troubleshooting of connected embedded Linux devices using Mender.io. The presentation was in Bulgarian and spread the word about the Yocto Project, OpenEmbedded and various Mender features among the local community.

Mender is an open-source, over-the-air (OTA) software update management platform specifically designed for embedded devices. It provides an efficient way for software updates and management of fleets of connected devices in various industries, such as IoT (Internet of Things), automotive, industrial automation, and healthcare. It provides options for ensuring the resilience of system-wide updates and also for updating individual applications. Furthermore debugging of devices is possible with the troubleshooting package, such as the File Transfer and Remote Terminal Add-ons.

Konsulko Group, a partner of Northern.tech, often works with Mender.io. If you are developing a new product, we would be thrilled to discuss how Konsulko’s engineering expertise and experience can contribute to your project. Or if you are a Linux software developer who is passionate about open source, we invite you to reach out to us regarding potential opportunities to join the Konsulko team.

Tag Archive for: konsulko group