[PATCH v1 1/6] dt-bindings: vendor-prefixes: Add BigTreeTech

[PATCH v1 1/6] dt-bindings: vendor-prefixes: Add BigTreeTech

[Martin Botka]

From: Martin Botka <martin.botka@somainline.org>

BigTreeTech is a company based in Shenzhen that makes
3D printers and accessories.

Add prefix for it.

Signed-off-by: Martin Botka <martin.botka@somainline.org>
---
 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 af60bf1a6664..1d5f86e3f099 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -194,6 +194,8 @@ patternProperties:
     description: Beckhoff Automation GmbH & Co. KG
   "^bitmain,.*":
     description: Bitmain Technologies
+  "^bigtreetech,.*":
+    description: Shenzhen BigTree Tech CO., LTD
   "^blutek,.*":
     description: BluTek Power
   "^boe,.*":
-- 
2.41.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 1/6] dt-bindings: vendor-prefixes: Add BigTreeTech

[Andre Przywara]

On Thu,  3 Aug 2023 00:02:34 +0200
Martin Botka <martin@biqu3d.com> wrote:

> From: Martin Botka <martin.botka@somainline.org>
> 
> BigTreeTech is a company based in Shenzhen that makes
> 3D printers and accessories.
> 
> Add prefix for it.
> 
> Signed-off-by: Martin Botka <martin.botka@somainline.org>

Reviewed-by: Andre Przywara <andre.przywara@arm.com>

Cheers,
Andre

> ---
>  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 af60bf1a6664..1d5f86e3f099 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -194,6 +194,8 @@ patternProperties:
>      description: Beckhoff Automation GmbH & Co. KG
>    "^bitmain,.*":
>      description: Bitmain Technologies
> +  "^bigtreetech,.*":
> +    description: Shenzhen BigTree Tech CO., LTD
>    "^blutek,.*":
>      description: BluTek Power
>    "^boe,.*":


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 1/6] dt-bindings: vendor-prefixes: Add BigTreeTech

[Krzysztof Kozlowski]

On 03/08/2023 00:02, Martin Botka wrote:
> From: Martin Botka <martin.botka@somainline.org>
> 
> BigTreeTech is a company based in Shenzhen that makes
> 3D printers and accessories.
> 
> Add prefix for it.
> 
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> ---
>  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 af60bf1a6664..1d5f86e3f099 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -194,6 +194,8 @@ patternProperties:
>      description: Beckhoff Automation GmbH & Co. KG
>    "^bitmain,.*":
>      description: Bitmain Technologies
> +  "^bigtreetech,.*":

Please keep alphabetical order.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 1/6] dt-bindings: vendor-prefixes: Add BigTreeTech

[Martin Botka]

On 8/3/23 4:27 PM, Krzysztof Kozlowski wrote:
> On 03/08/2023 00:02, Martin Botka wrote:
>> From: Martin Botka <martin.botka@somainline.org>
>>
>> BigTreeTech is a company based in Shenzhen that makes
>> 3D printers and accessories.
>>
>> Add prefix for it.
>>
>> Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> ---
>>   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 af60bf1a6664..1d5f86e3f099 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
>> @@ -194,6 +194,8 @@ patternProperties:
>>       description: Beckhoff Automation GmbH & Co. KG
>>     "^bitmain,.*":
>>       description: Bitmain Technologies
>> +  "^bigtreetech,.*":
> 
> Please keep alphabetical order.
Got it.

Cheers,
Martin
> 
> Best regards,
> Krzysztof
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 2/6] dt-bindings: arm: sunxi: Add BigTreeTech CB1

[Martin Botka]

From: Martin Botka <martin.botka@somainline.org>

Add a name & compatible for BigTreeTech CB1 SoM

Signed-off-by: Martin Botka <martin.botka@somainline.org>
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index ee8fdd2da869..5ae1b81af6fc 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -151,6 +151,11 @@ properties:
           - const: roofull,beelink-x2
           - const: allwinner,sun8i-h3
 
+      - description: BigTreeTech CB1 SoM
+        items:
+          - const: bigtreetech,cb1
+          - const: allwinner,sun50i-h616
+
       - description: Chuwi V7 CW0825
         items:
           - const: chuwi,v7-cw0825
-- 
2.41.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 2/6] dt-bindings: arm: sunxi: Add BigTreeTech CB1

[Andre Przywara]

On Thu,  3 Aug 2023 00:02:35 +0200
Martin Botka <martin@biqu3d.com> wrote:

Hi,

> From: Martin Botka <martin.botka@somainline.org>
> 
> Add a name & compatible for BigTreeTech CB1 SoM
> 
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> ---
>  Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> index ee8fdd2da869..5ae1b81af6fc 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> @@ -151,6 +151,11 @@ properties:
>            - const: roofull,beelink-x2
>            - const: allwinner,sun8i-h3
>  
> +      - description: BigTreeTech CB1 SoM
> +        items:
> +          - const: bigtreetech,cb1
> +          - const: allwinner,sun50i-h616
> +

If I get this correctly, the CB1 is the SoM, which cannot be used on its
own, right? In this case there is no need for an entry in this file, since
this combination will never appear in a board .dts file alone.
So just drop this patch then.

Cheers,
Andre

>        - description: Chuwi V7 CW0825
>          items:
>            - const: chuwi,v7-cw0825


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 3/6] dt-bindings: arm: sunxi: Add BigTreeTech Manta board

[Martin Botka]

From: Martin Botka <martin.botka@somainline.org>

Add name & compatible for BigTreeTech Manta boards

Signed-off-by: Martin Botka <martin.botka@somainline.org>
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 5ae1b81af6fc..e9e46434dd1a 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -155,6 +155,12 @@ properties:
         items:
           - const: bigtreetech,cb1
           - const: allwinner,sun50i-h616
+          
+      - description: BigTreeTech Manta M4/8P
+        items:
+          - const: bigtreetech,cb1-manta
+          - const: bigtreetech,cb1
+          - const: allwinner,sun50i-h616
 
       - description: Chuwi V7 CW0825
         items:
-- 
2.41.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 3/6] dt-bindings: arm: sunxi: Add BigTreeTech Manta board

[Andre Przywara]

On Thu,  3 Aug 2023 00:02:36 +0200
Martin Botka <martin@biqu3d.com> wrote:

> From: Martin Botka <martin.botka@somainline.org>
> 
> Add name & compatible for BigTreeTech Manta boards
> 
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> ---
>  Documentation/devicetree/bindings/arm/sunxi.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> index 5ae1b81af6fc..e9e46434dd1a 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> @@ -155,6 +155,12 @@ properties:
>          items:
>            - const: bigtreetech,cb1
>            - const: allwinner,sun50i-h616
> +          

whitespace error here above (leading spaces)

And there is no need to split those additions to sunxi.yaml into separate
patches, so just put them all in one (but drop patch 2/6, as mentioned
there).

Cheers,
Andre

> +      - description: BigTreeTech Manta M4/8P
> +        items:
> +          - const: bigtreetech,cb1-manta
> +          - const: bigtreetech,cb1
> +          - const: allwinner,sun50i-h616
>  
>        - description: Chuwi V7 CW0825
>          items:


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 4/6] dt-bindings: arm: sunxi: Add BigTreeTech Pi

[Martin Botka]

From: Martin Botka <martin.botka@somainline.org>

Add name & compatible for BigTreeTech Pi board

Signed-off-by: Martin Botka <martin.botka@somainline.org>
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index e9e46434dd1a..2b527653a303 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -162,6 +162,11 @@ properties:
           - const: bigtreetech,cb1
           - const: allwinner,sun50i-h616
 
+      - description: BigTreeTech Pi
+        items:
+          - const: bigtreetech,pi
+          - const: allwinner,sun50i-h616
+
       - description: Chuwi V7 CW0825
         items:
           - const: chuwi,v7-cw0825
-- 
2.41.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 4/6] dt-bindings: arm: sunxi: Add BigTreeTech Pi

[Andre Przywara]

On Thu,  3 Aug 2023 00:02:37 +0200
Martin Botka <martin@biqu3d.com> wrote:

Hi,

> From: Martin Botka <martin.botka@somainline.org>
> 
> Add name & compatible for BigTreeTech Pi board

That looks good in itself, but should be squashed into the previous patch.

Cheers,
Andre

> 
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> ---
>  Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> index e9e46434dd1a..2b527653a303 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> @@ -162,6 +162,11 @@ properties:
>            - const: bigtreetech,cb1
>            - const: allwinner,sun50i-h616
>  
> +      - description: BigTreeTech Pi
> +        items:
> +          - const: bigtreetech,pi
> +          - const: allwinner,sun50i-h616
> +
>        - description: Chuwi V7 CW0825
>          items:
>            - const: chuwi,v7-cw0825


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 5/6] arm64: dts: allwinner: h616: Add BigTreeTech CB1 SoM & boards support

[Martin Botka]

From: Martin Botka <martin.botka@somainline.org>

CB1 is Compute Module style board that plugs into Rpi board style adapter or
Manta 3D printer boards (M4P/M8P).

The SoM features:
  - H616 SoC
  - 1GiB of RAM
  - AXP313A PMIC
  - RTL8189FTV WiFi

Boards feature:
  - 4x USB via USB2 hub (usb1 on SoM).
  - SDcard slot for loading images.
  - Ethernet port wired to the internal PHY. (100M)
  - 2x HDMI 2.0. (Only 1 usable on CB1)
  - Power and Status LEDs. (Only Status LED usable on CB1)
  - 40 pin GPIO header

Currently working:
  - Booting
  - USB
  - UART
  - MMC
  - Status LED
  - WiFi (RTL8189FS via out of tree driver)

I didnt want to duplicate things so the manta DTS can also be used on BTT pi4b adapter.
CB1 SoM has its own DTSI file in case other boards shows up that accept this SoM.

Signed-off-by: Martin Botka <martin.botka@somainline.org>
---
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../sun50i-h616-bigtreetech-cb1-manta.dts     |  20 +++
 .../sun50i-h616-bigtreetech-cb1.dtsi          | 164 ++++++++++++++++++
 3 files changed, 185 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 6a96494a2e0a..7b386428510b 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -38,5 +38,6 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
new file mode 100644
index 000000000000..dff5b592a97a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2023 Martin Botka <martin.botka@somainline.org>.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616-bigtreetech-cb1.dtsi"
+
+/ {
+	compatible = "bigtreetech,cb1-manta", "bigtreetech,cb1", "allwinner,sun50i-h616";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
new file mode 100644
index 000000000000..e630114f0ce4
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2023 Martin Botka <martin.botka@somainline.org>.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	model = "BigTreeTech CB1";
+	compatible = "bigtreetech,cb1", "allwinner,sun50i-h616";
+
+	aliases {
+		serial0 = &uart0;
+		ethernet0 = &rtl8189ftv;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+	
+	leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			function = LED_FUNCTION_STATUS;
+			color = <LED_COLOR_ID_GREEN>;
+			gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+		};
+	};
+
+	reg_vcc5v: regulator-vcc5v {
+		/* board wide 5V supply directly from the USB-C socket */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc-5v";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	reg_usb1_vbus: regulator-usb1-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb1-vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&reg_vcc5v>;
+		enable-active-high;
+		gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
+	};
+	
+	reg_vcc33_wifi: vcc33-wifi {
+		/* Always on 3.3V regulator for WiFi and BT */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc33-wifi";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		vin-supply = <&reg_vcc5v>;
+	};
+	
+	reg_vcc_wifi_io: vcc-wifi-io {
+		/* Always on 1.8V/300mA regulator for WiFi and BT IO */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc-wifi-io";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+		vin-supply = <&reg_vcc33_wifi>;
+	};
+
+	wifi_pwrseq: wifi-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&rtc 1>;
+		clock-names = "ext_clock";
+		reset-gpios = <&pio 6 18 GPIO_ACTIVE_LOW>;  /* PG18 */
+		post-power-on-delay-ms = <200>;
+	};
+};
+
+&mmc0 {
+	vmmc-supply = <&reg_dldo1>;
+	broken-cd;
+	bus-width = <4>;
+	status = "okay";
+};
+
+&mmc1 {
+	vmmc-supply = <&reg_vcc33_wifi>;
+	vqmmc-supply = <&reg_vcc_wifi_io>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	bus-width = <4>;
+	non-removable;
+	mmc-ddr-1_8v;
+	status = "okay";
+
+	rtl8189ftv: sdio_wifi@1 {
+		reg = <1>;
+	};
+};
+
+&r_i2c {
+	status = "okay";
+
+	axp313a: pmic@36 {
+		compatible = "x-powers,axp313a";
+		reg = <0x36>;
+		interrupt-controller;
+		#interrupt-cells = <1>;
+
+		regulators{
+			reg_dcdc1: dcdc1 {
+				regulator-name = "vdd-gpu";
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-always-on;
+			};
+
+			reg_dcdc2: dcdc2 {
+				regulator-name = "vdd-cpu";
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1540000>;
+				regulator-ramp-delay = <200>;
+				regulator-always-on;
+			};
+
+			reg_dcdc3: dcdc3 {
+				regulator-name = "vcc-dram";
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1840000>;
+				regulator-always-on;
+			};
+
+			reg_aldo1: aldo1 {
+				regulator-name = "vcc-1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-always-on;
+			};
+
+			reg_dldo1: dldo1 {
+				regulator-name = "vcc-3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+		};
+	};
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_ph_pins>;
+	status = "okay";
+};
+
+&usbphy {
+	usb1_vbus-supply = <&reg_usb1_vbus>;
+	status = "okay";
+};
-- 
2.41.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 5/6] arm64: dts: allwinner: h616: Add BigTreeTech CB1 SoM & boards support

[Andre Przywara]

On Thu,  3 Aug 2023 00:02:38 +0200
Martin Botka <martin@biqu3d.com> wrote:

Hi Martin,

thanks for sending this!
There are some whitespace errors in here, some leading tabs in the first
section. "git show" should print them in red.

> From: Martin Botka <martin.botka@somainline.org>
> 
> CB1 is Compute Module style board that plugs into Rpi board style adapter or
> Manta 3D printer boards (M4P/M8P).
> 
> The SoM features:
>   - H616 SoC
>   - 1GiB of RAM
>   - AXP313A PMIC
>   - RTL8189FTV WiFi
> 
> Boards feature:
>   - 4x USB via USB2 hub (usb1 on SoM).
>   - SDcard slot for loading images.
>   - Ethernet port wired to the internal PHY. (100M)
>   - 2x HDMI 2.0. (Only 1 usable on CB1)
>   - Power and Status LEDs. (Only Status LED usable on CB1)
>   - 40 pin GPIO header
> 
> Currently working:
>   - Booting
>   - USB
>   - UART
>   - MMC
>   - Status LED
>   - WiFi (RTL8189FS via out of tree driver)
> 
> I didnt want to duplicate things so the manta DTS can also be used on BTT pi4b adapter.
> CB1 SoM has its own DTSI file in case other boards shows up that accept this SoM.
> 
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> ---
>  arch/arm64/boot/dts/allwinner/Makefile        |   1 +
>  .../sun50i-h616-bigtreetech-cb1-manta.dts     |  20 +++
>  .../sun50i-h616-bigtreetech-cb1.dtsi          | 164 ++++++++++++++++++
>  3 files changed, 185 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
> 
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index 6a96494a2e0a..7b386428510b 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -38,5 +38,6 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
> new file mode 100644
> index 000000000000..dff5b592a97a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
> @@ -0,0 +1,20 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2023 Martin Botka <martin.botka@somainline.org>.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616-bigtreetech-cb1.dtsi"
> +
> +/ {
> +	compatible = "bigtreetech,cb1-manta", "bigtreetech,cb1", "allwinner,sun50i-h616";
> +};
> +
> +&ehci1 {
> +	status = "okay";
> +};
> +
> +&ohci1 {
> +	status = "okay";
> +};

So how is the STM32 connected? Via SPI? If yes, you should activate the SPI
node and specify the pinctrl.
Even if this requires a patch cable to connect the SPI header coming from
the CB1 to the SPI pins on the STM (does it?), it might be worth stating
the pins used. I don't know for sure if we enable interfaces that are
routed to fixed function header pins, but it might be worth doing so here,
since this is some very obvious use case (I guess you wouldn't buy the M8P
if you don't plan to use all of its goodies).

And what's the USB-C connector doing? Is that an alternative power supply?
Ann does it connect the port0 D-/D+ pins, so can be used for OTG? If yes,
please enable the usb_otg node here.

> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
> new file mode 100644
> index 000000000000..e630114f0ce4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
> @@ -0,0 +1,164 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2023 Martin Botka <martin.botka@somainline.org>.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/leds/common.h>
> +
> +/ {
> +	model = "BigTreeTech CB1";
> +	compatible = "bigtreetech,cb1", "allwinner,sun50i-h616";
> +
> +	aliases {
> +		serial0 = &uart0;
> +		ethernet0 = &rtl8189ftv;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};

I think stdout-path belongs into the board .dts.

> +	
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		led-0 {
> +			function = LED_FUNCTION_STATUS;
> +			color = <LED_COLOR_ID_GREEN>;
> +			gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
> +		};
> +	};
> +
> +	reg_vcc5v: regulator-vcc5v {
> +		/* board wide 5V supply directly from the USB-C socket */

I guess this "regulator" is still valid, but please adjust the comment,
since there is certainly no USB-C socket on the SoM. I guess it's multiple
pins on the SoM connector that supply the incoming base voltage?

> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc-5v";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		regulator-always-on;
> +	};
> +
> +	reg_usb1_vbus: regulator-usb1-vbus {

So is this regulator really on the SoM? Or is it just PC16 on the SoM
connector, and the actual regulator chip is on the respective carrier
boards?

> +		compatible = "regulator-fixed";
> +		regulator-name = "usb1-vbus";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&reg_vcc5v>;
> +		enable-active-high;
> +		gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> +	};
> +	
> +	reg_vcc33_wifi: vcc33-wifi {
> +		/* Always on 3.3V regulator for WiFi and BT */
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc33-wifi";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		regulator-always-on;
> +		vin-supply = <&reg_vcc5v>;
> +	};
> +	
> +	reg_vcc_wifi_io: vcc-wifi-io {
> +		/* Always on 1.8V/300mA regulator for WiFi and BT IO */
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc-wifi-io";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		regulator-always-on;
> +		vin-supply = <&reg_vcc33_wifi>;
> +	};
> +
> +	wifi_pwrseq: wifi-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		clocks = <&rtc 1>;
> +		clock-names = "ext_clock";
> +		reset-gpios = <&pio 6 18 GPIO_ACTIVE_LOW>;  /* PG18 */
> +		post-power-on-delay-ms = <200>;
> +	};
> +};
> +
> +&mmc0 {
> +	vmmc-supply = <&reg_dldo1>;
> +	broken-cd;

Is there no card detect switch or is it not wired up, or is it really
"broken"? Might be good to have a comment explaining that.
And yeah, I also forgot to do this in my Orange Pi Zero3 .dts ;-)

> +	bus-width = <4>;
> +	status = "okay";
> +};
> +
> +&mmc1 {
> +	vmmc-supply = <&reg_vcc33_wifi>;
> +	vqmmc-supply = <&reg_vcc_wifi_io>;
> +	mmc-pwrseq = <&wifi_pwrseq>;
> +	bus-width = <4>;
> +	non-removable;
> +	mmc-ddr-1_8v;
> +	status = "okay";
> +
> +	rtl8189ftv: sdio_wifi@1 {
> +		reg = <1>;
> +	};
> +};
> +
> +&r_i2c {
> +	status = "okay";
> +
> +	axp313a: pmic@36 {
> +		compatible = "x-powers,axp313a";
> +		reg = <0x36>;
> +		interrupt-controller;
> +		#interrupt-cells = <1>;
> +
> +		regulators{
> +			reg_dcdc1: dcdc1 {
> +				regulator-name = "vdd-gpu";
> +				regulator-min-microvolt = <500000>;
> +				regulator-max-microvolt = <3400000>;

So those are the ranges of the PMIC rail, but if this is really connected
to VDD_GPU on the H616, you should limit it to between 0.81V and 0.99V, as
described in the H616 datasheet. Otherwise this risks frying the SoC, I
guess.

> +				regulator-always-on;

So is this connected to something else as well, like VDD_SYS? Please
either mention this as a comment, to justify the always-on, or name the
regulator accordingly, like "vdd-gpu-sys".
 
> +			};
> +
> +			reg_dcdc2: dcdc2 {
> +				regulator-name = "vdd-cpu";
> +				regulator-min-microvolt = <500000>;
> +				regulator-max-microvolt = <1540000>;

Same limit problem here, VDD_CPU must be between 0.81V and 1.1V.

> +				regulator-ramp-delay = <200>;
> +				regulator-always-on;
> +			};
> +
> +			reg_dcdc3: dcdc3 {
> +				regulator-name = "vcc-dram";
> +				regulator-min-microvolt = <500000>;
> +				regulator-max-microvolt = <1840000>;

Is that DDR3 or DDR3L DRAM here? I don't think there is any runtime
adjustments here, so just specify the respective voltage required, with the
same value for both min and max.

> +				regulator-always-on;
> +			};
> +
> +			reg_aldo1: aldo1 {
> +				regulator-name = "vcc-1v8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-always-on;

Please mention what this supplies that justifies always-on.

> +			};
> +
> +			reg_dldo1: dldo1 {
> +				regulator-name = "vcc-3v3";
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;

Please mention what this supplies that justifies always-on.

> +			};
> +		};
> +	};
> +};
> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_ph_pins>;
> +	status = "okay";
> +};

This belongs into the board .dts, since the connector/UART bridge is
there.

Cheers,
Andre

> +
> +&usbphy {
> +	usb1_vbus-supply = <&reg_usb1_vbus>;
> +	status = "okay";
> +};


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 5/6] arm64: dts: allwinner: h616: Add BigTreeTech CB1 SoM & boards support

[Martin Botka]

On 8/3/23 2:37 PM, Andre Przywara wrote:
> On Thu,  3 Aug 2023 00:02:38 +0200
> Martin Botka <martin@biqu3d.com> wrote:
> 
> Hi Martin,
> 
> thanks for sending this!
> There are some whitespace errors in here, some leading tabs in the first
> section. "git show" should print them in red.
> 
>> From: Martin Botka <martin.botka@somainline.org>
>>
>> CB1 is Compute Module style board that plugs into Rpi board style adapter or
>> Manta 3D printer boards (M4P/M8P).
>>
>> The SoM features:
>>    - H616 SoC
>>    - 1GiB of RAM
>>    - AXP313A PMIC
>>    - RTL8189FTV WiFi
>>
>> Boards feature:
>>    - 4x USB via USB2 hub (usb1 on SoM).
>>    - SDcard slot for loading images.
>>    - Ethernet port wired to the internal PHY. (100M)
>>    - 2x HDMI 2.0. (Only 1 usable on CB1)
>>    - Power and Status LEDs. (Only Status LED usable on CB1)
>>    - 40 pin GPIO header
>>
>> Currently working:
>>    - Booting
>>    - USB
>>    - UART
>>    - MMC
>>    - Status LED
>>    - WiFi (RTL8189FS via out of tree driver)
>>
>> I didnt want to duplicate things so the manta DTS can also be used on BTT pi4b adapter.
>> CB1 SoM has its own DTSI file in case other boards shows up that accept this SoM.
>>
>> Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> ---
>>   arch/arm64/boot/dts/allwinner/Makefile        |   1 +
>>   .../sun50i-h616-bigtreetech-cb1-manta.dts     |  20 +++
>>   .../sun50i-h616-bigtreetech-cb1.dtsi          | 164 ++++++++++++++++++
>>   3 files changed, 185 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
>>   create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
>> index 6a96494a2e0a..7b386428510b 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -38,5 +38,6 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
>>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
>>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
>>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
>>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
>>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
>> new file mode 100644
>> index 000000000000..dff5b592a97a
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
>> @@ -0,0 +1,20 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> +/*
>> + * Copyright (C) 2023 Martin Botka <martin.botka@somainline.org>.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "sun50i-h616-bigtreetech-cb1.dtsi"
>> +
>> +/ {
>> +	compatible = "bigtreetech,cb1-manta", "bigtreetech,cb1", "allwinner,sun50i-h616";
>> +};
>> +
>> +&ehci1 {
>> +	status = "okay";
>> +};
>> +
>> +&ohci1 {
>> +	status = "okay";
>> +};
> 
> So how is the STM32 connected? Via SPI? If yes, you should activate the SPI
> node and specify the pinctrl.
> Even if this requires a patch cable to connect the SPI header coming from
> the CB1 to the SPI pins on the STM (does it?), it might be worth stating
> the pins used. I don't know for sure if we enable interfaces that are
> routed to fixed function header pins, but it might be worth doing so here,
> since this is some very obvious use case (I guess you wouldn't buy the M8P
> if you don't plan to use all of its goodies).
So the STM32 chip is connected directly via USB. There is USB hub on 
Manta boards and Pi adapter (Not on BTT Pi. That one doesnt use USB hub)
that uses this USB port and STM32 connects via that. Then on manta 
boards there are 2 USB ports and 1 USB port with just pins exposed on
XH2.54 4 pin connector. Bit weird but it is what it is :)
> 
> And what's the USB-C connector doing? Is that an alternative power supply?
> Ann does it connect the port0 D-/D+ pins, so can be used for OTG? If yes,
> please enable the usb_otg node here.
> 
It is indeed an alternative power supply. Or well primary supply in the 
case of Pi adapter board.

It should be connected yes. Tho i never really had much luck getting it 
to work. Tho i will check again and if i get it to work i will enable it 
in V2 :)
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
>> new file mode 100644
>> index 000000000000..e630114f0ce4
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
>> @@ -0,0 +1,164 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> +/*
>> + * Copyright (C) 2023 Martin Botka <martin.botka@somainline.org>.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "sun50i-h616.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/leds/common.h>
>> +
>> +/ {
>> +	model = "BigTreeTech CB1";
>> +	compatible = "bigtreetech,cb1", "allwinner,sun50i-h616";
>> +
>> +	aliases {
>> +		serial0 = &uart0;
>> +		ethernet0 = &rtl8189ftv;
>> +	};
>> +
>> +	chosen {
>> +		stdout-path = "serial0:115200n8";
>> +	};
> 
> I think stdout-path belongs into the board .dts.
>

Got it

>> +	
>> +	leds {
>> +		compatible = "gpio-leds";
>> +
>> +		led-0 {
>> +			function = LED_FUNCTION_STATUS;
>> +			color = <LED_COLOR_ID_GREEN>;
>> +			gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
>> +		};
>> +	};
>> +
>> +	reg_vcc5v: regulator-vcc5v {
>> +		/* board wide 5V supply directly from the USB-C socket */
> 
> I guess this "regulator" is still valid, but please adjust the comment,
> since there is certainly no USB-C socket on the SoM. I guess it's multiple
> pins on the SoM connector that supply the incoming base voltage?
Correct. Its just pins that get the 5V power. My fault for saying 
directly from USB-C since it can be from somewhere else :)
> 
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vcc-5v";
>> +		regulator-min-microvolt = <5000000>;
>> +		regulator-max-microvolt = <5000000>;
>> +		regulator-always-on;
>> +	};
>> +
>> +	reg_usb1_vbus: regulator-usb1-vbus {
> 
> So is this regulator really on the SoM? Or is it just PC16 on the SoM
> connector, and the actual regulator chip is on the respective carrier
> boards?
> 

This is my bad. This is completely wrong. The actual regulator is the 5V 
one thats turned on when 5V comes in. Its bit weird but i suppose its 
done that way for USB-OTG. This will be removed in next revision of this 
DTS :)
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "usb1-vbus";
>> +		regulator-min-microvolt = <5000000>;
>> +		regulator-max-microvolt = <5000000>;
>> +		vin-supply = <&reg_vcc5v>;
>> +		enable-active-high;
>> +		gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>> +	};
>> +	
>> +	reg_vcc33_wifi: vcc33-wifi {
>> +		/* Always on 3.3V regulator for WiFi and BT */
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vcc33-wifi";
>> +		regulator-min-microvolt = <3300000>;
>> +		regulator-max-microvolt = <3300000>;
>> +		regulator-always-on;
>> +		vin-supply = <&reg_vcc5v>;
>> +	};
>> +	
>> +	reg_vcc_wifi_io: vcc-wifi-io {
>> +		/* Always on 1.8V/300mA regulator for WiFi and BT IO */
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vcc-wifi-io";
>> +		regulator-min-microvolt = <1800000>;
>> +		regulator-max-microvolt = <1800000>;
>> +		regulator-always-on;
>> +		vin-supply = <&reg_vcc33_wifi>;
>> +	};
>> +
>> +	wifi_pwrseq: wifi-pwrseq {
>> +		compatible = "mmc-pwrseq-simple";
>> +		clocks = <&rtc 1>;
>> +		clock-names = "ext_clock";
>> +		reset-gpios = <&pio 6 18 GPIO_ACTIVE_LOW>;  /* PG18 */
>> +		post-power-on-delay-ms = <200>;
>> +	};
>> +};
>> +
>> +&mmc0 {
>> +	vmmc-supply = <&reg_dldo1>;
>> +	broken-cd;
> 
> Is there no card detect switch or is it not wired up, or is it really
> "broken"? Might be good to have a comment explaining that.
> And yeah, I also forgot to do this in my Orange Pi Zero3 .dts ;-)
> 
Its just straight up not connected. And since documentation specifies 
that this should be set when no card detection is available i set it.

Will add a comment specifying that this is due to the pin not being 
connected.
>> +	bus-width = <4>;
>> +	status = "okay";
>> +};
>> +
>> +&mmc1 {
>> +	vmmc-supply = <&reg_vcc33_wifi>;
>> +	vqmmc-supply = <&reg_vcc_wifi_io>;
>> +	mmc-pwrseq = <&wifi_pwrseq>;
>> +	bus-width = <4>;
>> +	non-removable;
>> +	mmc-ddr-1_8v;
>> +	status = "okay";
>> +
>> +	rtl8189ftv: sdio_wifi@1 {
>> +		reg = <1>;
>> +	};
>> +};
>> +
>> +&r_i2c {
>> +	status = "okay";
>> +
>> +	axp313a: pmic@36 {
>> +		compatible = "x-powers,axp313a";
>> +		reg = <0x36>;
>> +		interrupt-controller;
>> +		#interrupt-cells = <1>;
>> +
>> +		regulators{
>> +			reg_dcdc1: dcdc1 {
>> +				regulator-name = "vdd-gpu";
>> +				regulator-min-microvolt = <500000>;
>> +				regulator-max-microvolt = <3400000>;
> 
> So those are the ranges of the PMIC rail, but if this is really connected
> to VDD_GPU on the H616, you should limit it to between 0.81V and 0.99V, as
> described in the H616 datasheet. Otherwise this risks frying the SoC, I
> guess.

The range here should be correct. It is also the sys rail. Since AXP313a 
lacks many rails this was chosen as the sys rail as well.
> 
>> +				regulator-always-on;
> 
> So is this connected to something else as well, like VDD_SYS? Please
> either mention this as a comment, to justify the always-on, or name the
> regulator accordingly, like "vdd-gpu-sys".
Will rename to vdd-gpu-sys.
>   
>> +			};
>> +
>> +			reg_dcdc2: dcdc2 {
>> +				regulator-name = "vdd-cpu";
>> +				regulator-min-microvolt = <500000>;
>> +				regulator-max-microvolt = <1540000>;
> 
> Same limit problem here, VDD_CPU must be between 0.81V and 1.1V.
That is indeed right. I will test it on the range you provided with OPP 
(WIP) and stress test it :)
> 
>> +				regulator-ramp-delay = <200>;
>> +				regulator-always-on;
>> +			};
>> +
>> +			reg_dcdc3: dcdc3 {
>> +				regulator-name = "vcc-dram";
>> +				regulator-min-microvolt = <500000>;
>> +				regulator-max-microvolt = <1840000>;
> 
> Is that DDR3 or DDR3L DRAM here? I don't think there is any runtime
> adjustments here, so just specify the respective voltage required, with the
> same value for both min and max.
it uses Kingston D2516ECMDXGJD so DDR3. I will specify the direct voltage.
> 
>> +				regulator-always-on;
>> +			};
>> +
>> +			reg_aldo1: aldo1 {
>> +				regulator-name = "vcc-1v8";
>> +				regulator-min-microvolt = <1800000>;
>> +				regulator-max-microvolt = <1800000>;
>> +				regulator-always-on;
> 
> Please mention what this supplies that justifies always-on.
ALDO1 1.8V gets also converted to 1.8V for DRAM. Thus needs to be on always.
> 
>> +			};
>> +
>> +			reg_dldo1: dldo1 {
>> +				regulator-name = "vcc-3v3";
>> +				regulator-min-microvolt = <3300000>;
>> +				regulator-max-microvolt = <3300000>;
>> +				regulator-always-on;
> 
> Please mention what this supplies that justifies always-on.
SDcard that serves as storage for system. Will add comments for both :)
> 
>> +			};
>> +		};
>> +	};
>> +};
>> +
>> +&uart0 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart0_ph_pins>;
>> +	status = "okay";
>> +};
> 
> This belongs into the board .dts, since the connector/UART bridge is
> there.
Actually the SoM has exposed pads to connect UART (Which is what i have 
done to get UART) but also the boards get the exact pins wired to GPIO.

But since most users would use the GPIO UART i will specify it in 
carrier boards and in BTT Pi boards separately.

Cheers,
Martin
> 
> Cheers,
> Andre
> 
>> +
>> +&usbphy {
>> +	usb1_vbus-supply = <&reg_usb1_vbus>;
>> +	status = "okay";
>> +};
> 
> 



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 5/6] arm64: dts: allwinner: h616: Add BigTreeTech CB1 SoM & boards support

[Andre Przywara]

On Thu, 3 Aug 2023 17:35:55 +0200
Martin Botka <martin@biqu3d.com> wrote:

Hi Martin,

thanks for the reply and the explanations, very helpful.

> On 8/3/23 2:37 PM, Andre Przywara wrote:
> > On Thu,  3 Aug 2023 00:02:38 +0200
> > Martin Botka <martin@biqu3d.com> wrote:
> > 
> > Hi Martin,
> > 
> > thanks for sending this!
> > There are some whitespace errors in here, some leading tabs in the first
> > section. "git show" should print them in red.
> >   
> >> From: Martin Botka <martin.botka@somainline.org>
> >>
> >> CB1 is Compute Module style board that plugs into Rpi board style adapter or
> >> Manta 3D printer boards (M4P/M8P).
> >>
> >> The SoM features:
> >>    - H616 SoC
> >>    - 1GiB of RAM
> >>    - AXP313A PMIC
> >>    - RTL8189FTV WiFi
> >>
> >> Boards feature:
> >>    - 4x USB via USB2 hub (usb1 on SoM).
> >>    - SDcard slot for loading images.
> >>    - Ethernet port wired to the internal PHY. (100M)
> >>    - 2x HDMI 2.0. (Only 1 usable on CB1)
> >>    - Power and Status LEDs. (Only Status LED usable on CB1)
> >>    - 40 pin GPIO header
> >>
> >> Currently working:
> >>    - Booting
> >>    - USB
> >>    - UART
> >>    - MMC
> >>    - Status LED
> >>    - WiFi (RTL8189FS via out of tree driver)
> >>
> >> I didnt want to duplicate things so the manta DTS can also be used on BTT pi4b adapter.
> >> CB1 SoM has its own DTSI file in case other boards shows up that accept this SoM.
> >>
> >> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> >> ---
> >>   arch/arm64/boot/dts/allwinner/Makefile        |   1 +
> >>   .../sun50i-h616-bigtreetech-cb1-manta.dts     |  20 +++
> >>   .../sun50i-h616-bigtreetech-cb1.dtsi          | 164 ++++++++++++++++++
> >>   3 files changed, 185 insertions(+)
> >>   create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
> >>   create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
> >>
> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> >> index 6a96494a2e0a..7b386428510b 100644
> >> --- a/arch/arm64/boot/dts/allwinner/Makefile
> >> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> >> @@ -38,5 +38,6 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> >>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> >>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> >>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
> >> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
> >>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> >>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
> >> new file mode 100644
> >> index 000000000000..dff5b592a97a
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
> >> @@ -0,0 +1,20 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> >> +/*
> >> + * Copyright (C) 2023 Martin Botka <martin.botka@somainline.org>.
> >> + */
> >> +
> >> +/dts-v1/;
> >> +
> >> +#include "sun50i-h616-bigtreetech-cb1.dtsi"
> >> +
> >> +/ {
> >> +	compatible = "bigtreetech,cb1-manta", "bigtreetech,cb1", "allwinner,sun50i-h616";
> >> +};
> >> +
> >> +&ehci1 {
> >> +	status = "okay";
> >> +};
> >> +
> >> +&ohci1 {
> >> +	status = "okay";
> >> +};  
> > 
> > So how is the STM32 connected? Via SPI? If yes, you should activate the SPI
> > node and specify the pinctrl.
> > Even if this requires a patch cable to connect the SPI header coming from
> > the CB1 to the SPI pins on the STM (does it?), it might be worth stating
> > the pins used. I don't know for sure if we enable interfaces that are
> > routed to fixed function header pins, but it might be worth doing so here,
> > since this is some very obvious use case (I guess you wouldn't buy the M8P
> > if you don't plan to use all of its goodies).  
> So the STM32 chip is connected directly via USB. There is USB hub on 
> Manta boards and Pi adapter (Not on BTT Pi. That one doesnt use USB hub)
> that uses this USB port and STM32 connects via that. Then on manta 
> boards there are 2 USB ports and 1 USB port with just pins exposed on
> XH2.54 4 pin connector. Bit weird but it is what it is :)

Ah, I missed that, and was already wondering where the fourth HUB output
went to. So USB is fine. Do the hub or the STM need a switched regulator?
Or is the hub and the STM32 always powered on?

> > And what's the USB-C connector doing? Is that an alternative power supply?
> > Ann does it connect the port0 D-/D+ pins, so can be used for OTG? If yes,
> > please enable the usb_otg node here.
> >   
> It is indeed an alternative power supply. Or well primary supply in the 
> case of Pi adapter board.
> 
> It should be connected yes. Tho i never really had much luck getting it 
> to work. Tho i will check again and if i get it to work i will enable it 
> in V2 :)

You could test with FEL. Get
https://github.com/linux-sunxi/sunxi-tools/raw/master/bin/fel-sdboot.sunxi,
write that to sector 16 of an SD card, and boot from there.
That should put the SoC into FEL mode, and you should be able to see the
BootROM provided USB device ID on a connected host - if the data pins are
connected to USB port 0.
I see DP0/DM0 test pads on the SoM, maybe you can chase them down to
see if they actually go to the SoM connector? But wasn't it that there is
only one pair of USB pins available on a CM4 pinout? Hence the hub on the
Mantra boards?

> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
> >> new file mode 100644
> >> index 000000000000..e630114f0ce4
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
> >> @@ -0,0 +1,164 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> >> +/*
> >> + * Copyright (C) 2023 Martin Botka <martin.botka@somainline.org>.
> >> + */
> >> +
> >> +/dts-v1/;
> >> +
> >> +#include "sun50i-h616.dtsi"
> >> +
> >> +#include <dt-bindings/gpio/gpio.h>
> >> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> >> +#include <dt-bindings/leds/common.h>
> >> +
> >> +/ {
> >> +	model = "BigTreeTech CB1";
> >> +	compatible = "bigtreetech,cb1", "allwinner,sun50i-h616";
> >> +
> >> +	aliases {
> >> +		serial0 = &uart0;
> >> +		ethernet0 = &rtl8189ftv;
> >> +	};
> >> +
> >> +	chosen {
> >> +		stdout-path = "serial0:115200n8";
> >> +	};  
> > 
> > I think stdout-path belongs into the board .dts.
> >  
> 
> Got it
> 
> >> +	
> >> +	leds {
> >> +		compatible = "gpio-leds";
> >> +
> >> +		led-0 {
> >> +			function = LED_FUNCTION_STATUS;
> >> +			color = <LED_COLOR_ID_GREEN>;
> >> +			gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
> >> +		};
> >> +	};
> >> +
> >> +	reg_vcc5v: regulator-vcc5v {
> >> +		/* board wide 5V supply directly from the USB-C socket */  
> > 
> > I guess this "regulator" is still valid, but please adjust the comment,
> > since there is certainly no USB-C socket on the SoM. I guess it's multiple
> > pins on the SoM connector that supply the incoming base voltage?  
> Correct. Its just pins that get the 5V power. My fault for saying 
> directly from USB-C since it can be from somewhere else :)
> >   
> >> +		compatible = "regulator-fixed";
> >> +		regulator-name = "vcc-5v";
> >> +		regulator-min-microvolt = <5000000>;
> >> +		regulator-max-microvolt = <5000000>;
> >> +		regulator-always-on;
> >> +	};
> >> +
> >> +	reg_usb1_vbus: regulator-usb1-vbus {  
> > 
> > So is this regulator really on the SoM? Or is it just PC16 on the SoM
> > connector, and the actual regulator chip is on the respective carrier
> > boards?
> >   
> 
> This is my bad. This is completely wrong. The actual regulator is the 5V 
> one thats turned on when 5V comes in. Its bit weird but i suppose its 
> done that way for USB-OTG. This will be removed in next revision of this 
> DTS :)

Having fixed 5V supply for USB ports, coming directly from the board power
supply, is actually quite common, see many Pine64 boards, for instance.
In this case you don't need to specify a usb<x>_vbus-supply property in
the PHY node below.

> >> +		compatible = "regulator-fixed";
> >> +		regulator-name = "usb1-vbus";
> >> +		regulator-min-microvolt = <5000000>;
> >> +		regulator-max-microvolt = <5000000>;
> >> +		vin-supply = <&reg_vcc5v>;
> >> +		enable-active-high;
> >> +		gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> >> +	};
> >> +	
> >> +	reg_vcc33_wifi: vcc33-wifi {
> >> +		/* Always on 3.3V regulator for WiFi and BT */
> >> +		compatible = "regulator-fixed";
> >> +		regulator-name = "vcc33-wifi";
> >> +		regulator-min-microvolt = <3300000>;
> >> +		regulator-max-microvolt = <3300000>;
> >> +		regulator-always-on;
> >> +		vin-supply = <&reg_vcc5v>;
> >> +	};
> >> +	
> >> +	reg_vcc_wifi_io: vcc-wifi-io {
> >> +		/* Always on 1.8V/300mA regulator for WiFi and BT IO */
> >> +		compatible = "regulator-fixed";
> >> +		regulator-name = "vcc-wifi-io";
> >> +		regulator-min-microvolt = <1800000>;
> >> +		regulator-max-microvolt = <1800000>;
> >> +		regulator-always-on;
> >> +		vin-supply = <&reg_vcc33_wifi>;
> >> +	};
> >> +
> >> +	wifi_pwrseq: wifi-pwrseq {
> >> +		compatible = "mmc-pwrseq-simple";
> >> +		clocks = <&rtc 1>;
> >> +		clock-names = "ext_clock";
> >> +		reset-gpios = <&pio 6 18 GPIO_ACTIVE_LOW>;  /* PG18 */
> >> +		post-power-on-delay-ms = <200>;
> >> +	};
> >> +};
> >> +
> >> +&mmc0 {
> >> +	vmmc-supply = <&reg_dldo1>;
> >> +	broken-cd;  
> > 
> > Is there no card detect switch or is it not wired up, or is it really
> > "broken"? Might be good to have a comment explaining that.
> > And yeah, I also forgot to do this in my Orange Pi Zero3 .dts ;-)
> >   
> Its just straight up not connected. And since documentation specifies 
> that this should be set when no card detection is available i set it.
> 
> Will add a comment specifying that this is due to the pin not being 
> connected.

Yes, that's correct, broken-cd is the right choice then and works fine. I
was just asking because it *is* connected on the OrangePi Zero3, but didn't
work for me there.

> >> +	bus-width = <4>;
> >> +	status = "okay";
> >> +};
> >> +
> >> +&mmc1 {
> >> +	vmmc-supply = <&reg_vcc33_wifi>;
> >> +	vqmmc-supply = <&reg_vcc_wifi_io>;
> >> +	mmc-pwrseq = <&wifi_pwrseq>;
> >> +	bus-width = <4>;
> >> +	non-removable;
> >> +	mmc-ddr-1_8v;
> >> +	status = "okay";
> >> +
> >> +	rtl8189ftv: sdio_wifi@1 {
> >> +		reg = <1>;
> >> +	};
> >> +};
> >> +
> >> +&r_i2c {
> >> +	status = "okay";
> >> +
> >> +	axp313a: pmic@36 {
> >> +		compatible = "x-powers,axp313a";
> >> +		reg = <0x36>;
> >> +		interrupt-controller;
> >> +		#interrupt-cells = <1>;
> >> +
> >> +		regulators{
> >> +			reg_dcdc1: dcdc1 {
> >> +				regulator-name = "vdd-gpu";
> >> +				regulator-min-microvolt = <500000>;
> >> +				regulator-max-microvolt = <3400000>;  
> > 
> > So those are the ranges of the PMIC rail, but if this is really connected
> > to VDD_GPU on the H616, you should limit it to between 0.81V and 0.99V, as
> > described in the H616 datasheet. Otherwise this risks frying the SoC, I
> > guess.  
> 
> The range here should be correct. It is also the sys rail. Since AXP313a 
> lacks many rails this was chosen as the sys rail as well.

Yes, very common indeed. I think in reality most boards will need all
rails to be always on.

> >   
> >> +				regulator-always-on;  
> > 
> > So is this connected to something else as well, like VDD_SYS? Please
> > either mention this as a comment, to justify the always-on, or name the
> > regulator accordingly, like "vdd-gpu-sys".  
> Will rename to vdd-gpu-sys.
> >     
> >> +			};
> >> +
> >> +			reg_dcdc2: dcdc2 {
> >> +				regulator-name = "vdd-cpu";
> >> +				regulator-min-microvolt = <500000>;
> >> +				regulator-max-microvolt = <1540000>;  
> > 
> > Same limit problem here, VDD_CPU must be between 0.81V and 1.1V.  
> That is indeed right. I will test it on the range you provided with OPP 
> (WIP) and stress test it :)
> >   
> >> +				regulator-ramp-delay = <200>;
> >> +				regulator-always-on;
> >> +			};
> >> +
> >> +			reg_dcdc3: dcdc3 {
> >> +				regulator-name = "vcc-dram";
> >> +				regulator-min-microvolt = <500000>;
> >> +				regulator-max-microvolt = <1840000>;  
> > 
> > Is that DDR3 or DDR3L DRAM here? I don't think there is any runtime
> > adjustments here, so just specify the respective voltage required, with the
> > same value for both min and max.  
> it uses Kingston D2516ECMDXGJD so DDR3. I will specify the direct voltage.

But this is DDR3L, so DDR3, just with a slightly lower voltage (1.35V
instead of 1.5V). Please note that this is different from LPDDR3, which
uses a different protocol, on top of lowering the voltage.

> >   
> >> +				regulator-always-on;
> >> +			};
> >> +
> >> +			reg_aldo1: aldo1 {
> >> +				regulator-name = "vcc-1v8";
> >> +				regulator-min-microvolt = <1800000>;
> >> +				regulator-max-microvolt = <1800000>;
> >> +				regulator-always-on;  
> > 
> > Please mention what this supplies that justifies always-on.  
> ALDO1 1.8V gets also converted to 1.8V for DRAM. Thus needs to be on always.

Yes, as seen with other boards, where it more prominently also supplies
VCC-PLL, which is essential for any clock operation. Might be worth
checking, if you have access to the complete schematic.

> >> +			};
> >> +
> >> +			reg_dldo1: dldo1 {
> >> +				regulator-name = "vcc-3v3";
> >> +				regulator-min-microvolt = <3300000>;
> >> +				regulator-max-microvolt = <3300000>;
> >> +				regulator-always-on;  
> > 
> > Please mention what this supplies that justifies always-on.  
> SDcard that serves as storage for system. Will add comments for both :)

SD card alone does not justify always-on, as you reference this regulator
in the mmc0 node, so a kernel could make the connection. But chances are
this is also connected to VCC-IO, which is also one of the mandatory supply
voltages.

> >   
> >> +			};
> >> +		};
> >> +	};
> >> +};
> >> +
> >> +&uart0 {
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&uart0_ph_pins>;
> >> +	status = "okay";
> >> +};  
> > 
> > This belongs into the board .dts, since the connector/UART bridge is
> > there.  
> Actually the SoM has exposed pads to connect UART (Which is what i have 
> done to get UART) but also the boards get the exact pins wired to GPIO.

Those pad on the lower right corner? In this case it might justify having
the UART node in the SoM .dtsi, though I don't know if (test)pads qualify
for enabling peripherals. Generic GPIO pins (say pinmux'ed I2C on some
GPIO headers) certainly don't.

Cheers,
Andre

> But since most users would use the GPIO UART i will specify it in 
> carrier boards and in BTT Pi boards separately.
> 
> Cheers,
> Martin
> > 
> > Cheers,
> > Andre
> >   
> >> +
> >> +&usbphy {
> >> +	usb1_vbus-supply = <&reg_usb1_vbus>;
> >> +	status = "okay";
> >> +};  
> > 
> >   
> 
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 5/6] arm64: dts: allwinner: h616: Add BigTreeTech CB1 SoM & boards support

[Martin Botka]

On 8/3/23 6:16 PM, Andre Przywara wrote:
> On Thu, 3 Aug 2023 17:35:55 +0200
> Martin Botka <martin@biqu3d.com> wrote:
> 
> Hi Martin,
> 
> thanks for the reply and the explanations, very helpful.
> 
>> On 8/3/23 2:37 PM, Andre Przywara wrote:
>>> On Thu,  3 Aug 2023 00:02:38 +0200
>>> Martin Botka <martin@biqu3d.com> wrote:
>>>
>>> Hi Martin,
>>>
>>> thanks for sending this!
>>> There are some whitespace errors in here, some leading tabs in the first
>>> section. "git show" should print them in red.
>>>    
>>>> From: Martin Botka <martin.botka@somainline.org>
>>>>
>>>> CB1 is Compute Module style board that plugs into Rpi board style adapter or
>>>> Manta 3D printer boards (M4P/M8P).
>>>>
>>>> The SoM features:
>>>>     - H616 SoC
>>>>     - 1GiB of RAM
>>>>     - AXP313A PMIC
>>>>     - RTL8189FTV WiFi
>>>>
>>>> Boards feature:
>>>>     - 4x USB via USB2 hub (usb1 on SoM).
>>>>     - SDcard slot for loading images.
>>>>     - Ethernet port wired to the internal PHY. (100M)
>>>>     - 2x HDMI 2.0. (Only 1 usable on CB1)
>>>>     - Power and Status LEDs. (Only Status LED usable on CB1)
>>>>     - 40 pin GPIO header
>>>>
>>>> Currently working:
>>>>     - Booting
>>>>     - USB
>>>>     - UART
>>>>     - MMC
>>>>     - Status LED
>>>>     - WiFi (RTL8189FS via out of tree driver)
>>>>
>>>> I didnt want to duplicate things so the manta DTS can also be used on BTT pi4b adapter.
>>>> CB1 SoM has its own DTSI file in case other boards shows up that accept this SoM.
>>>>
>>>> Signed-off-by: Martin Botka <martin.botka@somainline.org>
>>>> ---
>>>>    arch/arm64/boot/dts/allwinner/Makefile        |   1 +
>>>>    .../sun50i-h616-bigtreetech-cb1-manta.dts     |  20 +++
>>>>    .../sun50i-h616-bigtreetech-cb1.dtsi          | 164 ++++++++++++++++++
>>>>    3 files changed, 185 insertions(+)
>>>>    create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
>>>>    create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
>>>> index 6a96494a2e0a..7b386428510b 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>>>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>>>> @@ -38,5 +38,6 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
>>>>    dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
>>>>    dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
>>>>    dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
>>>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
>>>>    dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
>>>>    dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
>>>> new file mode 100644
>>>> index 000000000000..dff5b592a97a
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
>>>> @@ -0,0 +1,20 @@
>>>> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>>>> +/*
>>>> + * Copyright (C) 2023 Martin Botka <martin.botka@somainline.org>.
>>>> + */
>>>> +
>>>> +/dts-v1/;
>>>> +
>>>> +#include "sun50i-h616-bigtreetech-cb1.dtsi"
>>>> +
>>>> +/ {
>>>> +	compatible = "bigtreetech,cb1-manta", "bigtreetech,cb1", "allwinner,sun50i-h616";
>>>> +};
>>>> +
>>>> +&ehci1 {
>>>> +	status = "okay";
>>>> +};
>>>> +
>>>> +&ohci1 {
>>>> +	status = "okay";
>>>> +};
>>>
>>> So how is the STM32 connected? Via SPI? If yes, you should activate the SPI
>>> node and specify the pinctrl.
>>> Even if this requires a patch cable to connect the SPI header coming from
>>> the CB1 to the SPI pins on the STM (does it?), it might be worth stating
>>> the pins used. I don't know for sure if we enable interfaces that are
>>> routed to fixed function header pins, but it might be worth doing so here,
>>> since this is some very obvious use case (I guess you wouldn't buy the M8P
>>> if you don't plan to use all of its goodies).
>> So the STM32 chip is connected directly via USB. There is USB hub on
>> Manta boards and Pi adapter (Not on BTT Pi. That one doesnt use USB hub)
>> that uses this USB port and STM32 connects via that. Then on manta
>> boards there are 2 USB ports and 1 USB port with just pins exposed on
>> XH2.54 4 pin connector. Bit weird but it is what it is :)
> 
> Ah, I missed that, and was already wondering where the fourth HUB output
> went to. So USB is fine. Do the hub or the STM need a switched regulator?
> Or is the hub and the STM32 always powered on?
Always powered on :)
> 
>>> And what's the USB-C connector doing? Is that an alternative power supply?
>>> Ann does it connect the port0 D-/D+ pins, so can be used for OTG? If yes,
>>> please enable the usb_otg node here.
>>>    
>> It is indeed an alternative power supply. Or well primary supply in the
>> case of Pi adapter board.
>>
>> It should be connected yes. Tho i never really had much luck getting it
>> to work. Tho i will check again and if i get it to work i will enable it
>> in V2 :)
> 
> You could test with FEL. Get
> https://github.com/linux-sunxi/sunxi-tools/raw/master/bin/fel-sdboot.sunxi,
> write that to sector 16 of an SD card, and boot from there.
> That should put the SoC into FEL mode, and you should be able to see the
> BootROM provided USB device ID on a connected host - if the data pins are
> connected to USB port 0.
> I see DP0/DM0 test pads on the SoM, maybe you can chase them down to
> see if they actually go to the SoM connector? But wasn't it that there is
> only one pair of USB pins available on a CM4 pinout? Hence the hub on the
> Mantra boards?
Yea the SoM connector supplies only 1 USB and that goes to multiplexer 
that should be switched via a small 4 switch thingy on the board.
And then one of those 2 outputs goes to USB hub.
> 
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
>>>> new file mode 100644
>>>> index 000000000000..e630114f0ce4
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
>>>> @@ -0,0 +1,164 @@
>>>> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>>>> +/*
>>>> + * Copyright (C) 2023 Martin Botka <martin.botka@somainline.org>.
>>>> + */
>>>> +
>>>> +/dts-v1/;
>>>> +
>>>> +#include "sun50i-h616.dtsi"
>>>> +
>>>> +#include <dt-bindings/gpio/gpio.h>
>>>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> +#include <dt-bindings/leds/common.h>
>>>> +
>>>> +/ {
>>>> +	model = "BigTreeTech CB1";
>>>> +	compatible = "bigtreetech,cb1", "allwinner,sun50i-h616";
>>>> +
>>>> +	aliases {
>>>> +		serial0 = &uart0;
>>>> +		ethernet0 = &rtl8189ftv;
>>>> +	};
>>>> +
>>>> +	chosen {
>>>> +		stdout-path = "serial0:115200n8";
>>>> +	};
>>>
>>> I think stdout-path belongs into the board .dts.
>>>   
>>
>> Got it
>>
>>>> +	
>>>> +	leds {
>>>> +		compatible = "gpio-leds";
>>>> +
>>>> +		led-0 {
>>>> +			function = LED_FUNCTION_STATUS;
>>>> +			color = <LED_COLOR_ID_GREEN>;
>>>> +			gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
>>>> +		};
>>>> +	};
>>>> +
>>>> +	reg_vcc5v: regulator-vcc5v {
>>>> +		/* board wide 5V supply directly from the USB-C socket */
>>>
>>> I guess this "regulator" is still valid, but please adjust the comment,
>>> since there is certainly no USB-C socket on the SoM. I guess it's multiple
>>> pins on the SoM connector that supply the incoming base voltage?
>> Correct. Its just pins that get the 5V power. My fault for saying
>> directly from USB-C since it can be from somewhere else :)
>>>    
>>>> +		compatible = "regulator-fixed";
>>>> +		regulator-name = "vcc-5v";
>>>> +		regulator-min-microvolt = <5000000>;
>>>> +		regulator-max-microvolt = <5000000>;
>>>> +		regulator-always-on;
>>>> +	};
>>>> +
>>>> +	reg_usb1_vbus: regulator-usb1-vbus {
>>>
>>> So is this regulator really on the SoM? Or is it just PC16 on the SoM
>>> connector, and the actual regulator chip is on the respective carrier
>>> boards?
>>>    
>>
>> This is my bad. This is completely wrong. The actual regulator is the 5V
>> one thats turned on when 5V comes in. Its bit weird but i suppose its
>> done that way for USB-OTG. This will be removed in next revision of this
>> DTS :)
> 
> Having fixed 5V supply for USB ports, coming directly from the board power
> supply, is actually quite common, see many Pine64 boards, for instance.
> In this case you don't need to specify a usb<x>_vbus-supply property in
> the PHY node below.
Got it.
> 
>>>> +		compatible = "regulator-fixed";
>>>> +		regulator-name = "usb1-vbus";
>>>> +		regulator-min-microvolt = <5000000>;
>>>> +		regulator-max-microvolt = <5000000>;
>>>> +		vin-supply = <&reg_vcc5v>;
>>>> +		enable-active-high;
>>>> +		gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>>>> +	};
>>>> +	
>>>> +	reg_vcc33_wifi: vcc33-wifi {
>>>> +		/* Always on 3.3V regulator for WiFi and BT */
>>>> +		compatible = "regulator-fixed";
>>>> +		regulator-name = "vcc33-wifi";
>>>> +		regulator-min-microvolt = <3300000>;
>>>> +		regulator-max-microvolt = <3300000>;
>>>> +		regulator-always-on;
>>>> +		vin-supply = <&reg_vcc5v>;
>>>> +	};
>>>> +	
>>>> +	reg_vcc_wifi_io: vcc-wifi-io {
>>>> +		/* Always on 1.8V/300mA regulator for WiFi and BT IO */
>>>> +		compatible = "regulator-fixed";
>>>> +		regulator-name = "vcc-wifi-io";
>>>> +		regulator-min-microvolt = <1800000>;
>>>> +		regulator-max-microvolt = <1800000>;
>>>> +		regulator-always-on;
>>>> +		vin-supply = <&reg_vcc33_wifi>;
>>>> +	};
>>>> +
>>>> +	wifi_pwrseq: wifi-pwrseq {
>>>> +		compatible = "mmc-pwrseq-simple";
>>>> +		clocks = <&rtc 1>;
>>>> +		clock-names = "ext_clock";
>>>> +		reset-gpios = <&pio 6 18 GPIO_ACTIVE_LOW>;  /* PG18 */
>>>> +		post-power-on-delay-ms = <200>;
>>>> +	};
>>>> +};
>>>> +
>>>> +&mmc0 {
>>>> +	vmmc-supply = <&reg_dldo1>;
>>>> +	broken-cd;
>>>
>>> Is there no card detect switch or is it not wired up, or is it really
>>> "broken"? Might be good to have a comment explaining that.
>>> And yeah, I also forgot to do this in my Orange Pi Zero3 .dts ;-)
>>>    
>> Its just straight up not connected. And since documentation specifies
>> that this should be set when no card detection is available i set it.
>>
>> Will add a comment specifying that this is due to the pin not being
>> connected.
> 
> Yes, that's correct, broken-cd is the right choice then and works fine. I
> was just asking because it *is* connected on the OrangePi Zero3, but didn't
> work for me there.
> 
>>>> +	bus-width = <4>;
>>>> +	status = "okay";
>>>> +};
>>>> +
>>>> +&mmc1 {
>>>> +	vmmc-supply = <&reg_vcc33_wifi>;
>>>> +	vqmmc-supply = <&reg_vcc_wifi_io>;
>>>> +	mmc-pwrseq = <&wifi_pwrseq>;
>>>> +	bus-width = <4>;
>>>> +	non-removable;
>>>> +	mmc-ddr-1_8v;
>>>> +	status = "okay";
>>>> +
>>>> +	rtl8189ftv: sdio_wifi@1 {
>>>> +		reg = <1>;
>>>> +	};
>>>> +};
>>>> +
>>>> +&r_i2c {
>>>> +	status = "okay";
>>>> +
>>>> +	axp313a: pmic@36 {
>>>> +		compatible = "x-powers,axp313a";
>>>> +		reg = <0x36>;
>>>> +		interrupt-controller;
>>>> +		#interrupt-cells = <1>;
>>>> +
>>>> +		regulators{
>>>> +			reg_dcdc1: dcdc1 {
>>>> +				regulator-name = "vdd-gpu";
>>>> +				regulator-min-microvolt = <500000>;
>>>> +				regulator-max-microvolt = <3400000>;
>>>
>>> So those are the ranges of the PMIC rail, but if this is really connected
>>> to VDD_GPU on the H616, you should limit it to between 0.81V and 0.99V, as
>>> described in the H616 datasheet. Otherwise this risks frying the SoC, I
>>> guess.
>>
>> The range here should be correct. It is also the sys rail. Since AXP313a
>> lacks many rails this was chosen as the sys rail as well.
> 
> Yes, very common indeed. I think in reality most boards will need all
> rails to be always on.
> 
>>>    
>>>> +				regulator-always-on;
>>>
>>> So is this connected to something else as well, like VDD_SYS? Please
>>> either mention this as a comment, to justify the always-on, or name the
>>> regulator accordingly, like "vdd-gpu-sys".
>> Will rename to vdd-gpu-sys.
>>>      
>>>> +			};
>>>> +
>>>> +			reg_dcdc2: dcdc2 {
>>>> +				regulator-name = "vdd-cpu";
>>>> +				regulator-min-microvolt = <500000>;
>>>> +				regulator-max-microvolt = <1540000>;
>>>
>>> Same limit problem here, VDD_CPU must be between 0.81V and 1.1V.
>> That is indeed right. I will test it on the range you provided with OPP
>> (WIP) and stress test it :)
>>>    
>>>> +				regulator-ramp-delay = <200>;
>>>> +				regulator-always-on;
>>>> +			};
>>>> +
>>>> +			reg_dcdc3: dcdc3 {
>>>> +				regulator-name = "vcc-dram";
>>>> +				regulator-min-microvolt = <500000>;
>>>> +				regulator-max-microvolt = <1840000>;
>>>
>>> Is that DDR3 or DDR3L DRAM here? I don't think there is any runtime
>>> adjustments here, so just specify the respective voltage required, with the
>>> same value for both min and max.
>> it uses Kingston D2516ECMDXGJD so DDR3. I will specify the direct voltage.
> 
> But this is DDR3L, so DDR3, just with a slightly lower voltage (1.35V
> instead of 1.5V). Please note that this is different from LPDDR3, which
> uses a different protocol, on top of lowering the voltage.
Well my bad. Was slightly in hurry when checking the very very crude 
datasheet kingston provides for it. Must have overlooked the mention of 
DDR3L.
> 
>>>    
>>>> +				regulator-always-on;
>>>> +			};
>>>> +
>>>> +			reg_aldo1: aldo1 {
>>>> +				regulator-name = "vcc-1v8";
>>>> +				regulator-min-microvolt = <1800000>;
>>>> +				regulator-max-microvolt = <1800000>;
>>>> +				regulator-always-on;
>>>
>>> Please mention what this supplies that justifies always-on.
>> ALDO1 1.8V gets also converted to 1.8V for DRAM. Thus needs to be on always.
> 
> Yes, as seen with other boards, where it more prominently also supplies
> VCC-PLL, which is essential for any clock operation. Might be worth
> checking, if you have access to the complete schematic.
I do :)
yes it also supplies PLL.
> 
>>>> +			};
>>>> +
>>>> +			reg_dldo1: dldo1 {
>>>> +				regulator-name = "vcc-3v3";
>>>> +				regulator-min-microvolt = <3300000>;
>>>> +				regulator-max-microvolt = <3300000>;
>>>> +				regulator-always-on;
>>>
>>> Please mention what this supplies that justifies always-on.
>> SDcard that serves as storage for system. Will add comments for both :)
> 
> SD card alone does not justify always-on, as you reference this regulator
> in the mmc0 node, so a kernel could make the connection. But chances are
> this is also connected to VCC-IO, which is also one of the mandatory supply
> voltages.
Correct. VCC-IO is one of the rails supplied from this parent rail.
> 
>>>    
>>>> +			};
>>>> +		};
>>>> +	};
>>>> +};
>>>> +
>>>> +&uart0 {
>>>> +	pinctrl-names = "default";
>>>> +	pinctrl-0 = <&uart0_ph_pins>;
>>>> +	status = "okay";
>>>> +};
>>>
>>> This belongs into the board .dts, since the connector/UART bridge is
>>> there.
>> Actually the SoM has exposed pads to connect UART (Which is what i have
>> done to get UART) but also the boards get the exact pins wired to GPIO.
> 
> Those pad on the lower right corner? In this case it might justify having
> the UART node in the SoM .dtsi, though I don't know if (test)pads qualify
> for enabling peripherals. Generic GPIO pins (say pinmux'ed I2C on some
> GPIO headers) certainly don't.
Its fine. I will just enable it in carrier boards and BTT Pi DTS :)

Cheers,
Martin
> 
> Cheers,
> Andre
> 
>> But since most users would use the GPIO UART i will specify it in
>> carrier boards and in BTT Pi boards separately.
>>
>> Cheers,
>> Martin
>>>
>>> Cheers,
>>> Andre
>>>    
>>>> +
>>>> +&usbphy {
>>>> +	usb1_vbus-supply = <&reg_usb1_vbus>;
>>>> +	status = "okay";
>>>> +};
>>>
>>>    
>>
>>
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 5/6] arm64: dts: allwinner: h616: Add BigTreeTech CB1 SoM & boards support

[Jernej Škrabec]

Dne četrtek, 03. avgust 2023 ob 17:35:55 CEST je Martin Botka napisal(a):
> On 8/3/23 2:37 PM, Andre Przywara wrote:
> > On Thu,  3 Aug 2023 00:02:38 +0200
> > Martin Botka <martin@biqu3d.com> wrote:
> > 
> > Hi Martin,
> > 
> > thanks for sending this!
> > There are some whitespace errors in here, some leading tabs in the first
> > section. "git show" should print them in red.
> > 
> >> From: Martin Botka <martin.botka@somainline.org>
> >> 
> >> CB1 is Compute Module style board that plugs into Rpi board style adapter
> >> or Manta 3D printer boards (M4P/M8P).
> >> 
> >> The SoM features:
> >>    - H616 SoC
> >>    - 1GiB of RAM
> >>    - AXP313A PMIC
> >>    - RTL8189FTV WiFi
> >> 
> >> Boards feature:
> >>    - 4x USB via USB2 hub (usb1 on SoM).
> >>    - SDcard slot for loading images.
> >>    - Ethernet port wired to the internal PHY. (100M)
> >>    - 2x HDMI 2.0. (Only 1 usable on CB1)
> >>    - Power and Status LEDs. (Only Status LED usable on CB1)
> >>    - 40 pin GPIO header
> >> 
> >> Currently working:
> >>    - Booting
> >>    - USB
> >>    - UART
> >>    - MMC
> >>    - Status LED
> >>    - WiFi (RTL8189FS via out of tree driver)
> >> 
> >> I didnt want to duplicate things so the manta DTS can also be used on BTT
> >> pi4b adapter. CB1 SoM has its own DTSI file in case other boards shows
> >> up that accept this SoM.
> >> 
> >> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> >> ---
> >> 
> >>   arch/arm64/boot/dts/allwinner/Makefile        |   1 +
> >>   .../sun50i-h616-bigtreetech-cb1-manta.dts     |  20 +++
> >>   .../sun50i-h616-bigtreetech-cb1.dtsi          | 164 ++++++++++++++++++
> >>   3 files changed, 185 insertions(+)
> >>   create mode 100644
> >>   arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
> >>   create mode 100644
> >>   arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi>> 
> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> >> b/arch/arm64/boot/dts/allwinner/Makefile index
> >> 6a96494a2e0a..7b386428510b 100644
> >> --- a/arch/arm64/boot/dts/allwinner/Makefile
> >> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> >> @@ -38,5 +38,6 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> >> 
> >>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> >>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> >>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
> >> 
> >> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
> >> 
> >>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> >>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
> >> 
> >> diff --git
> >> a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
> >> b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
> >> new file mode 100644
> >> index 000000000000..dff5b592a97a
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1-manta.dts
> >> @@ -0,0 +1,20 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> >> +/*
> >> + * Copyright (C) 2023 Martin Botka <martin.botka@somainline.org>.
> >> + */
> >> +
> >> +/dts-v1/;
> >> +
> >> +#include "sun50i-h616-bigtreetech-cb1.dtsi"
> >> +
> >> +/ {
> >> +	compatible = "bigtreetech,cb1-manta", "bigtreetech,cb1",
> >> "allwinner,sun50i-h616"; +};
> >> +
> >> +&ehci1 {
> >> +	status = "okay";
> >> +};
> >> +
> >> +&ohci1 {
> >> +	status = "okay";
> >> +};
> > 
> > So how is the STM32 connected? Via SPI? If yes, you should activate the
> > SPI
> > node and specify the pinctrl.
> > Even if this requires a patch cable to connect the SPI header coming from
> > the CB1 to the SPI pins on the STM (does it?), it might be worth stating
> > the pins used. I don't know for sure if we enable interfaces that are
> > routed to fixed function header pins, but it might be worth doing so here,
> > since this is some very obvious use case (I guess you wouldn't buy the M8P
> > if you don't plan to use all of its goodies).
> 
> So the STM32 chip is connected directly via USB. There is USB hub on
> Manta boards and Pi adapter (Not on BTT Pi. That one doesnt use USB hub)
> that uses this USB port and STM32 connects via that. Then on manta
> boards there are 2 USB ports and 1 USB port with just pins exposed on
> XH2.54 4 pin connector. Bit weird but it is what it is :)
> 
> > And what's the USB-C connector doing? Is that an alternative power supply?
> > Ann does it connect the port0 D-/D+ pins, so can be used for OTG? If yes,
> > please enable the usb_otg node here.
> 
> It is indeed an alternative power supply. Or well primary supply in the
> case of Pi adapter board.
> 
> It should be connected yes. Tho i never really had much luck getting it
> to work. Tho i will check again and if i get it to work i will enable it
> in V2 :)
> 
> >> diff --git
> >> a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
> >> b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi new
> >> file mode 100644
> >> index 000000000000..e630114f0ce4
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
> >> @@ -0,0 +1,164 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> >> +/*
> >> + * Copyright (C) 2023 Martin Botka <martin.botka@somainline.org>.
> >> + */
> >> +
> >> +/dts-v1/;
> >> +
> >> +#include "sun50i-h616.dtsi"
> >> +
> >> +#include <dt-bindings/gpio/gpio.h>
> >> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> >> +#include <dt-bindings/leds/common.h>
> >> +
> >> +/ {
> >> +	model = "BigTreeTech CB1";
> >> +	compatible = "bigtreetech,cb1", "allwinner,sun50i-h616";
> >> +
> >> +	aliases {
> >> +		serial0 = &uart0;
> >> +		ethernet0 = &rtl8189ftv;
> >> +	};
> >> +
> >> +	chosen {
> >> +		stdout-path = "serial0:115200n8";
> >> +	};
> > 
> > I think stdout-path belongs into the board .dts.
> 
> Got it
> 
> >> +
> >> +	leds {
> >> +		compatible = "gpio-leds";
> >> +
> >> +		led-0 {
> >> +			function = LED_FUNCTION_STATUS;
> >> +			color = <LED_COLOR_ID_GREEN>;
> >> +			gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 
*/
> >> +		};
> >> +	};
> >> +
> >> +	reg_vcc5v: regulator-vcc5v {
> >> +		/* board wide 5V supply directly from the USB-C socket 
*/
> > 
> > I guess this "regulator" is still valid, but please adjust the comment,
> > since there is certainly no USB-C socket on the SoM. I guess it's multiple
> > pins on the SoM connector that supply the incoming base voltage?
> 
> Correct. Its just pins that get the 5V power. My fault for saying
> directly from USB-C since it can be from somewhere else :)
> 
> >> +		compatible = "regulator-fixed";
> >> +		regulator-name = "vcc-5v";
> >> +		regulator-min-microvolt = <5000000>;
> >> +		regulator-max-microvolt = <5000000>;
> >> +		regulator-always-on;
> >> +	};
> >> +
> >> +	reg_usb1_vbus: regulator-usb1-vbus {
> > 
> > So is this regulator really on the SoM? Or is it just PC16 on the SoM
> > connector, and the actual regulator chip is on the respective carrier
> > boards?
> 
> This is my bad. This is completely wrong. The actual regulator is the 5V
> one thats turned on when 5V comes in. Its bit weird but i suppose its
> done that way for USB-OTG. This will be removed in next revision of this
> DTS :)
> 
> >> +		compatible = "regulator-fixed";
> >> +		regulator-name = "usb1-vbus";
> >> +		regulator-min-microvolt = <5000000>;
> >> +		regulator-max-microvolt = <5000000>;
> >> +		vin-supply = <&reg_vcc5v>;
> >> +		enable-active-high;
> >> +		gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> >> +	};
> >> +
> >> +	reg_vcc33_wifi: vcc33-wifi {
> >> +		/* Always on 3.3V regulator for WiFi and BT */
> >> +		compatible = "regulator-fixed";
> >> +		regulator-name = "vcc33-wifi";
> >> +		regulator-min-microvolt = <3300000>;
> >> +		regulator-max-microvolt = <3300000>;
> >> +		regulator-always-on;
> >> +		vin-supply = <&reg_vcc5v>;
> >> +	};
> >> +
> >> +	reg_vcc_wifi_io: vcc-wifi-io {
> >> +		/* Always on 1.8V/300mA regulator for WiFi and BT IO */
> >> +		compatible = "regulator-fixed";
> >> +		regulator-name = "vcc-wifi-io";
> >> +		regulator-min-microvolt = <1800000>;
> >> +		regulator-max-microvolt = <1800000>;
> >> +		regulator-always-on;
> >> +		vin-supply = <&reg_vcc33_wifi>;
> >> +	};
> >> +
> >> +	wifi_pwrseq: wifi-pwrseq {
> >> +		compatible = "mmc-pwrseq-simple";
> >> +		clocks = <&rtc 1>;
> >> +		clock-names = "ext_clock";
> >> +		reset-gpios = <&pio 6 18 GPIO_ACTIVE_LOW>;  /* PG18 */
> >> +		post-power-on-delay-ms = <200>;
> >> +	};
> >> +};
> >> +
> >> +&mmc0 {
> >> +	vmmc-supply = <&reg_dldo1>;
> >> +	broken-cd;
> > 
> > Is there no card detect switch or is it not wired up, or is it really
> > "broken"? Might be good to have a comment explaining that.
> > And yeah, I also forgot to do this in my Orange Pi Zero3 .dts ;-)
> 
> Its just straight up not connected. And since documentation specifies
> that this should be set when no card detection is available i set it.
> 
> Will add a comment specifying that this is due to the pin not being
> connected.
> 
> >> +	bus-width = <4>;
> >> +	status = "okay";
> >> +};
> >> +
> >> +&mmc1 {
> >> +	vmmc-supply = <&reg_vcc33_wifi>;
> >> +	vqmmc-supply = <&reg_vcc_wifi_io>;
> >> +	mmc-pwrseq = <&wifi_pwrseq>;
> >> +	bus-width = <4>;
> >> +	non-removable;
> >> +	mmc-ddr-1_8v;
> >> +	status = "okay";
> >> +
> >> +	rtl8189ftv: sdio_wifi@1 {
> >> +		reg = <1>;
> >> +	};
> >> +};
> >> +
> >> +&r_i2c {
> >> +	status = "okay";
> >> +
> >> +	axp313a: pmic@36 {
> >> +		compatible = "x-powers,axp313a";
> >> +		reg = <0x36>;
> >> +		interrupt-controller;
> >> +		#interrupt-cells = <1>;
> >> +
> >> +		regulators{
> >> +			reg_dcdc1: dcdc1 {
> >> +				regulator-name = "vdd-gpu";
> >> +				regulator-min-microvolt = 
<500000>;
> >> +				regulator-max-microvolt = 
<3400000>;
> > 
> > So those are the ranges of the PMIC rail, but if this is really connected
> > to VDD_GPU on the H616, you should limit it to between 0.81V and 0.99V, as
> > described in the H616 datasheet. Otherwise this risks frying the SoC, I
> > guess.
> 
> The range here should be correct. It is also the sys rail. Since AXP313a
> lacks many rails this was chosen as the sys rail as well.

You should then expand name to "vdd-gpu-sys" or something like that, so it's 
obvious it's not only gpu, but sys power too. Same with other regulators.

SYS voltage has pretty narow range, right? You should always select strictest 
min and max limits according to all datasheets or manuals, so stability issues 
and frying electronics is avoided.

Best regards,
Jernej

> 
> >> +				regulator-always-on;
> > 
> > So is this connected to something else as well, like VDD_SYS? Please
> > either mention this as a comment, to justify the always-on, or name the
> > regulator accordingly, like "vdd-gpu-sys".
> 
> Will rename to vdd-gpu-sys.
> 
> >> +			};
> >> +
> >> +			reg_dcdc2: dcdc2 {
> >> +				regulator-name = "vdd-cpu";
> >> +				regulator-min-microvolt = 
<500000>;
> >> +				regulator-max-microvolt = 
<1540000>;
> > 
> > Same limit problem here, VDD_CPU must be between 0.81V and 1.1V.
> 
> That is indeed right. I will test it on the range you provided with OPP
> (WIP) and stress test it :)
> 
> >> +				regulator-ramp-delay = <200>;
> >> +				regulator-always-on;
> >> +			};
> >> +
> >> +			reg_dcdc3: dcdc3 {
> >> +				regulator-name = "vcc-dram";
> >> +				regulator-min-microvolt = 
<500000>;
> >> +				regulator-max-microvolt = 
<1840000>;
> > 
> > Is that DDR3 or DDR3L DRAM here? I don't think there is any runtime
> > adjustments here, so just specify the respective voltage required, with
> > the
> > same value for both min and max.
> 
> it uses Kingston D2516ECMDXGJD so DDR3. I will specify the direct voltage.
> 
> >> +				regulator-always-on;
> >> +			};
> >> +
> >> +			reg_aldo1: aldo1 {
> >> +				regulator-name = "vcc-1v8";
> >> +				regulator-min-microvolt = 
<1800000>;
> >> +				regulator-max-microvolt = 
<1800000>;
> >> +				regulator-always-on;
> > 
> > Please mention what this supplies that justifies always-on.
> 
> ALDO1 1.8V gets also converted to 1.8V for DRAM. Thus needs to be on always.
> >> +			};
> >> +
> >> +			reg_dldo1: dldo1 {
> >> +				regulator-name = "vcc-3v3";
> >> +				regulator-min-microvolt = 
<3300000>;
> >> +				regulator-max-microvolt = 
<3300000>;
> >> +				regulator-always-on;
> > 
> > Please mention what this supplies that justifies always-on.
> 
> SDcard that serves as storage for system. Will add comments for both :)
> 
> >> +			};
> >> +		};
> >> +	};
> >> +};
> >> +
> >> +&uart0 {
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&uart0_ph_pins>;
> >> +	status = "okay";
> >> +};
> > 
> > This belongs into the board .dts, since the connector/UART bridge is
> > there.
> 
> Actually the SoM has exposed pads to connect UART (Which is what i have
> done to get UART) but also the boards get the exact pins wired to GPIO.
> 
> But since most users would use the GPIO UART i will specify it in
> carrier boards and in BTT Pi boards separately.
> 
> Cheers,
> Martin
> 
> > Cheers,
> > Andre
> > 
> >> +
> >> +&usbphy {
> >> +	usb1_vbus-supply = <&reg_usb1_vbus>;
> >> +	status = "okay";
> >> +};





_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 5/6] arm64: dts: allwinner: h616: Add BigTreeTech CB1 SoM & boards support

[Krzysztof Kozlowski]

On 03/08/2023 00:02, Martin Botka wrote:
> From: Martin Botka <martin.botka@somainline.org>
> 
> CB1 is Compute Module style board that plugs into Rpi board style adapter or
> Manta 3D printer boards (M4P/M8P).
> 
> The SoM features:
>   - H616 SoC
>   - 1GiB of RAM
>   - AXP313A PMIC
>   - RTL8189FTV WiFi

...

> +&mmc0 {
> +	vmmc-supply = <&reg_dldo1>;
> +	broken-cd;
> +	bus-width = <4>;
> +	status = "okay";
> +};
> +
> +&mmc1 {
> +	vmmc-supply = <&reg_vcc33_wifi>;
> +	vqmmc-supply = <&reg_vcc_wifi_io>;
> +	mmc-pwrseq = <&wifi_pwrseq>;
> +	bus-width = <4>;
> +	non-removable;
> +	mmc-ddr-1_8v;
> +	status = "okay";
> +
> +	rtl8189ftv: sdio_wifi@1 {

No underxcores in node names. Generic node names, so probably "wifi".

> +		reg = <1>;

Missing compatible?



Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 5/6] arm64: dts: allwinner: h616: Add BigTreeTech CB1 SoM & boards support

[Martin Botka]

On 8/3/23 4:28 PM, Krzysztof Kozlowski wrote:
> On 03/08/2023 00:02, Martin Botka wrote:
>> From: Martin Botka <martin.botka@somainline.org>
>>
>> CB1 is Compute Module style board that plugs into Rpi board style adapter or
>> Manta 3D printer boards (M4P/M8P).
>>
>> The SoM features:
>>    - H616 SoC
>>    - 1GiB of RAM
>>    - AXP313A PMIC
>>    - RTL8189FTV WiFi
> 
> ...
> 
>> +&mmc0 {
>> +	vmmc-supply = <&reg_dldo1>;
>> +	broken-cd;
>> +	bus-width = <4>;
>> +	status = "okay";
>> +};
>> +
>> +&mmc1 {
>> +	vmmc-supply = <&reg_vcc33_wifi>;
>> +	vqmmc-supply = <&reg_vcc_wifi_io>;
>> +	mmc-pwrseq = <&wifi_pwrseq>;
>> +	bus-width = <4>;
>> +	non-removable;
>> +	mmc-ddr-1_8v;
>> +	status = "okay";
>> +
>> +	rtl8189ftv: sdio_wifi@1 {
> 
> No underxcores in node names. Generic node names, so probably "wifi".
Got it.
> 
>> +		reg = <1>;
> 
> Missing compatible?
No it is an explicitly defined SDIO device so we can add ethernet alias 
for it so we can for example set the MAC address of it via u-boot and etc :)

The actual driver for it is out of tree and from the current state of it 
looks like will be for a while.
Orange Pi Zero Plus based on H5 does this exact thing as well for the 
same purpose with the same wifi chip :)

Cheers,
Martin
> 
> 
> 
> Best regards,
> Krzysztof
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 6/6] arm64: dts: allwinner: h616: Add BigTreeTech Pi support

[Martin Botka]

The BigTreeTech Pi is an H616 based board based on CB1.
Just in Rpi format board.

It features the same internals as BTT CB1 but adds:
    - Fan port
    - IR receiver
    - 24V DC power supply via terminal plugs
    - USB to CAN module connector (The actual USB to CAN happens on the external module)

List of currently working things is the same as BTT CB1.

Signed-off-by: Martin Botka <martin@biqu3d.com>
---
 .../allwinner/sun50i-h616-bigtreetech-pi.dts  | 44 +++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
new file mode 100644
index 000000000000..05f39b3606ba
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2023 Martin Botka <martin@biqu3d.com>.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616-bigtreetech-cb1.dtsi"
+
+/ {
+	compatible = "bigtreetech,pi", "allwinner,sun50i-h616";
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&ohci0 {
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&ehci2 {
+	status = "okay";
+};
+
+&ohci2 {
+	status = "okay";
+};
+
+&ehci3 {
+	status = "okay";
+};
+
+&ohci3 {
+	status = "okay";
+};
-- 
2.41.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 6/6] arm64: dts: allwinner: h616: Add BigTreeTech Pi support

[Andre Przywara]

On Thu,  3 Aug 2023 00:02:39 +0200
Martin Botka <martin@biqu3d.com> wrote:

Hi,

> The BigTreeTech Pi is an H616 based board based on CB1.
> Just in Rpi format board.
> 
> It features the same internals as BTT CB1 but adds:
>     - Fan port
>     - IR receiver

You would then need to enable the "ir" node, check the X96 Mate .dts.

And I think this "ADXL345 SPI" connector justifies enabling the respective
SPI node.

>     - 24V DC power supply via terminal plugs
>     - USB to CAN module connector (The actual USB to CAN happens on the external module)

Still confused how this works. So you would need to connect an USB->CAN
adapter to one of the USB ports, but how do you feed the CAN signal back
to the board? Or if this is done via this port, where does it go then? To
the GPIO header?

> List of currently working things is the same as BTT CB1.
> 
> Signed-off-by: Martin Botka <martin@biqu3d.com>
> ---
>  .../allwinner/sun50i-h616-bigtreetech-pi.dts  | 44 +++++++++++++++++++

Please wire this up in the Makefile as well, otherwise we will miss out on
the build testing and DTB checking.

>  1 file changed, 44 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
> new file mode 100644
> index 000000000000..05f39b3606ba
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
> @@ -0,0 +1,44 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2023 Martin Botka <martin@biqu3d.com>.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616-bigtreetech-cb1.dtsi"
> +
> +/ {
> +	compatible = "bigtreetech,pi", "allwinner,sun50i-h616";
> +};
> +
> +&ehci0 {
> +	status = "okay";
> +};
> +
> +&ohci0 {
> +	status = "okay";
> +};
> +
> +&ehci1 {
> +	status = "okay";
> +};
> +
> +&ohci1 {
> +	status = "okay";
> +};
> +
> +&ehci2 {
> +	status = "okay";
> +};
> +
> +&ohci2 {
> +	status = "okay";
> +};
> +
> +&ehci3 {
> +	status = "okay";
> +};
> +
> +&ohci3 {
> +	status = "okay";
> +};

Oh wow, it really connects all four USB ports directly to the SoC? Nice.
Do you have access to the schematic to check what the power supply
situation is? Are all ports hardwired to a fixed 5V source?

And you would of course need to adjust this file according to the
changes requested in the previous patch, so that you have the UART,
stdout-path and other moved nodes in here.

Cheers,
Andre

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 6/6] arm64: dts: allwinner: h616: Add BigTreeTech Pi support

[Martin Botka]

On 8/3/23 2:39 PM, Andre Przywara wrote:
> On Thu,  3 Aug 2023 00:02:39 +0200
> Martin Botka <martin@biqu3d.com> wrote:
> 
> Hi,
> 
>> The BigTreeTech Pi is an H616 based board based on CB1.
>> Just in Rpi format board.
>>
>> It features the same internals as BTT CB1 but adds:
>>      - Fan port
>>      - IR receiver
> 
> You would then need to enable the "ir" node, check the X96 Mate .dts.
Got it.
> 
> And I think this "ADXL345 SPI" connector justifies enabling the respective
> SPI node.
Yea the accelerator. Sadly this is bit hard to actually test fully if 
not wired up to a printer. Tho i do have a spare board to serve as fake 
printer. Klipper will not know any better :)
> 
>>      - 24V DC power supply via terminal plugs
>>      - USB to CAN module connector (The actual USB to CAN happens on the external module)
> 
> Still confused how this works. So you would need to connect an USB->CAN
> adapter to one of the USB ports, but how do you feed the CAN signal back
> to the board? Or if this is done via this port, where does it go then? To
> the GPIO header?
OK so its not great but an USB port is also connected to 2x2 pin 
connector and secondary 2x2 pin connector slightly away. The USB to CAN 
module plugs into these 2x2 pin connectors where one serves as USB and 
the other one receives the CAN signal from the module and just wires it 
up to an XH2.54 3 pin connector with CAN+ CAN- and GND.
> 
>> List of currently working things is the same as BTT CB1.
>>
>> Signed-off-by: Martin Botka <martin@biqu3d.com>
>> ---
>>   .../allwinner/sun50i-h616-bigtreetech-pi.dts  | 44 +++++++++++++++++++
> 
> Please wire this up in the Makefile as well, otherwise we will miss out on
> the build testing and DTB checking.
YEP very much my bad on that one. Didnt add the file during git add :)
> 
>>   1 file changed, 44 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
>> new file mode 100644
>> index 000000000000..05f39b3606ba
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
>> @@ -0,0 +1,44 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> +/*
>> + * Copyright (C) 2023 Martin Botka <martin@biqu3d.com>.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "sun50i-h616-bigtreetech-cb1.dtsi"
>> +
>> +/ {
>> +	compatible = "bigtreetech,pi", "allwinner,sun50i-h616";
>> +};
>> +
>> +&ehci0 {
>> +	status = "okay";
>> +};
>> +
>> +&ohci0 {
>> +	status = "okay";
>> +};
>> +
>> +&ehci1 {
>> +	status = "okay";
>> +};
>> +
>> +&ohci1 {
>> +	status = "okay";
>> +};
>> +
>> +&ehci2 {
>> +	status = "okay";
>> +};
>> +
>> +&ohci2 {
>> +	status = "okay";
>> +};
>> +
>> +&ehci3 {
>> +	status = "okay";
>> +};
>> +
>> +&ohci3 {
>> +	status = "okay";
>> +};
> 
> Oh wow, it really connects all four USB ports directly to the SoC? Nice.
It indeed does :)
> Do you have access to the schematic to check what the power supply
> situation is? Are all ports hardwired to a fixed 5V source?
Correct just fixed 5V. Tho with the changes needed in CB1 DTSI file no 
change will be necessary here for this :)
> 
> And you would of course need to adjust this file according to the
> changes requested in the previous patch, so that you have the UART,
> stdout-path and other moved nodes in here.
Got it will do.

Cheers,
Martin
> 
> Cheers,
> Andre
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 6/6] arm64: dts: allwinner: h616: Add BigTreeTech Pi support

[Krzysztof Kozlowski]

On 03/08/2023 00:02, Martin Botka wrote:
> The BigTreeTech Pi is an H616 based board based on CB1.
> Just in Rpi format board.
> 
> It features the same internals as BTT CB1 but adds:
>     - Fan port
>     - IR receiver
>     - 24V DC power supply via terminal plugs
>     - USB to CAN module connector (The actual USB to CAN happens on the external module)
> 
> List of currently working things is the same as BTT CB1.
> 
> Signed-off-by: Martin Botka <martin@biqu3d.com>
> ---
>  .../allwinner/sun50i-h616-bigtreetech-pi.dts  | 44 +++++++++++++++++++
>  1 file changed, 44 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
> new file mode 100644
> index 000000000000..05f39b3606ba
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
> @@ -0,0 +1,44 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2023 Martin Botka <martin@biqu3d.com>.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616-bigtreetech-cb1.dtsi"

If this is using CB1 DTSI, does it mean it uses CB1 SoM? If so, I think
this should be reflected in the compatibles.

It's a bit confusing because in previous patch you call it "CB1 board"
but then with name "Manta"... So what is CB1?

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 6/6] arm64: dts: allwinner: h616: Add BigTreeTech Pi support

[Andre Przywara]

On Thu, 3 Aug 2023 16:30:06 +0200
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:

> On 03/08/2023 00:02, Martin Botka wrote:
> > The BigTreeTech Pi is an H616 based board based on CB1.
> > Just in Rpi format board.
> > 
> > It features the same internals as BTT CB1 but adds:
> >     - Fan port
> >     - IR receiver
> >     - 24V DC power supply via terminal plugs
> >     - USB to CAN module connector (The actual USB to CAN happens on the external module)
> > 
> > List of currently working things is the same as BTT CB1.
> > 
> > Signed-off-by: Martin Botka <martin@biqu3d.com>
> > ---
> >  .../allwinner/sun50i-h616-bigtreetech-pi.dts  | 44 +++++++++++++++++++
> >  1 file changed, 44 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
> > 
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
> > new file mode 100644
> > index 000000000000..05f39b3606ba
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
> > @@ -0,0 +1,44 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +/*
> > + * Copyright (C) 2023 Martin Botka <martin@biqu3d.com>.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "sun50i-h616-bigtreetech-cb1.dtsi"  
> 
> If this is using CB1 DTSI, does it mean it uses CB1 SoM? If so, I think
> this should be reflected in the compatibles.
> 
> It's a bit confusing because in previous patch you call it "CB1 board"
> but then with name "Manta"... So what is CB1?

That's indeed a bit confusing, but from what I got from the BTT webpage:
"CB1" is the SoM. M8P (and its M4P/M5P siblings) are carrier boards with
extra hardware for 3D printer support, taking the CB1 SoM.
The "Bigtreetech BTT Pi" is embedding the same hardware as the SoM, but
without actually using the SoM, directly on a PCB, so similar to what we
have with the Pine64 SoPine and the Pine64 LTS board. It doesn't come with
the extra goodies of the more 3D printer related boards.

I *think* the "BIGTREETECH PI4B Adapter" is a normal dev board using the
actual SoM, but with an otherwise identical(?) functionality software wise
- so it can run with the same DTB. I wonder if we should have a separate
.dts for this, though, since I believe it's not really identical in every
aspect - starting with the USB ports, for instance.

But for this board and patch here I think it's fine to include the
cb1.dtsi, but not using the CB1 name in the compatibles list.

Cheers,
Andre

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 6/6] arm64: dts: allwinner: h616: Add BigTreeTech Pi support

[Martin Botka]

On 8/3/23 4:49 PM, Andre Przywara wrote:
> On Thu, 3 Aug 2023 16:30:06 +0200
> Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> 
>> On 03/08/2023 00:02, Martin Botka wrote:
>>> The BigTreeTech Pi is an H616 based board based on CB1.
>>> Just in Rpi format board.
>>>
>>> It features the same internals as BTT CB1 but adds:
>>>      - Fan port
>>>      - IR receiver
>>>      - 24V DC power supply via terminal plugs
>>>      - USB to CAN module connector (The actual USB to CAN happens on the external module)
>>>
>>> List of currently working things is the same as BTT CB1.
>>>
>>> Signed-off-by: Martin Botka <martin@biqu3d.com>
>>> ---
>>>   .../allwinner/sun50i-h616-bigtreetech-pi.dts  | 44 +++++++++++++++++++
>>>   1 file changed, 44 insertions(+)
>>>   create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
>>> new file mode 100644
>>> index 000000000000..05f39b3606ba
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-pi.dts
>>> @@ -0,0 +1,44 @@
>>> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>>> +/*
>>> + * Copyright (C) 2023 Martin Botka <martin@biqu3d.com>.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include "sun50i-h616-bigtreetech-cb1.dtsi"
>>
>> If this is using CB1 DTSI, does it mean it uses CB1 SoM? If so, I think
>> this should be reflected in the compatibles.
>>
>> It's a bit confusing because in previous patch you call it "CB1 board"
>> but then with name "Manta"... So what is CB1?
> 
> That's indeed a bit confusing, but from what I got from the BTT webpage:
> "CB1" is the SoM. M8P (and its M4P/M5P siblings) are carrier boards with
> extra hardware for 3D printer support, taking the CB1 SoM.
> The "Bigtreetech BTT Pi" is embedding the same hardware as the SoM, but
> without actually using the SoM, directly on a PCB, so similar to what we
> have with the Pine64 SoPine and the Pine64 LTS board. It doesn't come with
> the extra goodies of the more 3D printer related boards.
> 
> I *think* the "BIGTREETECH PI4B Adapter" is a normal dev board using the
> actual SoM, but with an otherwise identical(?) functionality software wise
> - so it can run with the same DTB. I wonder if we should have a separate
> .dts for this, though, since I believe it's not really identical in every
> aspect - starting with the USB ports, for instance.
> 
> But for this board and patch here I think it's fine to include the
> cb1.dtsi, but not using the CB1 name in the compatibles list.
> 

You got it perfectly Andre :) Yes CB1 is an SoM and Manta boards and BTT 
Pi4B adapter board are just carriers of this SoM. PI4B board uses the 
same DTB as manta boards. It also has the same USB hub and etc.

BTT Pi on the other hand is CB1 hardware but actually comes in Pi format 
with the CB1 hardware embedded on the boards directly. BTT Pi wires up 
the USB ports to their respective ports on SoC and thus the separate DTS 
(Also ofc the extra stuff like IR and fan port which will be enabled in 
the future)

Cheers,
Martin
> Cheers,
> Andre
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel