Kernel & Embedded News: U-Boot 2026.10 Released; Meta Proposes CRAM

This edition covers movement in the infrastructure that embedded Linux work stands on: the bootloader, the memory subsystem, SoC upstreaming, the Arm architecture, and the kernel’s security process. None of the five items is an urgent fix. Each one changes something you plan around – release cadence, memory cost, platform support, or patch volume.

In this edition

• U-Boot v2026.10 released. The autumn release shipped on schedule on 5 October, with dm-verity root-hash authentication in FIT images and the release process now running fully on the project’s own infrastructure. – adopt for new bring-up
• Meta proposes CRAM, a compressed-RAM service for the kernel. Kernel management for hardware that stores memory compressed and presents more capacity than it physically has, presented at Linux Plumbers Conference. – long-term watch
• Pixel 10 device trees head toward mainline Linux 7.4. Peter Griffin’s Laguna/Tensor G5 series brings Google’s current phones to the point of booting a mainline kernel. – planning signal
• Arm posts first Linux patches for TLBI Domains. A new architecture capability that limits TLB-invalidation broadcast to the cores that need it, aimed at high core counts. – architecture watch
• The kernel’s security process adapts to AI-scale bug reporting. Greg Kroah-Hartman’s Kernel Recipes talk puts numbers on CVE growth and describes how the stable team is coping. – adjust your triage

U-Boot v2026.10: dm-verity reaches FIT images, and the migration is complete

Tom Rini released U-Boot v2026.10 on 5 October, on the exact date the release schedule named. The 15 September edition covered this cycle at rc4, together with the project’s move off its long-time denx.de hosting; the final release closes both stories.

The announcement lists platform additions, subsystem-wide fixes, and cleanups in command handling and FIT image code. Two entries matter directly for products. FIT images can now authenticate a dm-verity root hash. And a fix removes the spurious ERROR messages about reserved-memory regions that some platforms printed at every boot – cosmetic, but easy to mistake for a real failure.

The dm-verity change is the one to study. A typical verified-boot chain on an embedded product authenticates the FIT image – kernel, device tree, ramdisk – and then handles root-filesystem integrity separately, passing the dm-verity root hash on the kernel command line or in vendor-specific glue. Authenticating the root hash as part of the FIT closes that seam: the same signature that covers the kernel now covers the statement of what the root filesystem must hash to.

This is also the first full release published entirely from project-owned infrastructure, with release archives served from the project GitLab at git.u-boot-project.org. The next cycle starts immediately: the v2027.01 merge window closes on 26 October, with the release planned for 4 January 2027.

How to use it

Start new board bring-up on v2026.10 rather than on a mid-cycle snapshot, and treat the quarterly release as your sync point. Check that build scripts, mirrors and SBOM references point at the new hosting rather than at denx.de paths. If your product chains FIT authentication into a dm-verity rootfs with custom glue, evaluate the new root-hash authentication as a replacement – upstream-maintained verification logic is cheaper to carry than your own.

CRAM: Meta wants the kernel to manage hardware-compressed RAM

At Linux Plumbers Conference in Prague (5-7 October), Gregory Price of Meta presented “A Compressed RAM Service”: kernel support for memory devices that store their contents compressed in hardware and present more capacity than they physically carry. Unlike zram and zswap, where compressed data lives in a software pool and every access costs a fault plus decompression, these devices serve ordinary cacheline reads and writes against compressed data, and Price’s experimental implementation runs standard benchmarks at close to raw DRAM speed.

The hard problem is that the kernel assumes a page of memory is a page of capacity. On a compressed device, real capacity depends on how compressible the resident data is, and it changes as the data changes. The talk examined seven existing kernel mechanisms that help manage this – memory tiering, page-table write protection and ballooning among them – and how they combine into a usable service.

The work has a longer history on the list than the talk suggests. A February RFC included an mm/cram subsystem managing folios demoted to private memory nodes: pages are write-protected to preserve compression ratios, watermark-based backpressure halts demotion when the device fills, and a write fault promotes the page back to ordinary DRAM. By the July reposting the base infrastructure had been renamed Private Memory NUMA Nodes, a 36-patch series, with the CRAM module split out for separate submission. Engineers from other companies have already asked for a testable CRAM module for compression-capable CXL expander hardware, so the interest extends beyond one fleet.

The motivation is plainly stated: memory prices. The same pressure produced a zram rework the same week, and compressed capacity is becoming a planned tier in server fleets rather than an emergency measure.

What it means for memory-constrained devices

Embedded products will not see CXL compressed-memory expanders in this product generation; zram and zswap remain the right tools where RAM is tight. The piece worth tracking is the private memory node infrastructure underneath: a general way to represent memory the allocator must not treat as ordinary capacity. That abstraction is relevant to SoCs with device-managed or reclaimable carveouts, independent of compression hardware. If DRAM cost shapes your product’s bill of materials, follow this work – hardware compression changes capacity planning one level above the kernel.

Pixel 10 device trees head for mainline

Peter Griffin of Linaro, who maintains the upstream Google Tensor platform support and wrote the original Pixel 6 (gs101) mainline series, has been submitting device tree support for the Tensor G5 – codename Laguna – and the three Pixel 10 models: frankel (Pixel 10), blazer (Pixel 10 Pro) and mustang (Pixel 10 Pro XL). The series first appeared in late 2025 and has been revised through 2026: bindings, a dts directory for Google-designed silicon, the board device trees and defconfig enablement. The support is expected to land during the Linux 7.4 merge window, which opens once 7.3 ships in mid-October.

The scope is bring-up, not daily use: the device trees boot a mainline kernel to an initramfs BusyBox shell over UART, and ramoops crash logging works. That is the normal first step for any new SoC family. Tensor G5 is Google’s first TSMC-manufactured Tensor, with Cortex-X4, A725 and A520 CPU clusters and Imagination graphics, so this series puts current-generation phone silicon through mainline review rather than hardware that is already several years old.

The significance is the trajectory. Mainline support for the Pixel 6 generation arrived years after launch; Pixel 10 device trees are in review within months of the phones shipping. Mainline presence for current silicon reduces the long-term cost of every downstream kernel the platform carries, and it shows which vendors treat upstream as part of the product.

What it means for Android-based products

If you select SoCs for Android or AOSP-derived products, treat upstream device-tree presence as a supportability signal alongside the BSP contract – it predicts how much of your platform survives a kernel migration. For engineers learning phone-class bring-up, this series is a current, actively reviewed example of how to structure SoC and board device trees for a new silicon family; read it alongside the gs101 history.

Arm posts first Linux patches for TLBI Domains

Arm engineers have posted initial Linux enablement patches for TLBI Domains, the architecture feature FEAT_TLBID. The idea: let the operating system scope a TLB invalidation to a domain of cores instead of broadcasting it to every core in the system. On arm64, TLB invalidation is broadcast in hardware, and its cost grows with core count; on large systems, unmap-heavy workloads spend measurable time waiting for invalidations to complete on cores that never touched the address space.

The feature is early. It has not yet appeared in the published Arm Architecture Reference Manual, and no performance numbers have been published for the Linux patches. The toolchain moved first: binutils gained a +tlbid extension in January, adjusting the operand rules of the TLBI and TLBIP instruction families. No announced core implements the feature yet.

The pattern is familiar from TLBIOS and TLBI range instructions in Armv8.4: the architecture defines the capability, toolchains and kernel enablement land one to three years before silicon, and the benefit arrives only when both meet.

What it means for arm64 platforms

There is nothing to apply or configure today. Teams building many-core arm64 systems – networking, storage, dense edge servers – should track the series, because TLB-invalidation overhead is one of the costs that scales worst with core count. When hardware arrives, the kernel will use the feature transparently; applications do not change. For typical embedded SoCs with four to eight cores the gain will be small.

The kernel’s security process meets the AI flood

At Kernel Recipes in Paris in late September, Greg Kroah-Hartman presented the numbers behind a shift every kernel consumer has felt. His data: roughly 500 CVEs per release through the 6.9 to 6.19 era, and over 1,000 per release since 7.0. Linux 7.2 crossed 1,500 assigned CVEs in a single cycle, three times the volume that was normal through the 6.x series, and the growth comes from AI tools analyzing the codebase rather than from new code. Most of the AI-found issues are real but low severity, concentrated in old and obscure driver code.

The change is visible at every stage of the process now. Linus Torvalds described 7.3-rc6, released on 4 October, as normal “for the new ‘AI normal'”, with elevated counts of small error-path fixes. On the review side, Roman Gushchin published an update on Sashiko, an LLM-based review system now in use on kernel patches. Intake, review and fix volume are all adjusting to the same force, and the AGENTS.md discussion covered in the 29 September edition is part of the same adjustment.

CVE volume at this level means a per-CVE review process cannot be staffed, and a compliance posture that opens a ticket per kernel CVE stops working.

What it means for your patch process

Stop using CVE counts as a severity signal in reports and dashboards; the count now measures analysis activity, not risk. Filter first by the files your configuration builds, then triage what remains – the method described in our guide to reading stable kernel CVE announcements. Expect stable releases to stay large, and size update-validation effort from the last quarter’s observed volume. A documented filter, applied consistently, is a defensible process; an unfiltered backlog is not.

References

• U-Boot v2026.10 release announcement
• U-Boot release cycle (v2027.01 schedule)
• LPC 2026: A Compressed RAM Service (talk page)
• RFC: mm/cram compressed ram memory management subsystem
• PATCH v2: Add Laguna/Tensor G5 SoC and Frankel, Blazer & Mustang boards
• Phoronix: Linux 7.4 to mainline Google Tensor G5, Pixel 10 support
• binutils: aarch64 support for FEAT_TLBID
• Phoronix: Arm working on TLBID for Linux
• LWN: Coping with the onslaught of kernel security bugs (subscriber link)
• Phoronix: The Linux kernel is approaching 2,000 CVEs per release

— Raghu Bharadwaj