From: Andre Przywara <andre.przywara@arm.com>
To: Alexander Sverdlin <alexander.sverdlin@gmail.com>,
linux-sunxi@lists.linux.dev
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Chen-Yu Tsai <wens@kernel.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
Date: Mon, 11 May 2026 13:44:31 +0200 [thread overview]
Message-ID: <2306dd3c-6362-40ee-8d9f-77f89be3a502@arm.com> (raw)
In-Reply-To: <20260510201644.4143710-4-alexander.sverdlin@gmail.com>
Hi Alexander,
thanks for upstreaming the DTs!
On 5/10/26 22:16, Alexander Sverdlin wrote:
> Baijie Helper A133 board is a development board around Baijie A133 Core
> SBC. Features:
>
> - 1/2/4GiB LPDDR4 DRAM
> - 8/16/32GiB eMMC
> - AXP707 PMIC
> - 2 USB 2.0 ports
> - MicroSD slot and on-board eMMC module
> - Gigabit Ethernet
> - Bluetooth
> - WiFi
>
> Add initial support for both the Helper and Core boards, including UART,
> PMU, eMMC, USB, Ethernet.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> ---
>
> Changelog:
> v2:
> - introduced baijie,helper-a133-core compatible for the Core (SoM) board
>
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-a133-baije-core.dtsi | 162 ++++++++++++++++++
> .../allwinner/sun50i-a133-baijie-helper.dts | 94 ++++++++++
> 3 files changed, 257 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index d116864b6c2b..926dfa851100 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -18,6 +18,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h64-remix-mini-pc.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a133-baijie-helper.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a133-liontron-h-a133l.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus-v1.2.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> new file mode 100644
> index 000000000000..65b094f30bf5
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> @@ -0,0 +1,162 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2025 Arm Ltd.
Please put your own copyright here, even if that has been largely copied
from an existing file.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a100.dtsi"
> +#include "sun50i-a100-cpu-opp.dtsi"
> +
> +/{
> + compatible = "baijie,helper-a133-core",
> + "allwinner,sun50i-a100";
> +
> + aliases {
> + serial1 = &uart1; /* BT module */
Do we really need an alias for the BT UART? And is the BT module
supported already? Then please add a child node to the UART node.
> + };
> +};
> +
> +&cpu0 {
> + cpu-supply = <®_dcdc2>;
> +};
> +
> +&pio {
The order of those referenced nodes is alphabetically by the label name.
So this one goes further down.
> + vcc-pb-supply = <®_dcdc1>;
> + vcc-pc-supply = <®_eldo1>;
> + vcc-pd-supply = <®_dcdc1>;
> + vcc-pe-supply = <®_dldo2>;
> + vcc-pf-supply = <®_dcdc1>;
> + vcc-pg-supply = <®_dldo1>;
> + vcc-ph-supply = <®_dcdc1>;
> +};
> +
Isn't the WiFi/BT module on the SoM? Then please mention and enable MMC1
here. Provide the child node for the WiFi chip, even if there is no
upstream support in the kernel for it yet.
> +&mmc2 {
> + vmmc-supply = <®_dcdc1>;
> + vqmmc-supply = <®_eldo1>;
> + cap-mmc-hw-reset;
> + non-removable;
> + bus-width = <8>;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + status = "okay";
> +};
> +
> +&r_i2c0 {
> + status = "okay";
> +
> + axp803: pmic@34 {
> + compatible = "x-powers,axp803";
> + reg = <0x34>;
> + interrupt-parent = <&r_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + };
> +};
> +
> +#include "axp803.dtsi"
> +
> +&ac_power_supply {
> + status = "okay";
> +};
> +
> +®_aldo1 {
What is aldo1 used for, actually? I don't see this referenced anywhere.
I guess the kernel turns that off after booting?
If you have access to the schematic, please check that. If that's for
some peripheral not yet supported, please note the user anyway, ideally
by an explaining regulator-name, or by a comment. Also if it's used for
any of the required SoC VDD pins. See the Liontron .dts for comparison.
> + regulator-always-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
Please don't provide ranges here (those are in the driver already), the
point of this entry is to set the voltage required by the board. (And
yes, the vendor DTBs alway get this wrong). Typically there are fixed
requirements, so use the same value for min and max.
Same for the others below.
> +};
> +
> +®_aldo2 {
> + regulator-always-on;
For always-on regulators we definitely need an explanation. Does the
board stop booting if you remove this line?
Maybe it's for DRAM? Can you say what voltage it is, either from the
reset default, or set by the bootloader?
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
> +};
> +
> +®_aldo3 {
> + regulator-always-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
> +};
> +
> +®_dcdc1 {
> + regulator-always-on;
> + regulator-min-microvolt = <1600000>;
> + regulator-max-microvolt = <3400000>;
> + regulator-name = "vcc-3v3";
> +};
> +
> +®_dcdc2 {
> + regulator-always-on;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1300000>;
This one is an exception, because the voltage is to be adjusted at
runtime. But the voltage range needs to be tighter, the A133 datasheet
puts the valid VDD_CPU range between 810mV and 1200mV.
Compare to the Liontron dts file here.
> + regulator-name = "vdd-cpu";
> +};
> +
> +®_dcdc3 {
> + regulator-always-on;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1300000>;
> +};
> +
> +®_dcdc4 {
> + regulator-always-on;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-name = "vdd-sys";
> +};
> +
> +®_dcdc5 {
> + regulator-always-on;
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1840000>;
> + regulator-name = "vcc-dram";
> +};
> +
> +/* DCDC6 unused */
> +
> +®_dldo1 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
> +};
> +
> +®_dldo2 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3400000>;
> + regulator-enable-ramp-delay = <1000>;
> +};
> +
> +®_dldo3 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-name = "avdd-csi";
> +};
> +
> +®_dldo4 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
> +};
> +
> +®_eldo1 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1900000>;
> + regulator-enable-ramp-delay = <1000>;
> +};
> +
> +®_eldo2 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1900000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-name = "dvdd-csi";
> +};
> +
> +/* ELDO3 unused */
> +
> +®_fldo1 {
> + regulator-always-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1450000>;
> + regulator-name = "vdd-cpus-usb";
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
> new file mode 100644
> index 000000000000..ccbca5d0a40c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
> @@ -0,0 +1,94 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2025 Arm Ltd.
Your own copyright, please.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a133-baije-core.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/leds/common.h>
> +
> +/{
> + model = "HelperBoard A133";
> + compatible = "baijie,helper-a133",
> + "baijie,helper-a133-core",
> + "allwinner,sun50i-a100";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led {
> + function = LED_FUNCTION_INDICATOR;
> + color = <LED_COLOR_ID_GREEN>;
> + gpios = <&pio 7 13 GPIO_ACTIVE_LOW>; /* PH13 */
> + };
> + };
I see quite some buttons on the board. I guess they are connected to
GPIOs? Can you please describe them then, using gpio-keys? Look at
sun50i-h5-orangepi-pc2.dts for an example.
And you should provide a top level 5V regulator here, to be the root of
the regulator tree. Look at reg_vcc5v in the Liontron .dts.
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_dcdc1>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pb_pins>;
> + status = "okay";
> +};
> +
> +&rgmii0_pins {
> + drive-strength = <30>;
> +};
> +
> +&emac0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii0_pins>;
> + phy-handle = <ð_phy>;
> + phy-mode = "rgmii-id";
> + allwinner,rx-delay-ps = <200>;
> + allwinner,tx-delay-ps = <200>;
> + status = "okay";
> +};
> +
> +&mdio0 {
> + reset-gpios = <&pio 7 11 GPIO_ACTIVE_LOW>; /* PH11 */
> + reset-delay-us = <10000>;
> + reset-post-delay-us = <150000>;
> +
> + eth_phy: ethernet-phy@1 {
The typical label here would be rgmii_phy. The node name is correct, though.
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> +};
> +
So from the pictures I found online it looks like there is an USB-C port
labelled "OTG", so can you please add an &usbotg reference here and
describe that port.
> +&usbphy {
Are the two USB ports always powered?
And anyway, I see a *dual* USB-A socket on the pictures online, in
addition to the USB-OTG port. So where does the third USB come from? The
A133 only supports one host USB port plus the one OTG port. So is there
an USB hub chip on the board?
> + status = "okay";
> +};
> +
> +&ehci0 {
(and again, please order those nodes alphabetically)
Cheers,
Andre.
> + status = "okay";
> +};
> +
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
next prev parent reply other threads:[~2026-05-11 11:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-10 20:16 [PATCH v2 0/3] Add support for Baijie Helper A133 board Alexander Sverdlin
2026-05-10 20:16 ` [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add Shenzhen Baijie Technology Co., Ltd Alexander Sverdlin
2026-05-10 20:16 ` [PATCH v2 2/3] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible Alexander Sverdlin
2026-05-11 16:08 ` Conor Dooley
2026-05-11 16:18 ` Alexander Sverdlin
2026-05-11 16:34 ` Conor Dooley
2026-05-10 20:16 ` [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board Alexander Sverdlin
2026-05-11 11:44 ` Andre Przywara [this message]
2026-05-11 22:07 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2306dd3c-6362-40ee-8d9f-77f89be3a502@arm.com \
--to=andre.przywara@arm.com \
--cc=alexander.sverdlin@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jernej.skrabec@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=robh@kernel.org \
--cc=samuel@sholland.org \
--cc=wens@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox