Kernel & Embedded News: Linux 7.2 EOL; Yocto 6.1 Blacksail Ships

This edition is about maintenance boundaries. The Linux 7.2 EOL closes one kernel branch, one build-system release arrived with real migration work attached, and the 7.4 merge window settled parts of the baseline that 2027 products will inherit. The two hardware announcements show where edge AI accelerators and SBC storage are heading.

In this edition

• Linux 7.2.y is end-of-life. 7.2.15 is the final release of the series, and Greg Kroah-Hartman has asked users to move to 7.3.y. — act now
• Yocto Project 6.1 Blacksail released. Strict SPDX LICENSE values, offline SBOM-based CVE checking and a kernel 7.2 reference, supported until April 2027. — plan the migration
• EEVDF short-slice latency work lands in 7.4. Vincent Guittot’s series makes tasks that request short scheduling slices wait less behind long-slice tasks. — evaluate on rc kernels
• Google Tensor G5 and the Pixel 10 reach mainline. Linux 7.4 adds an ARCH_GOOGLE platform and minimal device trees for the Pixel 10 family. — planning signal
• BrainChip ships an AKD1500 Raspberry Pi 5 kit. A 1,295-dollar bundle for event-based neuromorphic inference with on-device learning. — evaluate
• Banana Pi BPI-M8 brings UFS to a low-cost board. Allwinner A733, LPDDR5 and a UFS module socket, but no OS images published yet. — watch

Linux 7.2.y is end-of-life; 7.2.15 is the last release

On 1 November, Greg Kroah-Hartman released Linux 7.2.15 and closed the series, stating plainly that this is the last 7.2.y release and that the tree is now end-of-life. His advice to users is direct: “Please move to 7.3.y at this time.” The front page of kernel.org already marks 7.2.15 with the EOL label, and 7.3.1 has been available since 30 October, so there is a maintained destination ready.

The Linux 7.2 EOL is routine in kernel terms: a stable series that is not selected for long-term support is maintained only until shortly after the next mainline release, and 7.3 shipped on 18 October. Routine or not, this pattern keeps catching teams who adopted the newest stable series for hardware enablement and then discovered its support window measured in weeks.

If a shipping device tracks 7.2.y, it stops receiving security and bug fixes from this point, and the move needs to be scheduled now rather than at the next planned release. There are two reasonable destinations. Moving to 7.3.y keeps the newest code but inherits the same short support window, since 7.3.y will in turn be maintained only until a few weeks after 7.4 ships, which is expected in late December. Moving to an LTS trades recency for a longer support window: 6.18.y and 6.12.y are projected to December 2028, and 6.6.y and 6.1.y to December 2027.

One more date in the same table deserves attention: 5.15.y and 5.10.y are both projected to end in December 2026, so devices still on them have weeks, not quarters, to plan an exit. If the usual end-of-year pattern holds, 7.4 will become the 2026 long-term kernel after it ships — an expectation, not yet an announcement.

What the Linux 7.2 EOL means for BSP teams

• Confirm what every shipping product actually runs. Anything on 7.2.y moves now; anything on 5.15.y or 5.10.y needs a funded migration plan this quarter.
• Standardise products on an LTS series and treat non-LTS stable kernels as development vehicles; 7.2 lived about three months, shorter than most QA cycles.
• Hold a decision point for when 7.4 ships: if it is confirmed LTS, it becomes the default base for 2027 platform work.

Yocto Project 6.1 Blacksail: strict SPDX licences and offline SBOM checks

The Yocto Project announced release 6.1, codename Blacksail, on 21 October through build and release engineer Lee Chee Yang; the 21 October edition had noted it as due. The baseline: a Linux 7.2 reference kernel, gcc 16.2, glibc 2.44, LLVM 23.1.1 and over 300 other recipe upgrades, with Python 3.9 the minimum on the build host and OLDEST_KERNEL set to 5.15. Blacksail is a standard release supported until April 2027; the LTS releases remain Wrynose 6.0 (April 2030) and Scarthgap 5.0 (April 2028).

The migration item that will touch the most layers is licensing. LICENSE is now interpreted as a strict SPDX licence expression: & becomes AND, | becomes OR, non-SPDX values are errors, PD is no longer allowed and CLOSED is deprecated. Licence exceptions must use WITH, and GPLv3-class exceptions must be listed in INCOMPATIBLE_LICENSE_EXCEPTIONS or they will match INCOMPATIBLE_LICENSE. Old syntax still converts with warnings in this release; use that window to fix layers before the warnings become errors.

The security workflow continues its move onto SBOM foundations. The sbom-cve-check tooling gains an offline mode for build environments without network access, and the linux-yocto recipe has dropped its manually maintained CVE exclusion list because the SBOM-based checker derives that information itself. On the kernel side, module tarball deployment is now off by default, the kernel FIT image class gains signing-key validation and PKCS #11 friendly handling, Clang toolchain support reaches kernel builds, and new packagegroups cover building Rust kernel modules on target or in the SDK.

One fact worth stating in any compliance review: Blacksail’s reference kernel is 7.2, the same series mainline just closed. The linux-yocto kernel is maintained by the Yocto kernel team on its own branches, so this is not an emergency, but teams should be able to explain where their kernel fixes come from once upstream stable releases stop.

How to use it

Products should stay on Scarthgap or Wrynose. The practical use of Blacksail today is a rehearsal: run one build of your layers against it in CI and collect the SPDX licence warnings while they are still warnings. A first pass over a layer takes one search:

raghu@techveda.org:~$ grep -rn --include='*.bb*' -E 'LICENSE *= *"[^"]*[&|]' ../meta-custom/

Fix the operator spellings and the PD/CLOSED values now, and the next LTS migration loses its largest mechanical part. If your build hosts are network-restricted, the offline mode of the SBOM-based CVE checking is the feature to pilot.

Linux 7.4 cuts queueing delay for short-slice tasks in EEVDF

The scheduler pull for 7.4, merged on 20 October, carries a series by Vincent Guittot of Linaro that changes how the EEVDF scheduler treats tasks that request a short scheduling slice through sched_setattr(). The previous edition covered the first week of this merge window; this item landed in the same window’s scheduler pull.

The mechanism is specific. EEVDF protects a running task’s slice from preemption; until now that protection could make a newly woken short-slice task wait out full slices of other tasks.

The merged commits narrow the protection: when a task with a shorter slice is enqueued, the running longer-slice task is protected only until it becomes ineligible rather than for its full slice, and the protection is cancelled outright when an eligible short-slice task is waiting. A companion change stops delayed-dequeue tasks from preempting. Secondary coverage attaches large percentage improvements to this work, but the merged commit messages carry no benchmark figures, so measure on your own workload rather than quoting a number.

This matters to embedded teams running latency-sensitive work in the fair class — audio paths, soft control loops, media pipelines — where a short custom slice is the tuning option that avoids promoting everything to SCHED_FIFO. It is still fair-class latency work, not determinism: nothing here changes what PREEMPT_RT exists to guarantee. The same pull also adds Shrikanth Hegde’s steal governor, which backs vCPUs off based on steal time and is relevant to virtualised edge deployments, and continues the long-range proxy-execution work led by John Stultz.

How to evaluate it on your workload

• If your software sets custom slices via sched_setattr(), run your own wakeup-latency probe on a 7.4 release candidate and compare against your current kernel before adopting any claimed figures.
• If you have been considering a move from tuned SCHED_OTHER to SCHED_FIFO purely for queueing-delay reasons, re-test on 7.4 first; the cheaper option may now be sufficient.
• Keep hard-deadline work on PREEMPT_RT plus explicit real-time policy; this change does not alter worst-case behaviour.

Google Tensor G5 and the Pixel 10 arrive in mainline

Linux 7.4 adds a new arm64 platform, ARCH_GOOGLE, for Google-designed SoCs. The Kconfig help text is explicit about the boundary: support starts at the Tensor G5, codename Laguna, found in the Pixel 10 family, while Tensor G1 through G4 remain under ARCH_EXYNOS because they are Samsung Exynos derivatives. The device trees, written by Peter Griffin and pulled into the SoC tree by platform maintainer Krzysztof Kozlowski, cover the SoC (lga.dtsi) and three phones: frankel (Pixel 10), blazer (Pixel 10 Pro) and mustang (Pixel 10 Pro XL).

The initial scope is deliberately minimal: CPU topology and idle states, the interrupt controller, the architected timer, a UART console, and reserved-memory regions including one for ramoops crash logs. That is enough to boot mainline to a BusyBox shell from an initramfs. Storage, display, USB and connectivity are not yet described, so this is a developer bring-up, not an alternative operating system for a phone.

The significance is the trend it marks. Google has historically kept Pixel kernels downstream, built on the Android common kernel with GKI and vendor hooks; mainlining its own silicon under its own platform entry is a commitment of maintainer attention that vendors rarely make without intent. The bring-up order on display — console first, the smallest possible device tree, everything else later — is also exactly the discipline of any board bring-up, and makes a good reference to study.

What it means for Android and BSP teams

• Do not plan products around running mainline on Pixel hardware; the enabled feature set is a serial console and a shell.
• Do treat the lga device trees as reference code for clean minimal bring-up, and as a current example of how a large vendor structures a new ARCH_* submission.
• When negotiating upstreaming commitments with SoC vendors, cite this precedent: the owner of the largest downstream Android kernel investment is paying the mainline cost for its newest SoC.

BrainChip packages the AKD1500 with a Raspberry Pi 5

BrainChip announced an AKD1500 Raspberry Pi 5 development kit on 29 October, priced at 1,295 dollars: a Raspberry Pi 5 with 8 GB of RAM, the official M.2 HAT+, an Akida AKD1500 M.2 card, a metal case and a preloaded 32 GB SD card. A browser-based launcher serves person-presence, object-detection and classification demos; the required USB camera is not included.

The interesting part is the compute model rather than the packaging. Akida is event-based, neuromorphic hardware: it processes sparse activation events rather than dense tensor batches, which is why its power draw on intermittent workloads can undercut conventional NPUs. It also supports on-device learning, so a deployed model can be taught additional classes without a cloud retraining round trip. The cost of that difference is the toolchain: models reach the chip through BrainChip’s MetaTF conversion flow, not through a drop-in ONNX or TFLite path.

Judged as hardware, the kit is expensive: every component in it is available separately for a fraction of the price. Judged as an evaluation vehicle, the premium buys an assembled, preconfigured unit that demonstrates something in the first hour. The deciding question is not the demos, which favour the architecture, but whether your own model survives conversion with acceptable accuracy.

How to evaluate it

• Treat the kit as evaluation hardware, and push your own model through MetaTF conversion early in the evaluation window — conversion feasibility, not demo performance, is the real gate.
• Benchmark against the baseline you already know: the same Raspberry Pi 5 with a conventional M.2 NPU accelerator, measured on your workload’s latency and energy per inference.
• If your workload is genuinely sparse and event-driven — wake-word, presence, anomaly detection — the architecture is worth evaluating; for dense continuous vision it rarely wins on throughput.

Banana Pi BPI-M8: UFS storage reaches the low-cost SBC class

Banana Pi has introduced the BPI-M8, an 85 × 56 mm board in the Raspberry Pi 5 form factor built on the Allwinner A733: two Cortex-A76 cores at 2.0 GHz, six Cortex-A55 at 1.8 GHz, a small RISC-V E902 management core, an Imagination BXM-4-64 GPU and a 3 TOPS NPU on a 12 nm process. It carries 4 GB of LPDDR5, HDMI 2.0b, Wi-Fi 6, Gigabit Ethernet with optional PoE, and a Raspberry Pi compatible 40-pin header. The M8A variant ships 64 GB of eMMC at roughly 103–109 dollars; the M8B ships 16 MB of SPI NOR flash at roughly 69–73 dollars.

Two features stand out at this price. The first is a UFS module socket: UFS is the storage interface that has been displacing eMMC in phones for years, and a socketed module on a sub-110-dollar board is an early sign of it reaching the SBC and industrial class, with meaningfully higher throughput than eMMC and a replaceable module besides. The second is a 16-pin FFC connector carrying PCIe, multiplexed with DisplayPort.

The caution is software. The vendor lists Android, Linux and Armbian support, but at announcement no OS images or kernel sources were published for the board, and mainline support for the A733 is at an early stage. Another vendor announced an A733 board in September, so vendor BSP code exists in the ecosystem, but a board is only as usable as the BSP you can actually download. For training labs and products alike, that is the item to verify before ordering.

How to check before you buy

• Look for published kernel and U-Boot sources for this specific board, not only flashable images; images without sources cannot support product work.
• Check the community support status for the A733 before assuming the usual Allwinner path will apply; NPU and VPU support in particular tend to arrive last, if at all.
• If the UFS socket is the attraction, confirm which UFS module format is used and that Linux on this board has actually been demonstrated booting from it.

References

• Final release for the 7.2 stable series
• kernel.org: active kernel releases and projected EOL dates
• Yocto Project 6.1 (blacksail-6.1) release announcement
• Yocto Project 6.1 migration guide
• Yocto Project releases and support windows
• Scheduler updates for v7.4 (merge commit)
• arch/arm64/boot/dts/google at v7.4-rc1
• ARCH_GOOGLE in arch/arm64/Kconfig.platforms at v7.4-rc1
• AKD1500 Raspberry Pi 5 Dev Kit (vendor page)
• Banana Pi BPI-M8 announcement coverage

— Raghu Bharadwaj