From: "J. Neuschäfer" <j.ne@posteo.net>
The X96Q is a set-top box with an H313 SoC, AXP305 PMIC, 1 or 2 GiB RAM,
8 or 16 GiB eMMC flash, 2x USB A, Micro-SD, HDMI, Ethernet, audio/video
output, and infrared input.
https://x96mini.com/products/x96q-tv-box-android-10-set-top-box
Tested, works:
- debug UART
- status LED
- USB ports in host mode
- MicroSD
- eMMC
- recovery button hidden behind audio/video port
- analog audio (line out)
Does not work:
- Ethernet (requires AC200 MFD/EPHY driver)
- analog video output (requires AC200 driver)
- HDMI audio/video output
Untested:
- "OTG" USB port in device mode
- built-in IR receiver
- external IR receiver
- WLAN (requires out-of-tree XRadio driver)
Table of regulators on the downstream kernel, for reference:
vcc-5v 1 15 0 unknown 5000mV 0mA 5000mV 5000mV
dcdca 0 0 0 unknown 900mV 0mA 0mV 0mV
dcdcb 0 0 0 unknown 1350mV 0mA 0mV 0mV
dcdcc 0 0 0 unknown 900mV 0mA 0mV 0mV
dcdcd 0 0 0 unknown 1500mV 0mA 0mV 0mV
dcdce 0 0 0 unknown 3300mV 0mA 0mV 0mV
aldo1 0 0 0 unknown 3300mV 0mA 0mV 0mV
aldo2 0 0 0 unknown 700mV 0mA 0mV 0mV
aldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
bldo1 0 0 0 unknown 1800mV 0mA 0mV 0mV
bldo2 0 0 0 unknown 1800mV 0mA 0mV 0mV
bldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
bldo4 0 0 0 unknown 700mV 0mA 0mV 0mV
cldo1 0 0 0 unknown 2500mV 0mA 0mV 0mV
cldo2 0 0 0 unknown 700mV 0mA 0mV 0mV
cldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts | 235 +++++++++++++++++++++
2 files changed, 236 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 780aeba0f3a4e14d69c9602e37b8d299165507b9..2edfa7bf4ab31c4aa934da98e5e042edc9aaf600 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h313-tanix-tx1.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h313-x96q.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts b/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts
new file mode 100644
index 0000000000000000000000000000000000000000..9534eb03b89557f2545af5af7cf43390be722cf0
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (C) 2025 J. Neuschäfer <j.ne@posteo.net>
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "X96Q";
+ compatible = "amediatech,x96q", "allwinner,sun50i-h616";
+
+ aliases {
+ mmc0 = &mmc0;
+ mmc1 = &mmc1;
+ mmc2 = &mmc2;
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_vcc5v: vcc5v {
+ /* board wide 5V supply directly from the DC input */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ key-recovery {
+ label = "Recovery";
+ linux,code = <KEY_VENDOR>;
+ gpios = <&pio 7 9 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ color = <LED_COLOR_ID_BLUE>;
+ gpios = <&pio 7 6 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+ };
+};
+
+&codec {
+ allwinner,audio-routing = "Line Out", "LINEOUT";
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdca>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci3 {
+ status = "okay";
+};
+
+/* TODO: EMAC1 connected to AC200 PHY */
+
+&gpu {
+ mali-supply = <®_dcdcc>;
+ status = "okay";
+};
+
+&ir {
+ status = "okay";
+};
+
+&mmc0 {
+ vmmc-supply = <®_aldo1>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+ disable-wp;
+ bus-width = <4>;
+ max-frequency = <150000000>;
+ status = "okay";
+ /* µSD */
+};
+
+&mmc1 {
+ /* TODO: XRadio XR819 WLAN */
+};
+
+&mmc2 {
+ vmmc-supply = <®_aldo1>;
+ vqmmc-supply = <®_bldo1>;
+ non-removable;
+ cap-mmc-hw-reset;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ bus-width = <8>;
+ max-frequency = <100000000>;
+ status = "okay";
+ /* eMMC */
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci3 {
+ status = "okay";
+};
+
+&r_i2c {
+ status = "okay";
+
+ axp305: pmic@36 {
+ compatible = "x-powers,axp305", "x-powers,axp805",
+ "x-powers,axp806";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x36>;
+
+ x-powers,self-working-mode;
+ vina-supply = <®_vcc5v>;
+ vinb-supply = <®_vcc5v>;
+ vinc-supply = <®_vcc5v>;
+ vind-supply = <®_vcc5v>;
+ vine-supply = <®_vcc5v>;
+ aldoin-supply = <®_vcc5v>;
+ bldoin-supply = <®_vcc5v>;
+ cldoin-supply = <®_vcc5v>;
+
+ regulators {
+ reg_dcdca: dcdca {
+ regulator-always-on;
+ regulator-min-microvolt = <810000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vdd-cpu";
+ };
+
+ dcdcb {
+ /* unused */
+ };
+
+ reg_dcdcc: dcdcc {
+ regulator-always-on;
+ regulator-min-microvolt = <810000>;
+ regulator-max-microvolt = <990000>;
+ regulator-name = "vdd-gpu-sys";
+ };
+
+ dcdcd {
+ regulator-always-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ };
+
+ dcdce {
+ /* unused */
+ };
+
+ reg_aldo1: aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc3v3";
+ };
+
+ aldo2 {
+ /* unused */
+ };
+
+ aldo3 {
+ /* unused */
+ };
+
+ reg_bldo1: bldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc1v8";
+ };
+
+ bldo2 {
+ /* unused */
+ };
+
+ bldo3 {
+ /* unused */
+ };
+
+ bldo4 {
+ /* unused */
+ };
+
+ cldo1 {
+ /* unused */
+ };
+
+ cldo2 {
+ /* unused */
+ };
+
+ cldo3 {
+ /* unused */
+ };
+ };
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_ph_pins>;
+ status = "okay";
+};
+
+&usbotg {
+ dr_mode = "host"; /* USB A type receptacle */
+ status = "okay";
+};
+
+&usbphy {
+ status = "okay";
+};
--
2.48.0.rc1.219.gb6b6757d772
On Fri, 12 Sep 2025 01:52:10 +0200
J. Neuschäfer via B4 Relay <devnull+j.ne.posteo.net@kernel.org> wrote:
Hi,
many thanks for posting the DT, I really wish more people would do that!
> From: "J. Neuschäfer" <j.ne@posteo.net>
>
> The X96Q is a set-top box with an H313 SoC, AXP305 PMIC, 1 or 2 GiB RAM,
> 8 or 16 GiB eMMC flash, 2x USB A, Micro-SD, HDMI, Ethernet, audio/video
> output, and infrared input.
>
> https://x96mini.com/products/x96q-tv-box-android-10-set-top-box
>
> Tested, works:
> - debug UART
> - status LED
> - USB ports in host mode
> - MicroSD
> - eMMC
> - recovery button hidden behind audio/video port
> - analog audio (line out)
>
> Does not work:
> - Ethernet (requires AC200 MFD/EPHY driver)
> - analog video output (requires AC200 driver)
> - HDMI audio/video output
>
> Untested:
> - "OTG" USB port in device mode
> - built-in IR receiver
> - external IR receiver
> - WLAN (requires out-of-tree XRadio driver)
>
> Table of regulators on the downstream kernel, for reference:
>
> vcc-5v 1 15 0 unknown 5000mV 0mA 5000mV 5000mV
> dcdca 0 0 0 unknown 900mV 0mA 0mV 0mV
> dcdcb 0 0 0 unknown 1350mV 0mA 0mV 0mV
> dcdcc 0 0 0 unknown 900mV 0mA 0mV 0mV
> dcdcd 0 0 0 unknown 1500mV 0mA 0mV 0mV
> dcdce 0 0 0 unknown 3300mV 0mA 0mV 0mV
> aldo1 0 0 0 unknown 3300mV 0mA 0mV 0mV
> aldo2 0 0 0 unknown 700mV 0mA 0mV 0mV
> aldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> bldo1 0 0 0 unknown 1800mV 0mA 0mV 0mV
> bldo2 0 0 0 unknown 1800mV 0mA 0mV 0mV
> bldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> bldo4 0 0 0 unknown 700mV 0mA 0mV 0mV
> cldo1 0 0 0 unknown 2500mV 0mA 0mV 0mV
> cldo2 0 0 0 unknown 700mV 0mA 0mV 0mV
> cldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
>
> Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts | 235 +++++++++++++++++++++
> 2 files changed, 236 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index 780aeba0f3a4e14d69c9602e37b8d299165507b9..2edfa7bf4ab31c4aa934da98e5e042edc9aaf600 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h313-tanix-tx1.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h313-x96q.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts b/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts
> new file mode 100644
> index 0000000000000000000000000000000000000000..9534eb03b89557f2545af5af7cf43390be722cf0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts
> @@ -0,0 +1,235 @@
> +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> +/*
> + * Copyright (C) 2025 J. Neuschäfer <j.ne@posteo.net>
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616.dtsi"
> +#include "sun50i-h616-cpu-opp.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include <dt-bindings/leds/common.h>
> +
> +/ {
> + model = "X96Q";
> + compatible = "amediatech,x96q", "allwinner,sun50i-h616";
> +
> + aliases {
> + mmc0 = &mmc0;
> + mmc1 = &mmc1;
> + mmc2 = &mmc2;
We don't do mmc aliases in the upstream DTs. Long story, but you should
not need them. I guess you want to disagree ;-), in this case U-Boot has
you covered, by adding the aliases during build time: just use
$fdtcontroladdr, as you should do anyway.
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + reg_vcc5v: vcc5v {
> + /* board wide 5V supply directly from the DC input */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-5v";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + key-recovery {
> + label = "Recovery";
> + linux,code = <KEY_VENDOR>;
> + gpios = <&pio 7 9 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led-0 {
> + color = <LED_COLOR_ID_BLUE>;
> + gpios = <&pio 7 6 GPIO_ACTIVE_LOW>;
> + default-state = "on";
> + };
> + };
> +};
> +
> +&codec {
> + allwinner,audio-routing = "Line Out", "LINEOUT";
> + status = "okay";
> +};
> +
> +&cpu0 {
> + cpu-supply = <®_dcdca>;
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
> +
> +&ehci3 {
> + status = "okay";
> +};
> +
> +/* TODO: EMAC1 connected to AC200 PHY */
> +
> +&gpu {
> + mali-supply = <®_dcdcc>;
> + status = "okay";
> +};
> +
> +&ir {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_aldo1>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + disable-wp;
> + bus-width = <4>;
> + max-frequency = <150000000>;
That line is already in the .dtsi file, so redundant.
> + status = "okay";
> + /* µSD */
If we really need this comment, it should be above, right after the
"&mmc0 {". And I wonder if it should be "microSD" instead.
> +};
> +
> +&mmc1 {
> + /* TODO: XRadio XR819 WLAN */
Either you just keep the comment, an mention mmc1, but don't reference the
node, or you add the properties that you know of already, like
vmmc-supply, vqmmc-supply, mmc-pwrseq, bus-width, non-removable.
But this "empty reference with a comment" is somewhat odd.
> +};
> +
> +&mmc2 {
> + vmmc-supply = <®_aldo1>;
> + vqmmc-supply = <®_bldo1>;
> + non-removable;
> + cap-mmc-hw-reset;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + bus-width = <8>;
> + max-frequency = <100000000>;
Are you sure you need that?
> + status = "okay";
> + /* eMMC */
Please move that comment up.
> +};
> +
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&ohci3 {
> + status = "okay";
> +};
> +
> +&r_i2c {
> + status = "okay";
> +
> + axp305: pmic@36 {
> + compatible = "x-powers,axp305", "x-powers,axp805",
> + "x-powers,axp806";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + reg = <0x36>;
> +
> + x-powers,self-working-mode;
> + vina-supply = <®_vcc5v>;
> + vinb-supply = <®_vcc5v>;
> + vinc-supply = <®_vcc5v>;
> + vind-supply = <®_vcc5v>;
> + vine-supply = <®_vcc5v>;
> + aldoin-supply = <®_vcc5v>;
> + bldoin-supply = <®_vcc5v>;
> + cldoin-supply = <®_vcc5v>;
> +
> + regulators {
> + reg_dcdca: dcdca {
> + regulator-always-on;
> + regulator-min-microvolt = <810000>;
> + regulator-max-microvolt = <1100000>;
> + regulator-name = "vdd-cpu";
> + };
> +
> + dcdcb {
> + /* unused */
> + };
> +
> + reg_dcdcc: dcdcc {
> + regulator-always-on;
> + regulator-min-microvolt = <810000>;
> + regulator-max-microvolt = <990000>;
> + regulator-name = "vdd-gpu-sys";
> + };
> +
> + dcdcd {
> + regulator-always-on;
Why is this always on? What happens if you remove that line or turn it off?
For always-on regulators we either need a comment saying why, or, better,
have an explanatory regulator-name (like above).
Is that for DRAM, by any chance (1.5V for DDR3 chips)?
Cheers,
Andre
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> + };
> +
> + dcdce {
> + /* unused */
> + };
> +
> + reg_aldo1: aldo1 {
> + regulator-always-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc3v3";
> + };
> +
> + aldo2 {
> + /* unused */
> + };
> +
> + aldo3 {
> + /* unused */
> + };
> +
> + reg_bldo1: bldo1 {
> + regulator-always-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-name = "vcc1v8";
> + };
> +
> + bldo2 {
> + /* unused */
> + };
> +
> + bldo3 {
> + /* unused */
> + };
> +
> + bldo4 {
> + /* unused */
> + };
> +
> + cldo1 {
> + /* unused */
> + };
> +
> + cldo2 {
> + /* unused */
> + };
> +
> + cldo3 {
> + /* unused */
> + };
> + };
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_ph_pins>;
> + status = "okay";
> +};
> +
> +&usbotg {
> + dr_mode = "host"; /* USB A type receptacle */
> + status = "okay";
> +};
> +
> +&usbphy {
> + status = "okay";
> +};
>
On Fri, Sep 12, 2025 at 10:54:49AM +0100, Andre Przywara wrote:
> On Fri, 12 Sep 2025 01:52:10 +0200
> J. Neuschäfer via B4 Relay <devnull+j.ne.posteo.net@kernel.org> wrote:
>
> Hi,
>
> many thanks for posting the DT, I really wish more people would do that!
>
> > From: "J. Neuschäfer" <j.ne@posteo.net>
> >
> > The X96Q is a set-top box with an H313 SoC, AXP305 PMIC, 1 or 2 GiB RAM,
> > 8 or 16 GiB eMMC flash, 2x USB A, Micro-SD, HDMI, Ethernet, audio/video
> > output, and infrared input.
> >
> > https://x96mini.com/products/x96q-tv-box-android-10-set-top-box
> >
> > Tested, works:
> > - debug UART
> > - status LED
> > - USB ports in host mode
> > - MicroSD
> > - eMMC
> > - recovery button hidden behind audio/video port
> > - analog audio (line out)
> >
> > Does not work:
> > - Ethernet (requires AC200 MFD/EPHY driver)
> > - analog video output (requires AC200 driver)
> > - HDMI audio/video output
> >
> > Untested:
> > - "OTG" USB port in device mode
> > - built-in IR receiver
> > - external IR receiver
> > - WLAN (requires out-of-tree XRadio driver)
> >
> > Table of regulators on the downstream kernel, for reference:
> >
> > vcc-5v 1 15 0 unknown 5000mV 0mA 5000mV 5000mV
> > dcdca 0 0 0 unknown 900mV 0mA 0mV 0mV
> > dcdcb 0 0 0 unknown 1350mV 0mA 0mV 0mV
> > dcdcc 0 0 0 unknown 900mV 0mA 0mV 0mV
> > dcdcd 0 0 0 unknown 1500mV 0mA 0mV 0mV
> > dcdce 0 0 0 unknown 3300mV 0mA 0mV 0mV
> > aldo1 0 0 0 unknown 3300mV 0mA 0mV 0mV
> > aldo2 0 0 0 unknown 700mV 0mA 0mV 0mV
> > aldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> > bldo1 0 0 0 unknown 1800mV 0mA 0mV 0mV
> > bldo2 0 0 0 unknown 1800mV 0mA 0mV 0mV
> > bldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> > bldo4 0 0 0 unknown 700mV 0mA 0mV 0mV
> > cldo1 0 0 0 unknown 2500mV 0mA 0mV 0mV
> > cldo2 0 0 0 unknown 700mV 0mA 0mV 0mV
> > cldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> >
> > Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
> > ---
> > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts | 235 +++++++++++++++++++++
> > 2 files changed, 236 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> > index 780aeba0f3a4e14d69c9602e37b8d299165507b9..2edfa7bf4ab31c4aa934da98e5e042edc9aaf600 100644
> > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > @@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h313-tanix-tx1.dtb
> > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h313-x96q.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts b/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..9534eb03b89557f2545af5af7cf43390be722cf0
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts
> > @@ -0,0 +1,235 @@
> > +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> > +/*
> > + * Copyright (C) 2025 J. Neuschäfer <j.ne@posteo.net>
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "sun50i-h616.dtsi"
> > +#include "sun50i-h616-cpu-opp.dtsi"
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +#include <dt-bindings/input/linux-event-codes.h>
> > +#include <dt-bindings/leds/common.h>
> > +
> > +/ {
> > + model = "X96Q";
> > + compatible = "amediatech,x96q", "allwinner,sun50i-h616";
> > +
> > + aliases {
> > + mmc0 = &mmc0;
> > + mmc1 = &mmc1;
> > + mmc2 = &mmc2;
>
> We don't do mmc aliases in the upstream DTs. Long story, but you should
> not need them. I guess you want to disagree ;-),
I've seen mmc aliases before, and I've seen the annoying effects of an
unstable probe order, so this is mostly of thing of habit.
> in this case U-Boot has
> you covered, by adding the aliases during build time: just use
> $fdtcontroladdr, as you should do anyway.
I'm using a recent upstream U-Boot with a FIT image ('make image.fit' in
the Linux source tree). In this case U-Boot does not add mmc aliases.
Is there a special Kconfig option I need to enable in U-Boot?
What do you mean by 'build time'? U-Boot's?
>
> > + serial0 = &uart0;
> > + };
[...]
> > +&mmc0 {
> > + vmmc-supply = <®_aldo1>;
> > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > + disable-wp;
> > + bus-width = <4>;
> > + max-frequency = <150000000>;
>
> That line is already in the .dtsi file, so redundant.
Good point, removing.
>
> > + status = "okay";
> > + /* µSD */
>
> If we really need this comment, it should be above, right after the
> "&mmc0 {". And I wonder if it should be "microSD" instead.
Good points, I'll do both.
> > +};
> > +
> > +&mmc1 {
> > + /* TODO: XRadio XR819 WLAN */
>
> Either you just keep the comment, an mention mmc1, but don't reference the
> node, or you add the properties that you know of already, like
> vmmc-supply, vqmmc-supply, mmc-pwrseq, bus-width, non-removable.
> But this "empty reference with a comment" is somewhat odd.
I'll change it to a pure comment for now.
> > +};
> > +
> > +&mmc2 {
> > + vmmc-supply = <®_aldo1>;
> > + vqmmc-supply = <®_bldo1>;
> > + non-removable;
> > + cap-mmc-hw-reset;
> > + mmc-ddr-1_8v;
> > + mmc-hs200-1_8v;
> > + bus-width = <8>;
> > + max-frequency = <100000000>;
>
> Are you sure you need that?
I found it in the downstream DT. The eMMC probes fine without it, so
I'll remove it. The eMMC datasheet (assuming I found the right one),
claims a maximum of 200 MHz, so the 100 MHz restriction seems
unnecessary.
>
> > + status = "okay";
> > + /* eMMC */
>
> Please move that comment up.
Will do.
[...]
> > + regulators {
> > + reg_dcdca: dcdca {
> > + regulator-always-on;
> > + regulator-min-microvolt = <810000>;
> > + regulator-max-microvolt = <1100000>;
> > + regulator-name = "vdd-cpu";
> > + };
> > +
> > + dcdcb {
> > + /* unused */
> > + };
> > +
> > + reg_dcdcc: dcdcc {
> > + regulator-always-on;
> > + regulator-min-microvolt = <810000>;
> > + regulator-max-microvolt = <990000>;
> > + regulator-name = "vdd-gpu-sys";
> > + };
> > +
> > + dcdcd {
> > + regulator-always-on;
>
> Why is this always on? What happens if you remove that line or turn it off?
> For always-on regulators we either need a comment saying why, or, better,
> have an explanatory regulator-name (like above).
> Is that for DRAM, by any chance (1.5V for DDR3 chips)?
The observed behavior is that the system halts when dcdcd is disabled.
The relationship is a bit hard to determine without schematics, but the
DDR3 chips (Micron MT41J256M4) do indeed use 1.5V. Since this is the
only source of 1.5V, I think it's a safe guess that this is indeed the
DRAM regulator.
>
> Cheers,
> Andre
Thanks for the review!
J. Neuschäfer
On Mon, 15 Sep 2025 13:40:15 +0000
J. Neuschäfer <j.ne@posteo.net> wrote:
> On Fri, Sep 12, 2025 at 10:54:49AM +0100, Andre Przywara wrote:
> > On Fri, 12 Sep 2025 01:52:10 +0200
> > J. Neuschäfer via B4 Relay <devnull+j.ne.posteo.net@kernel.org> wrote:
> >
> > Hi,
> >
> > many thanks for posting the DT, I really wish more people would do that!
> >
> > > From: "J. Neuschäfer" <j.ne@posteo.net>
> > >
> > > The X96Q is a set-top box with an H313 SoC, AXP305 PMIC, 1 or 2 GiB RAM,
> > > 8 or 16 GiB eMMC flash, 2x USB A, Micro-SD, HDMI, Ethernet, audio/video
> > > output, and infrared input.
> > >
> > > https://x96mini.com/products/x96q-tv-box-android-10-set-top-box
> > >
> > > Tested, works:
> > > - debug UART
> > > - status LED
> > > - USB ports in host mode
> > > - MicroSD
> > > - eMMC
> > > - recovery button hidden behind audio/video port
> > > - analog audio (line out)
> > >
> > > Does not work:
> > > - Ethernet (requires AC200 MFD/EPHY driver)
> > > - analog video output (requires AC200 driver)
> > > - HDMI audio/video output
> > >
> > > Untested:
> > > - "OTG" USB port in device mode
> > > - built-in IR receiver
> > > - external IR receiver
> > > - WLAN (requires out-of-tree XRadio driver)
> > >
> > > Table of regulators on the downstream kernel, for reference:
> > >
> > > vcc-5v 1 15 0 unknown 5000mV 0mA 5000mV 5000mV
> > > dcdca 0 0 0 unknown 900mV 0mA 0mV 0mV
> > > dcdcb 0 0 0 unknown 1350mV 0mA 0mV 0mV
> > > dcdcc 0 0 0 unknown 900mV 0mA 0mV 0mV
> > > dcdcd 0 0 0 unknown 1500mV 0mA 0mV 0mV
> > > dcdce 0 0 0 unknown 3300mV 0mA 0mV 0mV
> > > aldo1 0 0 0 unknown 3300mV 0mA 0mV 0mV
> > > aldo2 0 0 0 unknown 700mV 0mA 0mV 0mV
> > > aldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> > > bldo1 0 0 0 unknown 1800mV 0mA 0mV 0mV
> > > bldo2 0 0 0 unknown 1800mV 0mA 0mV 0mV
> > > bldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> > > bldo4 0 0 0 unknown 700mV 0mA 0mV 0mV
> > > cldo1 0 0 0 unknown 2500mV 0mA 0mV 0mV
> > > cldo2 0 0 0 unknown 700mV 0mA 0mV 0mV
> > > cldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> > >
> > > Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
> > > ---
> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > > arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts | 235 +++++++++++++++++++++
> > > 2 files changed, 236 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> > > index 780aeba0f3a4e14d69c9602e37b8d299165507b9..2edfa7bf4ab31c4aa934da98e5e042edc9aaf600 100644
> > > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > > @@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
> > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h313-tanix-tx1.dtb
> > > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h313-x96q.dtb
> > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
> > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
> > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts b/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts
> > > new file mode 100644
> > > index 0000000000000000000000000000000000000000..9534eb03b89557f2545af5af7cf43390be722cf0
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts
> > > @@ -0,0 +1,235 @@
> > > +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> > > +/*
> > > + * Copyright (C) 2025 J. Neuschäfer <j.ne@posteo.net>
> > > + */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include "sun50i-h616.dtsi"
> > > +#include "sun50i-h616-cpu-opp.dtsi"
> > > +
> > > +#include <dt-bindings/gpio/gpio.h>
> > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > +#include <dt-bindings/input/linux-event-codes.h>
> > > +#include <dt-bindings/leds/common.h>
> > > +
> > > +/ {
> > > + model = "X96Q";
> > > + compatible = "amediatech,x96q", "allwinner,sun50i-h616";
> > > +
> > > + aliases {
> > > + mmc0 = &mmc0;
> > > + mmc1 = &mmc1;
> > > + mmc2 = &mmc2;
> >
> > We don't do mmc aliases in the upstream DTs. Long story, but you should
> > not need them. I guess you want to disagree ;-),
>
> I've seen mmc aliases before, and I've seen the annoying effects of an
> unstable probe order, so this is mostly of thing of habit.
Yes, as I said, it's a long story ;-) IIUC Rockchip does it, we
traditionally don't. There are arguments for both ways, and the decision
for sunxi was to not do it.
> > in this case U-Boot has
> > you covered, by adding the aliases during build time: just use
> > $fdtcontroladdr, as you should do anyway.
>
> I'm using a recent upstream U-Boot with a FIT image ('make image.fit' in
> the Linux source tree). In this case U-Boot does not add mmc aliases.
> Is there a special Kconfig option I need to enable in U-Boot?
U-Boot now automatically sync's the kernel DTs into the U-Boot tree, so
U-Boot is using the exact same DT for itself - and can pass that on to any
kernel. The trick is to just not load a DTB, but instead forward the
address of the one U-Boot is already using: $fdtcontroladdr.
If you are using EFI boot, this is done automatically, if you are using
the traditional booti method, you just change the last parameter:
=> booti $kernel_addr_r $ramdisk_addr_r:$filesize $fdtcontroladdr
I don't know how this works exactly with FIT images, so if you can
override the DTB in there or not include it in the first place. The
concept of bundling a particular DTB with a kernel is admittedly a long
standing practise in the embedded world, but does not make much sense
outside of it (in a single image, distribution world), and I like to treat
the embedded use case as a special case of a more generic approach.
> What do you mean by 'build time'? U-Boot's?
When U-Boot builds the DTB it uses itself, it will add some nodes, mostly
from arch/arm/dts/sunxi-u-boot.dtsi.
And because U-Boot relies on the MMC aliases internally, we add them
there. So if you pass on that DT, you will get the aliases.
Cheers,
Andre
> > > + serial0 = &uart0;
> > > + };
> [...]
> > > +&mmc0 {
> > > + vmmc-supply = <®_aldo1>;
> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > > + disable-wp;
> > > + bus-width = <4>;
> > > + max-frequency = <150000000>;
> >
> > That line is already in the .dtsi file, so redundant.
>
> Good point, removing.
> >
> > > + status = "okay";
> > > + /* µSD */
> >
> > If we really need this comment, it should be above, right after the
> > "&mmc0 {". And I wonder if it should be "microSD" instead.
>
> Good points, I'll do both.
>
> > > +};
> > > +
> > > +&mmc1 {
> > > + /* TODO: XRadio XR819 WLAN */
> >
> > Either you just keep the comment, an mention mmc1, but don't reference the
> > node, or you add the properties that you know of already, like
> > vmmc-supply, vqmmc-supply, mmc-pwrseq, bus-width, non-removable.
> > But this "empty reference with a comment" is somewhat odd.
>
> I'll change it to a pure comment for now.
>
> > > +};
> > > +
> > > +&mmc2 {
> > > + vmmc-supply = <®_aldo1>;
> > > + vqmmc-supply = <®_bldo1>;
> > > + non-removable;
> > > + cap-mmc-hw-reset;
> > > + mmc-ddr-1_8v;
> > > + mmc-hs200-1_8v;
> > > + bus-width = <8>;
> > > + max-frequency = <100000000>;
> >
> > Are you sure you need that?
>
> I found it in the downstream DT. The eMMC probes fine without it, so
> I'll remove it. The eMMC datasheet (assuming I found the right one),
> claims a maximum of 200 MHz, so the 100 MHz restriction seems
> unnecessary.
>
> >
> > > + status = "okay";
> > > + /* eMMC */
> >
> > Please move that comment up.
>
> Will do.
>
>
> [...]
> > > + regulators {
> > > + reg_dcdca: dcdca {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <810000>;
> > > + regulator-max-microvolt = <1100000>;
> > > + regulator-name = "vdd-cpu";
> > > + };
> > > +
> > > + dcdcb {
> > > + /* unused */
> > > + };
> > > +
> > > + reg_dcdcc: dcdcc {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <810000>;
> > > + regulator-max-microvolt = <990000>;
> > > + regulator-name = "vdd-gpu-sys";
> > > + };
> > > +
> > > + dcdcd {
> > > + regulator-always-on;
> >
> > Why is this always on? What happens if you remove that line or turn it off?
> > For always-on regulators we either need a comment saying why, or, better,
> > have an explanatory regulator-name (like above).
> > Is that for DRAM, by any chance (1.5V for DDR3 chips)?
>
> The observed behavior is that the system halts when dcdcd is disabled.
> The relationship is a bit hard to determine without schematics, but the
> DDR3 chips (Micron MT41J256M4) do indeed use 1.5V. Since this is the
> only source of 1.5V, I think it's a safe guess that this is indeed the
> DRAM regulator.
>
> >
> > Cheers,
> > Andre
>
> Thanks for the review!
> J. Neuschäfer
On Fri, Sep 12, 2025 at 5:54 PM Andre Przywara <andre.przywara@arm.com> wrote:
>
> On Fri, 12 Sep 2025 01:52:10 +0200
> J. Neuschäfer via B4 Relay <devnull+j.ne.posteo.net@kernel.org> wrote:
>
> Hi,
>
> many thanks for posting the DT, I really wish more people would do that!
>
> > From: "J. Neuschäfer" <j.ne@posteo.net>
> >
> > The X96Q is a set-top box with an H313 SoC, AXP305 PMIC, 1 or 2 GiB RAM,
> > 8 or 16 GiB eMMC flash, 2x USB A, Micro-SD, HDMI, Ethernet, audio/video
> > output, and infrared input.
> >
> > https://x96mini.com/products/x96q-tv-box-android-10-set-top-box
> >
> > Tested, works:
> > - debug UART
> > - status LED
> > - USB ports in host mode
> > - MicroSD
> > - eMMC
> > - recovery button hidden behind audio/video port
> > - analog audio (line out)
> >
> > Does not work:
> > - Ethernet (requires AC200 MFD/EPHY driver)
> > - analog video output (requires AC200 driver)
> > - HDMI audio/video output
> >
> > Untested:
> > - "OTG" USB port in device mode
> > - built-in IR receiver
> > - external IR receiver
> > - WLAN (requires out-of-tree XRadio driver)
> >
> > Table of regulators on the downstream kernel, for reference:
> >
> > vcc-5v 1 15 0 unknown 5000mV 0mA 5000mV 5000mV
> > dcdca 0 0 0 unknown 900mV 0mA 0mV 0mV
> > dcdcb 0 0 0 unknown 1350mV 0mA 0mV 0mV
> > dcdcc 0 0 0 unknown 900mV 0mA 0mV 0mV
> > dcdcd 0 0 0 unknown 1500mV 0mA 0mV 0mV
> > dcdce 0 0 0 unknown 3300mV 0mA 0mV 0mV
> > aldo1 0 0 0 unknown 3300mV 0mA 0mV 0mV
> > aldo2 0 0 0 unknown 700mV 0mA 0mV 0mV
> > aldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> > bldo1 0 0 0 unknown 1800mV 0mA 0mV 0mV
> > bldo2 0 0 0 unknown 1800mV 0mA 0mV 0mV
> > bldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> > bldo4 0 0 0 unknown 700mV 0mA 0mV 0mV
> > cldo1 0 0 0 unknown 2500mV 0mA 0mV 0mV
> > cldo2 0 0 0 unknown 700mV 0mA 0mV 0mV
> > cldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> >
> > Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
> > ---
> > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts | 235 +++++++++++++++++++++
> > 2 files changed, 236 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> > index 780aeba0f3a4e14d69c9602e37b8d299165507b9..2edfa7bf4ab31c4aa934da98e5e042edc9aaf600 100644
> > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > @@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h313-tanix-tx1.dtb
> > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h313-x96q.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts b/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..9534eb03b89557f2545af5af7cf43390be722cf0
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h313-x96q.dts
> > @@ -0,0 +1,235 @@
> > +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> > +/*
> > + * Copyright (C) 2025 J. Neuschäfer <j.ne@posteo.net>
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "sun50i-h616.dtsi"
> > +#include "sun50i-h616-cpu-opp.dtsi"
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +#include <dt-bindings/input/linux-event-codes.h>
> > +#include <dt-bindings/leds/common.h>
> > +
> > +/ {
> > + model = "X96Q";
> > + compatible = "amediatech,x96q", "allwinner,sun50i-h616";
> > +
> > + aliases {
> > + mmc0 = &mmc0;
> > + mmc1 = &mmc1;
> > + mmc2 = &mmc2;
>
> We don't do mmc aliases in the upstream DTs. Long story, but you should
> not need them. I guess you want to disagree ;-), in this case U-Boot has
> you covered, by adding the aliases during build time: just use
> $fdtcontroladdr, as you should do anyway.
>
> > + serial0 = &uart0;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + reg_vcc5v: vcc5v {
> > + /* board wide 5V supply directly from the DC input */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-5v";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + regulator-always-on;
> > + };
> > +
> > + gpio-keys {
> > + compatible = "gpio-keys";
> > +
> > + key-recovery {
> > + label = "Recovery";
> > + linux,code = <KEY_VENDOR>;
> > + gpios = <&pio 7 9 GPIO_ACTIVE_LOW>;
> > + };
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + led-0 {
> > + color = <LED_COLOR_ID_BLUE>;
> > + gpios = <&pio 7 6 GPIO_ACTIVE_LOW>;
> > + default-state = "on";
> > + };
> > + };
> > +};
> > +
> > +&codec {
> > + allwinner,audio-routing = "Line Out", "LINEOUT";
> > + status = "okay";
> > +};
> > +
> > +&cpu0 {
> > + cpu-supply = <®_dcdca>;
> > +};
> > +
> > +&ehci0 {
> > + status = "okay";
> > +};
> > +
> > +&ehci3 {
> > + status = "okay";
> > +};
> > +
> > +/* TODO: EMAC1 connected to AC200 PHY */
> > +
> > +&gpu {
> > + mali-supply = <®_dcdcc>;
> > + status = "okay";
> > +};
> > +
> > +&ir {
> > + status = "okay";
> > +};
> > +
> > +&mmc0 {
> > + vmmc-supply = <®_aldo1>;
> > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > + disable-wp;
> > + bus-width = <4>;
> > + max-frequency = <150000000>;
>
> That line is already in the .dtsi file, so redundant.
>
> > + status = "okay";
> > + /* µSD */
>
> If we really need this comment, it should be above, right after the
> "&mmc0 {". And I wonder if it should be "microSD" instead.
Yes. Please use ASCII in the code if possible, since some of us have
setups that don't quite work well with extended character sets.
> > +};
> > +
> > +&mmc1 {
> > + /* TODO: XRadio XR819 WLAN */
>
> Either you just keep the comment, an mention mmc1, but don't reference the
> node, or you add the properties that you know of already, like
> vmmc-supply, vqmmc-supply, mmc-pwrseq, bus-width, non-removable.
> But this "empty reference with a comment" is somewhat odd.
I'd say just fill it in completely so that the mmc host is enabled and
the SDIO card is detected. Missing driver support for the chip is a
different issue, but since this is an enumerable bus it shouldn't prevent
you from describing everything already.
> > +};
> > +
> > +&mmc2 {
> > + vmmc-supply = <®_aldo1>;
> > + vqmmc-supply = <®_bldo1>;
> > + non-removable;
> > + cap-mmc-hw-reset;
> > + mmc-ddr-1_8v;
> > + mmc-hs200-1_8v;
> > + bus-width = <8>;
> > + max-frequency = <100000000>;
>
> Are you sure you need that?
>
> > + status = "okay";
> > + /* eMMC */
>
> Please move that comment up.
I don't think it's necessary though. hs200 and 8-bit width would make
it obvious that it's an eMMC.
> > +};
> > +
> > +&ohci0 {
> > + status = "okay";
> > +};
> > +
> > +&ohci3 {
> > + status = "okay";
> > +};
> > +
> > +&r_i2c {
> > + status = "okay";
> > +
> > + axp305: pmic@36 {
> > + compatible = "x-powers,axp305", "x-powers,axp805",
> > + "x-powers,axp806";
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + reg = <0x36>;
> > +
> > + x-powers,self-working-mode;
> > + vina-supply = <®_vcc5v>;
> > + vinb-supply = <®_vcc5v>;
> > + vinc-supply = <®_vcc5v>;
> > + vind-supply = <®_vcc5v>;
> > + vine-supply = <®_vcc5v>;
> > + aldoin-supply = <®_vcc5v>;
> > + bldoin-supply = <®_vcc5v>;
> > + cldoin-supply = <®_vcc5v>;
> > +
> > + regulators {
> > + reg_dcdca: dcdca {
> > + regulator-always-on;
> > + regulator-min-microvolt = <810000>;
> > + regulator-max-microvolt = <1100000>;
> > + regulator-name = "vdd-cpu";
> > + };
> > +
> > + dcdcb {
> > + /* unused */
> > + };
> > +
> > + reg_dcdcc: dcdcc {
> > + regulator-always-on;
> > + regulator-min-microvolt = <810000>;
> > + regulator-max-microvolt = <990000>;
> > + regulator-name = "vdd-gpu-sys";
> > + };
> > +
> > + dcdcd {
> > + regulator-always-on;
>
> Why is this always on? What happens if you remove that line or turn it off?
> For always-on regulators we either need a comment saying why, or, better,
> have an explanatory regulator-name (like above).
> Is that for DRAM, by any chance (1.5V for DDR3 chips)?
>
> Cheers,
> Andre
>
> > + regulator-min-microvolt = <1500000>;
> > + regulator-max-microvolt = <1500000>;
> > + };
> > +
> > + dcdce {
> > + /* unused */
> > + };
> > +
> > + reg_aldo1: aldo1 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-name = "vcc3v3";
> > + };
> > +
> > + aldo2 {
> > + /* unused */
> > + };
> > +
> > + aldo3 {
> > + /* unused */
> > + };
> > +
> > + reg_bldo1: bldo1 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-name = "vcc1v8";
> > + };
> > +
> > + bldo2 {
> > + /* unused */
> > + };
> > +
> > + bldo3 {
> > + /* unused */
> > + };
> > +
> > + bldo4 {
> > + /* unused */
> > + };
> > +
> > + cldo1 {
> > + /* unused */
> > + };
> > +
> > + cldo2 {
> > + /* unused */
> > + };
> > +
> > + cldo3 {
> > + /* unused */
> > + };
> > + };
> > + };
> > +};
> > +
> > +&uart0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&uart0_ph_pins>;
> > + status = "okay";
> > +};
> > +
> > +&usbotg {
> > + dr_mode = "host"; /* USB A type receptacle */
> > + status = "okay";
> > +};
> > +
> > +&usbphy {
> > + status = "okay";
> > +};
> >
>
>
On Sat, Sep 13, 2025 at 05:36:12PM +0800, Chen-Yu Tsai wrote:
> On Fri, Sep 12, 2025 at 5:54 PM Andre Przywara <andre.przywara@arm.com> wrote:
> >
> > On Fri, 12 Sep 2025 01:52:10 +0200
> > J. Neuschäfer via B4 Relay <devnull+j.ne.posteo.net@kernel.org> wrote:
> >
> > Hi,
> >
> > many thanks for posting the DT, I really wish more people would do that!
> >
> > > From: "J. Neuschäfer" <j.ne@posteo.net>
> > >
> > > The X96Q is a set-top box with an H313 SoC, AXP305 PMIC, 1 or 2 GiB RAM,
> > > 8 or 16 GiB eMMC flash, 2x USB A, Micro-SD, HDMI, Ethernet, audio/video
> > > output, and infrared input.
> > >
> > > https://x96mini.com/products/x96q-tv-box-android-10-set-top-box
> > >
> > > Tested, works:
> > > - debug UART
> > > - status LED
> > > - USB ports in host mode
> > > - MicroSD
> > > - eMMC
> > > - recovery button hidden behind audio/video port
> > > - analog audio (line out)
> > >
> > > Does not work:
> > > - Ethernet (requires AC200 MFD/EPHY driver)
> > > - analog video output (requires AC200 driver)
> > > - HDMI audio/video output
> > >
> > > Untested:
> > > - "OTG" USB port in device mode
> > > - built-in IR receiver
> > > - external IR receiver
> > > - WLAN (requires out-of-tree XRadio driver)
> > >
> > > Table of regulators on the downstream kernel, for reference:
> > >
> > > vcc-5v 1 15 0 unknown 5000mV 0mA 5000mV 5000mV
> > > dcdca 0 0 0 unknown 900mV 0mA 0mV 0mV
> > > dcdcb 0 0 0 unknown 1350mV 0mA 0mV 0mV
> > > dcdcc 0 0 0 unknown 900mV 0mA 0mV 0mV
> > > dcdcd 0 0 0 unknown 1500mV 0mA 0mV 0mV
> > > dcdce 0 0 0 unknown 3300mV 0mA 0mV 0mV
> > > aldo1 0 0 0 unknown 3300mV 0mA 0mV 0mV
> > > aldo2 0 0 0 unknown 700mV 0mA 0mV 0mV
> > > aldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> > > bldo1 0 0 0 unknown 1800mV 0mA 0mV 0mV
> > > bldo2 0 0 0 unknown 1800mV 0mA 0mV 0mV
> > > bldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> > > bldo4 0 0 0 unknown 700mV 0mA 0mV 0mV
> > > cldo1 0 0 0 unknown 2500mV 0mA 0mV 0mV
> > > cldo2 0 0 0 unknown 700mV 0mA 0mV 0mV
> > > cldo3 0 0 0 unknown 700mV 0mA 0mV 0mV
> > >
> > > Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
> > > ---
[...]
> > > +&mmc0 {
> > > + vmmc-supply = <®_aldo1>;
> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > > + disable-wp;
> > > + bus-width = <4>;
> > > + max-frequency = <150000000>;
> >
> > That line is already in the .dtsi file, so redundant.
> >
> > > + status = "okay";
> > > + /* µSD */
> >
> > If we really need this comment, it should be above, right after the
> > "&mmc0 {". And I wonder if it should be "microSD" instead.
>
> Yes. Please use ASCII in the code if possible, since some of us have
> setups that don't quite work well with extended character sets.
ACK
>
> > > +};
> > > +
> > > +&mmc1 {
> > > + /* TODO: XRadio XR819 WLAN */
> >
> > Either you just keep the comment, an mention mmc1, but don't reference the
> > node, or you add the properties that you know of already, like
> > vmmc-supply, vqmmc-supply, mmc-pwrseq, bus-width, non-removable.
> > But this "empty reference with a comment" is somewhat odd.
>
> I'd say just fill it in completely so that the mmc host is enabled and
> the SDIO card is detected. Missing driver support for the chip is a
> different issue, but since this is an enumerable bus it shouldn't prevent
> you from describing everything already.
I gave it a try just now, but I wasn't successful with enumeration:
&mmc1 {
/* XRadio XR819 WLAN */
vmmc-supply = <®_aldo1>;
vqmmc-supply = <®_bldo1>;
mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
non-removable;
mmc-ddr-1_8v;
status = "okay";
};
The result is unsuccessful (with or without the questionable mmc-ddr-1_8v):
[ 1.607511] mmc1: Failed to initialize a non-removable card
The downstream DT mentions a few relevant properties:
/wlan {
wlan_regon = <&pio 6 18 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&losc>;
};
...
losc: clk_losc@0 {
linux,phandle = <0xd3>;
phandle = <0xd3>;
allwinner,drive = <0x02>;
allwinner,function = "x32kfout";
allwinner,muxsel = <0x03>;
allwinner,pins = "PG10";
allwinner,pull = <0x01>;
};
Translating this (roughly) into mainline bindings:
mmc-pwrseq = <&wifi_pwrseq>;
...
wifi_pwrseq: pwrseq {
compatible = "mmc-pwrseq-emmc";
reset-gpios = <&pio 6 18 GPIO_ACTIVE_LOW>;
clocks = <&rtc CLK_OSC32K_FANOUT>;
clock-names = "ext_clock";
pinctrl-names = "default";
pinctrl-0 = <&x32clk_fanout_pin>;
};
... it fails in drivers/reset/core.c, because __reset_add_reset_gpio_device
doesn't handle #gpio-cells = <3>, which is the case for &pio:
/*
* Currently only #gpio-cells=2 is supported with the meaning of:
* args[0]: GPIO number
* args[1]: GPIO flags
* TODO: Handle other cases.
*/
if (args->args_count != 2)
return -ENOENT;
Relatedly, I'd expect this limitation to break WiFi on sun50i-h313-tanix-tx1.dts
(upstreamed by Andre) as well.
> > > +};
> > > +
> > > +&mmc2 {
> > > + vmmc-supply = <®_aldo1>;
> > > + vqmmc-supply = <®_bldo1>;
> > > + non-removable;
> > > + cap-mmc-hw-reset;
> > > + mmc-ddr-1_8v;
> > > + mmc-hs200-1_8v;
> > > + bus-width = <8>;
> > > + max-frequency = <100000000>;
> >
> > Are you sure you need that?
After some more testing, it turns out that I do need to limit the
frequency to 100 MHz. At the default of 150 MHz, stable operation of
the eMMC isn't possible (all other properties being as they are).
> >
> > > + status = "okay";
> > > + /* eMMC */
> >
> > Please move that comment up.
>
> I don't think it's necessary though. hs200 and 8-bit width would make
> it obvious that it's an eMMC.
Not necessary, but perhaps still useful for someone having a quick
glance at the devicetree, so I'd prefer to keep it in.
Best regards,
J. Neuschäfer
On Fri, Sep 12, 2025 at 01:52:10AM +0200, J. Neuschäfer via B4 Relay wrote:
> From: "J. Neuschäfer" <j.ne@posteo.net>
>
> The X96Q is a set-top box with an H313 SoC, AXP305 PMIC, 1 or 2 GiB RAM,
> 8 or 16 GiB eMMC flash, 2x USB A, Micro-SD, HDMI, Ethernet, audio/video
> output, and infrared input.
>
> https://x96mini.com/products/x96q-tv-box-android-10-set-top-box
[...]
> +&gpu {
> + mali-supply = <®_dcdcc>;
> + status = "okay";
> +};
Note for v2: The GPU gets stuck in probe deferral, and I forgot to
investigate why.
On Fri, Sep 12, 2025 at 4:54 PM J. Neuschäfer <j.ne@posteo.net> wrote:
>
> On Fri, Sep 12, 2025 at 01:52:10AM +0200, J. Neuschäfer via B4 Relay wrote:
> > From: "J. Neuschäfer" <j.ne@posteo.net>
> >
> > The X96Q is a set-top box with an H313 SoC, AXP305 PMIC, 1 or 2 GiB RAM,
> > 8 or 16 GiB eMMC flash, 2x USB A, Micro-SD, HDMI, Ethernet, audio/video
> > output, and infrared input.
> >
> > https://x96mini.com/products/x96q-tv-box-android-10-set-top-box
> [...]
> > +&gpu {
> > + mali-supply = <®_dcdcc>;
> > + status = "okay";
> > +};
>
> Note for v2: The GPU gets stuck in probe deferral, and I forgot to
> investigate why.
You are probably missing the GPU power domain driver?
ChenYu
On Fri, Sep 12, 2025 at 04:56:36PM +0800, Chen-Yu Tsai wrote:
> On Fri, Sep 12, 2025 at 4:54 PM J. Neuschäfer <j.ne@posteo.net> wrote:
> >
> > On Fri, Sep 12, 2025 at 01:52:10AM +0200, J. Neuschäfer via B4 Relay wrote:
> > > From: "J. Neuschäfer" <j.ne@posteo.net>
> > >
> > > The X96Q is a set-top box with an H313 SoC, AXP305 PMIC, 1 or 2 GiB RAM,
> > > 8 or 16 GiB eMMC flash, 2x USB A, Micro-SD, HDMI, Ethernet, audio/video
> > > output, and infrared input.
> > >
> > > https://x96mini.com/products/x96q-tv-box-android-10-set-top-box
> > [...]
> > > +&gpu {
> > > + mali-supply = <®_dcdcc>;
> > > + status = "okay";
> > > +};
> >
> > Note for v2: The GPU gets stuck in probe deferral, and I forgot to
> > investigate why.
>
> You are probably missing the GPU power domain driver?
Indeed, with CONFIG_SUN50I_H6_PRCM_PPU=y the GPU probes successfully:
[ 1.396826] panfrost 1800000.gpu: clock rate = 432000000
[ 1.396859] panfrost 1800000.gpu: bus_clock rate = 200000000
[ 1.400125] panfrost 1800000.gpu: clock rate = 432000000
[ 1.400158] panfrost 1800000.gpu: bus_clock rate = 200000000
[ 1.403263] panfrost 1800000.gpu: clock rate = 432000000
[ 1.403297] panfrost 1800000.gpu: bus_clock rate = 200000000
[ 1.406582] panfrost 1800000.gpu: clock rate = 432000000
[ 1.428046] panfrost 1800000.gpu: bus_clock rate = 200000000
[ 1.442411] panfrost 1800000.gpu: clock rate = 432000000
[ 1.455175] panfrost 1800000.gpu: bus_clock rate = 200000000
[ 1.466484] panfrost 1800000.gpu: mali-g31 id 0x7093 major 0x0 minor 0x0 status 0x0
[ 1.476828] panfrost 1800000.gpu: features: 00000000,000027f7, issues: 00000000,00000400
[ 1.493284] panfrost 1800000.gpu: Features: L2:0x07100206 Shader:0x00000000 Tiler:0x00000209 Mem:0x1 MMU:0x00002821 AS:0xff JS:0x7
[ 1.493297] panfrost 1800000.gpu: shader_present=0x1 l2_present=0x1
[ 1.506114] [drm] Initialized panfrost 1.4.0 for 1800000.gpu on minor 0
Thanks,
J. Neuschäfer
© 2016 - 2025 Red Hat, Inc.