Alp SDK v0.15 — a dual-core flash release-blocker fixed on AEN801, DRP-AI3 reachable, four Linux backends land
On E1M-AEN801 the M55-HP and M55-HE images both linked to the same slot0 address, so flashing both cores silently overwrote one of them. That release-blocker is fixed, eight dual-core examples get the cache setting they were missing, the Renesas DRP-AI3 NPU becomes reachable from <alp/inference.h>, and display, i3c, storage and usb gain real Yocto backends.
Alp SDK v0.15 is a correctness cut. Its headline is a release-blocker on the E1M-AEN801 (Alif Ensemble E8): the M55-HP and M55-HE images both linked to slot0 at 0x80010000, so a developer flashing both cores of a dual-core project silently overwrote one image with the other. Nothing errored — the second flash simply won, and the first core booted whatever was left. The linked addresses are now distinct per core.
The same dual-core path picked up two more corrections from the bench. Eight AEN dual-core and SRAM0-beacon examples did not set CONFIG_DCACHE=n on their own, leaving them silently exposed to cross-core cache incoherence, and five AEN examples had been reporting ALP_ERR_NOSUPPORT as a SKIP that is unreachable in practice — a result that reads as "not applicable here" when it actually means the call failed. alp_mproc_boot_core() now documents its image-residency precondition and a direction-specific M55-HP TCM-invalidation erratum, both written from E8 bench evidence rather than from the vendor datasheet, and a new aen-dualcore-he-master example (HE core as master, HP as peer) is silicon-proven as of 2026-08-01.
On the Renesas side, the RZ/V2N on-die DRP-AI3 NPU is now reachable from the portable <alp/inference.h> as an opt-in backend, and four portable classes that had a Zephyr backend only — <alp/display.h>, <alp/i3c.h>, <alp/storage.h> and <alp/usb.h> — gain real Yocto/Linux implementations, so the same header works on the A-cluster as well as the M-class companion. Two architecture decisions were recorded alongside: ADR 0023 keeps Ethernet out of the <alp/*> surface (the portable contract stays the capability count, the port identity, and the PHY chip driver — there is no <alp/net.h>), and ADR 0024 keeps ADC, PWM, DAC, counter and qenc on V2N and V2M served exclusively by the GD32 IO-MCU bridge, because no SoC pin on that family reaches an E1M-standard analog or counter pad at all.
A large share of this release is hardening found by reviewing the tree rather than by running it. Two path-traversal bugs (in tan model build and in untrusted template catalogs), path traversal plus script command injection in the flash backends, five memory-safety defects across the AEN Zephyr drivers, signed-left-shift undefined behaviour in SHA-256 word assembly, a busy-spin in alp_handle_begin_close() that could deadlock under priority scheduling, and a shared unlocked transport underneath the CC3501E Wi-Fi, BLE, GPIO and OTA backends. The gates themselves were audited too: test-all.sh had been running 1 of 34 required gate scripts on Windows, and the macOS and Windows CI legs can now actually fail a pull request instead of merely being claimed to.
Status is unchanged in the way that matters. Silicon evidence still covers two SoM families — the E1M-X V2N and the E1M-AEN801; i.MX 93, V2M/DEEPX and the AEN30x–70x parts remain [UNTESTED] on real hardware. The DRP-AI3 backend and the four new Yocto backends are code and CI, not bench results. And the flash release-blocker is worth reading as a warning as much as a fix: if you built a dual-core AEN801 image on v0.14 or earlier, reflash both cores on v0.15 before trusting what is resident on the part.
