[PATCH v2 0/3] Add support for Baijie Helper A133 board

[PATCH v2 0/3] Add support for Baijie Helper A133 board

[Alexander Sverdlin]

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.

Link: https://szbaijie.com/index/product/product_detail.html?product_id=23&language=en

Changelog:
v2:
- introduced baijie,helper-a133-core compatible for the Core (SoM) board
v1:
- https://lore.kernel.org/all/20260503191842.2736130-1-alexander.sverdlin@gmail.com/

Alexander Sverdlin (3):
  dt-bindings: vendor-prefixes: Add Shenzhen Baijie Technology Co., Ltd.
  dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible
  arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

 .../devicetree/bindings/arm/sunxi.yaml        |  11 ++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../dts/allwinner/sun50i-a133-baije-core.dtsi | 162 ++++++++++++++++++
 .../allwinner/sun50i-a133-baijie-helper.dts   |  94 ++++++++++
 5 files changed, 270 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

-- 
2.54.0

[PATCH v2 1/3] dt-bindings: vendor-prefixes: Add Shenzhen Baijie Technology Co., Ltd.

[Alexander Sverdlin]

Shenzhen Baijie Technology Co., Ltd. focuses on R&D and production of
embedded products as well as customization of embedded solutions.

Link: https://szbaijie.com/
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 28784d66ae7b..095cf654787f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -229,6 +229,8 @@ patternProperties:
     description: Azoteq (Pty) Ltd
   "^azw,.*":
     description: Shenzhen AZW Technology Co., Ltd.
+  "^baijie,.*":
+    description: Shenzhen Baijie Technology Co., Ltd.
   "^baikal,.*":
     description: BAIKAL ELECTRONICS, JSC
   "^bananapi,.*":
-- 
2.54.0

Re: [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add Shenzhen Baijie Technology Co., Ltd.

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

Hi,

Le Sun 10 May 26, 22:16, Alexander Sverdlin a écrit :
> Shenzhen Baijie Technology Co., Ltd. focuses on R&D and production of
> embedded products as well as customization of embedded solutions.
> 
> Link: https://szbaijie.com/
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>

Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>

All the best,

Paul

> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 28784d66ae7b..095cf654787f 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -229,6 +229,8 @@ patternProperties:
>      description: Azoteq (Pty) Ltd
>    "^azw,.*":
>      description: Shenzhen AZW Technology Co., Ltd.
> +  "^baijie,.*":
> +    description: Shenzhen Baijie Technology Co., Ltd.
>    "^baikal,.*":
>      description: BAIKAL ELECTRONICS, JSC
>    "^bananapi,.*":
> -- 
> 2.54.0
> 
> 

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v2 2/3] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible

[Alexander Sverdlin]

Baijie HelperBoard A133 is a development board around their A133 Core
board. Introduce a compatible for both the Core and the development
boards.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---

Changelog:
v2:
- introduced baijie,helper-a133-core compatible for the Core (SoM) board

 Documentation/devicetree/bindings/arm/sunxi.yaml | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index e6443c266fa1..d7b9dec81165 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -96,6 +96,17 @@ properties:
           - const: allwinner,ba10-tvbox
           - const: allwinner,sun4i-a10
 
+      - description: Baijie Helper A133
+        items:
+          - const: baijie,helper-a133
+          - const: baijie,helper-a133-core
+          - const: allwinner,sun50i-a100
+
+      - description: HelperBoardA133 Core
+        items:
+          - const: baijie,helper-a133-core
+          - const: allwinner,sun50i-a100
+
       - description: BananaPi
         items:
           - const: lemaker,bananapi
-- 
2.54.0

Re: [PATCH v2 2/3] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

On Sun, May 10, 2026 at 10:16:39PM +0200, Alexander Sverdlin wrote:
> Baijie HelperBoard A133 is a development board around their A133 Core
> board. Introduce a compatible for both the Core and the development
> boards.
> 
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> ---
> 
> Changelog:
> v2:
> - introduced baijie,helper-a133-core compatible for the Core (SoM) board
> 
>  Documentation/devicetree/bindings/arm/sunxi.yaml | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> index e6443c266fa1..d7b9dec81165 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> @@ -96,6 +96,17 @@ properties:
>            - const: allwinner,ba10-tvbox
>            - const: allwinner,sun4i-a10
>  
> +      - description: Baijie Helper A133
> +        items:
> +          - const: baijie,helper-a133
> +          - const: baijie,helper-a133-core
> +          - const: allwinner,sun50i-a100
> +
> +      - description: HelperBoardA133 Core
> +        items:
> +          - const: baijie,helper-a133-core
> +          - const: allwinner,sun50i-a100

Does this make sense? Can the core board be used without a carrier?

> +
>        - description: BananaPi
>          items:
>            - const: lemaker,bananapi
> -- 
> 2.54.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 2/3] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible

[Alexander Sverdlin]

Hi Conor,

On Mon, 2026-05-11 at 17:08 +0100, Conor Dooley wrote:
> > Baijie HelperBoard A133 is a development board around their A133 Core
> > board. Introduce a compatible for both the Core and the development
> > boards.
> > 
> > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> > ---
> > 
> > Changelog:
> > v2:
> > - introduced baijie,helper-a133-core compatible for the Core (SoM) board
> > 
> >   Documentation/devicetree/bindings/arm/sunxi.yaml | 11 +++++++++++
> >   1 file changed, 11 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > index e6443c266fa1..d7b9dec81165 100644
> > --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> > +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > @@ -96,6 +96,17 @@ properties:
> >             - const: allwinner,ba10-tvbox
> >             - const: allwinner,sun4i-a10
> >   
> > +      - description: Baijie Helper A133
> > +        items:
> > +          - const: baijie,helper-a133
> > +          - const: baijie,helper-a133-core
> > +          - const: allwinner,sun50i-a100
> > +
> > +      - description: HelperBoardA133 Core
> > +        items:
> > +          - const: baijie,helper-a133-core
> > +          - const: allwinner,sun50i-a100
> 
> Does this make sense? Can the core board be used without a carrier?

such operation would be impractical at least, that's why in my v1
Core board didn't have its own compatible. Maybe I didn't understand
you correctly.

Shall I drop the above 4 lines, the compatible property from the
root in sun50i-a133-baije-core.dtsi and only leave
sun50i-a133-baijie-helper.dtb with 3-strings compatible as it is
now in v2?

-- 
Alexander Sverdlin.

Re: [PATCH v2 2/3] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]

On Mon, May 11, 2026 at 06:18:22PM +0200, Alexander Sverdlin wrote:
> Hi Conor,
> 
> On Mon, 2026-05-11 at 17:08 +0100, Conor Dooley wrote:
> > > Baijie HelperBoard A133 is a development board around their A133 Core
> > > board. Introduce a compatible for both the Core and the development
> > > boards.
> > > 
> > > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> > > ---
> > > 
> > > Changelog:
> > > v2:
> > > - introduced baijie,helper-a133-core compatible for the Core (SoM) board
> > > 
> > >   Documentation/devicetree/bindings/arm/sunxi.yaml | 11 +++++++++++
> > >   1 file changed, 11 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > index e6443c266fa1..d7b9dec81165 100644
> > > --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > @@ -96,6 +96,17 @@ properties:
> > >             - const: allwinner,ba10-tvbox
> > >             - const: allwinner,sun4i-a10
> > >   


> > > +
> > > +      - description: HelperBoardA133 Core
> > > +        items:
> > > +          - const: baijie,helper-a133-core
> > > +          - const: allwinner,sun50i-a100
> > 
> > Does this make sense? Can the core board be used without a carrier?
> 
> such operation would be impractical at least, that's why in my v1
> Core board didn't have its own compatible. Maybe I didn't understand
> you correctly.

I just wanted a comaptible for the SoM, so that there's a common
compatible for that if it ends up on another carrier. IIRC these Baijie
folks had another one on their site, but may be misremembering.

> 
> Shall I drop the above 4 lines, the compatible property from the
> root in sun50i-a133-baije-core.dtsi and only leave
> sun50i-a133-baijie-helper.dtb with 3-strings compatible as it is
> now in v2?

> > > +      - description: Baijie Helper A133
> > > +        items:
> > > +          - const: baijie,helper-a133
> > > +          - const: baijie,helper-a133-core
> > > +          - const: allwinner,sun50i-a100

What I wanted was just this, so trim it down to that and you can add
my Acked-by: Conor Dooley <conor.dooley@microchip.com>

~heers,
Conor.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 2/3] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]

Hi Alexander,

Le Sun 10 May 26, 22:16, Alexander Sverdlin a écrit :
> Baijie HelperBoard A133 is a development board around their A133 Core
> board. Introduce a compatible for both the Core and the development
> boards.
> 
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> ---
> 
> Changelog:
> v2:
> - introduced baijie,helper-a133-core compatible for the Core (SoM) board
> 
>  Documentation/devicetree/bindings/arm/sunxi.yaml | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> index e6443c266fa1..d7b9dec81165 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> @@ -96,6 +96,17 @@ properties:
>            - const: allwinner,ba10-tvbox
>            - const: allwinner,sun4i-a10
>  
> +      - description: Baijie Helper A133

Please use the correct naming from the vendor, which is: "Baijie
A133 HelperBoard"

> +        items:
> +          - const: baijie,helper-a133

Please make this: "baijie,helperboard-a133"

> +          - const: baijie,helper-a133-core

Please make this: "baijie,helperboard-a133-core"

Thanks!

> +          - const: allwinner,sun50i-a100
> +
> +      - description: HelperBoardA133 Core
> +        items:
> +          - const: baijie,helper-a133-core
> +          - const: allwinner,sun50i-a100
> +
>        - description: BananaPi
>          items:
>            - const: lemaker,bananapi
> -- 
> 2.54.0
> 
> 

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Alexander Sverdlin]

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.
+ */
+
+/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 */
+	};
+};
+
+&cpu0 {
+	cpu-supply = <&reg_dcdc2>;
+};
+
+&pio {
+	vcc-pb-supply = <&reg_dcdc1>;
+	vcc-pc-supply = <&reg_eldo1>;
+	vcc-pd-supply = <&reg_dcdc1>;
+	vcc-pe-supply = <&reg_dldo2>;
+	vcc-pf-supply = <&reg_dcdc1>;
+	vcc-pg-supply = <&reg_dldo1>;
+	vcc-ph-supply = <&reg_dcdc1>;
+};
+
+&mmc2 {
+	vmmc-supply = <&reg_dcdc1>;
+	vqmmc-supply = <&reg_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";
+};
+
+&reg_aldo1 {
+	regulator-always-on;
+	regulator-min-microvolt = <700000>;
+	regulator-max-microvolt = <3300000>;
+};
+
+&reg_aldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <700000>;
+	regulator-max-microvolt = <3300000>;
+};
+
+&reg_aldo3 {
+	regulator-always-on;
+	regulator-min-microvolt = <700000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-enable-ramp-delay = <1000>;
+};
+
+&reg_dcdc1 {
+	regulator-always-on;
+	regulator-min-microvolt = <1600000>;
+	regulator-max-microvolt = <3400000>;
+	regulator-name = "vcc-3v3";
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <500000>;
+	regulator-max-microvolt = <1300000>;
+	regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc3 {
+	regulator-always-on;
+	regulator-min-microvolt = <500000>;
+	regulator-max-microvolt = <1300000>;
+};
+
+&reg_dcdc4 {
+	regulator-always-on;
+	regulator-min-microvolt = <500000>;
+	regulator-max-microvolt = <1300000>;
+	regulator-name = "vdd-sys";
+};
+
+&reg_dcdc5 {
+	regulator-always-on;
+	regulator-min-microvolt = <800000>;
+	regulator-max-microvolt = <1840000>;
+	regulator-name = "vcc-dram";
+};
+
+/* DCDC6 unused */
+
+&reg_dldo1 {
+	regulator-min-microvolt = <700000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-enable-ramp-delay = <1000>;
+};
+
+&reg_dldo2 {
+	regulator-min-microvolt = <700000>;
+	regulator-max-microvolt = <3400000>;
+	regulator-enable-ramp-delay = <1000>;
+};
+
+&reg_dldo3 {
+	regulator-min-microvolt = <700000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-enable-ramp-delay = <1000>;
+	regulator-name = "avdd-csi";
+};
+
+&reg_dldo4 {
+	regulator-min-microvolt = <700000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-enable-ramp-delay = <1000>;
+};
+
+&reg_eldo1 {
+	regulator-min-microvolt = <700000>;
+	regulator-max-microvolt = <1900000>;
+	regulator-enable-ramp-delay = <1000>;
+};
+
+&reg_eldo2 {
+	regulator-min-microvolt = <700000>;
+	regulator-max-microvolt = <1900000>;
+	regulator-enable-ramp-delay = <1000>;
+	regulator-name = "dvdd-csi";
+};
+
+/* ELDO3 unused */
+
+&reg_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.
+ */
+
+/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 */
+		};
+	};
+};
+
+&mmc0 {
+	vmmc-supply = <&reg_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 = <&eth_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 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+	};
+};
+
+&usbphy {
+	status = "okay";
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&ohci0 {
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
-- 
2.54.0

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Andre Przywara]

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 = <&reg_dcdc2>;
> +};
> +
> +&pio {

The order of those referenced nodes is alphabetically by the label name. 
So this one goes further down.

> +	vcc-pb-supply = <&reg_dcdc1>;
> +	vcc-pc-supply = <&reg_eldo1>;
> +	vcc-pd-supply = <&reg_dcdc1>;
> +	vcc-pe-supply = <&reg_dldo2>;
> +	vcc-pf-supply = <&reg_dcdc1>;
> +	vcc-pg-supply = <&reg_dldo1>;
> +	vcc-ph-supply = <&reg_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 = <&reg_dcdc1>;
> +	vqmmc-supply = <&reg_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";
> +};
> +
> +&reg_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.

> +};
> +
> +&reg_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>;
> +};
> +
> +&reg_aldo3 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-enable-ramp-delay = <1000>;
> +};
> +
> +&reg_dcdc1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1600000>;
> +	regulator-max-microvolt = <3400000>;
> +	regulator-name = "vcc-3v3";
> +};
> +
> +&reg_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";
> +};
> +
> +&reg_dcdc3 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <500000>;
> +	regulator-max-microvolt = <1300000>;
> +};
> +
> +&reg_dcdc4 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <500000>;
> +	regulator-max-microvolt = <1300000>;
> +	regulator-name = "vdd-sys";
> +};
> +
> +&reg_dcdc5 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <800000>;
> +	regulator-max-microvolt = <1840000>;
> +	regulator-name = "vcc-dram";
> +};
> +
> +/* DCDC6 unused */
> +
> +&reg_dldo1 {
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-enable-ramp-delay = <1000>;
> +};
> +
> +&reg_dldo2 {
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <3400000>;
> +	regulator-enable-ramp-delay = <1000>;
> +};
> +
> +&reg_dldo3 {
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-enable-ramp-delay = <1000>;
> +	regulator-name = "avdd-csi";
> +};
> +
> +&reg_dldo4 {
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-enable-ramp-delay = <1000>;
> +};
> +
> +&reg_eldo1 {
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <1900000>;
> +	regulator-enable-ramp-delay = <1000>;
> +};
> +
> +&reg_eldo2 {
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <1900000>;
> +	regulator-enable-ramp-delay = <1000>;
> +	regulator-name = "dvdd-csi";
> +};
> +
> +/* ELDO3 unused */
> +
> +&reg_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 = <&reg_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 = <&eth_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";
> +};

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Alexander Sverdlin]

Hi Andre,

thanks for the quick feedback!

On Mon, 2026-05-11 at 13:44 +0200, Andre Przywara wrote:
> > --- /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.

That's the only thing I can do currently regarding BT: stabilize the
serial enumeration, because UART1 cannot be used for anything else
except BT module, because this is soldered inside "core" module.
We can avoid different tty enumeration, should the support for
BT be implemented in the future...

> 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.

So both the above BT and the WiFi is AW869A/AIC8800 combo chip, which
has neither upstream driver, nor [upstream] DT bindings. Even github
driver for AIC8800 doesn't seem to use DT, therefore it looks quite
pointless to me at this point to specify anything in the DT for the
chip which doesn't have the bindings idea even theoretically.

Nothing in the current DT shall block any future work on the AW869A
support though and the above "aliases" entry shall even guarantee
unchanged serial enumeration shall such support arise.

> > +&reg_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;
        ^^^^^^^^^^^^^^^^^^^
I suppose it's not being switcdhed of because of the above.
It's used for both PLL supply for the whole SoC + as analog voltage reference
for LRADC (the buttons you've noticed on the board are connected to
this ADC via a resistor ladder).

> 
> > +&reg_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?

Thanks for the hint! I'll put proper voltages into all regulators +
comment all the always-on regulators.

> 
> > 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

> 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.

It doesn't look to me as if Liontron had reg_vcc5v as its 5V "root" regulator.
It seems to be only used for reg_usb1_vbus, while HelperBoard A133 doesn't
have USB power control. The second issue with Helper/Core split is that
all PMIC story is inside Core board which has 5V input rail, while HelperBoard
around it has indeed 12V->5V DCDC regulator (similar to Liontron), but
putting it in the DT would introduce wierd dependency of the core to the
HelperBoard which carries it. Do you think it would make sense?

> 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.

Nice catch! I've missed the fact usbphy 0 has to be in peripheral mode,
not host mode. Will rework!

> > +&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?

There are two hubs, one on each usbphy. OTG side hub is even bus-powered,
two USB-A ports are always powered from the board's 12V->5V DCDC, no USB
load switches.
> 

-- 
Alexander Sverdlin.

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Chen-Yu Tsai]

On Mon, May 18, 2026 at 4:37 AM Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
>
> Hi Andre,
>
> thanks for the quick feedback!
>
> On Mon, 2026-05-11 at 13:44 +0200, Andre Przywara wrote:
> > > --- /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.
>
> That's the only thing I can do currently regarding BT: stabilize the
> serial enumeration, because UART1 cannot be used for anything else
> except BT module, because this is soldered inside "core" module.
> We can avoid different tty enumeration, should the support for
> BT be implemented in the future...
>
> > 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.
>
> So both the above BT and the WiFi is AW869A/AIC8800 combo chip, which
> has neither upstream driver, nor [upstream] DT bindings. Even github
> driver for AIC8800 doesn't seem to use DT, therefore it looks quite
> pointless to me at this point to specify anything in the DT for the
> chip which doesn't have the bindings idea even theoretically.
>
> Nothing in the current DT shall block any future work on the AW869A
> support though and the above "aliases" entry shall even guarantee
> unchanged serial enumeration shall such support arise.
>
> > > +&reg_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;
>         ^^^^^^^^^^^^^^^^^^^
> I suppose it's not being switcdhed of because of the above.
> It's used for both PLL supply for the whole SoC + as analog voltage reference
> for LRADC (the buttons you've noticed on the board are connected to
> this ADC via a resistor ladder).
>
> >
> > > +&reg_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?
>
> Thanks for the hint! I'll put proper voltages into all regulators +
> comment all the always-on regulators.

Please also give them proper names. If you have the schematics, then use
the names from that; otherwise just make up names matching their use.

> >
> > > 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
>
> > 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.
>
> It doesn't look to me as if Liontron had reg_vcc5v as its 5V "root" regulator.
> It seems to be only used for reg_usb1_vbus, while HelperBoard A133 doesn't
> have USB power control. The second issue with Helper/Core split is that
> all PMIC story is inside Core board which has 5V input rail, while HelperBoard
> around it has indeed 12V->5V DCDC regulator (similar to Liontron), but
> putting it in the DT would introduce wierd dependency of the core to the
> HelperBoard which carries it. Do you think it would make sense?

In that case I would probably put a 5v "fake root" regulator in the core
dtsi. And in combined dts, I'd then add the 12v "real root", and use that
as the supply for the 5v fake root.

Does that make sense?


ChenYu

> > 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.
>
> Nice catch! I've missed the fact usbphy 0 has to be in peripheral mode,
> not host mode. Will rework!
>
> > > +&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?
>
> There are two hubs, one on each usbphy. OTG side hub is even bus-powered,
> two USB-A ports are always powered from the board's 12V->5V DCDC, no USB
> load switches.
> >
>
> --
> Alexander Sverdlin.

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Alexander Sverdlin]

Hi Checn-Yu,

thanks for the review!

On Mon, 2026-05-18 at 11:30 +0800, Chen-Yu Tsai wrote:
> > > 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.
> > 
> > It doesn't look to me as if Liontron had reg_vcc5v as its 5V "root" regulator.
> > It seems to be only used for reg_usb1_vbus, while HelperBoard A133 doesn't
> > have USB power control. The second issue with Helper/Core split is that
> > all PMIC story is inside Core board which has 5V input rail, while HelperBoard
> > around it has indeed 12V->5V DCDC regulator (similar to Liontron), but
> > putting it in the DT would introduce wierd dependency of the core to the
> > HelperBoard which carries it. Do you think it would make sense?
> 
> In that case I would probably put a 5v "fake root" regulator in the core
> dtsi. And in combined dts, I'd then add the 12v "real root", and use that
> as the supply for the 5v fake root.
> 
> Does that make sense?

"core" board has some battery management schematics, switching the 5V,
I'll look into specifying this part in "core" .dtsi, maybe it will result
in some kind of regulator in "core" part. I'll send v4.

-- 
Alexander Sverdlin.

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Andre Przywara]

Hi Alexander,

On 5/17/26 22:38, Alexander Sverdlin wrote:
> Hi Andre,
> 
> thanks for the quick feedback!
> 
> On Mon, 2026-05-11 at 13:44 +0200, Andre Przywara wrote:
>>> --- /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.
> 
> That's the only thing I can do currently regarding BT: stabilize the
> serial enumeration, because UART1 cannot be used for anything else
> except BT module, because this is soldered inside "core" module.
> We can avoid different tty enumeration, should the support for
> BT be implemented in the future...
> 
>> 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.
> 
> So both the above BT and the WiFi is AW869A/AIC8800 combo chip, which
> has neither upstream driver, nor [upstream] DT bindings. Even github
> driver for AIC8800 doesn't seem to use DT, therefore it looks quite
> pointless to me at this point to specify anything in the DT for the
> chip which doesn't have the bindings idea even theoretically.
> 
> Nothing in the current DT shall block any future work on the AW869A
> support though and the above "aliases" entry shall even guarantee
> unchanged serial enumeration shall such support arise.

Fair enough for not providing DT nodes for those unsupported chips, but 
why do we need to force enumeration? For the eventual Bluetooth usage, 
the driver will find the respective serial interface by just looking at 
its parent interface. IIUC there is nothing referring to ttyS1 
explicitly. So we wouldn't really need an alias, would we?
I see that some boards do define an alias, but others with Bluetooth 
don't, which I think is the right thing to do. Which name the kernel 
comes up with for UART1 shouldn't matter in any way.

>>> +&reg_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;
>          ^^^^^^^^^^^^^^^^^^^
> I suppose it's not being switcdhed of because of the above.
> It's used for both PLL supply for the whole SoC + as analog voltage reference
> for LRADC (the buttons you've noticed on the board are connected to
> this ADC via a resistor ladder).

Ah, yeah, somehow missed that line. So as stated below, please use a 
descriptive regulator name.
Look at sun55i-a527-cubie-a5e.dts, I think is a more modern example of 
how to handle regulators best.

> 
>>
>>> +&reg_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?
> 
> Thanks for the hint! I'll put proper voltages into all regulators +
> comment all the always-on regulators.

Thanks!

> 
>>
>>> 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
> 
>> 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.
> 
> It doesn't look to me as if Liontron had reg_vcc5v as its 5V "root" regulator.
> It seems to be only used for reg_usb1_vbus, while HelperBoard A133 doesn't
> have USB power control. The second issue with Helper/Core split is that
> all PMIC story is inside Core board which has 5V input rail, while HelperBoard
> around it has indeed 12V->5V DCDC regulator (similar to Liontron), but
> putting it in the DT would introduce wierd dependency of the core to the
> HelperBoard which carries it. Do you think it would make sense?

Ah yeah, the Liontron is not the best example, we don't have the full 
description there, because this board misses schematics.
So look at sun55i-a527-cubie-a5e.dts instead, which uses the top level 
regulator correctly. We didn't traditionally do this with the A64 boards 
using the AXP803, and just learned to live with those dummy supplies 
created by the kernel, but for new boards we should do better.

Regarding the board/SoM split: You should have a fixed regulator in the 
SoM .dtsi reflecting the 5V input pin(s), and then using that as the VIN 
  supply for the various PMIC rails, as the Cubie A5E does. This would 
mimic some barrel connector on a standard board: the voltage is applied 
"by the user", externally.
So in this SoM .dtsi node, there is no vin-supply property, but you add 
that in the board .dts:

&reg_vcc5v {
	vin-supply = <&reg_vcc12v5v>;
};
Please come up with some better names than I just did ;-) Maybe 
something like reg_vcc5v_som to make this clearer.

And then you have that 12V->5V regulator described in the board .dts, 
along with a parent-less 12V regulator, check sun55i-t527-avaota-a1.dts 
for an example.

That should work cleanly, I think.

>> 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.
> 
> Nice catch! I've missed the fact usbphy 0 has to be in peripheral mode,
> not host mode. Will rework!

I guess that's the same situation as in the other recent boards using 
USB-C: they hardwired it to peripheral mode, although you can use this 
as a host port with some tricks, check sun50i-h616-orangepi-zero.dtsi, 
and copy this comment, should it apply.

>>> +&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?
> 
> There are two hubs, one on each usbphy. OTG side hub is even bus-powered,

What do you mean with OTG side hub, exactly? Is there a hub on USB0? How 
does this work, then?

Cheers,
Andre

> two USB-A ports are always powered from the board's 12V->5V DCDC, no USB
> load switches.
>>
> 

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Alexander Sverdlin]

Hi Andre,

On Mon, 2026-05-18 at 13:16 +0200, Andre Przywara wrote:
> > > 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?
> > 
> > There are two hubs, one on each usbphy. OTG side hub is even bus-powered,
> 
> What do you mean with OTG side hub, exactly? Is there a hub on USB0? How 
> does this work, then?

the upstream port of this hub is wired to the USB-C connector, one port has
CH340E USB-UART on it for the console, the other port goes to the SoC usbphy 0.
So it would be "peripheral" only, I suppose.

-- 
Alexander Sverdlin.

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

Hi Alexander,

Le Mon 18 May 26, 13:29, Alexander Sverdlin a écrit :
> Hi Andre,
> 
> On Mon, 2026-05-18 at 13:16 +0200, Andre Przywara wrote:
> > > > 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?
> > > 
> > > There are two hubs, one on each usbphy. OTG side hub is even bus-powered,
> > 
> > What do you mean with OTG side hub, exactly? Is there a hub on USB0? How 
> > does this work, then?
> 
> the upstream port of this hub is wired to the USB-C connector, one port has
> CH340E USB-UART on it for the console, the other port goes to the SoC usbphy 0.
> So it would be "peripheral" only, I suppose.

Yes like I explained in my other email there used to be a USB0 ID pin in
earlier revisions of the board but it was reassigned and USB0 is now
sitting behind the hub so it should be peripheral only.

All the best,

Paul

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Andre Przywara]

Hi,

On 5/18/26 13:29, Alexander Sverdlin wrote:
> Hi Andre,
> 
> On Mon, 2026-05-18 at 13:16 +0200, Andre Przywara wrote:
>>>> 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?
>>>
>>> There are two hubs, one on each usbphy. OTG side hub is even bus-powered,
>>
>> What do you mean with OTG side hub, exactly? Is there a hub on USB0? How
>> does this work, then?
> 
> the upstream port of this hub is wired to the USB-C connector, one port has
> CH340E USB-UART on it for the console, the other port goes to the SoC usbphy 0.
> So it would be "peripheral" only, I suppose.

Ah, that's interesting, I was wondering about this, but don't think we 
have seen this before.
So yeah, then it's definitely peripheral only. And please state in the 
comment that it's connected to the downstream port of a hub, so changing 
it to "host" will not work.

Thanks,
Andre

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Chen-Yu Tsai]

On Mon, May 18, 2026 at 7:16 PM Andre Przywara <andre.przywara@arm.com> wrote:
>
> Hi Alexander,
>
> On 5/17/26 22:38, Alexander Sverdlin wrote:
> > Hi Andre,
> >
> > thanks for the quick feedback!
> >
> > On Mon, 2026-05-11 at 13:44 +0200, Andre Przywara wrote:
> >>> --- /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.
> >
> > That's the only thing I can do currently regarding BT: stabilize the
> > serial enumeration, because UART1 cannot be used for anything else
> > except BT module, because this is soldered inside "core" module.
> > We can avoid different tty enumeration, should the support for
> > BT be implemented in the future...
> >
> >> 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.
> >
> > So both the above BT and the WiFi is AW869A/AIC8800 combo chip, which
> > has neither upstream driver, nor [upstream] DT bindings. Even github
> > driver for AIC8800 doesn't seem to use DT, therefore it looks quite
> > pointless to me at this point to specify anything in the DT for the
> > chip which doesn't have the bindings idea even theoretically.
> >
> > Nothing in the current DT shall block any future work on the AW869A
> > support though and the above "aliases" entry shall even guarantee
> > unchanged serial enumeration shall such support arise.
>
> Fair enough for not providing DT nodes for those unsupported chips, but
> why do we need to force enumeration? For the eventual Bluetooth usage,
> the driver will find the respective serial interface by just looking at
> its parent interface. IIUC there is nothing referring to ttyS1
> explicitly. So we wouldn't really need an alias, would we?
> I see that some boards do define an alias, but others with Bluetooth
> don't, which I think is the right thing to do. Which name the kernel
> comes up with for UART1 shouldn't matter in any way.

It does provide a hint for any users enabling more UARTs and adding
aliases for them that they should number them starting from 2? And
just stable numbering overall.


ChenYu

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Alexander Sverdlin]

Hi Chen-Yu,

On Mon, 2026-05-18 at 22:47 +0800, Chen-Yu Tsai wrote:
> > > > > --- /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.
> > > 
> > > That's the only thing I can do currently regarding BT: stabilize the
> > > serial enumeration, because UART1 cannot be used for anything else
> > > except BT module, because this is soldered inside "core" module.
> > > We can avoid different tty enumeration, should the support for
> > > BT be implemented in the future...
> > > 
> > > > 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.
> > > 
> > > So both the above BT and the WiFi is AW869A/AIC8800 combo chip, which
> > > has neither upstream driver, nor [upstream] DT bindings. Even github
> > > driver for AIC8800 doesn't seem to use DT, therefore it looks quite
> > > pointless to me at this point to specify anything in the DT for the
> > > chip which doesn't have the bindings idea even theoretically.
> > > 
> > > Nothing in the current DT shall block any future work on the AW869A
> > > support though and the above "aliases" entry shall even guarantee
> > > unchanged serial enumeration shall such support arise.
> > 
> > Fair enough for not providing DT nodes for those unsupported chips, but
> > why do we need to force enumeration? For the eventual Bluetooth usage,
> > the driver will find the respective serial interface by just looking at
> > its parent interface. IIUC there is nothing referring to ttyS1
> > explicitly. So we wouldn't really need an alias, would we?
> > I see that some boards do define an alias, but others with Bluetooth
> > don't, which I think is the right thing to do. Which name the kernel
> > comes up with for UART1 shouldn't matter in any way.
> 
> It does provide a hint for any users enabling more UARTs and adding
> aliases for them that they should number them starting from 2? And
> just stable numbering overall.

that's exactly what I had in mind, as the the status of BT/WiFi might
change in future, we might want to make UART1=tty1 and UART2=tty2
today and this will not change with potentially coming AW869A support.

But that's not an essential feature to me, just nice to have.

-- 
Alexander Sverdlin.

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Board-level regulator constraints are dangerously overly permissive, reflecting PMIC hardware limits instead of the board's electrical design.
- [Medium] Mismatch between the commit message and device tree configuration regarding the PMIC model.
- [Medium] Missing DT bindings for new compatible strings and vendor prefix.
- [Low] Typo in the new device tree include filename.
--

commit 995a0c0548d7cc620abeca1987efff325083911e
Author: Alexander Sverdlin <alexander.sverdlin@gmail.com>

arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

This commit adds initial support for the Baijie Helper A133 board and its
core SBC. It enables UART, PMU, eMMC, USB, and Ethernet peripherals.

> 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

The commit message mentions an AXP707 PMIC, but the device tree configures
an x-powers,axp803 PMIC. Is AXP707 a typo in the message, or does the
hardware actually use an AXP707?

Also, are the new compatible strings baijie,helper-a133 and
baijie,helper-a133-core, along with the baijie vendor prefix, included in a
separate dt-bindings patch? I don't see them documented here, which might
cause schema validation failures.

> 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 0000000000000..65b094f30bf5b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi

This isn't a bug, but there is a typo in the filename. The vendor prefix is
baijie but the file is named baije.

[ ... ]

> +&reg_dcdc1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1600000>;
> +	regulator-max-microvolt = <3400000>;
> +	regulator-name = "vcc-3v3";
> +};

Does this overly permissive voltage range match the physical board design?

Since this rail is named vcc-3v3 and shared by multiple 3.3V IO banks,
allowing the voltage to drop to 1.6V could undervolt other components if a
driver dynamically requests a lower voltage. 

Could the constraints be tightened to match the safe operating limits of
the board layout, rather than the PMIC hardware capabilities?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260510201644.4143710-1-alexander.sverdlin@gmail.com?part=3

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 11951 bytes --]

Hi Alexander,

Le Sun 10 May 26, 22:16, Alexander Sverdlin a écrit :
> Baijie Helper A133 board is a development board around Baijie A133 Core
> SBC. Features:

Just in case you missed it, there was a previous submission for this
board which wasn't followed up on.

I also have one of this board and wanted to respin support, but it looks
like you beat me to it :)

Thanks for working on this!

Please change the naming to "Baijie HelperBoard A133" and "Baijie A133
HelperBoard Core" to align with the vendor terminology and rename the
files as:
- sun50i-a133-helperboard.dts
- sun50i-a133-helperboard-core.dtsi

> - 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.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a100.dtsi"
> +#include "sun50i-a100-cpu-opp.dtsi"
> +
> +/{

You could add a model here while at it, even though it would generally
be overwritten.

> +	compatible = "baijie,helper-a133-core",
> +		     "allwinner,sun50i-a100";
> +
> +	aliases {
> +		serial1 = &uart1;	/* BT module */

Not sure this is reallyt useful.

> +	};

You should add:

	chosen {
		stdout-path = "serial0:115200n8";
	};

As well as the incoming 5v regulator:

	reg_vcc5v: vcc5v {
		compatible = "regulator-fixed";
		regulator-name = "vcc-5v";
		regulator-min-microvolt = <5000000>;
		regulator-max-microvolt = <5000000>;
		regulator-always-on;
	};

> +};
> +
> +&cpu0 {
> +	cpu-supply = <&reg_dcdc2>;
> +};
> +
> +&pio {
> +	vcc-pb-supply = <&reg_dcdc1>;
> +	vcc-pc-supply = <&reg_eldo1>;
> +	vcc-pd-supply = <&reg_dcdc1>;
> +	vcc-pe-supply = <&reg_dldo2>;
> +	vcc-pf-supply = <&reg_dcdc1>;
> +	vcc-pg-supply = <&reg_dldo1>;
> +	vcc-ph-supply = <&reg_dcdc1>;
> +};
> +
> +&mmc2 {

mmc2 goes before pio (alphanum sorting).

> +	vmmc-supply = <&reg_dcdc1>;
> +	vqmmc-supply = <&reg_eldo1>;
> +	cap-mmc-hw-reset;
> +	non-removable;
> +	bus-width = <8>;
> +	mmc-ddr-1_8v;
> +	mmc-hs200-1_8v;
> +	status = "okay";

You can add:
	max-frequency = <100000000>;
	cap-mmc-highspeed;

> +};
> +
> +&r_i2c0 {
> +	status = "okay";
> +
> +	axp803: pmic@34 {
> +		compatible = "x-powers,axp803";
> +		reg = <0x34>;
> +		interrupt-parent = <&r_intc>;
> +		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;

You can also add:
		x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */

		aldoin-supply = <&reg_vcc5v>;
		dldoin-supply = <&reg_vcc5v>;
		eldoin-supply = <&reg_vcc5v>;
		fldoin-supply = <&reg_dcdc5>;
		vin1-supply = <&reg_vcc5v>;
		vin2-supply = <&reg_vcc5v>;
		vin3-supply = <&reg_vcc5v>;
		vin4-supply = <&reg_vcc5v>;
		vin5-supply = <&reg_vcc5v>;
		vin6-supply = <&reg_vcc5v>;


> +	};
> +};
> +
> +#include "axp803.dtsi"
> +
> +&ac_power_supply {
> +	status = "okay";
> +};
> +
> +&reg_aldo1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <3300000>;

Should be:
	regulator-min-microvolt = <1800000>;
	regulator-max-microvolt = <1800000>;
	regulator-name = "vcc-pll-avcc";

> +};
> +
> +&reg_aldo2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <3300000>;

Should be:
	regulator-min-microvolt = <1800000>;
	regulator-max-microvolt = <1800000>;
	regulator-name = "vcc-dram-lpddr";

> +};
> +
> +&reg_aldo3 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-enable-ramp-delay = <1000>;

Should be:
	regulator-min-microvolt = <1800000>;
	regulator-max-microvolt = <1800000>;
	regulator-name = "vcc-pl";

> +};
> +
> +&reg_dcdc1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1600000>;
> +	regulator-max-microvolt = <3400000>;
> +	regulator-name = "vcc-3v3";

Should be:
	regulator-min-microvolt = <3300000>;
	regulator-max-microvolt = <3300000>;
	regulator-name = "vcc-io-usb-pd-nand-3v3";

> +};
> +
> +&reg_dcdc2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <500000>;
> +	regulator-max-microvolt = <1300000>;

Should be:
	regulator-min-microvolt = <900000>;
	regulator-max-microvolt = <1300000>;


> +	regulator-name = "vdd-cpu";
> +};
> +
> +&reg_dcdc3 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <500000>;
> +	regulator-max-microvolt = <1300000>;
> +};

DCDC3 is polyphased with DCDC2, so remove this one and add:
/* DCDC3 is polyphased with DCDC2 */

> +
> +&reg_dcdc4 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <500000>;
> +	regulator-max-microvolt = <1300000>;
> +	regulator-name = "vdd-sys";

Should be:
	regulator-min-microvolt = <810000>;
	regulator-max-microvolt = <990000>;
	regulator-name = "vcc-usb-sys";

> +};
> +
> +&reg_dcdc5 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <800000>;
> +	regulator-max-microvolt = <1840000>;
> +	regulator-name = "vcc-dram";

Should be:
	regulator-min-microvolt = <1100000>;
	regulator-max-microvolt = <1100000>;
	regulator-name = "vcc-dram-2";

ALDO2 is the main DRAM supply, this is the second one.

> +};
> +
> +/* DCDC6 unused */
> +
> +&reg_dldo1 {
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-enable-ramp-delay = <1000>;

Should be:
	regulator-min-microvolt = <1800000>;
	regulator-max-microvolt = <1800000>;
	regulator-name = "vcc-pg";

> +};
> +
> +&reg_dldo2 {
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <3400000>;
> +	regulator-enable-ramp-delay = <1000>;

Should be:
	regulator-min-microvolt = <1800000>;
	regulator-max-microvolt = <1800000>;
	regulator-name = "vcc-csi-pe";

> +};
> +
> +&reg_dldo3 {
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-enable-ramp-delay = <1000>;
> +	regulator-name = "avdd-csi";

Should be:
	regulator-min-microvolt = <2800000>;
	regulator-max-microvolt = <2800000>;
	regulator-name = "ldo-avdd-csi";

> +};
> +
> +&reg_dldo4 {
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-enable-ramp-delay = <1000>;

Should be:
	regulator-min-microvolt = <2800000>;
	regulator-max-microvolt = <2800000>;
	regulator-name = "ldo-avdd-csi";

> +};

You can add:

&reg_drivevbus {
	regulator-name = "usb0-vbus";
	status = "okay";
};

> +
> +&reg_eldo1 {
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <1900000>;
> +	regulator-enable-ramp-delay = <1000>;

Should be:
	regulator-min-microvolt = <1800000>;
	regulator-max-microvolt = <1800000>;
	regulator-name = "vcc-pc-efuse-lvds-cpvin-mcsi";


> +};
> +
> +&reg_eldo2 {
> +	regulator-min-microvolt = <700000>;
> +	regulator-max-microvolt = <1900000>;

Should be:
	regulator-min-microvolt = <1200000>;
	regulator-max-microvolt = <1200000>;

> +	regulator-enable-ramp-delay = <1000>;
> +	regulator-name = "dvdd-csi";
> +};
> +
> +/* ELDO3 unused */
> +
> +&reg_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.
> + */
> +
> +/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;

The is best added to the core dtsi.

> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";

Ditto.

> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		led {
> +			function = LED_FUNCTION_INDICATOR;
> +			color = <LED_COLOR_ID_GREEN>;
> +			gpios = <&pio 7 13 GPIO_ACTIVE_LOW>;	/* PH13 */
> +		};
> +	};
> +};
> +
> +&mmc0 {
> +	vmmc-supply = <&reg_dcdc1>;
> +	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;	/* PF6 */
> +	bus-width = <4>;
> +	status = "okay";

You can add:
	disable-wp;

> +};
> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_pb_pins>;
> +	status = "okay";
> +};
> +
> +&rgmii0_pins {
> +	drive-strength = <30>;
> +};

Sorting is also incorrect throughout the file, please use alphanum
sorting for phandle-based overwrites.

> +
> +&emac0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&rgmii0_pins>;
> +	phy-handle = <&eth_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 {
> +		compatible = "ethernet-phy-ieee802.3-c22";
> +		reg = <1>;
> +	};
> +};
> +
> +&usbphy {
> +	status = "okay";

You can add:
	usb0_vbus-supply = <&reg_dcdc1>;
	usb1_vbus-supply = <&reg_dcdc4>;

> +};
> +
> +&ehci0 {
> +	status = "okay";
> +};

AFAIK there is no ID pin so ehci0/ohci0 will not be used.
It seems that version 1.7 of the board used PH0 as USB0 ID pin but
version 2.5 has reassigned PH8 to LCD reset.

> +&ohci0 {
> +	status = "okay";
> +};
> +
> +&ehci1 {
> +	status = "okay";
> +};
> +
> +&ohci1 {
> +	status = "okay";
> +};
> -- 
> 2.54.0
> 
> 

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Alexander Sverdlin]

Hi Paul,

On Mon, 2026-05-18 at 13:52 +0200, Paul Kocialkowski wrote:
> Just in case you missed it, there was a previous submission for this
> board which wasn't followed up on.
> 
> I also have one of this board and wanted to respin support, but it looks
> like you beat me to it :)

thanks for the hint!
Do you mean this series:
https://lore.kernel.org/all/20241227-a133-display-support-v1-0-13b52f71fb14@linumiz.com/
?

I've missed it indeed! I'll look into it!

-- 
Alexander Sverdlin.

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]

Hi Alexander,

Le Mon 18 May 26, 14:09, Alexander Sverdlin a écrit :
> Hi Paul,
> 
> On Mon, 2026-05-18 at 13:52 +0200, Paul Kocialkowski wrote:
> > Just in case you missed it, there was a previous submission for this
> > board which wasn't followed up on.
> > 
> > I also have one of this board and wanted to respin support, but it looks
> > like you beat me to it :)
> 
> thanks for the hint!
> Do you mean this series:
> https://lore.kernel.org/all/20241227-a133-display-support-v1-0-13b52f71fb14@linumiz.com/
> ?
> 
> I've missed it indeed! I'll look into it!

Yes that's the one! But I don't think there are features that your
series is missing, as long as you apply the suggestions I made earlier.

I also have a U-Boot config ready for it, which I could send once the
device-trees are merged on the kernel side. I could send it to you if
you're interested.

I will also get back to you about your TF-A series so we can move all of
this forward!

By the way it's good to wait a few days before sending new versions of
patch series, to avoid overwhelmind the developers.

All the best,

Paul

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Alexander Sverdlin]

Hi Paul,

On Mon, 2026-05-18 at 16:14 +0200, Paul Kocialkowski wrote:
> I also have a U-Boot config ready for it, which I could send once the
> device-trees are merged on the kernel side. I could send it to you if
> you're interested.

I do have one as well, I'm testing all open-source ;-) from ATF-upwards,
just thought U-Boot would require ATF merged and kernel DT merged
because of OF_UPSTREAM in U-Boot. But I'd be happy to sync when we get
there.

-- 
Alexander Sverdlin.

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

Alexander,

Le Mon 18 May 26, 16:40, Alexander Sverdlin a écrit :
> Hi Paul,
> 
> On Mon, 2026-05-18 at 16:14 +0200, Paul Kocialkowski wrote:
> > I also have a U-Boot config ready for it, which I could send once the
> > device-trees are merged on the kernel side. I could send it to you if
> > you're interested.
> 
> I do have one as well, I'm testing all open-source ;-) from ATF-upwards,
> just thought U-Boot would require ATF merged and kernel DT merged
> because of OF_UPSTREAM in U-Boot. But I'd be happy to sync when we get
> there.

Sure, let's keep in touch about this!

I also have the 7" LVDS LCD that goes with it, which was supported by
Parthiban's initial series (but needs rework, and it seems that he's
unlikely to do it). I also have the 5" MIPI LCD but it's less likely
that it will be supported, although I have seen dirty patches to make
some other MIPI panel work with A133.

We'll need PWM for it which should be a follow-up to the current H616
PWM series from Richard Genoud.

Other than that there is a PCF8563TS RTC on the board, audio stuff:
speaker (which I have) mic and headphones and a GPIO beeper which could
be added.

Do you have other A133 boards that you're interested in?
I also have:
- KICKPI K5C
- DshanPi-R818
- Logicom La Tab 129
- Trimui Brick

And have some WIP device-trees and u-boot for most of them.

All the best,

Paul

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Alexander Sverdlin]

Paul,

On Mon, 2026-05-18 at 16:56 +0200, Paul Kocialkowski wrote:
> I also have the 7" LVDS LCD that goes with it, which was supported by
> Parthiban's initial series (but needs rework, and it seems that he's
> unlikely to do it). I also have the 5" MIPI LCD but it's less likely
> that it will be supported, although I have seen dirty patches to make
> some other MIPI panel work with A133.
> 
> We'll need PWM for it which should be a follow-up to the current H616
> PWM series from Richard Genoud.

I didn't have video in my mind, but...

> Other than that there is a PCF8563TS RTC on the board, audio stuff:
> speaker (which I have) mic and headphones and a GPIO beeper which could
> be added.

... would be happy to work on higher quality audio I/O support after
we get the base merged...

> Do you have other A133 boards that you're interested in?
> I also have:
> - KICKPI K5C
> - DshanPi-R818
> - Logicom La Tab 129
> - Trimui Brick

thanks! I'll try to concentrate on the SzBaijie Core/Helper boards
I have for now.

-- 
Alexander Sverdlin.

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Andre Przywara]

On Mon, 18 May 2026 16:40:11 +0200
Alexander Sverdlin <alexander.sverdlin@gmail.com> wrote:

Hi Alexander,

> On Mon, 2026-05-18 at 16:14 +0200, Paul Kocialkowski wrote:
> > I also have a U-Boot config ready for it, which I could send once the
> > device-trees are merged on the kernel side. I could send it to you if
> > you're interested.  
> 
> I do have one as well, I'm testing all open-source ;-) from ATF-upwards,
> just thought U-Boot would require ATF merged and kernel DT merged
> because of OF_UPSTREAM in U-Boot. But I'd be happy to sync when we get
> there.

There is no requirement for upstream TF-A support when adding U-Boot
support. All we need is *some* blob to feed to the U-Boot build system.
There is one dependency, though: the TF-A load address. Mostly that's
some quite obvious SRAM address, but in this case it turned out that
the SRAM on the A133 is probably too small, so it looks like we need to
move to DRAM. Not sure how we handle the transition, but at the moment
there is just one board supported, so it will be slightly painful for a
few weeks or months, I am afraid.

And yes, DTs need to be merged into Linus' tree to be considered, so
this series of yours is exactly the right thing to do. There are
regular syncs between the DT rebasing repo and U-Boot, but we can
manually cherry-pick patches once they have reached the mainline tree.
But feel free to send U-Boot patches once this series has been ACKed,
so the defconfig file can be reviewed and then queued, to wait for
the DT to appear in v7.2-rc1, for instance.

Cheers,
Andre

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Alexander Sverdlin]

Hi Paul,

thanks for the review!

On Mon, 2026-05-18 at 13:52 +0200, Paul Kocialkowski wrote:
> 
> > 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

[]

> You should add:
> 
> 	chosen {
> 		stdout-path = "serial0:115200n8";
> 	};

I actually have it in .dts, but it's theoretically possible to deploy
the core board in a way that serial0 is *not* a console, so the above
probably will not be valid in all cases in .dtsi.

> 
> 
> 
> > +&reg_dcdc2 {
> > +	regulator-always-on;
> > +	regulator-min-microvolt = <500000>;
> > +	regulator-max-microvolt = <1300000>;
> 
> Should be:
> 	regulator-min-microvolt = <900000>;
> 	regulator-max-microvolt = <1300000>;

0.81..1.2v according to A133 Datasheet Revision 1.1 Jul.14, 2020?

> 
> > +&reg_dcdc4 {
> > +	regulator-always-on;
> > +	regulator-min-microvolt = <500000>;
> > +	regulator-max-microvolt = <1300000>;
> > +	regulator-name = "vdd-sys";
> 
> Should be:
> 	regulator-min-microvolt = <810000>;
> 	regulator-max-microvolt = <990000>;
> 	regulator-name = "vcc-usb-sys";

I'm a bit puzzled here: datasheet says 0.9..1.0v
and it has no "Typ" value, similar to VDD_CPU, but
VDD_SYS is not part of OPP tables, so who is going
to adjust this? Or shall it be just

regulator-min-microvolt = <950000>;
regulator-max-microvolt = <950000>;

?

> 
> > +};
> > +
> > +&reg_dcdc5 {
> > +	regulator-always-on;
> > +	regulator-min-microvolt = <800000>;
> > +	regulator-max-microvolt = <1840000>;
> > +	regulator-name = "vcc-dram";
> 
> Should be:
> 	regulator-min-microvolt = <1100000>;
> 	regulator-max-microvolt = <1100000>;
> 	regulator-name = "vcc-dram-2";
> 
> ALDO2 is the main DRAM supply, this is the second one.

Core schematics mentions 1.1V/1.2/1.35/1.5 on this rail...
Currently U-Boot has CONFIG_AXP_DCDC5_VOLT=1100, but potentially
this is adjustable, right? At some point LPDDR4 chips they
are soldering today will be unavailable. And in the current
market it will happen rather sooner than later...

> 
> > +};
> > +
> > +/* DCDC6 unused */
> > +
> > +&reg_dldo1 {
> > +	regulator-min-microvolt = <700000>;
> > +	regulator-max-microvolt = <3300000>;
> > +	regulator-enable-ramp-delay = <1000>;
> 
> Should be:
> 	regulator-min-microvolt = <1800000>;
> 	regulator-max-microvolt = <1800000>;
> 	regulator-name = "vcc-pg";

Do suggest to drop vendor's

regulator-enable-ramp-delay = <1000>;

in all cases?

> > 
> > 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

[]

> > +	aliases {
> > +		serial0 = &uart0;
> 
> The is best added to the core dtsi.
> 
> > +	};
> > +
> > +	chosen {
> > +		stdout-path = "serial0:115200n8";
> 
> Ditto.

But it only physically materializes in Helperboard, the carrier.
Potentially this one can be left floating or used for something else.

-- 
Alexander Sverdlin.

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 5275 bytes --]

Hi Alexander,

On Mon 18 May 26, 22:05, Alexander Sverdlin wrote:
> Hi Paul,
> 
> thanks for the review!
> 
> On Mon, 2026-05-18 at 13:52 +0200, Paul Kocialkowski wrote:
> > 
> > > 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
> 
> []
> 
> > You should add:
> > 
> > 	chosen {
> > 		stdout-path = "serial0:115200n8";
> > 	};
> 
> I actually have it in .dts, but it's theoretically possible to deploy
> the core board in a way that serial0 is *not* a console, so the above
> probably will not be valid in all cases in .dtsi.

Yes I figured out later that it was in the board dts file and I initially
assumed it was missing entirely.

In practice both options are fine, although the reference software does
hardcode UART0 as debug serial.

> > > +&reg_dcdc2 {
> > > +	regulator-always-on;
> > > +	regulator-min-microvolt = <500000>;
> > > +	regulator-max-microvolt = <1300000>;
> > 
> > Should be:
> > 	regulator-min-microvolt = <900000>;
> > 	regulator-max-microvolt = <1300000>;
> 
> 0.81..1.2v according to A133 Datasheet Revision 1.1 Jul.14, 2020?

I guess the initial values are taken from the allwinner-perf1 board dts.

The 900 mV-1.3 V range matches the CPU OPPs (although it really only goes up
to 1.13 V). Maybe down to 810 mV does work, but we don't have an OPP for it.
I think I took these values from the reference BSP for the board.

Also it would be good to add:

	regulator-name = "vdd-cpux";

> > 
> > > +&reg_dcdc4 {
> > > +	regulator-always-on;
> > > +	regulator-min-microvolt = <500000>;
> > > +	regulator-max-microvolt = <1300000>;
> > > +	regulator-name = "vdd-sys";
> > 
> > Should be:
> > 	regulator-min-microvolt = <810000>;
> > 	regulator-max-microvolt = <990000>;
> > 	regulator-name = "vcc-usb-sys";
> 
> I'm a bit puzzled here: datasheet says 0.9..1.0v
> and it has no "Typ" value, similar to VDD_CPU, but
> VDD_SYS is not part of OPP tables, so who is going
> to adjust this? Or shall it be just
> 
> regulator-min-microvolt = <950000>;
> regulator-max-microvolt = <950000>;
> 
> ?

Yes the reference BSP runs it at 950 mV, LGTM.

> 
> > 
> > > +};
> > > +
> > > +&reg_dcdc5 {
> > > +	regulator-always-on;
> > > +	regulator-min-microvolt = <800000>;
> > > +	regulator-max-microvolt = <1840000>;
> > > +	regulator-name = "vcc-dram";
> > 
> > Should be:
> > 	regulator-min-microvolt = <1100000>;
> > 	regulator-max-microvolt = <1100000>;
> > 	regulator-name = "vcc-dram-2";
> > 
> > ALDO2 is the main DRAM supply, this is the second one.
> 
> Core schematics mentions 1.1V/1.2/1.35/1.5 on this rail...
> Currently U-Boot has CONFIG_AXP_DCDC5_VOLT=1100, but potentially
> this is adjustable, right? At some point LPDDR4 chips they
> are soldering today will be unavailable. And in the current
> market it will happen rather sooner than later...

It is part of the LPDDR4 spec that the main voltage should be 1.8 V and
the second and I/O buffer ones should be 1.1 V. See JESD209-4D Table 180 —
Recommended DC Operating Conditions.

Maybe they jsut copied this comment from a reference design that allows for
other types of DRAM too. In any case their BSP hardcodes 1.1 V anyway.

> > 
> > > +};
> > > +
> > > +/* DCDC6 unused */
> > > +
> > > +&reg_dldo1 {
> > > +	regulator-min-microvolt = <700000>;
> > > +	regulator-max-microvolt = <3300000>;
> > > +	regulator-enable-ramp-delay = <1000>;
> > 
> > Should be:
> > 	regulator-min-microvolt = <1800000>;
> > 	regulator-max-microvolt = <1800000>;
> > 	regulator-name = "vcc-pg";
> 
> Do suggest to drop vendor's
> 
> regulator-enable-ramp-delay = <1000>;
> 
> in all cases?

Well we generally don't have the delays in the axp regulator definitions and
it works well without them, but I guess they don't hurt either.

In practice many drivers will have a delay after a regulator power on anyway
because we generally expect that hardware needs some time to power up,
in addition to the regulator. So all in all it's rarely critical.

> 
> > > 
> > > 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
> 
> []
> 
> > > +	aliases {
> > > +		serial0 = &uart0;
> > 
> > The is best added to the core dtsi.
> > 
> > > +	};
> > > +
> > > +	chosen {
> > > +		stdout-path = "serial0:115200n8";
> > 
> > Ditto.
> 
> But it only physically materializes in Helperboard, the carrier.
> Potentially this one can be left floating or used for something else.

Yes fair enough, I'm happy with having it on the helperboard dts file.

All the best,

Paul

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Chen-Yu Tsai]

On Tue, May 19, 2026 at 5:46 AM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> Hi Alexander,
>
> On Mon 18 May 26, 22:05, Alexander Sverdlin wrote:
> > Hi Paul,
> >
> > thanks for the review!
> >
> > On Mon, 2026-05-18 at 13:52 +0200, Paul Kocialkowski wrote:
> > >
> > > > 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
> >
> > []
> >
> > > You should add:
> > >
> > >     chosen {
> > >             stdout-path = "serial0:115200n8";
> > >     };
> >
> > I actually have it in .dts, but it's theoretically possible to deploy
> > the core board in a way that serial0 is *not* a console, so the above
> > probably will not be valid in all cases in .dtsi.
>
> Yes I figured out later that it was in the board dts file and I initially
> assumed it was missing entirely.
>
> In practice both options are fine, although the reference software does
> hardcode UART0 as debug serial.
>
> > > > +&reg_dcdc2 {
> > > > + regulator-always-on;
> > > > + regulator-min-microvolt = <500000>;
> > > > + regulator-max-microvolt = <1300000>;
> > >
> > > Should be:
> > >     regulator-min-microvolt = <900000>;
> > >     regulator-max-microvolt = <1300000>;
> >
> > 0.81..1.2v according to A133 Datasheet Revision 1.1 Jul.14, 2020?
>
> I guess the initial values are taken from the allwinner-perf1 board dts.
>
> The 900 mV-1.3 V range matches the CPU OPPs (although it really only goes up
> to 1.13 V). Maybe down to 810 mV does work, but we don't have an OPP for it.
> I think I took these values from the reference BSP for the board.
>
> Also it would be good to add:
>
>         regulator-name = "vdd-cpux";
>
> > >
> > > > +&reg_dcdc4 {
> > > > + regulator-always-on;
> > > > + regulator-min-microvolt = <500000>;
> > > > + regulator-max-microvolt = <1300000>;
> > > > + regulator-name = "vdd-sys";
> > >
> > > Should be:
> > >     regulator-min-microvolt = <810000>;
> > >     regulator-max-microvolt = <990000>;
> > >     regulator-name = "vcc-usb-sys";
> >
> > I'm a bit puzzled here: datasheet says 0.9..1.0v
> > and it has no "Typ" value, similar to VDD_CPU, but
> > VDD_SYS is not part of OPP tables, so who is going
> > to adjust this? Or shall it be just

No one really. As long as the current voltage is within the range,
the kernel will be happy. But ideally the DT just describes the
acceptable range, and the bootloader programs the correct recommended
voltage.

> > regulator-min-microvolt = <950000>;
> > regulator-max-microvolt = <950000>;
> >
> > ?
>
> Yes the reference BSP runs it at 950 mV, LGTM.
>
> >
> > >
> > > > +};
> > > > +
> > > > +&reg_dcdc5 {
> > > > + regulator-always-on;
> > > > + regulator-min-microvolt = <800000>;
> > > > + regulator-max-microvolt = <1840000>;
> > > > + regulator-name = "vcc-dram";
> > >
> > > Should be:
> > >     regulator-min-microvolt = <1100000>;
> > >     regulator-max-microvolt = <1100000>;
> > >     regulator-name = "vcc-dram-2";
> > >
> > > ALDO2 is the main DRAM supply, this is the second one.
> >
> > Core schematics mentions 1.1V/1.2/1.35/1.5 on this rail...
> > Currently U-Boot has CONFIG_AXP_DCDC5_VOLT=1100, but potentially
> > this is adjustable, right? At some point LPDDR4 chips they
> > are soldering today will be unavailable. And in the current
> > market it will happen rather sooner than later...
>
> It is part of the LPDDR4 spec that the main voltage should be 1.8 V and
> the second and I/O buffer ones should be 1.1 V. See JESD209-4D Table 180 —
> Recommended DC Operating Conditions.
>
> Maybe they jsut copied this comment from a reference design that allows for
> other types of DRAM too. In any case their BSP hardcodes 1.1 V anyway.
>
> > >
> > > > +};
> > > > +
> > > > +/* DCDC6 unused */
> > > > +
> > > > +&reg_dldo1 {
> > > > + regulator-min-microvolt = <700000>;
> > > > + regulator-max-microvolt = <3300000>;
> > > > + regulator-enable-ramp-delay = <1000>;
> > >
> > > Should be:
> > >     regulator-min-microvolt = <1800000>;
> > >     regulator-max-microvolt = <1800000>;
> > >     regulator-name = "vcc-pg";
> >
> > Do suggest to drop vendor's
> >
> > regulator-enable-ramp-delay = <1000>;
> >
> > in all cases?
>
> Well we generally don't have the delays in the axp regulator definitions and
> it works well without them, but I guess they don't hurt either.

We should probably keep them if we know that they are properly measured
values, and not just cargo-culted.

> In practice many drivers will have a delay after a regulator power on anyway
> because we generally expect that hardware needs some time to power up,
> in addition to the regulator. So all in all it's rarely critical.

Those are two different things. Devices generally say "wait x ms" after
power rail is at full voltage. The enable ramp delay is the time it
takes the rail to get to full voltage. The latter depends on board
design (capacitor rating) and PMIC settings.


ChenYu

> >
> > > >
> > > > 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
> >
> > []
> >
> > > > + aliases {
> > > > +         serial0 = &uart0;
> > >
> > > The is best added to the core dtsi.
> > >
> > > > + };
> > > > +
> > > > + chosen {
> > > > +         stdout-path = "serial0:115200n8";
> > >
> > > Ditto.
> >
> > But it only physically materializes in Helperboard, the carrier.
> > Potentially this one can be left floating or used for something else.
>
> Yes fair enough, I'm happy with having it on the helperboard dts file.
>
> All the best,
>
> Paul
>
> --
> Paul Kocialkowski,
>
> Independent contractor - sys-base - https://www.sys-base.io/
> Free software developer - https://www.paulk.fr/
>
> Expert in multimedia, graphics and embedded hardware support with Linux.

Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board

[Andre Przywara]

On Mon, 18 May 2026 22:05:25 +0200
Alexander Sverdlin <alexander.sverdlin@gmail.com> wrote:

Hi Paul, Alexander,

> thanks for the review!
> 
> On Mon, 2026-05-18 at 13:52 +0200, Paul Kocialkowski wrote:
> >   
> > > 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  
> 
> []
> 
> > You should add:
> > 
> > 	chosen {
> > 		stdout-path = "serial0:115200n8";
> > 	};  
> 
> I actually have it in .dts, but it's theoretically possible to deploy
> the core board in a way that serial0 is *not* a console, so the above
> probably will not be valid in all cases in .dtsi.

I am with Alexander here, to me the serial port belong into the
helper board .dts, not the SoM .dtsi.

> 
> > 
> > 
> >   
> > > +&reg_dcdc2 {
> > > +	regulator-always-on;
> > > +	regulator-min-microvolt = <500000>;
> > > +	regulator-max-microvolt = <1300000>;  
> > 
> > Should be:
> > 	regulator-min-microvolt = <900000>;
> > 	regulator-max-microvolt = <1300000>;  
> 
> 0.81..1.2v according to A133 Datasheet Revision 1.1 Jul.14, 2020?

Do you have the CPU OPPs for this board? Do they slightly
overclock/over-volt the core? We have seen this for some other boards.
But you could go with the safer 810mV...1200mV range, and we adjust
this when needed.

> 
> >   
> > > +&reg_dcdc4 {
> > > +	regulator-always-on;
> > > +	regulator-min-microvolt = <500000>;
> > > +	regulator-max-microvolt = <1300000>;
> > > +	regulator-name = "vdd-sys";  
> > 
> > Should be:
> > 	regulator-min-microvolt = <810000>;
> > 	regulator-max-microvolt = <990000>;
> > 	regulator-name = "vcc-usb-sys";  
> 
> I'm a bit puzzled here: datasheet says 0.9..1.0v
> and it has no "Typ" value, similar to VDD_CPU, but
> VDD_SYS is not part of OPP tables, so who is going
> to adjust this? Or shall it be just
> 
> regulator-min-microvolt = <950000>;
> regulator-max-microvolt = <950000>;

There is indeed no exact value to be found. Just go with whatever the
BSP used: either it's the PMIC reset value, or it's adjusted by boot0.
If you have a BSP kernel booted, check the value of this regulator on
the Linux prompt, then use this value. Chances are it's indeed 950mV,
as used by the Liontron board.

> 
> ?
> 
> >   
> > > +};
> > > +
> > > +&reg_dcdc5 {
> > > +	regulator-always-on;
> > > +	regulator-min-microvolt = <800000>;
> > > +	regulator-max-microvolt = <1840000>;
> > > +	regulator-name = "vcc-dram";  
> > 
> > Should be:
> > 	regulator-min-microvolt = <1100000>;
> > 	regulator-max-microvolt = <1100000>;
> > 	regulator-name = "vcc-dram-2";
> > 
> > ALDO2 is the main DRAM supply, this is the second one.  
> 
> Core schematics mentions 1.1V/1.2/1.35/1.5 on this rail...
> Currently U-Boot has CONFIG_AXP_DCDC5_VOLT=1100, but potentially
> this is adjustable, right? At some point LPDDR4 chips they
> are soldering today will be unavailable. And in the current
> market it will happen rather sooner than later...

We don't support multiple DRAM types for one board, really. If they
switch to another DRAM type, we will need a new DT or some other way to
adjust this (potentially runtime patched by U-Boot). But we can address
this when we get there, so just set the 1.1V that LPDDR4 requires for
the existing boards right now.

> 
> >   
> > > +};
> > > +
> > > +/* DCDC6 unused */
> > > +
> > > +&reg_dldo1 {
> > > +	regulator-min-microvolt = <700000>;
> > > +	regulator-max-microvolt = <3300000>;
> > > +	regulator-enable-ramp-delay = <1000>;  
> > 
> > Should be:
> > 	regulator-min-microvolt = <1800000>;
> > 	regulator-max-microvolt = <1800000>;
> > 	regulator-name = "vcc-pg";  
> 
> Do suggest to drop vendor's
> 
> regulator-enable-ramp-delay = <1000>;
> 
> in all cases?
> 

I don't see this used in many other mainline DTs, mostly it's just for
some picky peripherals (PHYs). So if that works stable for you without,
I'd drop all of them.

> > > 
> > > 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  
> 
> []
> 
> > > +	aliases {
> > > +		serial0 = &uart0;  
> > 
> > The is best added to the core dtsi.
> >   
> > > +	};
> > > +
> > > +	chosen {
> > > +		stdout-path = "serial0:115200n8";  
> > 
> > Ditto.  
> 
> But it only physically materializes in Helperboard, the carrier.
> Potentially this one can be left floating or used for something else.

As mentioned above, I agree on this staying in the helper board .dts,
and it not being moved.

Cheers,
Andre