Zephyr audio on MediaTek Genio 700: AFE support lands

MediaTek quietly shipped something we have been waiting on: working audio support for Zephyr on the Genio 700. The commits landed in MediaTek’s public Zephyr fork at the end of June 2026, and they are not a toy. The branch adds a full driver stack for the MT8390 audio front end, the clock plumbing to run it without Linux’s help, and capture samples that exercise real uplink paths on the Genio 700 EVK. If you have been designing audio products on Genio and wishing the deterministic half of the system could live on an RTOS, this is the piece that was missing.

Key Insights

• MediaTek’s Zephyr fork (branch MTK-Genio_4.3.0, Zephyr 4.3.0 base) now drives the Genio 700’s AFE: core driver, eTDM DAI, AFE clock management, AUDSYS clock gates, and the topckgen and apmixedsys clock drivers underneath.
• The deployment model is Linux plus Zephyr side by side under the Jailhouse hypervisor. The Jailhouse recipe is public in the meta-mediatek-experimental Yocto layer for RITY Scarthgap v25.1.
• The AFE’s many DMA paths make clean sharing possible: on our EVK, Linux claims DL0 to DL7 and UL0 to UL2, while the Zephyr samples capture on UL3, UL8, and UL9. The two operating systems do not fight over the same hardware.
• Everything is buildable today from public repositories, but none of it is upstream yet. Interfaces will move.

What did MediaTek actually ship?

The interesting commits landed on 2026-06-29 in the MTK-Genio_4.3.0 branch of MediaTek’s Zephyr fork. Together they form a complete audio path for the MT8390, the SoC inside the Genio 700:

Commit area	What it adds
AFE core driver	The audio front end: DMA engine and register-level control of the audio interconnect
eTDM DAI driver	The digital audio interface that moves PCM between the AFE and external codecs or TDM devices
AFE clock management	Runtime clock control for the audio subsystem
AUDSYS clock gates	The audio-block clock gates Zephyr must toggle itself
topckgen mux/gate driver	Top-level clock mux and gate control
apmixedsys PLL driver	The PLL source feeding the audio clock tree
genio_700_evk board enable	Device tree and pinctrl wiring for the AFE on the reference board
Capture samples	Working examples recording from the UL3, UL8, and UL9 uplink paths

The clock drivers deserve a highlight. On Linux, audio drivers lean on the common clock framework and the whole tree is already up when a machine driver probes. A Zephyr cell gets none of that. Shipping topckgen, apmixedsys, and AUDSYS drivers means the Zephyr side can source and gate its own audio clocks, which is the difference between a demo that works because Linux happened to leave clocks on, and a driver stack that owns its hardware.

The branch history also shows where this is heading: earlier commits carry board support for the MT8365 and MT8370 Pumpkin boards, Genio 510 EVK groundwork, UART, timer, GPIO, EINT, and pinctrl refactors, and vPCI support. Audio is the newest and most product-relevant layer on an actively developed port.

Why run audio under Zephyr instead of Linux?

Because worst case beats average case for audio. Linux with PipeWire is excellent at desktop-grade audio, and on Genio it works well (we cover that stack in our PipeWire on Genio guide). But Linux schedules audio work alongside everything else the system does. When your product needs a capture-to-output path that never misses, page cache pressure, a busy GPU, or one badly behaved userspace process become audio problems. You can chase preempt-rt and priority tuning a long way (see Real-Time Linux on Genio), and sometimes that is enough. When it is not, the clean answer is to take the audio path off Linux entirely.

That is the architecture this port enables: Linux keeps networking, UI, updates, and the application layer, while a Zephyr cell owns the audio interfaces with microsecond-scale, provable scheduling. Instruments, intercoms, conferencing endpoints, and industrial acoustic monitoring all fit that shape. Until now, building it on Genio meant porting an RTOS and writing AFE drivers yourself. MediaTek just paid that bill.

How do Linux and Zephyr share one audio subsystem?

The MT8390’s AFE is built around many independent DMA paths: downlink (DL) paths for playback and uplink (UL) paths for capture, all routed through one interconnect. That fan-out is what makes the split workable in practice.

On the Genio EVK in our lab, the stock Linux sound card registers as mt8391-evk and claims DL0 through DL7 for playback, UL0 through UL2 for capture, plus an HDMI playback device. You can see it directly on any Genio board:

cat /proc/asound/cards
cat /proc/asound/pcm

MediaTek’s Zephyr samples capture on UL3, UL8, and UL9. Those are uplink paths the default Linux machine driver does not reference at all. That is the pattern to copy in a product design: give Linux the paths it needs for system audio, give the Zephyr cell its own UL and DL paths, and the two sides never contend for a DMA channel. The partitioning below reinforces the same boundary. Under Jailhouse, the Zephyr inmate cell gets an isolated memory carveout and its own CPU core (a single Cortex-A55 in the reference configs), with the hypervisor at EL2 keeping each side inside its assigned hardware.

How do you build and run it?

Two halves: a Yocto image with Jailhouse for the Linux side, and a Zephyr application for the inmate cell.

For the image, MediaTek publishes the Jailhouse recipe in its experimental layer. On top of a normal RITY Scarthgap v25.1 build (kernel 6.6.92 at the time of writing):

cd $PROJ_ROOT/src
git clone https://gitlab.com/mediatek/aiot/rity/meta-mediatek-experimental -b scarthgap
# add the layer to bblayers.conf, then in local.conf:
# IMAGE_INSTALL:append = " jailhouse "

The resulting image carries the jailhouse tool and a library of cell configs, including genio-510-evk-zephyr.cell and genio-720-evk-zephyr.cell. The inmate load address is set by JH_CONFIG_INMATE_BASE in the Jailhouse recipe if you need to move it.

For the Zephyr half, initialize the workspace against MediaTek’s fork instead of upstream:

west init -m https://github.com/ffreimann-mtk/zephyr --mr MTK-Genio_4.3.0 ~/zephyrproject
cd ~/zephyrproject && west update
west build -b genio_700_evk samples/<audio sample>

Then the Jailhouse lifecycle on the board is the standard one: enable the hypervisor with the root cell config, create the Zephyr cell, load zephyr.bin at the cell’s base address, and start it. From our own Jailhouse bring-up work on a Genio 720 EVK, the one piece of advice that saves the most time is to treat the cell config as the real interface: know exactly which memory carveout, CPU, and peripherals the inmate owns before you chase any driver-level symptom. We walk through that config anatomy in our Jailhouse on MediaTek Genio guide.

What is still experimental?

Be clear-eyed about the maturity here. The audio work targets the Genio 700 first; the fork carries Genio 510 groundwork and the cell configs cover more boards, but MT8390 is where the samples run. Nothing is upstream: the Zephyr port lives on a fork and the Yocto recipe lives in a layer with “experimental” in its name, so pin your revisions and expect interface churn. Cross-cell communication is the standard Jailhouse story, shared memory via IVSHMEM, and anything richer is yours to design. And the samples are capture-oriented today, so a full product audio path still means writing your application-side processing and output plumbing in Zephyr.

None of that changes the headline. The hard, vendor-specific part of RTOS audio on Genio, the AFE and its clock tree, now has public, working code from the silicon vendor itself.

Where to start

If you are evaluating this for a product: build the RITY image with the Jailhouse recipe, run the stock Zephyr capture sample on a Genio 700 EVK, and then map your own audio topology onto the AFE’s path structure with Linux and Zephyr on disjoint UL and DL sets. The public code takes you through the first two steps; the third is product engineering.

Designing an audio product on Genio and weighing how to split real-time work between Linux and an RTOS? That partitioning decision is cheap to get right up front and expensive to retrofit. Talk to us about MediaTek Genio engineering support.

Sources: MediaTek’s Zephyr fork, branch MTK-Genio_4.3.0, meta-mediatek-experimental on GitLab, Zephyr getting started guide, and MediaTek’s IoT Yocto documentation.