Alp SDK v0.14 — a portable I3C controller class, bench-proven on AEN801
A new portable <alp/i3c.h> MIPI I3C Basic controller surface lands with a Zephyr backend on the Alif Ensemble E8, with controller init bench-proven on E1M-AEN801 and a live transfer still unproven. Bootstrap facts and the Zephyr-SDK toolchain pin move into data, and the hw_rev / SDK-version gate the docs had been advertising finally exists.
Alp SDK v0.14 adds I3C to the portable surface. The new <alp/i3c.h> is a MIPI I3C Basic controller class — alp_i3c_open, write, read, write_read, close and capabilities — marked [ABI-EXPERIMENTAL], with a Zephyr backend riding upstream i3c_dw.c on the Alif Ensemble E8 lpi3c0 instance. I3C joins the portable-API conformance suite in the same cut, so the class is held to the same per-case contract as the twelve before it.
The evidence for it is deliberately narrow. Controller initialisation is bench-proven on a physical E1M-AEN801 via a Flow C RAM-run on 2026-07-25; a live transfer to a real I3C target has not been demonstrated. Alongside it the E8 gains build-only SoC peripheral coverage for I3C, OSPI/HexSPI and managed-MDIO, and the Alif Ensemble peripheral counts were re-ingested from the vendor DFP with provenance recorded for every count that is inherited rather than audited — a count you cannot trace is now labelled as such instead of shipping as fact.
Two pieces of setup infrastructure moved from code into data. metadata/bootstrap.json and metadata/toolchains.json now single-source the cross-platform bootstrap facts and the Zephyr-SDK toolchain pin, with a prerequisites.install block as the one place a host-tool install command is written, replacing the same facts hardcoded across several bootstrap scripts that had already drifted apart. README.md and docs/getting-started.md now lead with tan bootstrap, matching the CLI’s own quickstart, so there is a single first command for a fresh clone.
The most consequential fix is one the documentation had been promising for some time: an hw_rev / SDK-version compatibility gate that had never actually been implemented. The claim was first removed from the docs, then made true. A board revision outside a declared [min_sdk_version, max_sdk_version] range now raises SdkRevisionUnsupported, and an hw_rev absent from the resolved revision table raises SdkRevisionUnknown — a distinct error, because an unknown revision has no range to have been outside of — instead of silently building against the wrong hardware. Four V2N and V2M SoM manifests had also been promising a gd32_bridge firmware path that exists in no clone; the build now refuses cleanly when the bridge image is absent.
The Alif silicon work in this cut is small and specific: gpio11 through gpio14 added to the E8 peripherals device tree, which is what makes the RGB LED’s green and blue channels reachable at all; a DesignWare GPIO functional-clock enable driver; and an OSPI0 clock-enable fix that had reproduced a bus fault on real E8. E8 builds also now default to the real SoC capability profile rather than the permissive one, so a capability an E8 does not have stops compiling instead of failing later on the bench. Zephyr moves v4.4.0 to v4.4.1.
Status is unchanged: two SoM families carry silicon evidence — the E1M-X V2N and the E1M-AEN801. i.MX 93, V2M/DEEPX and the AEN30x–70x parts remain [UNTESTED] on real hardware, and the I3C class in particular should be read as controller-init-proven, not transfer-proven.
