arm64: dts: rockchip: Add support for Axelera Metis SBC
Subsystems (2)
cover arm64: dts: rockchip: Add support for Axelera Metis SBC
The Axelera AI Metis Compute Board is a SBC based on the Rockchip RK3588 SoC. It offers efficient AI compute for multi-stream computer vision and generative AI applications in a compact design.
Product page [1].
This series was tested against Linux 7.1-rc4 (5200f5f493f79f14bbdc349e402a40dfb32f23c8), and aims to introduce basic support for the board, which includes the console, the eMMC, the two Gigabit Ethernet ports, the four USB ports and
the HDMI connector.
[1]: https://axelera.ai/evaluation-systems/metis-compute-board
Patrick Barsanti (3):
dt-bindings: vendor-prefixes: Add Axelera AI
dt-bindings: arm: rockchip: Add Axelera AI Metis Compute Board
arm64: dts: rockchip: Add Axelera AI metis-sbc
.../devicetree/bindings/arm/rockchip.yaml | 5 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3588-metis-sbc.dts | 840 ++++++++++++++++++ 4 files changed, 848 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts
Signature · 1 line
2.53.0
PATCH 1/3 dt-bindings: vendor-prefixes: Add Axelera AI
Axelera AI is an EU-based provider of AIPUs for edge AI inference.
--- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+)
Documentation/devicetree/bindings/vendor-prefixes.yaml +2 -0
@@ -217,6 +217,8 @@ patternProperties: description: Avnet, Inc. "^awinic,.*": description: Shanghai Awinic Technology Co., Ltd. + "^axelera,.*": + description: Axelera AI "^axentia,.*": description: Axentia Technologies AB "^axiado,.*":
Signature · 1 line
2.53.0
Heiko Stuebner
maintainerRe: [PATCH 1/3] dt-bindings: vendor-prefixes: Add Axelera AI
Am Freitag, 22. Mai 2026, 19:49:16 Mitteleuropäische Sommerzeit schrieb Patrick Barsanti:
Quoted 13 lines
Axelera AI is an EU-based provider of AIPUs for edge AI inference.
Link https://axelera.ai/Signed-off-by Patrick Barsanti <[email protected]>--- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+)Documentation/devicetree/bindings/vendor-prefixes.yaml +0
-0
Documentation/devicetree/bindings/vendor-prefixes.yaml patternProperties: · line 221
Quoted 5 lines
Documentation/devicetree/bindings/vendor-prefixes.yaml +2
-0@@ -217,6 +217,8 @@ patternProperties: description: Avnet, Inc. "^awinic,.*": description: Shanghai Awinic Technology Co., Ltd. + "^axelera,.*": + description: Axelera AI
description: Axelera AI B.V.
Which is the dutch equivalent to a Ltd., so that is the full company name. See
https://axelera.ai/hubfs/Axelera%20T%26C%20Sales%20Feb%202026.pdf?hsLang=en
Quoted 4 lines
Documentation/devicetree/bindings/vendor-prefixes.yaml +0
-0"^axentia,.*": description: Axentia Technologies AB "^axiado,.*":
Re: [PATCH 1/3] dt-bindings: vendor-prefixes: Add Axelera AI
In reply to Patrick BarsantiPATCH 2/3 dt-bindings: arm: rockchip: Add Axelera AI Metis Compute Board
In reply to Patrick BarsantiThe Axelera AI Metis Compute Board is a SBC based on the Rockchip RK3588 SoC.
Specification:
- Rockchip RK3588
- 16GB LPDDR4
- Axelera AI Metis AIPU, 4GB/16GB LPDDR4X
- 64GB eMMC
- uSD slot
- 2x SATA ports
- 2x Gigabit LAN
- 1x M.2 E key
- 1x M.2 B key
- 1x HDMI2.0
- 1x USB-C with DP
- 4x USB3.1
--- Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++ 1 file changed, 5 insertions(+)
Documentation/devicetree/bindings/arm/rockchip.yaml +5 -0
@@ -107,6 +107,11 @@ properties: - asus,rk3566-tinker-board-3s - const: rockchip,rk3566 + - description: Axelera AI Metis Compute Board + items: + - const: axelera,metis-sbc + - const: rockchip,rk3588 + - description: Beelink A1 items: - const: azw,beelink-a1
Signature · 1 line
2.53.0
Re: [PATCH 2/3] dt-bindings: arm: rockchip: Add Axelera AI Metis Compute Board
pw-bot: not-applicable
PATCH 3/3 arm64: dts: rockchip: Add Axelera AI metis-sbc
In reply to Patrick BarsantiAdd minimal device tree for the Axelera AI Metis Compute Board (rk3588-metis-sbc).
It offers efficient AI compute for multi-stream computer vision and GenAI applications in a compact design. It features a quad-core Axelera AI Metis AIPU and an RK3588 SoC processor.
This basic version of the dts supports:
- Console
- eMMC
- HDMI
- 4x USB-A
- 2x Gigabit Ethernet
- RTC
- Enumeration of on-board Axelera Metis AIPU
--- arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3588-metis-sbc.dts | 840 ++++++++++++++++++ 2 files changed, 841 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts
arch/arm64/boot/dts/rockchip/Makefile +1 -0
@@ -192,6 +192,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-h96-max-v58.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-jaguar.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-jaguar-ethernet-switch.dtbo dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-jaguar-pre-ict-tester.dtbo +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-metis-sbc.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-mnt-reform2.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-nanopc-t6.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-nanopc-t6-lts.dtb
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +840 -0
840 lines not on this page · raw message
Signature · 1 line
2.53.0
[email protected]
AI reviewRe: [PATCH 3/3] arm64: dts: rockchip: Add Axelera AI metis-sbc
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider: - [High] The `&hdmi0` node mixes HDMI M0 and M1 pinmux groups for its pins, which will cause the HDMI…
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] The &hdmi0 node mixes HDMI M0 and M1 pinmux groups for its pins, which will cause the HDMI controller to miss Hot-Plug Detection (HPD) signals.
- [Medium] The &sdhci (eMMC) node specifies full-pwr-cycle-in-suspend but lacks the required vmmc-supply and vqmmc-supply regulator assignments, and the underlying PMIC supplies are not configured to turn off in suspend.
- [Medium] The pmic@0 (RK806) node lacks a pinctrl assignment for its interrupt pin.
- [Medium] The vcc3v3_hubreset regulator is used as a hack to release a USB hub reset GPIO, and is incorrectly passed as the phy-supply to &usbdp_phy1 while being marked as regulator-always-on and regulator-boot-on.
- [Low] The vbus5v0_typec and vcc_3v3_sd_s0 regulators are defined but never referenced by any consumer node in the device tree, and lack the regulator-always-on property.
--
commit 4aee50a229d0828f7f68b373236eeefdfcd2b1b8
Author: Patrick Barsanti <[email protected]>
arm64: dts: rockchip: Add Axelera AI metis-sbc
Add minimal device tree for the Axelera AI Metis Compute Board (rk3588-metis-sbc).
Quoted 19 lines
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +13
-0@@ -0,0 +1,840 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +/dts-v1/; + +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/input/input.h> +#include <dt-bindings/pinctrl/rockchip.h> +#include <dt-bindings/soc/rockchip,vop2.h> +#include "rk3588.dtsi" + +/ { + model = "Axelera AI Metis Compute Board"; + compatible = "axelera,metis-sbc", "rockchip,rk3588";
[ ... ]
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts line 86
Quoted 11 lines
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +11
-0+ vbus5v0_typec: vbus5v0-typec { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>; /* TYPEC5V_PWREN */ + pinctrl-0 = <&typec5v_pwren>; + pinctrl-names = "default"; + regulator-name = "usbc_ss_vbus"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + vin-supply = <&vcc5v0_sus>; + };
[Severity: Low]
Are this regulator and vcc_3v3_sd_s0 actually used anywhere?
They lack the regulator-always-on property and are never referenced by any consumer node in the device tree, which means the regulator framework will never enable them.
[ ... ]
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts line 123
Quoted 12 lines
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +12
-0+ vcc_3v3_sd_s0: vcc-3v3-sd-s0 { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio0 RK_PC5 GPIO_ACTIVE_HIGH>; /* SDMMC_PWREN */ + pinctrl-0 = <&sdmmc_pwren>; + pinctrl-names = "default"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vsd_3v3"; + startup-delay-us = <1000000>; + vin-supply = <&vcc_3v3_s3>; + };
[Severity: Low]
Similar to vbus5v0_typec, is this regulator actually utilized?
It appears to be unreferenced dead code since it is not marked as always on and is not linked to any consumer node.
[ ... ]
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts line 144
Quoted 11 lines
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +11
-0+ vcc3v3_hubreset: vcc3v3-hubreset { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio3 RK_PB2 GPIO_ACTIVE_HIGH>; /* USB_HUB_RST_N */ + pinctrl-0 = <&usb_hub_rst_n>; + pinctrl-names = "default"; + regulator-always-on; + regulator-boot-on; + regulator-name = "vcc3v3_hubreset"; + vin-supply = <&vcc_3v3_s3>; + };
[Severity: Medium]
Does marking this regulator with regulator-always-on and regulator-boot-on defeat the intended reset sequencing mechanism?
It looks like this regulator is used to control a reset line for the downstream hub and is later referenced as phy-supply in &usbdp_phy1 to allow the PHY driver to sequence the reset. However, keeping it always on forces the reset line to be de-asserted immediately at boot before the PHY driver is ready, which can cause the hub to fail enumeration.
[ ... ]
Quoted 5 lines
+&hdmi0 {
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +4
-0+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd_sbc &hdmim0_tx0_scl &hdmim0_tx0_sda>; + pinctrl-names = "default"; + status = "okay"; +};
[ ... ]
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts line 433
Quoted 5 lines
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +5
-0+ hdmi { + hdmim0_tx0_hpd_sbc: hdmim0-tx0-hpd-sbc { + rockchip,pins = <3 RK_PD4 3 &pcfg_pull_none>; + }; + };
[Severity: High]
Does mixing HDMI M0 and M1 pinmux groups break display hot-plug detection?
The hdmi0 node uses the M0 hardware pinmux group for CEC, SCL, and SDA, but hdmim0_tx0_hpd_sbc is mapped to 3 RK_PD4 3, which corresponds to the M1 group.
Since Rockchip SoCs configure IOMUX routing globally for a peripheral via GRF, and the controller is routed to the M0 group for CEC/I2C, won't the M1 HPD pin be electrically ignored?
[ ... ]
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts line 504
Quoted 11 lines
+&sdhci {
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +10
-0+ bus-width = <8>; + max-frequency = <200000000>; + mmc-hs400-1_8v; + mmc-hs400-enhanced-strobe; + no-sd; + no-sdio; + non-removable; + full-pwr-cycle-in-suspend; + status = "okay"; +};
[Severity: Medium]
Without explicit vmmc-supply and vqmmc-supply regulator assignments, can this full-pwr-cycle-in-suspend property cause eMMC resume failures?
Because the underlying vcc_3v3_s3 regulator is configured with regulator-on-in-suspend, power will not actually be removed during suspend. Upon resume, the MMC core will attempt a full re-initialization expecting the card to be idle, but since the card never lost power, the re-initialization might fail.
[ ... ]
Quoted 5 lines
+&spi2 {
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +4
-0+ assigned-clock-rates = <200000000>; + assigned-clocks = <&cru CLK_SPI2>; + num-cs = <1>; + pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts line 520
Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +10
-0+ pinctrl-names = "default"; + status = "okay"; + + pmic@0 { + compatible = "rockchip,rk806"; + reg = <0x0>; + interrupt-parent = <&gpio0>; + interrupts = <RK_PA7 IRQ_TYPE_LEVEL_LOW>; /* PMIC_INT_L */ + spi-max-frequency = <1000000>; + system-power-controller;
[Severity: Medium]
Should there be a pinctrl assignment for the PMIC interrupt pin?
Relying entirely on the bootloader's default pin configuration could result in the pin being left floating or misconfigured as an output, which can lead to missed or spurious PMIC interrupts and power management failures.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
Heiko Stuebner
maintainerRe: [PATCH 3/3] arm64: dts: rockchip: Add Axelera AI metis-sbc
In reply to Patrick BarsantiHi,
Am Freitag, 22. Mai 2026, 19:49:18 Mitteleuropäische Sommerzeit schrieb Patrick Barsanti:
[...]
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts line 36
Quoted 1 line
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +1
-0+ pcie20_avdd0v85: pcie20-avdd0v85 {
Regulator nodes should start with "regulator-", so
pcie20_avdd0v85: regulator-pcie20-avdd0v85
same for all others.
Quoted 5 lines
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +5
-0+ compatible = "regulator-fixed"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <850000>; + regulator-max-microvolt = <850000>;
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts line 54
Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +7
-0+ regulator-name = "pcie20_avdd0v85"; + vin-supply = <&vdda_0v85_s0>; + }; +&cpu_b0 { + cpu-supply = <&vdd_cpu_big0_s0>; + mem-supply = <&vdd_cpu_big0_s0>; +};
There is no mem-supply in the mainline binidng, and it's the same regulators anyway. Again, same for all cpu nodes.
You should be able to run something like
make ARCH=arm64 .... CHECK_DTBS=y rockchip/rk3588-metis-sbc.dtb
to find all the binding problems.
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts line 248
Quoted 4 lines
+&gmac0 {
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +3
-0+ clock_in_out = "output"; + phy-handle = <&rgmii_phy0>; + /* Use rgmii-rxid mode to disable rx delay inside Soc */
no need for that comment
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts line 254
Quoted 6 lines
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +6
-0+ phy-mode = "rgmii-rxid"; + pinctrl-0 = <&gmac0_miim + &gmac0_tx_bus2 + &gmac0_rx_bus2 + &gmac0_rgmii_clk + &gmac0_rgmii_bus>;
please add a pinctrl entry (setting to GPIO) for that reset-pin Though ... is that the phy-reset ... this should be ideally described the phy node with its reset-gpios property.
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts line 263
Quoted 9 lines
arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts new file +9
-0+ pinctrl-names = "default"; + tx_delay = <0x44>; + snps,reset-gpio = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>; /* GMAC0_RST_N */ + snps,reset-active-low; + /* Reset time is 20ms, 100ms for rtl8211f */ + snps,reset-delays-us = <0 20000 100000>; + status = "okay"; +}; +
That's how far I got today :-)
Heiko