Posts

TL;DR: bakar is a Python CLI that wraps kas and kas-container for Yocto Board Support Package (BSP) builds. It defaults to container builds via kas-container when KAS_CONTAINER_IMAGE is set, and falls back to plain kas on the host when it is not. Pass --host to any subcommand to force host mode. On top of kas, bakar adds pre-flight environment checks before the build starts, applies a curated tuning overlay (ccache, fetch mirrors, reproducibility knobs) without modifying your YAML on disk, writes structured per-run logs, and provides bakar triage to locate the failing recipe after a crash. For vendor BSPs that ship as repo manifests (NXP i.MX) or oe-layertool configs (TI Sitara), it translates those to kas YAMLs automatically. For projects initialized with bitbake-setup (the official Yocto 5.3+ workspace tool), bakar detects the workspace automatically, translates the JSON layer config to a kas YAML, and drives the same pipeline. Install: uv tool install bakar. ...

Two FOSDEM 2026 talks on the Cyber Resilience Act caught my attention when I watched the recordings. One came from two German IT lawyers - Anika Niemann and Florian Hackel - who spent twenty minutes walking an audience of open source developers through how to think about CRA compliance from a manufacturer’s perspective. The other came from the European Commission itself, joined on stage by representatives from CEN-CENELEC, ETSI, and the German BSI. ...

If you followed the Intel IPU6 webcam migration post, you know that libcamera’s Simple IPA falls back to uncalibrated.yaml when no sensor-specific tuning file exists. That fallback enables AGC and AWB but has no color correction matrix, which means colors depend entirely on the grey world AWB algorithm to converge - and it often does not converge well, especially under mixed or warm lighting. Intel ships a per-sensor calibration binary with every Windows IPU6 camera driver: a file with the .aiqb extension, sometimes called a CPFF. These binaries contain the CCMs, AWB neutral locus, and sensor properties that Intel’s proprietary icamerasrc pipeline reads. The data was measured on real hardware, which makes it more accurate than any generic default. ...

Every Yocto user eventually copies the same handful of tunables into local.conf to make builds bearable. ccache, a parallelism bump, a longer fetch timeout, a couple of PREMIRROR lines, an image-features prune. The recipe gets passed around in chat, lands on a wiki, gets forked into a layer. What rarely gets passed around is the failure mode each line buys you. Every one of these knobs swaps “slow” for “different failure mode”, and the new mode shows up at the worst possible time - mid-fetch on a CI runner, or at link time when the box runs out of memory. ...

Today, April 27, marks exactly one month since I was told my job was over. Looking back, the signs were there - when the mass layoffs started and good people began disappearing, it was hard not to read it as a signal that nobody was safe, including me. And yet, when the moment actually came, it still landed differently than I expected. That gap between knowing it is possible and having it happen to you is where the shock lives. Do not be surprised by it. It does not mean you were naive or unprepared. It means you are human. ...

TL;DR CRA is a process and design regulation; the risk analysis is the central document and the technical file is the evidence the regulator audits, not a scanner-selection problem. Yocto already emits the build-derivable half: SBOM (create-spdx), CVE scans, license manifests, signing posture. The vendor-committed half - CVD policy, support period, update mechanism, Declaration of Conformity - has to be written by hand. shipcheck reads a Yocto build plus product.yaml, pivots findings by CRA Annex, and drafts your Annex VII technical file and DoC. The received wisdom is wrong Read any CRA compliance article from a security vendor and you will see the same shape of pitch: run a scanner, triage the CVEs, generate an SBOM, ship. The regulation becomes a scanner-selection problem, and whichever product the vendor sells happens to be the right scanner. ...

At the end of March 2026 I was laid off from Linaro as part of a round of cuts. After 3.5 years working on upstream kernel enablement, embedded security, and CI/CD infrastructure for ARM-based platforms, it came as a surprise - but I am using the time well. What I have been doing since The upstream work did not stop. I currently have three active patch series under review: An 18-patch WiFi 7 series on linux-wireless@ adding full support for the MediaTek MT7927 (Filogic 380) to the mt76/mt7925 driver. The series is at v4, community-tested across 10+ hardware platforms with 9 Tested-by tags from ASUS, Lenovo, Foxconn, and AMD. Phoronix covered it: MediaTek MT7927 WiFi 7 Linux Support Coming Together. ...

In my previous post, I ended with a wall: mt7925e 0000:0b:00.0: ASIC revision: 0000 mt7925e 0000:0b:00.0: Message 00000010 (seq 2) timeout mt7925e 0000:0b:00.0: Failed to get patch semaphore mt7925e 0000:0b:00.0: hardware init failed The mt7925e driver bound to the MT7927’s WiFi hardware, but registers returned zeros. The chip sat behind PCIe doing nothing. The ehausig/mt7927 project had gotten firmware into kernel memory but stalled at DMA state 0xffff10f1 - “waiting for firmware transfer.” Nobody had gotten past it. ...

In Part 1, I documented getting MT7927 Bluetooth working through a DKMS package - patching three missing layers (USB device ID, hardware variant support, and firmware) into an out-of-tree build. That post ended with: As of February 2026, none of the three layers have reached mainline Linux. This post covers what happened next: submitting all three layers upstream and getting the BT driver patches merged after five revision cycles. Update (2026-03-31): The BT driver patches have been merged into bluetooth-next by Luiz Augusto von Dentz. They will ship in mainline Linux 7.1 or 7.2. ...

Three devices on my PC have firmware that can only be updated through Windows tools: an ASMedia ASM4242 USB4 controller (ASUS firmware utility), an NZXT Kraken Elite AIO cooler (NZXT CAM), and a Razer Kiyo Pro Ultra webcam (Razer Synapse). Every other component - NVMe SSD, motherboard BIOS, fwupd-supported devices - has a Linux-native update path. These three don’t, and their vendors show no interest in changing that. The obvious answer is “just boot Windows.” But I don’t have a Windows partition, don’t want one, and installing Windows to flash three firmware blobs is absurd. I needed a way to boot a fully configured Windows environment from Linux, run the vendor tools, and shut down. No permanent installation, no dual-boot, no repartitioning. ...