* [PATCH v3 1/2] dt-bindings: arm: sunxi: Add BIQU CB1
@ 2022-11-14 21:44 ` Martin Botka
0 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-14 21:44 UTC (permalink / raw)
To: martin.botka1
Cc: ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Martin Botka, Rob Herring,
Krzysztof Kozlowski, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Andre Przywara, Maxime Ripard, Andrew Lunn,
Conley Lee, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Add a name & compatible for BIQU CB1
Signed-off-by: Martin Botka <martin.botka@somainline.org>
---
Changes in V2:
Add compatible and name to dt-bindings
Changes in V3:
None
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 3ad1cd50e3fe..d886924023f5 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: Biqu CB1
+ items:
+ - const: biqu,cb1
+ - const: allwinner,sun50i-h616
+
- description: Chuwi V7 CW0825
items:
- const: chuwi,v7-cw0825
--
2.38.1
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH v3 1/2] dt-bindings: arm: sunxi: Add BIQU CB1
@ 2022-11-14 21:44 ` Martin Botka
0 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-14 21:44 UTC (permalink / raw)
To: martin.botka1
Cc: ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Martin Botka, Rob Herring,
Krzysztof Kozlowski, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Andre Przywara, Maxime Ripard, Andrew Lunn,
Conley Lee, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Add a name & compatible for BIQU CB1
Signed-off-by: Martin Botka <martin.botka@somainline.org>
---
Changes in V2:
Add compatible and name to dt-bindings
Changes in V3:
None
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 3ad1cd50e3fe..d886924023f5 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: Biqu CB1
+ items:
+ - const: biqu,cb1
+ - const: allwinner,sun50i-h616
+
- description: Chuwi V7 CW0825
items:
- const: chuwi,v7-cw0825
--
2.38.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-14 21:44 ` Martin Botka
@ 2022-11-14 21:44 ` Martin Botka
-1 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-14 21:44 UTC (permalink / raw)
To: martin.botka1
Cc: ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Martin Botka, Rob Herring,
Krzysztof Kozlowski, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Maxime Ripard, Andre Przywara, Conley Lee,
Andrew Lunn, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
CB1 is Compute Module style board that plugs into Rpi board style adapter or
Manta 3D printer boards (M4P/M8P).
The board has:
H616 SoC
1GB of RAM
AXP313A PMIC
And the actual boards that CB1 plugs in are just extension to it with ports and
thus are not split in DT.
Boards have:
4x (3x for Manta boards) USB and 1 USB OTG.
SDcard slot for loading images.
Ethernet port wired to the internal PHY.
2x HDMI 2.0.
Power and Status LEDs.
Currently working:
Booting
USB
UART
Signed-off-by: Martin Botka <martin.botka@somainline.org>
---
Changes in V2:
Add proper board compatible
Add regulator prefix for vcc5v
Drop okay status from PMIC
Drop standby_param
Changes in V3:
Change copyright to me
regulator_vcc5v to regulator-vcc5v
Drop ehci0 and ohci0
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
2 files changed, 179 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
new file mode 100644
index 000000000000..86b5aca9b53e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2022 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 = "BIQU CB1";
+ compatible = "biqu,cb1", "allwinner,sun50i-h616";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ function = LED_FUNCTION_POWER;
+ color = <LED_COLOR_ID_RED>;
+ gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
+ default-state = "on";
+ };
+
+ led-1 {
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_GREEN>;
+ gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
+ };
+ };
+
+ 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 = <®_vcc5v>;
+ enable-active-high;
+ gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
+ };
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&ehci2 {
+ status = "okay";
+};
+
+&ehci3 {
+ status = "okay";
+};
+
+&mmc0 {
+ vmmc-supply = <®_dldo1>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+ no-1-8-v;
+ bus-width = <4>;
+ status = "disabled";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&ohci2 {
+ status = "okay";
+};
+
+&ohci3 {
+ status = "okay";
+};
+
+&r_i2c {
+ status = "okay";
+
+ axp1530: pmic@36 {
+ compatible = "x-powers,axp1530";
+ reg = <0x36>;
+ wakeup-source;
+
+ regulators{
+ reg_dcdc1: dcdc1 {
+ regulator-name = "axp1530-dcdc1";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-step-delay-us = <25>;
+ regulator-final-delay-us = <50>;
+ regulator-always-on;
+ };
+
+ reg_dcdc2: dcdc2 {
+ regulator-name = "axp1530-dcdc2";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1540000>;
+ regulator-step-delay-us = <25>;
+ regulator-final-delay-us = <50>;
+ regulator-ramp-delay = <200>;
+ regulator-always-on;
+ };
+
+ reg_dcdc3: dcdc3 {
+ regulator-name = "axp1530-dcdc3";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1840000>;
+ regulator-step-delay-us = <25>;
+ regulator-final-delay-us = <50>;
+ regulator-always-on;
+ };
+
+ reg_aldo1: ldo1 {
+ regulator-name = "axp1530-aldo1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-step-delay-us = <25>;
+ regulator-final-delay-us = <50>;
+ regulator-always-on;
+ };
+
+ reg_dldo1: ldo2 {
+ regulator-name = "axp1530-dldo1";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-step-delay-us = <25>;
+ regulator-final-delay-us = <50>;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_ph_pins>;
+ status = "okay";
+};
+
+&usbotg {
+ /*
+ * PHY0 pins are connected to a USB-C socket, but a role switch
+ * is not implemented: both CC pins are pulled to GND.
+ * The VBUS pins power the device, so a fixed peripheral mode
+ * is the best choice.
+ * The board can be powered via GPIOs, in this case port0 *can*
+ * act as a host (with a cable/adapter ignoring CC), as VBUS is
+ * then provided by the GPIOs. Any user of this setup would
+ * need to adjust the DT accordingly: dr_mode set to "host",
+ * enabling OHCI0 and EHCI0.
+ */
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&usbphy {
+ usb1_vbus-supply = <®_usb1_vbus>;
+ status = "okay";
+};
--
2.38.1
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-14 21:44 ` Martin Botka
0 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-14 21:44 UTC (permalink / raw)
To: martin.botka1
Cc: ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Martin Botka, Rob Herring,
Krzysztof Kozlowski, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Maxime Ripard, Andre Przywara, Conley Lee,
Andrew Lunn, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
CB1 is Compute Module style board that plugs into Rpi board style adapter or
Manta 3D printer boards (M4P/M8P).
The board has:
H616 SoC
1GB of RAM
AXP313A PMIC
And the actual boards that CB1 plugs in are just extension to it with ports and
thus are not split in DT.
Boards have:
4x (3x for Manta boards) USB and 1 USB OTG.
SDcard slot for loading images.
Ethernet port wired to the internal PHY.
2x HDMI 2.0.
Power and Status LEDs.
Currently working:
Booting
USB
UART
Signed-off-by: Martin Botka <martin.botka@somainline.org>
---
Changes in V2:
Add proper board compatible
Add regulator prefix for vcc5v
Drop okay status from PMIC
Drop standby_param
Changes in V3:
Change copyright to me
regulator_vcc5v to regulator-vcc5v
Drop ehci0 and ohci0
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
2 files changed, 179 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
new file mode 100644
index 000000000000..86b5aca9b53e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2022 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 = "BIQU CB1";
+ compatible = "biqu,cb1", "allwinner,sun50i-h616";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ function = LED_FUNCTION_POWER;
+ color = <LED_COLOR_ID_RED>;
+ gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
+ default-state = "on";
+ };
+
+ led-1 {
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_GREEN>;
+ gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
+ };
+ };
+
+ 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 = <®_vcc5v>;
+ enable-active-high;
+ gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
+ };
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&ehci2 {
+ status = "okay";
+};
+
+&ehci3 {
+ status = "okay";
+};
+
+&mmc0 {
+ vmmc-supply = <®_dldo1>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+ no-1-8-v;
+ bus-width = <4>;
+ status = "disabled";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&ohci2 {
+ status = "okay";
+};
+
+&ohci3 {
+ status = "okay";
+};
+
+&r_i2c {
+ status = "okay";
+
+ axp1530: pmic@36 {
+ compatible = "x-powers,axp1530";
+ reg = <0x36>;
+ wakeup-source;
+
+ regulators{
+ reg_dcdc1: dcdc1 {
+ regulator-name = "axp1530-dcdc1";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-step-delay-us = <25>;
+ regulator-final-delay-us = <50>;
+ regulator-always-on;
+ };
+
+ reg_dcdc2: dcdc2 {
+ regulator-name = "axp1530-dcdc2";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1540000>;
+ regulator-step-delay-us = <25>;
+ regulator-final-delay-us = <50>;
+ regulator-ramp-delay = <200>;
+ regulator-always-on;
+ };
+
+ reg_dcdc3: dcdc3 {
+ regulator-name = "axp1530-dcdc3";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1840000>;
+ regulator-step-delay-us = <25>;
+ regulator-final-delay-us = <50>;
+ regulator-always-on;
+ };
+
+ reg_aldo1: ldo1 {
+ regulator-name = "axp1530-aldo1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-step-delay-us = <25>;
+ regulator-final-delay-us = <50>;
+ regulator-always-on;
+ };
+
+ reg_dldo1: ldo2 {
+ regulator-name = "axp1530-dldo1";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-step-delay-us = <25>;
+ regulator-final-delay-us = <50>;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_ph_pins>;
+ status = "okay";
+};
+
+&usbotg {
+ /*
+ * PHY0 pins are connected to a USB-C socket, but a role switch
+ * is not implemented: both CC pins are pulled to GND.
+ * The VBUS pins power the device, so a fixed peripheral mode
+ * is the best choice.
+ * The board can be powered via GPIOs, in this case port0 *can*
+ * act as a host (with a cable/adapter ignoring CC), as VBUS is
+ * then provided by the GPIOs. Any user of this setup would
+ * need to adjust the DT accordingly: dr_mode set to "host",
+ * enabling OHCI0 and EHCI0.
+ */
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&usbphy {
+ usb1_vbus-supply = <®_usb1_vbus>;
+ status = "okay";
+};
--
2.38.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-14 21:44 ` Martin Botka
@ 2022-11-14 22:30 ` Jernej Škrabec
-1 siblings, 0 replies; 38+ messages in thread
From: Jernej Škrabec @ 2022-11-14 22:30 UTC (permalink / raw)
To: martin.botka1, Martin Botka
Cc: ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Martin Botka, Rob Herring,
Krzysztof Kozlowski, Chen-Yu Tsai, Samuel Holland, Maxime Ripard,
Andre Przywara, Conley Lee, Andrew Lunn, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel
Hi Martin,
I was just writing new e-mail as response to v2. You should wait at least a
day or two, usually more, before sending new version. Others will likely have
some more comments. And there is also no rush. Until PMIC series is merged,
this will not go anywhere. Since there is only this week until cut off date for
DT updates for kernel 6.2, it's most likely that this will land in 6.3. And
that gives as a few weeks (month) more.
See comments below.
Dne ponedeljek, 14. november 2022 ob 22:44:49 CET je Martin Botka napisal(a):
> CB1 is Compute Module style board that plugs into Rpi board style adapter or
> Manta 3D printer boards (M4P/M8P).
>
> The board has:
> H616 SoC
> 1GB of RAM
> AXP313A PMIC
>
> And the actual boards that CB1 plugs in are just extension to it with ports
> and thus are not split in DT.
>
> Boards have:
> 4x (3x for Manta boards) USB and 1 USB OTG.
> SDcard slot for loading images.
> Ethernet port wired to the internal PHY.
> 2x HDMI 2.0.
H616 has only one HDMI output. Unless there is some additional chip for some
conversion, only one HDMI port can work.
> Power and Status LEDs.
>
> Currently working:
> Booting
> USB
> UART
>
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> ---
> Changes in V2:
> Add proper board compatible
> Add regulator prefix for vcc5v
> Drop okay status from PMIC
> Drop standby_param
> Changes in V3:
> Change copyright to me
> regulator_vcc5v to regulator-vcc5v
> Drop ehci0 and ohci0
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
> 2 files changed, 179 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile index 6a96494a2e0a..223f1be73541
> 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-biqu-cb1.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-biqu-cb1.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts new file mode
> 100644
> index 000000000000..86b5aca9b53e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> @@ -0,0 +1,178 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2022 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 = "BIQU CB1";
> + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led-0 {
> + function = LED_FUNCTION_POWER;
> + color = <LED_COLOR_ID_RED>;
> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /*
PC12 */
> + default-state = "on";
> + };
> +
> + led-1 {
> + function = LED_FUNCTION_STATUS;
> + color = <LED_COLOR_ID_GREEN>;
> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /*
PC13 */
> + };
> + };
> +
> + 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 = <®_vcc5v>;
> + enable-active-high;
> + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> + };
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&ehci2 {
> + status = "okay";
> +};
> +
> +&ehci3 {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_dldo1>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + no-1-8-v;
Above property is not needed. If you don't provide vqmmc-supply with 1.8 V
regulator, it won't be used.
> + bus-width = <4>;
> + status = "disabled";
Why is set to disabled? If it's not a typo, remove whole node. It could be
added later when it works.
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> +
> +&ohci2 {
> + status = "okay";
> +};
> +
> +&ohci3 {
> + status = "okay";
> +};
> +
> +&r_i2c {
> + status = "okay";
> +
> + axp1530: pmic@36 {
> + compatible = "x-powers,axp1530";
I just checked datasheet and it really seems that it supports only I2C.
Anyway, rather than using axp1530 compatible, introduce axp313a compatible
instead.
> + reg = <0x36>;
> + wakeup-source;
> +
> + regulators{
> + reg_dcdc1: dcdc1 {
> + regulator-name = "axp1530-dcdc1";
> + regulator-min-microvolt =
<500000>;
> + regulator-max-microvolt =
<3400000>;
This one is most likely used by CPU. If so, you should set appropriate range
according to CPU needs, which are 810 - 1100 mV.
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> +
> + reg_dcdc2: dcdc2 {
> + regulator-name = "axp1530-dcdc2";
> + regulator-min-microvolt =
<500000>;
> + regulator-max-microvolt =
<1540000>;
This one is most likely used by GPU. Its range must also be adjusted to GPU
needs.
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-ramp-delay = <200>;
> + regulator-always-on;
> + };
> +
> + reg_dcdc3: dcdc3 {
> + regulator-name = "axp1530-dcdc3";
> + regulator-min-microvolt =
<500000>;
> + regulator-max-microvolt =
<1840000>;
This one looks like it supplies DRAM. You should set both min and max to
actual DRAM needs.
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> +
> + reg_aldo1: ldo1 {
ldo1 -> aldo1
> + regulator-name = "axp1530-aldo1";
> + regulator-min-microvolt =
<1800000>;
> + regulator-max-microvolt =
<1800000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> +
> + reg_dldo1: ldo2 {
ldo2 -> dldo1
Another issue I see is that you marked all regulators with regulator-always-
on; While this works, I don't think this faithfully represent HW. For example,
GPU regulator will be enabled by GPU driver when needed, so it shouldn't be
marked with always on.
There is also RTCLDO, but without schematic it's impossible to say if it is
used or not.
There are at least a few clues in AXP313A datasheet about which regulator is
used for what. See chapter 7.5 in https://github.com/bigtreetech/CB1-Kernel/
blob/kernel-5.16/docs/AXP313A%20datasheet%20V0.1%20-
%2020201105_draft%20version.pdf
Best regards,
Jernej
> + regulator-name = "axp1530-dldo1";
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> + };
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_ph_pins>;
> + status = "okay";
> +};
> +
> +&usbotg {
> + /*
> + * PHY0 pins are connected to a USB-C socket, but a role switch
> + * is not implemented: both CC pins are pulled to GND.
> + * The VBUS pins power the device, so a fixed peripheral mode
> + * is the best choice.
> + * The board can be powered via GPIOs, in this case port0 *can*
> + * act as a host (with a cable/adapter ignoring CC), as VBUS is
> + * then provided by the GPIOs. Any user of this setup would
> + * need to adjust the DT accordingly: dr_mode set to "host",
> + * enabling OHCI0 and EHCI0.
> + */
> + dr_mode = "peripheral";
> + status = "okay";
> +};
> +
> +&usbphy {
> + usb1_vbus-supply = <®_usb1_vbus>;
> + status = "okay";
> +};
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-14 22:30 ` Jernej Škrabec
0 siblings, 0 replies; 38+ messages in thread
From: Jernej Škrabec @ 2022-11-14 22:30 UTC (permalink / raw)
To: martin.botka1, Martin Botka
Cc: ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Martin Botka, Rob Herring,
Krzysztof Kozlowski, Chen-Yu Tsai, Samuel Holland, Maxime Ripard,
Andre Przywara, Conley Lee, Andrew Lunn, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel
Hi Martin,
I was just writing new e-mail as response to v2. You should wait at least a
day or two, usually more, before sending new version. Others will likely have
some more comments. And there is also no rush. Until PMIC series is merged,
this will not go anywhere. Since there is only this week until cut off date for
DT updates for kernel 6.2, it's most likely that this will land in 6.3. And
that gives as a few weeks (month) more.
See comments below.
Dne ponedeljek, 14. november 2022 ob 22:44:49 CET je Martin Botka napisal(a):
> CB1 is Compute Module style board that plugs into Rpi board style adapter or
> Manta 3D printer boards (M4P/M8P).
>
> The board has:
> H616 SoC
> 1GB of RAM
> AXP313A PMIC
>
> And the actual boards that CB1 plugs in are just extension to it with ports
> and thus are not split in DT.
>
> Boards have:
> 4x (3x for Manta boards) USB and 1 USB OTG.
> SDcard slot for loading images.
> Ethernet port wired to the internal PHY.
> 2x HDMI 2.0.
H616 has only one HDMI output. Unless there is some additional chip for some
conversion, only one HDMI port can work.
> Power and Status LEDs.
>
> Currently working:
> Booting
> USB
> UART
>
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> ---
> Changes in V2:
> Add proper board compatible
> Add regulator prefix for vcc5v
> Drop okay status from PMIC
> Drop standby_param
> Changes in V3:
> Change copyright to me
> regulator_vcc5v to regulator-vcc5v
> Drop ehci0 and ohci0
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
> 2 files changed, 179 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile index 6a96494a2e0a..223f1be73541
> 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-biqu-cb1.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-biqu-cb1.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts new file mode
> 100644
> index 000000000000..86b5aca9b53e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> @@ -0,0 +1,178 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2022 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 = "BIQU CB1";
> + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led-0 {
> + function = LED_FUNCTION_POWER;
> + color = <LED_COLOR_ID_RED>;
> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /*
PC12 */
> + default-state = "on";
> + };
> +
> + led-1 {
> + function = LED_FUNCTION_STATUS;
> + color = <LED_COLOR_ID_GREEN>;
> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /*
PC13 */
> + };
> + };
> +
> + 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 = <®_vcc5v>;
> + enable-active-high;
> + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> + };
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&ehci2 {
> + status = "okay";
> +};
> +
> +&ehci3 {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_dldo1>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + no-1-8-v;
Above property is not needed. If you don't provide vqmmc-supply with 1.8 V
regulator, it won't be used.
> + bus-width = <4>;
> + status = "disabled";
Why is set to disabled? If it's not a typo, remove whole node. It could be
added later when it works.
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> +
> +&ohci2 {
> + status = "okay";
> +};
> +
> +&ohci3 {
> + status = "okay";
> +};
> +
> +&r_i2c {
> + status = "okay";
> +
> + axp1530: pmic@36 {
> + compatible = "x-powers,axp1530";
I just checked datasheet and it really seems that it supports only I2C.
Anyway, rather than using axp1530 compatible, introduce axp313a compatible
instead.
> + reg = <0x36>;
> + wakeup-source;
> +
> + regulators{
> + reg_dcdc1: dcdc1 {
> + regulator-name = "axp1530-dcdc1";
> + regulator-min-microvolt =
<500000>;
> + regulator-max-microvolt =
<3400000>;
This one is most likely used by CPU. If so, you should set appropriate range
according to CPU needs, which are 810 - 1100 mV.
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> +
> + reg_dcdc2: dcdc2 {
> + regulator-name = "axp1530-dcdc2";
> + regulator-min-microvolt =
<500000>;
> + regulator-max-microvolt =
<1540000>;
This one is most likely used by GPU. Its range must also be adjusted to GPU
needs.
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-ramp-delay = <200>;
> + regulator-always-on;
> + };
> +
> + reg_dcdc3: dcdc3 {
> + regulator-name = "axp1530-dcdc3";
> + regulator-min-microvolt =
<500000>;
> + regulator-max-microvolt =
<1840000>;
This one looks like it supplies DRAM. You should set both min and max to
actual DRAM needs.
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> +
> + reg_aldo1: ldo1 {
ldo1 -> aldo1
> + regulator-name = "axp1530-aldo1";
> + regulator-min-microvolt =
<1800000>;
> + regulator-max-microvolt =
<1800000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> +
> + reg_dldo1: ldo2 {
ldo2 -> dldo1
Another issue I see is that you marked all regulators with regulator-always-
on; While this works, I don't think this faithfully represent HW. For example,
GPU regulator will be enabled by GPU driver when needed, so it shouldn't be
marked with always on.
There is also RTCLDO, but without schematic it's impossible to say if it is
used or not.
There are at least a few clues in AXP313A datasheet about which regulator is
used for what. See chapter 7.5 in https://github.com/bigtreetech/CB1-Kernel/
blob/kernel-5.16/docs/AXP313A%20datasheet%20V0.1%20-
%2020201105_draft%20version.pdf
Best regards,
Jernej
> + regulator-name = "axp1530-dldo1";
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> + };
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_ph_pins>;
> + status = "okay";
> +};
> +
> +&usbotg {
> + /*
> + * PHY0 pins are connected to a USB-C socket, but a role switch
> + * is not implemented: both CC pins are pulled to GND.
> + * The VBUS pins power the device, so a fixed peripheral mode
> + * is the best choice.
> + * The board can be powered via GPIOs, in this case port0 *can*
> + * act as a host (with a cable/adapter ignoring CC), as VBUS is
> + * then provided by the GPIOs. Any user of this setup would
> + * need to adjust the DT accordingly: dr_mode set to "host",
> + * enabling OHCI0 and EHCI0.
> + */
> + dr_mode = "peripheral";
> + status = "okay";
> +};
> +
> +&usbphy {
> + usb1_vbus-supply = <®_usb1_vbus>;
> + status = "okay";
> +};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-14 22:30 ` Jernej Škrabec
@ 2022-11-14 22:54 ` Martin Botka
-1 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-14 22:54 UTC (permalink / raw)
To: Jernej Škrabec
Cc: martin.botka1, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Samuel Holland, Maxime Ripard, Andre Przywara,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
On Mon, Nov 14 2022 at 11:30:17 PM +01:00:00, Jernej Škrabec
<jernej.skrabec@gmail.com> wrote:
> Hi Martin,
>
> I was just writing new e-mail as response to v2. You should wait at
> least a
> day or two, usually more, before sending new version. Others will
> likely have
> some more comments. And there is also no rush. Until PMIC series is
> merged,
> this will not go anywhere. Since there is only this week until cut
> off date for
> DT updates for kernel 6.2, it's most likely that this will land in
> 6.3. And
> that gives as a few weeks (month) more.
Yep. Was hoping for 5.2 thus the frequent updates. Will take it slow
then since 5.3 :)
>
> See comments below.
>
> Dne ponedeljek, 14. november 2022 ob 22:44:49 CET je Martin Botka
> napisal(a):
>> CB1 is Compute Module style board that plugs into Rpi board style
>> adapter or
>> Manta 3D printer boards (M4P/M8P).
>>
>> The board has:
>> H616 SoC
>> 1GB of RAM
>> AXP313A PMIC
>>
>> And the actual boards that CB1 plugs in are just extension to it
>> with ports
>> and thus are not split in DT.
>>
>> Boards have:
>> 4x (3x for Manta boards) USB and 1 USB OTG.
>> SDcard slot for loading images.
>> Ethernet port wired to the internal PHY.
>> 2x HDMI 2.0.
>
> H616 has only one HDMI output. Unless there is some additional chip
> for some
> conversion, only one HDMI port can work.
Yes correct. But the Rpi adapter and Manta boards also support
Rpi Compute Module 4 which has 2 HDMI outputs.
The chip itself ofc doesnt support this on CB1. Same goes for DSI/CSI
ports
on the boards and the 4x USB on Rpi adapter.
It is indeed a bit of a mess.
>
>> Power and Status LEDs.
>>
>> Currently working:
>> Booting
>> USB
>> UART
>>
>> Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> ---
>> Changes in V2:
>> Add proper board compatible
>> Add regulator prefix for vcc5v
>> Drop okay status from PMIC
>> Drop standby_param
>> Changes in V3:
>> Change copyright to me
>> regulator_vcc5v to regulator-vcc5v
>> Drop ehci0 and ohci0
>> arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
>> ++++++++++++++++++
>> 2 files changed, 179 insertions(+)
>> create mode 100644
>> arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> b/arch/arm64/boot/dts/allwinner/Makefile index
>> 6a96494a2e0a..223f1be73541
>> 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-biqu-cb1.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-biqu-cb1.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts new file
>> mode
>> 100644
>> index 000000000000..86b5aca9b53e
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> @@ -0,0 +1,178 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> +/*
>> + * Copyright (C) 2022 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 = "BIQU CB1";
>> + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> +
>> + led-0 {
>> + function = LED_FUNCTION_POWER;
>> + color = <LED_COLOR_ID_RED>;
>> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /*
> PC12 */
>> + default-state = "on";
>> + };
>> +
>> + led-1 {
>> + function = LED_FUNCTION_STATUS;
>> + color = <LED_COLOR_ID_GREEN>;
>> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /*
> PC13 */
>> + };
>> + };
>> +
>> + 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 = <®_vcc5v>;
>> + enable-active-high;
>> + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>> + };
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&ehci2 {
>> + status = "okay";
>> +};
>> +
>> +&ehci3 {
>> + status = "okay";
>> +};
>> +
>> +&mmc0 {
>> + vmmc-supply = <®_dldo1>;
>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> + no-1-8-v;
>
> Above property is not needed. If you don't provide vqmmc-supply with
> 1.8 V
> regulator, it won't be used.
>
>> + bus-width = <4>;
>> + status = "disabled";
>
> Why is set to disabled? If it's not a typo, remove whole node. It
> could be
> added later when it works.
Would not removing it also make PMIC node useless as the regulators
wont be used and thus
should be technically removed ?
>
>> +};
>> +
>> +&ohci1 {
>> + status = "okay";
>> +};
>> +
>> +&ohci2 {
>> + status = "okay";
>> +};
>> +
>> +&ohci3 {
>> + status = "okay";
>> +};
>> +
>> +&r_i2c {
>> + status = "okay";
>> +
>> + axp1530: pmic@36 {
>> + compatible = "x-powers,axp1530";
>
> I just checked datasheet and it really seems that it supports only
> I2C.
> Anyway, rather than using axp1530 compatible, introduce axp313a
> compatible
> instead.
Will do in V2 for drivers later.
>
>> + reg = <0x36>;
>> + wakeup-source;
>> +
>> + regulators{
>> + reg_dcdc1: dcdc1 {
>> + regulator-name = "axp1530-dcdc1";
>> + regulator-min-microvolt =
> <500000>;
>> + regulator-max-microvolt =
> <3400000>;
>
> This one is most likely used by CPU. If so, you should set
> appropriate range
> according to CPU needs, which are 810 - 1100 mV.
>
>> + regulator-step-delay-us = <25>;
>> + regulator-final-delay-us = <50>;
>> + regulator-always-on;
>> + };
>> +
>> + reg_dcdc2: dcdc2 {
>> + regulator-name = "axp1530-dcdc2";
>> + regulator-min-microvolt =
> <500000>;
>> + regulator-max-microvolt =
> <1540000>;
>
> This one is most likely used by GPU. Its range must also be adjusted
> to GPU
> needs.
>
>> + regulator-step-delay-us = <25>;
>> + regulator-final-delay-us = <50>;
>> + regulator-ramp-delay = <200>;
>> + regulator-always-on;
>> + };
>> +
>> + reg_dcdc3: dcdc3 {
>> + regulator-name = "axp1530-dcdc3";
>> + regulator-min-microvolt =
> <500000>;
>> + regulator-max-microvolt =
> <1840000>;
>
> This one looks like it supplies DRAM. You should set both min and max
> to
> actual DRAM needs.
>
>> + regulator-step-delay-us = <25>;
>> + regulator-final-delay-us = <50>;
>> + regulator-always-on;
>> + };
>> +
>> + reg_aldo1: ldo1 {
>
> ldo1 -> aldo1
>
>> + regulator-name = "axp1530-aldo1";
>> + regulator-min-microvolt =
> <1800000>;
>> + regulator-max-microvolt =
> <1800000>;
>> + regulator-step-delay-us = <25>;
>> + regulator-final-delay-us = <50>;
>> + regulator-always-on;
>> + };
>> +
>> + reg_dldo1: ldo2 {
>
> ldo2 -> dldo1
>
> Another issue I see is that you marked all regulators with
> regulator-always-
> on; While this works, I don't think this faithfully represent HW. For
> example,
> GPU regulator will be enabled by GPU driver when needed, so it
> shouldn't be
> marked with always on.
>
> There is also RTCLDO, but without schematic it's impossible to say if
> it is
> used or not.
>
> There are at least a few clues in AXP313A datasheet about which
> regulator is
> used for what. See chapter 7.5 in
> https://github.com/bigtreetech/CB1-Kernel/
> blob/kernel-5.16/docs/AXP313A%20datasheet%20V0.1%20-
> %2020201105_draft%20version.pdf
As for regulators themselves. I have kept them as what downstream
kernel specifies.
But until I have schematic in hand and can confirm that they actually
used the correct regulators in
the correct place i will stick to stock values. If they in the end
decide to not supply schematic or etc
to the public i can test with adjusted values.
>
> Best regards,
> Jernej
>
>> + regulator-name = "axp1530-dldo1";
>> + regulator-min-microvolt =
> <3300000>;
>> + regulator-max-microvolt =
> <3300000>;
>> + regulator-step-delay-us = <25>;
>> + regulator-final-delay-us = <50>;
>> + regulator-always-on;
>> + };
>> + };
>> + };
>> +};
>> +
>> +&uart0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart0_ph_pins>;
>> + status = "okay";
>> +};
>> +
>> +&usbotg {
>> + /*
>> + * PHY0 pins are connected to a USB-C socket, but a role switch
>> + * is not implemented: both CC pins are pulled to GND.
>> + * The VBUS pins power the device, so a fixed peripheral mode
>> + * is the best choice.
>> + * The board can be powered via GPIOs, in this case port0 *can*
>> + * act as a host (with a cable/adapter ignoring CC), as VBUS is
>> + * then provided by the GPIOs. Any user of this setup would
>> + * need to adjust the DT accordingly: dr_mode set to "host",
>> + * enabling OHCI0 and EHCI0.
>> + */
>> + dr_mode = "peripheral";
>> + status = "okay";
>> +};
>> +
>> +&usbphy {
>> + usb1_vbus-supply = <®_usb1_vbus>;
>> + status = "okay";
>> +};
>
>
>
>
Best Regards,
Martin
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-14 22:54 ` Martin Botka
0 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-14 22:54 UTC (permalink / raw)
To: Jernej Škrabec
Cc: martin.botka1, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Samuel Holland, Maxime Ripard, Andre Przywara,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
On Mon, Nov 14 2022 at 11:30:17 PM +01:00:00, Jernej Škrabec
<jernej.skrabec@gmail.com> wrote:
> Hi Martin,
>
> I was just writing new e-mail as response to v2. You should wait at
> least a
> day or two, usually more, before sending new version. Others will
> likely have
> some more comments. And there is also no rush. Until PMIC series is
> merged,
> this will not go anywhere. Since there is only this week until cut
> off date for
> DT updates for kernel 6.2, it's most likely that this will land in
> 6.3. And
> that gives as a few weeks (month) more.
Yep. Was hoping for 5.2 thus the frequent updates. Will take it slow
then since 5.3 :)
>
> See comments below.
>
> Dne ponedeljek, 14. november 2022 ob 22:44:49 CET je Martin Botka
> napisal(a):
>> CB1 is Compute Module style board that plugs into Rpi board style
>> adapter or
>> Manta 3D printer boards (M4P/M8P).
>>
>> The board has:
>> H616 SoC
>> 1GB of RAM
>> AXP313A PMIC
>>
>> And the actual boards that CB1 plugs in are just extension to it
>> with ports
>> and thus are not split in DT.
>>
>> Boards have:
>> 4x (3x for Manta boards) USB and 1 USB OTG.
>> SDcard slot for loading images.
>> Ethernet port wired to the internal PHY.
>> 2x HDMI 2.0.
>
> H616 has only one HDMI output. Unless there is some additional chip
> for some
> conversion, only one HDMI port can work.
Yes correct. But the Rpi adapter and Manta boards also support
Rpi Compute Module 4 which has 2 HDMI outputs.
The chip itself ofc doesnt support this on CB1. Same goes for DSI/CSI
ports
on the boards and the 4x USB on Rpi adapter.
It is indeed a bit of a mess.
>
>> Power and Status LEDs.
>>
>> Currently working:
>> Booting
>> USB
>> UART
>>
>> Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> ---
>> Changes in V2:
>> Add proper board compatible
>> Add regulator prefix for vcc5v
>> Drop okay status from PMIC
>> Drop standby_param
>> Changes in V3:
>> Change copyright to me
>> regulator_vcc5v to regulator-vcc5v
>> Drop ehci0 and ohci0
>> arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
>> ++++++++++++++++++
>> 2 files changed, 179 insertions(+)
>> create mode 100644
>> arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> b/arch/arm64/boot/dts/allwinner/Makefile index
>> 6a96494a2e0a..223f1be73541
>> 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-biqu-cb1.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-biqu-cb1.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts new file
>> mode
>> 100644
>> index 000000000000..86b5aca9b53e
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> @@ -0,0 +1,178 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> +/*
>> + * Copyright (C) 2022 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 = "BIQU CB1";
>> + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> +
>> + led-0 {
>> + function = LED_FUNCTION_POWER;
>> + color = <LED_COLOR_ID_RED>;
>> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /*
> PC12 */
>> + default-state = "on";
>> + };
>> +
>> + led-1 {
>> + function = LED_FUNCTION_STATUS;
>> + color = <LED_COLOR_ID_GREEN>;
>> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /*
> PC13 */
>> + };
>> + };
>> +
>> + 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 = <®_vcc5v>;
>> + enable-active-high;
>> + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>> + };
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&ehci2 {
>> + status = "okay";
>> +};
>> +
>> +&ehci3 {
>> + status = "okay";
>> +};
>> +
>> +&mmc0 {
>> + vmmc-supply = <®_dldo1>;
>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> + no-1-8-v;
>
> Above property is not needed. If you don't provide vqmmc-supply with
> 1.8 V
> regulator, it won't be used.
>
>> + bus-width = <4>;
>> + status = "disabled";
>
> Why is set to disabled? If it's not a typo, remove whole node. It
> could be
> added later when it works.
Would not removing it also make PMIC node useless as the regulators
wont be used and thus
should be technically removed ?
>
>> +};
>> +
>> +&ohci1 {
>> + status = "okay";
>> +};
>> +
>> +&ohci2 {
>> + status = "okay";
>> +};
>> +
>> +&ohci3 {
>> + status = "okay";
>> +};
>> +
>> +&r_i2c {
>> + status = "okay";
>> +
>> + axp1530: pmic@36 {
>> + compatible = "x-powers,axp1530";
>
> I just checked datasheet and it really seems that it supports only
> I2C.
> Anyway, rather than using axp1530 compatible, introduce axp313a
> compatible
> instead.
Will do in V2 for drivers later.
>
>> + reg = <0x36>;
>> + wakeup-source;
>> +
>> + regulators{
>> + reg_dcdc1: dcdc1 {
>> + regulator-name = "axp1530-dcdc1";
>> + regulator-min-microvolt =
> <500000>;
>> + regulator-max-microvolt =
> <3400000>;
>
> This one is most likely used by CPU. If so, you should set
> appropriate range
> according to CPU needs, which are 810 - 1100 mV.
>
>> + regulator-step-delay-us = <25>;
>> + regulator-final-delay-us = <50>;
>> + regulator-always-on;
>> + };
>> +
>> + reg_dcdc2: dcdc2 {
>> + regulator-name = "axp1530-dcdc2";
>> + regulator-min-microvolt =
> <500000>;
>> + regulator-max-microvolt =
> <1540000>;
>
> This one is most likely used by GPU. Its range must also be adjusted
> to GPU
> needs.
>
>> + regulator-step-delay-us = <25>;
>> + regulator-final-delay-us = <50>;
>> + regulator-ramp-delay = <200>;
>> + regulator-always-on;
>> + };
>> +
>> + reg_dcdc3: dcdc3 {
>> + regulator-name = "axp1530-dcdc3";
>> + regulator-min-microvolt =
> <500000>;
>> + regulator-max-microvolt =
> <1840000>;
>
> This one looks like it supplies DRAM. You should set both min and max
> to
> actual DRAM needs.
>
>> + regulator-step-delay-us = <25>;
>> + regulator-final-delay-us = <50>;
>> + regulator-always-on;
>> + };
>> +
>> + reg_aldo1: ldo1 {
>
> ldo1 -> aldo1
>
>> + regulator-name = "axp1530-aldo1";
>> + regulator-min-microvolt =
> <1800000>;
>> + regulator-max-microvolt =
> <1800000>;
>> + regulator-step-delay-us = <25>;
>> + regulator-final-delay-us = <50>;
>> + regulator-always-on;
>> + };
>> +
>> + reg_dldo1: ldo2 {
>
> ldo2 -> dldo1
>
> Another issue I see is that you marked all regulators with
> regulator-always-
> on; While this works, I don't think this faithfully represent HW. For
> example,
> GPU regulator will be enabled by GPU driver when needed, so it
> shouldn't be
> marked with always on.
>
> There is also RTCLDO, but without schematic it's impossible to say if
> it is
> used or not.
>
> There are at least a few clues in AXP313A datasheet about which
> regulator is
> used for what. See chapter 7.5 in
> https://github.com/bigtreetech/CB1-Kernel/
> blob/kernel-5.16/docs/AXP313A%20datasheet%20V0.1%20-
> %2020201105_draft%20version.pdf
As for regulators themselves. I have kept them as what downstream
kernel specifies.
But until I have schematic in hand and can confirm that they actually
used the correct regulators in
the correct place i will stick to stock values. If they in the end
decide to not supply schematic or etc
to the public i can test with adjusted values.
>
> Best regards,
> Jernej
>
>> + regulator-name = "axp1530-dldo1";
>> + regulator-min-microvolt =
> <3300000>;
>> + regulator-max-microvolt =
> <3300000>;
>> + regulator-step-delay-us = <25>;
>> + regulator-final-delay-us = <50>;
>> + regulator-always-on;
>> + };
>> + };
>> + };
>> +};
>> +
>> +&uart0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart0_ph_pins>;
>> + status = "okay";
>> +};
>> +
>> +&usbotg {
>> + /*
>> + * PHY0 pins are connected to a USB-C socket, but a role switch
>> + * is not implemented: both CC pins are pulled to GND.
>> + * The VBUS pins power the device, so a fixed peripheral mode
>> + * is the best choice.
>> + * The board can be powered via GPIOs, in this case port0 *can*
>> + * act as a host (with a cable/adapter ignoring CC), as VBUS is
>> + * then provided by the GPIOs. Any user of this setup would
>> + * need to adjust the DT accordingly: dr_mode set to "host",
>> + * enabling OHCI0 and EHCI0.
>> + */
>> + dr_mode = "peripheral";
>> + status = "okay";
>> +};
>> +
>> +&usbphy {
>> + usb1_vbus-supply = <®_usb1_vbus>;
>> + status = "okay";
>> +};
>
>
>
>
Best Regards,
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-14 21:44 ` Martin Botka
@ 2022-11-14 23:31 ` Andre Przywara
-1 siblings, 0 replies; 38+ messages in thread
From: Andre Przywara @ 2022-11-14 23:31 UTC (permalink / raw)
To: Martin Botka
Cc: martin.botka1, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
On Mon, 14 Nov 2022 22:44:49 +0100
Martin Botka <martin.botka@somainline.org> wrote:
> CB1 is Compute Module style board that plugs into Rpi board style adapter or
> Manta 3D printer boards (M4P/M8P).
>
> The board has:
> H616 SoC
> 1GB of RAM
> AXP313A PMIC
>
> And the actual boards that CB1 plugs in are just extension to it with ports and
> thus are not split in DT.
I don't really understand that sentence. There is some precedent for a
SoM/board split, look at the sun50i-a64-sopine or
sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
there are *two* boards available for the same CB1 SoM, the PI4B and the
Manta board? Which would a strong case for a SoM .dtsi, plus the one
or two board .dts files.
I am just not sure whether that relation to the Pi4-CM is helpful or
just complicates things...
Cheers,
Andre
>
> Boards have:
> 4x (3x for Manta boards) USB and 1 USB OTG.
> SDcard slot for loading images.
> Ethernet port wired to the internal PHY.
> 2x HDMI 2.0.
> Power and Status LEDs.
>
> Currently working:
> Booting
> USB
> UART
>
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> ---
> Changes in V2:
> Add proper board compatible
> Add regulator prefix for vcc5v
> Drop okay status from PMIC
> Drop standby_param
> Changes in V3:
> Change copyright to me
> regulator_vcc5v to regulator-vcc5v
> Drop ehci0 and ohci0
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
> 2 files changed, 179 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> new file mode 100644
> index 000000000000..86b5aca9b53e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> @@ -0,0 +1,178 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2022 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 = "BIQU CB1";
> + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led-0 {
> + function = LED_FUNCTION_POWER;
> + color = <LED_COLOR_ID_RED>;
> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
> + default-state = "on";
> + };
> +
> + led-1 {
> + function = LED_FUNCTION_STATUS;
> + color = <LED_COLOR_ID_GREEN>;
> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
> + };
> + };
> +
> + 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 = <®_vcc5v>;
> + enable-active-high;
> + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> + };
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&ehci2 {
> + status = "okay";
> +};
> +
> +&ehci3 {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_dldo1>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + no-1-8-v;
> + bus-width = <4>;
> + status = "disabled";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> +
> +&ohci2 {
> + status = "okay";
> +};
> +
> +&ohci3 {
> + status = "okay";
> +};
> +
> +&r_i2c {
> + status = "okay";
> +
> + axp1530: pmic@36 {
> + compatible = "x-powers,axp1530";
> + reg = <0x36>;
> + wakeup-source;
> +
> + regulators{
> + reg_dcdc1: dcdc1 {
> + regulator-name = "axp1530-dcdc1";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <3400000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> +
> + reg_dcdc2: dcdc2 {
> + regulator-name = "axp1530-dcdc2";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1540000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-ramp-delay = <200>;
> + regulator-always-on;
> + };
> +
> + reg_dcdc3: dcdc3 {
> + regulator-name = "axp1530-dcdc3";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1840000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> +
> + reg_aldo1: ldo1 {
> + regulator-name = "axp1530-aldo1";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> +
> + reg_dldo1: ldo2 {
> + regulator-name = "axp1530-dldo1";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> + };
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_ph_pins>;
> + status = "okay";
> +};
> +
> +&usbotg {
> + /*
> + * PHY0 pins are connected to a USB-C socket, but a role switch
> + * is not implemented: both CC pins are pulled to GND.
> + * The VBUS pins power the device, so a fixed peripheral mode
> + * is the best choice.
> + * The board can be powered via GPIOs, in this case port0 *can*
> + * act as a host (with a cable/adapter ignoring CC), as VBUS is
> + * then provided by the GPIOs. Any user of this setup would
> + * need to adjust the DT accordingly: dr_mode set to "host",
> + * enabling OHCI0 and EHCI0.
> + */
> + dr_mode = "peripheral";
> + status = "okay";
> +};
> +
> +&usbphy {
> + usb1_vbus-supply = <®_usb1_vbus>;
> + status = "okay";
> +};
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-14 23:31 ` Andre Przywara
0 siblings, 0 replies; 38+ messages in thread
From: Andre Przywara @ 2022-11-14 23:31 UTC (permalink / raw)
To: Martin Botka
Cc: martin.botka1, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
On Mon, 14 Nov 2022 22:44:49 +0100
Martin Botka <martin.botka@somainline.org> wrote:
> CB1 is Compute Module style board that plugs into Rpi board style adapter or
> Manta 3D printer boards (M4P/M8P).
>
> The board has:
> H616 SoC
> 1GB of RAM
> AXP313A PMIC
>
> And the actual boards that CB1 plugs in are just extension to it with ports and
> thus are not split in DT.
I don't really understand that sentence. There is some precedent for a
SoM/board split, look at the sun50i-a64-sopine or
sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
there are *two* boards available for the same CB1 SoM, the PI4B and the
Manta board? Which would a strong case for a SoM .dtsi, plus the one
or two board .dts files.
I am just not sure whether that relation to the Pi4-CM is helpful or
just complicates things...
Cheers,
Andre
>
> Boards have:
> 4x (3x for Manta boards) USB and 1 USB OTG.
> SDcard slot for loading images.
> Ethernet port wired to the internal PHY.
> 2x HDMI 2.0.
> Power and Status LEDs.
>
> Currently working:
> Booting
> USB
> UART
>
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> ---
> Changes in V2:
> Add proper board compatible
> Add regulator prefix for vcc5v
> Drop okay status from PMIC
> Drop standby_param
> Changes in V3:
> Change copyright to me
> regulator_vcc5v to regulator-vcc5v
> Drop ehci0 and ohci0
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
> 2 files changed, 179 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> new file mode 100644
> index 000000000000..86b5aca9b53e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> @@ -0,0 +1,178 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2022 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 = "BIQU CB1";
> + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led-0 {
> + function = LED_FUNCTION_POWER;
> + color = <LED_COLOR_ID_RED>;
> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
> + default-state = "on";
> + };
> +
> + led-1 {
> + function = LED_FUNCTION_STATUS;
> + color = <LED_COLOR_ID_GREEN>;
> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
> + };
> + };
> +
> + 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 = <®_vcc5v>;
> + enable-active-high;
> + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> + };
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&ehci2 {
> + status = "okay";
> +};
> +
> +&ehci3 {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_dldo1>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + no-1-8-v;
> + bus-width = <4>;
> + status = "disabled";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> +
> +&ohci2 {
> + status = "okay";
> +};
> +
> +&ohci3 {
> + status = "okay";
> +};
> +
> +&r_i2c {
> + status = "okay";
> +
> + axp1530: pmic@36 {
> + compatible = "x-powers,axp1530";
> + reg = <0x36>;
> + wakeup-source;
> +
> + regulators{
> + reg_dcdc1: dcdc1 {
> + regulator-name = "axp1530-dcdc1";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <3400000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> +
> + reg_dcdc2: dcdc2 {
> + regulator-name = "axp1530-dcdc2";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1540000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-ramp-delay = <200>;
> + regulator-always-on;
> + };
> +
> + reg_dcdc3: dcdc3 {
> + regulator-name = "axp1530-dcdc3";
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1840000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> +
> + reg_aldo1: ldo1 {
> + regulator-name = "axp1530-aldo1";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> +
> + reg_dldo1: ldo2 {
> + regulator-name = "axp1530-dldo1";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-step-delay-us = <25>;
> + regulator-final-delay-us = <50>;
> + regulator-always-on;
> + };
> + };
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_ph_pins>;
> + status = "okay";
> +};
> +
> +&usbotg {
> + /*
> + * PHY0 pins are connected to a USB-C socket, but a role switch
> + * is not implemented: both CC pins are pulled to GND.
> + * The VBUS pins power the device, so a fixed peripheral mode
> + * is the best choice.
> + * The board can be powered via GPIOs, in this case port0 *can*
> + * act as a host (with a cable/adapter ignoring CC), as VBUS is
> + * then provided by the GPIOs. Any user of this setup would
> + * need to adjust the DT accordingly: dr_mode set to "host",
> + * enabling OHCI0 and EHCI0.
> + */
> + dr_mode = "peripheral";
> + status = "okay";
> +};
> +
> +&usbphy {
> + usb1_vbus-supply = <®_usb1_vbus>;
> + status = "okay";
> +};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
[not found] ` <CADQ2G_HXx59YYjNvhcNRonahgT3AcE_2BiU43vDJ3CRUGKwAKA@mail.gmail.com>
@ 2022-11-15 0:54 ` Andre Przywara
0 siblings, 0 replies; 38+ messages in thread
From: Andre Przywara @ 2022-11-15 0:54 UTC (permalink / raw)
To: Martin Botka
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On Tue, 15 Nov 2022 00:44:46 +0100
Martin Botka <martin.botka1@gmail.com> wrote:
Hi Martin,
> I can totally understand how this can get confusing.
>
> Basically because of the Rpi shortage biqu decided to make an Rpi
> alternative.
>
> So they made CB1 which is compute module style board.
>
> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
> boards are:
>
> Rpi adapter which takes the Compute module style boards and turns them into
> SBC style with basically identical size and etc to Rpi 4.
>
> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
> they were made for Klipper use case which requires a computer or SBC
> (Usually Rpi4). They combined it into 1 board.
> Where you get the MCU and you can plug in CM4 or CB1
Thanks for the explanations! I was guessing along those shortage lines,
since the H616 is quite a step down from the RPi4CM, though probably
still enough for driving a 3D printer.
> All these boards are basically taking the pins and routing them to ports.
Yes, this is what those SoM carrier boards do ;-)
> There is nearly 0 chips for conversion or processing of the pins from CB1
> or CM4 thus i do not see a reason for having parent dtsi and dts for the
> adapter and Manta boards.
And the DT does not need to describe "chips" only, a lot of DT nodes
are about connectors, and which ports and which exact pins (out of the
possible pinmuxes) are actually used. The SoM itself mostly exposes
just pins, and the board DT describes how these pins are used (GPIO or
special function, for instance).
So did you try to split this up? How would that look?
Cheers,
Andre
> The only exception to conversion are the LEDs on the boards but since both
> adapter and manta boards have them this yet again eliminates need for
> parent style DT.
>
> Best regards,
> Martin
>
> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
> wrote:
>
> > On Mon, 14 Nov 2022 22:44:49 +0100
> > Martin Botka <martin.botka@somainline.org> wrote:
> >
> > > CB1 is Compute Module style board that plugs into Rpi board style
> > adapter or
> > > Manta 3D printer boards (M4P/M8P).
> > >
> > > The board has:
> > > H616 SoC
> > > 1GB of RAM
> > > AXP313A PMIC
> > >
> > > And the actual boards that CB1 plugs in are just extension to it with
> > ports and
> > > thus are not split in DT.
> >
> > I don't really understand that sentence. There is some precedent for a
> > SoM/board split, look at the sun50i-a64-sopine or
> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
> > there are *two* boards available for the same CB1 SoM, the PI4B and the
> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
> > or two board .dts files.
> > I am just not sure whether that relation to the Pi4-CM is helpful or
> > just complicates things...
> >
> > Cheers,
> > Andre
> >
> > >
> > > Boards have:
> > > 4x (3x for Manta boards) USB and 1 USB OTG.
> > > SDcard slot for loading images.
> > > Ethernet port wired to the internal PHY.
> > > 2x HDMI 2.0.
> > > Power and Status LEDs.
> > >
> > > Currently working:
> > > Booting
> > > USB
> > > UART
> > >
> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
> > > ---
> > > Changes in V2:
> > > Add proper board compatible
> > > Add regulator prefix for vcc5v
> > > Drop okay status from PMIC
> > > Drop standby_param
> > > Changes in V3:
> > > Change copyright to me
> > > regulator_vcc5v to regulator-vcc5v
> > > Drop ehci0 and ohci0
> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
> > > 2 files changed, 179 insertions(+)
> > > create mode 100644
> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> > b/arch/arm64/boot/dts/allwinner/Makefile
> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> > > new file mode 100644
> > > index 000000000000..86b5aca9b53e
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> > > @@ -0,0 +1,178 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > > +/*
> > > + * Copyright (C) 2022 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 = "BIQU CB1";
> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> > > +
> > > + aliases {
> > > + serial0 = &uart0;
> > > + };
> > > +
> > > + chosen {
> > > + stdout-path = "serial0:115200n8";
> > > + };
> > > +
> > > + leds {
> > > + compatible = "gpio-leds";
> > > +
> > > + led-0 {
> > > + function = LED_FUNCTION_POWER;
> > > + color = <LED_COLOR_ID_RED>;
> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
> > > + default-state = "on";
> > > + };
> > > +
> > > + led-1 {
> > > + function = LED_FUNCTION_STATUS;
> > > + color = <LED_COLOR_ID_GREEN>;
> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
> > > + };
> > > + };
> > > +
> > > + 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 = <®_vcc5v>;
> > > + enable-active-high;
> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> > > + };
> > > +};
> > > +
> > > +&ehci1 {
> > > + status = "okay";
> > > +};
> > > +
> > > +&ehci2 {
> > > + status = "okay";
> > > +};
> > > +
> > > +&ehci3 {
> > > + status = "okay";
> > > +};
> > > +
> > > +&mmc0 {
> > > + vmmc-supply = <®_dldo1>;
> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > > + no-1-8-v;
> > > + bus-width = <4>;
> > > + status = "disabled";
> > > +};
> > > +
> > > +&ohci1 {
> > > + status = "okay";
> > > +};
> > > +
> > > +&ohci2 {
> > > + status = "okay";
> > > +};
> > > +
> > > +&ohci3 {
> > > + status = "okay";
> > > +};
> > > +
> > > +&r_i2c {
> > > + status = "okay";
> > > +
> > > + axp1530: pmic@36 {
> > > + compatible = "x-powers,axp1530";
> > > + reg = <0x36>;
> > > + wakeup-source;
> > > +
> > > + regulators{
> > > + reg_dcdc1: dcdc1 {
> > > + regulator-name = "axp1530-dcdc1";
> > > + regulator-min-microvolt = <500000>;
> > > + regulator-max-microvolt = <3400000>;
> > > + regulator-step-delay-us = <25>;
> > > + regulator-final-delay-us = <50>;
> > > + regulator-always-on;
> > > + };
> > > +
> > > + reg_dcdc2: dcdc2 {
> > > + regulator-name = "axp1530-dcdc2";
> > > + regulator-min-microvolt = <500000>;
> > > + regulator-max-microvolt = <1540000>;
> > > + regulator-step-delay-us = <25>;
> > > + regulator-final-delay-us = <50>;
> > > + regulator-ramp-delay = <200>;
> > > + regulator-always-on;
> > > + };
> > > +
> > > + reg_dcdc3: dcdc3 {
> > > + regulator-name = "axp1530-dcdc3";
> > > + regulator-min-microvolt = <500000>;
> > > + regulator-max-microvolt = <1840000>;
> > > + regulator-step-delay-us = <25>;
> > > + regulator-final-delay-us = <50>;
> > > + regulator-always-on;
> > > + };
> > > +
> > > + reg_aldo1: ldo1 {
> > > + regulator-name = "axp1530-aldo1";
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <1800000>;
> > > + regulator-step-delay-us = <25>;
> > > + regulator-final-delay-us = <50>;
> > > + regulator-always-on;
> > > + };
> > > +
> > > + reg_dldo1: ldo2 {
> > > + regulator-name = "axp1530-dldo1";
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-step-delay-us = <25>;
> > > + regulator-final-delay-us = <50>;
> > > + regulator-always-on;
> > > + };
> > > + };
> > > + };
> > > +};
> > > +
> > > +&uart0 {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&uart0_ph_pins>;
> > > + status = "okay";
> > > +};
> > > +
> > > +&usbotg {
> > > + /*
> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
> > > + * is not implemented: both CC pins are pulled to GND.
> > > + * The VBUS pins power the device, so a fixed peripheral mode
> > > + * is the best choice.
> > > + * The board can be powered via GPIOs, in this case port0 *can*
> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
> > > + * then provided by the GPIOs. Any user of this setup would
> > > + * need to adjust the DT accordingly: dr_mode set to "host",
> > > + * enabling OHCI0 and EHCI0.
> > > + */
> > > + dr_mode = "peripheral";
> > > + status = "okay";
> > > +};
> > > +
> > > +&usbphy {
> > > + usb1_vbus-supply = <®_usb1_vbus>;
> > > + status = "okay";
> > > +};
> >
> >
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-15 0:54 ` Andre Przywara
0 siblings, 0 replies; 38+ messages in thread
From: Andre Przywara @ 2022-11-15 0:54 UTC (permalink / raw)
To: Martin Botka
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On Tue, 15 Nov 2022 00:44:46 +0100
Martin Botka <martin.botka1@gmail.com> wrote:
Hi Martin,
> I can totally understand how this can get confusing.
>
> Basically because of the Rpi shortage biqu decided to make an Rpi
> alternative.
>
> So they made CB1 which is compute module style board.
>
> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
> boards are:
>
> Rpi adapter which takes the Compute module style boards and turns them into
> SBC style with basically identical size and etc to Rpi 4.
>
> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
> they were made for Klipper use case which requires a computer or SBC
> (Usually Rpi4). They combined it into 1 board.
> Where you get the MCU and you can plug in CM4 or CB1
Thanks for the explanations! I was guessing along those shortage lines,
since the H616 is quite a step down from the RPi4CM, though probably
still enough for driving a 3D printer.
> All these boards are basically taking the pins and routing them to ports.
Yes, this is what those SoM carrier boards do ;-)
> There is nearly 0 chips for conversion or processing of the pins from CB1
> or CM4 thus i do not see a reason for having parent dtsi and dts for the
> adapter and Manta boards.
And the DT does not need to describe "chips" only, a lot of DT nodes
are about connectors, and which ports and which exact pins (out of the
possible pinmuxes) are actually used. The SoM itself mostly exposes
just pins, and the board DT describes how these pins are used (GPIO or
special function, for instance).
So did you try to split this up? How would that look?
Cheers,
Andre
> The only exception to conversion are the LEDs on the boards but since both
> adapter and manta boards have them this yet again eliminates need for
> parent style DT.
>
> Best regards,
> Martin
>
> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
> wrote:
>
> > On Mon, 14 Nov 2022 22:44:49 +0100
> > Martin Botka <martin.botka@somainline.org> wrote:
> >
> > > CB1 is Compute Module style board that plugs into Rpi board style
> > adapter or
> > > Manta 3D printer boards (M4P/M8P).
> > >
> > > The board has:
> > > H616 SoC
> > > 1GB of RAM
> > > AXP313A PMIC
> > >
> > > And the actual boards that CB1 plugs in are just extension to it with
> > ports and
> > > thus are not split in DT.
> >
> > I don't really understand that sentence. There is some precedent for a
> > SoM/board split, look at the sun50i-a64-sopine or
> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
> > there are *two* boards available for the same CB1 SoM, the PI4B and the
> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
> > or two board .dts files.
> > I am just not sure whether that relation to the Pi4-CM is helpful or
> > just complicates things...
> >
> > Cheers,
> > Andre
> >
> > >
> > > Boards have:
> > > 4x (3x for Manta boards) USB and 1 USB OTG.
> > > SDcard slot for loading images.
> > > Ethernet port wired to the internal PHY.
> > > 2x HDMI 2.0.
> > > Power and Status LEDs.
> > >
> > > Currently working:
> > > Booting
> > > USB
> > > UART
> > >
> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
> > > ---
> > > Changes in V2:
> > > Add proper board compatible
> > > Add regulator prefix for vcc5v
> > > Drop okay status from PMIC
> > > Drop standby_param
> > > Changes in V3:
> > > Change copyright to me
> > > regulator_vcc5v to regulator-vcc5v
> > > Drop ehci0 and ohci0
> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
> > > 2 files changed, 179 insertions(+)
> > > create mode 100644
> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> > b/arch/arm64/boot/dts/allwinner/Makefile
> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> > > new file mode 100644
> > > index 000000000000..86b5aca9b53e
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> > > @@ -0,0 +1,178 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > > +/*
> > > + * Copyright (C) 2022 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 = "BIQU CB1";
> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> > > +
> > > + aliases {
> > > + serial0 = &uart0;
> > > + };
> > > +
> > > + chosen {
> > > + stdout-path = "serial0:115200n8";
> > > + };
> > > +
> > > + leds {
> > > + compatible = "gpio-leds";
> > > +
> > > + led-0 {
> > > + function = LED_FUNCTION_POWER;
> > > + color = <LED_COLOR_ID_RED>;
> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
> > > + default-state = "on";
> > > + };
> > > +
> > > + led-1 {
> > > + function = LED_FUNCTION_STATUS;
> > > + color = <LED_COLOR_ID_GREEN>;
> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
> > > + };
> > > + };
> > > +
> > > + 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 = <®_vcc5v>;
> > > + enable-active-high;
> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> > > + };
> > > +};
> > > +
> > > +&ehci1 {
> > > + status = "okay";
> > > +};
> > > +
> > > +&ehci2 {
> > > + status = "okay";
> > > +};
> > > +
> > > +&ehci3 {
> > > + status = "okay";
> > > +};
> > > +
> > > +&mmc0 {
> > > + vmmc-supply = <®_dldo1>;
> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > > + no-1-8-v;
> > > + bus-width = <4>;
> > > + status = "disabled";
> > > +};
> > > +
> > > +&ohci1 {
> > > + status = "okay";
> > > +};
> > > +
> > > +&ohci2 {
> > > + status = "okay";
> > > +};
> > > +
> > > +&ohci3 {
> > > + status = "okay";
> > > +};
> > > +
> > > +&r_i2c {
> > > + status = "okay";
> > > +
> > > + axp1530: pmic@36 {
> > > + compatible = "x-powers,axp1530";
> > > + reg = <0x36>;
> > > + wakeup-source;
> > > +
> > > + regulators{
> > > + reg_dcdc1: dcdc1 {
> > > + regulator-name = "axp1530-dcdc1";
> > > + regulator-min-microvolt = <500000>;
> > > + regulator-max-microvolt = <3400000>;
> > > + regulator-step-delay-us = <25>;
> > > + regulator-final-delay-us = <50>;
> > > + regulator-always-on;
> > > + };
> > > +
> > > + reg_dcdc2: dcdc2 {
> > > + regulator-name = "axp1530-dcdc2";
> > > + regulator-min-microvolt = <500000>;
> > > + regulator-max-microvolt = <1540000>;
> > > + regulator-step-delay-us = <25>;
> > > + regulator-final-delay-us = <50>;
> > > + regulator-ramp-delay = <200>;
> > > + regulator-always-on;
> > > + };
> > > +
> > > + reg_dcdc3: dcdc3 {
> > > + regulator-name = "axp1530-dcdc3";
> > > + regulator-min-microvolt = <500000>;
> > > + regulator-max-microvolt = <1840000>;
> > > + regulator-step-delay-us = <25>;
> > > + regulator-final-delay-us = <50>;
> > > + regulator-always-on;
> > > + };
> > > +
> > > + reg_aldo1: ldo1 {
> > > + regulator-name = "axp1530-aldo1";
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <1800000>;
> > > + regulator-step-delay-us = <25>;
> > > + regulator-final-delay-us = <50>;
> > > + regulator-always-on;
> > > + };
> > > +
> > > + reg_dldo1: ldo2 {
> > > + regulator-name = "axp1530-dldo1";
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-step-delay-us = <25>;
> > > + regulator-final-delay-us = <50>;
> > > + regulator-always-on;
> > > + };
> > > + };
> > > + };
> > > +};
> > > +
> > > +&uart0 {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&uart0_ph_pins>;
> > > + status = "okay";
> > > +};
> > > +
> > > +&usbotg {
> > > + /*
> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
> > > + * is not implemented: both CC pins are pulled to GND.
> > > + * The VBUS pins power the device, so a fixed peripheral mode
> > > + * is the best choice.
> > > + * The board can be powered via GPIOs, in this case port0 *can*
> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
> > > + * then provided by the GPIOs. Any user of this setup would
> > > + * need to adjust the DT accordingly: dr_mode set to "host",
> > > + * enabling OHCI0 and EHCI0.
> > > + */
> > > + dr_mode = "peripheral";
> > > + status = "okay";
> > > +};
> > > +
> > > +&usbphy {
> > > + usb1_vbus-supply = <®_usb1_vbus>;
> > > + status = "okay";
> > > +};
> >
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-15 0:54 ` Andre Przywara
@ 2022-11-15 8:24 ` Martin Botka
-1 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 8:24 UTC (permalink / raw)
To: Andre Przywara, Martin Botka
Cc: ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>On Tue, 15 Nov 2022 00:44:46 +0100
>Martin Botka <martin.botka1@gmail.com> wrote:
>
>Hi Martin,
>
>> I can totally understand how this can get confusing.
>>
>> Basically because of the Rpi shortage biqu decided to make an Rpi
>> alternative.
>>
>> So they made CB1 which is compute module style board.
>>
>> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
>> boards are:
>>
>> Rpi adapter which takes the Compute module style boards and turns them into
>> SBC style with basically identical size and etc to Rpi 4.
>>
>> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
>> they were made for Klipper use case which requires a computer or SBC
>> (Usually Rpi4). They combined it into 1 board.
>> Where you get the MCU and you can plug in CM4 or CB1
>
>Thanks for the explanations! I was guessing along those shortage lines,
>since the H616 is quite a step down from the RPi4CM, though probably
>still enough for driving a 3D printer.
Mostly yes
>
>> All these boards are basically taking the pins and routing them to ports.
>
>Yes, this is what those SoM carrier boards do ;-)
:)
>
>> There is nearly 0 chips for conversion or processing of the pins from CB1
>> or CM4 thus i do not see a reason for having parent dtsi and dts for the
>> adapter and Manta boards.
>
>And the DT does not need to describe "chips" only, a lot of DT nodes
>are about connectors, and which ports and which exact pins (out of the
>possible pinmuxes) are actually used. The SoM itself mostly exposes
>just pins, and the board DT describes how these pins are used (GPIO or
>special function, for instance).
>
>So did you try to split this up? How would that look?
The main difference between adapter and Manta boards is that adapter has 4x USB. Manta only has 3 and 1 otg. But it has a switch to disable or enable otg.
Im not opposed to splitting it up. It is probably a good idea.
I dont see how to resolve that switch on manta boards tho.
Regards,
Martin
>
>Cheers,
>Andre
>
>> The only exception to conversion are the LEDs on the boards but since both
>> adapter and manta boards have them this yet again eliminates need for
>> parent style DT.
>>
>> Best regards,
>> Martin
>>
>> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
>> wrote:
>>
>> > On Mon, 14 Nov 2022 22:44:49 +0100
>> > Martin Botka <martin.botka@somainline.org> wrote:
>> >
>> > > CB1 is Compute Module style board that plugs into Rpi board style
>> > adapter or
>> > > Manta 3D printer boards (M4P/M8P).
>> > >
>> > > The board has:
>> > > H616 SoC
>> > > 1GB of RAM
>> > > AXP313A PMIC
>> > >
>> > > And the actual boards that CB1 plugs in are just extension to it with
>> > ports and
>> > > thus are not split in DT.
>> >
>> > I don't really understand that sentence. There is some precedent for a
>> > SoM/board split, look at the sun50i-a64-sopine or
>> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
>> > there are *two* boards available for the same CB1 SoM, the PI4B and the
>> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
>> > or two board .dts files.
>> > I am just not sure whether that relation to the Pi4-CM is helpful or
>> > just complicates things...
>> >
>> > Cheers,
>> > Andre
>> >
>> > >
>> > > Boards have:
>> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> > > SDcard slot for loading images.
>> > > Ethernet port wired to the internal PHY.
>> > > 2x HDMI 2.0.
>> > > Power and Status LEDs.
>> > >
>> > > Currently working:
>> > > Booting
>> > > USB
>> > > UART
>> > >
>> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> > > ---
>> > > Changes in V2:
>> > > Add proper board compatible
>> > > Add regulator prefix for vcc5v
>> > > Drop okay status from PMIC
>> > > Drop standby_param
>> > > Changes in V3:
>> > > Change copyright to me
>> > > regulator_vcc5v to regulator-vcc5v
>> > > Drop ehci0 and ohci0
>> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
>> > > 2 files changed, 179 insertions(+)
>> > > create mode 100644
>> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> > >
>> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> > b/arch/arm64/boot/dts/allwinner/Makefile
>> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> > > new file mode 100644
>> > > index 000000000000..86b5aca9b53e
>> > > --- /dev/null
>> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> > > @@ -0,0 +1,178 @@
>> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> > > +/*
>> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> > > +
>> > > + aliases {
>> > > + serial0 = &uart0;
>> > > + };
>> > > +
>> > > + chosen {
>> > > + stdout-path = "serial0:115200n8";
>> > > + };
>> > > +
>> > > + leds {
>> > > + compatible = "gpio-leds";
>> > > +
>> > > + led-0 {
>> > > + function = LED_FUNCTION_POWER;
>> > > + color = <LED_COLOR_ID_RED>;
>> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
>> > > + default-state = "on";
>> > > + };
>> > > +
>> > > + led-1 {
>> > > + function = LED_FUNCTION_STATUS;
>> > > + color = <LED_COLOR_ID_GREEN>;
>> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
>> > > + };
>> > > + };
>> > > +
>> > > + 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 = <®_vcc5v>;
>> > > + enable-active-high;
>> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>> > > + };
>> > > +};
>> > > +
>> > > +&ehci1 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ehci2 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ehci3 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&mmc0 {
>> > > + vmmc-supply = <®_dldo1>;
>> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> > > + no-1-8-v;
>> > > + bus-width = <4>;
>> > > + status = "disabled";
>> > > +};
>> > > +
>> > > +&ohci1 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ohci2 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ohci3 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&r_i2c {
>> > > + status = "okay";
>> > > +
>> > > + axp1530: pmic@36 {
>> > > + compatible = "x-powers,axp1530";
>> > > + reg = <0x36>;
>> > > + wakeup-source;
>> > > +
>> > > + regulators{
>> > > + reg_dcdc1: dcdc1 {
>> > > + regulator-name = "axp1530-dcdc1";
>> > > + regulator-min-microvolt = <500000>;
>> > > + regulator-max-microvolt = <3400000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_dcdc2: dcdc2 {
>> > > + regulator-name = "axp1530-dcdc2";
>> > > + regulator-min-microvolt = <500000>;
>> > > + regulator-max-microvolt = <1540000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-ramp-delay = <200>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_dcdc3: dcdc3 {
>> > > + regulator-name = "axp1530-dcdc3";
>> > > + regulator-min-microvolt = <500000>;
>> > > + regulator-max-microvolt = <1840000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_aldo1: ldo1 {
>> > > + regulator-name = "axp1530-aldo1";
>> > > + regulator-min-microvolt = <1800000>;
>> > > + regulator-max-microvolt = <1800000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_dldo1: ldo2 {
>> > > + regulator-name = "axp1530-dldo1";
>> > > + regulator-min-microvolt = <3300000>;
>> > > + regulator-max-microvolt = <3300000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > + };
>> > > + };
>> > > +};
>> > > +
>> > > +&uart0 {
>> > > + pinctrl-names = "default";
>> > > + pinctrl-0 = <&uart0_ph_pins>;
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&usbotg {
>> > > + /*
>> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
>> > > + * is not implemented: both CC pins are pulled to GND.
>> > > + * The VBUS pins power the device, so a fixed peripheral mode
>> > > + * is the best choice.
>> > > + * The board can be powered via GPIOs, in this case port0 *can*
>> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
>> > > + * then provided by the GPIOs. Any user of this setup would
>> > > + * need to adjust the DT accordingly: dr_mode set to "host",
>> > > + * enabling OHCI0 and EHCI0.
>> > > + */
>> > > + dr_mode = "peripheral";
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&usbphy {
>> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> > > + status = "okay";
>> > > +};
>> >
>> >
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-15 8:24 ` Martin Botka
0 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 8:24 UTC (permalink / raw)
To: Andre Przywara, Martin Botka
Cc: ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>On Tue, 15 Nov 2022 00:44:46 +0100
>Martin Botka <martin.botka1@gmail.com> wrote:
>
>Hi Martin,
>
>> I can totally understand how this can get confusing.
>>
>> Basically because of the Rpi shortage biqu decided to make an Rpi
>> alternative.
>>
>> So they made CB1 which is compute module style board.
>>
>> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
>> boards are:
>>
>> Rpi adapter which takes the Compute module style boards and turns them into
>> SBC style with basically identical size and etc to Rpi 4.
>>
>> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
>> they were made for Klipper use case which requires a computer or SBC
>> (Usually Rpi4). They combined it into 1 board.
>> Where you get the MCU and you can plug in CM4 or CB1
>
>Thanks for the explanations! I was guessing along those shortage lines,
>since the H616 is quite a step down from the RPi4CM, though probably
>still enough for driving a 3D printer.
Mostly yes
>
>> All these boards are basically taking the pins and routing them to ports.
>
>Yes, this is what those SoM carrier boards do ;-)
:)
>
>> There is nearly 0 chips for conversion or processing of the pins from CB1
>> or CM4 thus i do not see a reason for having parent dtsi and dts for the
>> adapter and Manta boards.
>
>And the DT does not need to describe "chips" only, a lot of DT nodes
>are about connectors, and which ports and which exact pins (out of the
>possible pinmuxes) are actually used. The SoM itself mostly exposes
>just pins, and the board DT describes how these pins are used (GPIO or
>special function, for instance).
>
>So did you try to split this up? How would that look?
The main difference between adapter and Manta boards is that adapter has 4x USB. Manta only has 3 and 1 otg. But it has a switch to disable or enable otg.
Im not opposed to splitting it up. It is probably a good idea.
I dont see how to resolve that switch on manta boards tho.
Regards,
Martin
>
>Cheers,
>Andre
>
>> The only exception to conversion are the LEDs on the boards but since both
>> adapter and manta boards have them this yet again eliminates need for
>> parent style DT.
>>
>> Best regards,
>> Martin
>>
>> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
>> wrote:
>>
>> > On Mon, 14 Nov 2022 22:44:49 +0100
>> > Martin Botka <martin.botka@somainline.org> wrote:
>> >
>> > > CB1 is Compute Module style board that plugs into Rpi board style
>> > adapter or
>> > > Manta 3D printer boards (M4P/M8P).
>> > >
>> > > The board has:
>> > > H616 SoC
>> > > 1GB of RAM
>> > > AXP313A PMIC
>> > >
>> > > And the actual boards that CB1 plugs in are just extension to it with
>> > ports and
>> > > thus are not split in DT.
>> >
>> > I don't really understand that sentence. There is some precedent for a
>> > SoM/board split, look at the sun50i-a64-sopine or
>> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
>> > there are *two* boards available for the same CB1 SoM, the PI4B and the
>> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
>> > or two board .dts files.
>> > I am just not sure whether that relation to the Pi4-CM is helpful or
>> > just complicates things...
>> >
>> > Cheers,
>> > Andre
>> >
>> > >
>> > > Boards have:
>> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> > > SDcard slot for loading images.
>> > > Ethernet port wired to the internal PHY.
>> > > 2x HDMI 2.0.
>> > > Power and Status LEDs.
>> > >
>> > > Currently working:
>> > > Booting
>> > > USB
>> > > UART
>> > >
>> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> > > ---
>> > > Changes in V2:
>> > > Add proper board compatible
>> > > Add regulator prefix for vcc5v
>> > > Drop okay status from PMIC
>> > > Drop standby_param
>> > > Changes in V3:
>> > > Change copyright to me
>> > > regulator_vcc5v to regulator-vcc5v
>> > > Drop ehci0 and ohci0
>> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
>> > > 2 files changed, 179 insertions(+)
>> > > create mode 100644
>> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> > >
>> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> > b/arch/arm64/boot/dts/allwinner/Makefile
>> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> > > new file mode 100644
>> > > index 000000000000..86b5aca9b53e
>> > > --- /dev/null
>> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> > > @@ -0,0 +1,178 @@
>> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> > > +/*
>> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> > > +
>> > > + aliases {
>> > > + serial0 = &uart0;
>> > > + };
>> > > +
>> > > + chosen {
>> > > + stdout-path = "serial0:115200n8";
>> > > + };
>> > > +
>> > > + leds {
>> > > + compatible = "gpio-leds";
>> > > +
>> > > + led-0 {
>> > > + function = LED_FUNCTION_POWER;
>> > > + color = <LED_COLOR_ID_RED>;
>> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
>> > > + default-state = "on";
>> > > + };
>> > > +
>> > > + led-1 {
>> > > + function = LED_FUNCTION_STATUS;
>> > > + color = <LED_COLOR_ID_GREEN>;
>> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
>> > > + };
>> > > + };
>> > > +
>> > > + 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 = <®_vcc5v>;
>> > > + enable-active-high;
>> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>> > > + };
>> > > +};
>> > > +
>> > > +&ehci1 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ehci2 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ehci3 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&mmc0 {
>> > > + vmmc-supply = <®_dldo1>;
>> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> > > + no-1-8-v;
>> > > + bus-width = <4>;
>> > > + status = "disabled";
>> > > +};
>> > > +
>> > > +&ohci1 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ohci2 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ohci3 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&r_i2c {
>> > > + status = "okay";
>> > > +
>> > > + axp1530: pmic@36 {
>> > > + compatible = "x-powers,axp1530";
>> > > + reg = <0x36>;
>> > > + wakeup-source;
>> > > +
>> > > + regulators{
>> > > + reg_dcdc1: dcdc1 {
>> > > + regulator-name = "axp1530-dcdc1";
>> > > + regulator-min-microvolt = <500000>;
>> > > + regulator-max-microvolt = <3400000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_dcdc2: dcdc2 {
>> > > + regulator-name = "axp1530-dcdc2";
>> > > + regulator-min-microvolt = <500000>;
>> > > + regulator-max-microvolt = <1540000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-ramp-delay = <200>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_dcdc3: dcdc3 {
>> > > + regulator-name = "axp1530-dcdc3";
>> > > + regulator-min-microvolt = <500000>;
>> > > + regulator-max-microvolt = <1840000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_aldo1: ldo1 {
>> > > + regulator-name = "axp1530-aldo1";
>> > > + regulator-min-microvolt = <1800000>;
>> > > + regulator-max-microvolt = <1800000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_dldo1: ldo2 {
>> > > + regulator-name = "axp1530-dldo1";
>> > > + regulator-min-microvolt = <3300000>;
>> > > + regulator-max-microvolt = <3300000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > + };
>> > > + };
>> > > +};
>> > > +
>> > > +&uart0 {
>> > > + pinctrl-names = "default";
>> > > + pinctrl-0 = <&uart0_ph_pins>;
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&usbotg {
>> > > + /*
>> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
>> > > + * is not implemented: both CC pins are pulled to GND.
>> > > + * The VBUS pins power the device, so a fixed peripheral mode
>> > > + * is the best choice.
>> > > + * The board can be powered via GPIOs, in this case port0 *can*
>> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
>> > > + * then provided by the GPIOs. Any user of this setup would
>> > > + * need to adjust the DT accordingly: dr_mode set to "host",
>> > > + * enabling OHCI0 and EHCI0.
>> > > + */
>> > > + dr_mode = "peripheral";
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&usbphy {
>> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> > > + status = "okay";
>> > > +};
>> >
>> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-15 0:54 ` Andre Przywara
@ 2022-11-15 9:55 ` Martin Botka
-1 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 9:55 UTC (permalink / raw)
To: Andre Przywara, Martin Botka
Cc: ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>On Tue, 15 Nov 2022 00:44:46 +0100
>Martin Botka <martin.botka1@gmail.com> wrote:
>
>Hi Martin,
>
>> I can totally understand how this can get confusing.
>>
>> Basically because of the Rpi shortage biqu decided to make an Rpi
>> alternative.
>>
>> So they made CB1 which is compute module style board.
>>
>> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
>> boards are:
>>
>> Rpi adapter which takes the Compute module style boards and turns them into
>> SBC style with basically identical size and etc to Rpi 4.
>>
>> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
>> they were made for Klipper use case which requires a computer or SBC
>> (Usually Rpi4). They combined it into 1 board.
>> Where you get the MCU and you can plug in CM4 or CB1
>
>Thanks for the explanations! I was guessing along those shortage lines,
>since the H616 is quite a step down from the RPi4CM, though probably
>still enough for driving a 3D printer.
>
>> All these boards are basically taking the pins and routing them to ports.
>
>Yes, this is what those SoM carrier boards do ;-)
>
>> There is nearly 0 chips for conversion or processing of the pins from CB1
>> or CM4 thus i do not see a reason for having parent dtsi and dts for the
>> adapter and Manta boards.
>
>And the DT does not need to describe "chips" only, a lot of DT nodes
>are about connectors, and which ports and which exact pins (out of the
>possible pinmuxes) are actually used. The SoM itself mostly exposes
>just pins, and the board DT describes how these pins are used (GPIO or
>special function, for instance).
>
>So did you try to split this up? How would that look?
>
>Cheers,
>Andre
>
>> The only exception to conversion are the LEDs on the boards but since both
>> adapter and manta boards have them this yet again eliminates need for
>> parent style DT.
>>
>> Best regards,
>> Martin
>>
>> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
>> wrote:
>>
>> > On Mon, 14 Nov 2022 22:44:49 +0100
>> > Martin Botka <martin.botka@somainline.org> wrote:
>> >
>> > > CB1 is Compute Module style board that plugs into Rpi board style
>> > adapter or
>> > > Manta 3D printer boards (M4P/M8P).
>> > >
>> > > The board has:
>> > > H616 SoC
>> > > 1GB of RAM
>> > > AXP313A PMIC
>> > >
>> > > And the actual boards that CB1 plugs in are just extension to it with
>> > ports and
>> > > thus are not split in DT.
>> >
>> > I don't really understand that sentence. There is some precedent for a
>> > SoM/board split, look at the sun50i-a64-sopine or
>> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
>> > there are *two* boards available for the same CB1 SoM, the PI4B and the
>> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
>> > or two board .dts files.
>> > I am just not sure whether that relation to the Pi4-CM is helpful or
>> > just complicates things...
>> >
>> > Cheers,
>> > Andre
>> >
>> > >
>> > > Boards have:
>> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> > > SDcard slot for loading images.
>> > > Ethernet port wired to the internal PHY.
>> > > 2x HDMI 2.0.
>> > > Power and Status LEDs.
>> > >
>> > > Currently working:
>> > > Booting
>> > > USB
>> > > UART
>> > >
>> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> > > ---
>> > > Changes in V2:
>> > > Add proper board compatible
>> > > Add regulator prefix for vcc5v
>> > > Drop okay status from PMIC
>> > > Drop standby_param
>> > > Changes in V3:
>> > > Change copyright to me
>> > > regulator_vcc5v to regulator-vcc5v
>> > > Drop ehci0 and ohci0
>> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
>> > > 2 files changed, 179 insertions(+)
>> > > create mode 100644
>> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> > >
>> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> > b/arch/arm64/boot/dts/allwinner/Makefile
>> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> > > new file mode 100644
>> > > index 000000000000..86b5aca9b53e
>> > > --- /dev/null
>> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> > > @@ -0,0 +1,178 @@
>> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> > > +/*
>> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> > > +
>> > > + aliases {
>> > > + serial0 = &uart0;
>> > > + };
>> > > +
>> > > + chosen {
>> > > + stdout-path = "serial0:115200n8";
>> > > + };
>> > > +
>> > > + leds {
>> > > + compatible = "gpio-leds";
>> > > +
>> > > + led-0 {
>> > > + function = LED_FUNCTION_POWER;
>> > > + color = <LED_COLOR_ID_RED>;
>> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
>> > > + default-state = "on";
>> > > + };
>> > > +
>> > > + led-1 {
>> > > + function = LED_FUNCTION_STATUS;
>> > > + color = <LED_COLOR_ID_GREEN>;
>> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
>> > > + };
>> > > + };
>> > > +
>> > > + 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 = <®_vcc5v>;
>> > > + enable-active-high;
>> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>> > > + };
>> > > +};
>> > > +
>> > > +&ehci1 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ehci2 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ehci3 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&mmc0 {
>> > > + vmmc-supply = <®_dldo1>;
>> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> > > + no-1-8-v;
>> > > + bus-width = <4>;
>> > > + status = "disabled";
>> > > +};
>> > > +
>> > > +&ohci1 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ohci2 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ohci3 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&r_i2c {
>> > > + status = "okay";
>> > > +
>> > > + axp1530: pmic@36 {
>> > > + compatible = "x-powers,axp1530";
>> > > + reg = <0x36>;
>> > > + wakeup-source;
>> > > +
>> > > + regulators{
>> > > + reg_dcdc1: dcdc1 {
>> > > + regulator-name = "axp1530-dcdc1";
>> > > + regulator-min-microvolt = <500000>;
>> > > + regulator-max-microvolt = <3400000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_dcdc2: dcdc2 {
>> > > + regulator-name = "axp1530-dcdc2";
>> > > + regulator-min-microvolt = <500000>;
>> > > + regulator-max-microvolt = <1540000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-ramp-delay = <200>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_dcdc3: dcdc3 {
>> > > + regulator-name = "axp1530-dcdc3";
>> > > + regulator-min-microvolt = <500000>;
>> > > + regulator-max-microvolt = <1840000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_aldo1: ldo1 {
>> > > + regulator-name = "axp1530-aldo1";
>> > > + regulator-min-microvolt = <1800000>;
>> > > + regulator-max-microvolt = <1800000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_dldo1: ldo2 {
>> > > + regulator-name = "axp1530-dldo1";
>> > > + regulator-min-microvolt = <3300000>;
>> > > + regulator-max-microvolt = <3300000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > + };
>> > > + };
>> > > +};
>> > > +
>> > > +&uart0 {
>> > > + pinctrl-names = "default";
>> > > + pinctrl-0 = <&uart0_ph_pins>;
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&usbotg {
>> > > + /*
>> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
>> > > + * is not implemented: both CC pins are pulled to GND.
>> > > + * The VBUS pins power the device, so a fixed peripheral mode
>> > > + * is the best choice.
>> > > + * The board can be powered via GPIOs, in this case port0 *can*
>> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
>> > > + * then provided by the GPIOs. Any user of this setup would
>> > > + * need to adjust the DT accordingly: dr_mode set to "host",
>> > > + * enabling OHCI0 and EHCI0.
>> > > + */
>> > > + dr_mode = "peripheral";
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&usbphy {
>> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> > > + status = "okay";
>> > > +};
>> >
>> >
>
Dear Andre,
I have read the schematic of M8P again to recheck a few things. The split of DTS may not be needed after all.
The 4 USB of H616 are used on both boards.
Where this changes is with Rpi CM4 and the usbotg switch is used alongside rpiboot switch to make eMMC of CM4 as host media so data can be loaded onto it.
I will adjust the DT in next revision accordingly.
Regards,
Martin
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-15 9:55 ` Martin Botka
0 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 9:55 UTC (permalink / raw)
To: Andre Przywara, Martin Botka
Cc: ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>On Tue, 15 Nov 2022 00:44:46 +0100
>Martin Botka <martin.botka1@gmail.com> wrote:
>
>Hi Martin,
>
>> I can totally understand how this can get confusing.
>>
>> Basically because of the Rpi shortage biqu decided to make an Rpi
>> alternative.
>>
>> So they made CB1 which is compute module style board.
>>
>> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
>> boards are:
>>
>> Rpi adapter which takes the Compute module style boards and turns them into
>> SBC style with basically identical size and etc to Rpi 4.
>>
>> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
>> they were made for Klipper use case which requires a computer or SBC
>> (Usually Rpi4). They combined it into 1 board.
>> Where you get the MCU and you can plug in CM4 or CB1
>
>Thanks for the explanations! I was guessing along those shortage lines,
>since the H616 is quite a step down from the RPi4CM, though probably
>still enough for driving a 3D printer.
>
>> All these boards are basically taking the pins and routing them to ports.
>
>Yes, this is what those SoM carrier boards do ;-)
>
>> There is nearly 0 chips for conversion or processing of the pins from CB1
>> or CM4 thus i do not see a reason for having parent dtsi and dts for the
>> adapter and Manta boards.
>
>And the DT does not need to describe "chips" only, a lot of DT nodes
>are about connectors, and which ports and which exact pins (out of the
>possible pinmuxes) are actually used. The SoM itself mostly exposes
>just pins, and the board DT describes how these pins are used (GPIO or
>special function, for instance).
>
>So did you try to split this up? How would that look?
>
>Cheers,
>Andre
>
>> The only exception to conversion are the LEDs on the boards but since both
>> adapter and manta boards have them this yet again eliminates need for
>> parent style DT.
>>
>> Best regards,
>> Martin
>>
>> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
>> wrote:
>>
>> > On Mon, 14 Nov 2022 22:44:49 +0100
>> > Martin Botka <martin.botka@somainline.org> wrote:
>> >
>> > > CB1 is Compute Module style board that plugs into Rpi board style
>> > adapter or
>> > > Manta 3D printer boards (M4P/M8P).
>> > >
>> > > The board has:
>> > > H616 SoC
>> > > 1GB of RAM
>> > > AXP313A PMIC
>> > >
>> > > And the actual boards that CB1 plugs in are just extension to it with
>> > ports and
>> > > thus are not split in DT.
>> >
>> > I don't really understand that sentence. There is some precedent for a
>> > SoM/board split, look at the sun50i-a64-sopine or
>> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
>> > there are *two* boards available for the same CB1 SoM, the PI4B and the
>> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
>> > or two board .dts files.
>> > I am just not sure whether that relation to the Pi4-CM is helpful or
>> > just complicates things...
>> >
>> > Cheers,
>> > Andre
>> >
>> > >
>> > > Boards have:
>> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> > > SDcard slot for loading images.
>> > > Ethernet port wired to the internal PHY.
>> > > 2x HDMI 2.0.
>> > > Power and Status LEDs.
>> > >
>> > > Currently working:
>> > > Booting
>> > > USB
>> > > UART
>> > >
>> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> > > ---
>> > > Changes in V2:
>> > > Add proper board compatible
>> > > Add regulator prefix for vcc5v
>> > > Drop okay status from PMIC
>> > > Drop standby_param
>> > > Changes in V3:
>> > > Change copyright to me
>> > > regulator_vcc5v to regulator-vcc5v
>> > > Drop ehci0 and ohci0
>> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
>> > > 2 files changed, 179 insertions(+)
>> > > create mode 100644
>> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> > >
>> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> > b/arch/arm64/boot/dts/allwinner/Makefile
>> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> > > new file mode 100644
>> > > index 000000000000..86b5aca9b53e
>> > > --- /dev/null
>> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> > > @@ -0,0 +1,178 @@
>> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> > > +/*
>> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> > > +
>> > > + aliases {
>> > > + serial0 = &uart0;
>> > > + };
>> > > +
>> > > + chosen {
>> > > + stdout-path = "serial0:115200n8";
>> > > + };
>> > > +
>> > > + leds {
>> > > + compatible = "gpio-leds";
>> > > +
>> > > + led-0 {
>> > > + function = LED_FUNCTION_POWER;
>> > > + color = <LED_COLOR_ID_RED>;
>> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
>> > > + default-state = "on";
>> > > + };
>> > > +
>> > > + led-1 {
>> > > + function = LED_FUNCTION_STATUS;
>> > > + color = <LED_COLOR_ID_GREEN>;
>> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
>> > > + };
>> > > + };
>> > > +
>> > > + 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 = <®_vcc5v>;
>> > > + enable-active-high;
>> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>> > > + };
>> > > +};
>> > > +
>> > > +&ehci1 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ehci2 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ehci3 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&mmc0 {
>> > > + vmmc-supply = <®_dldo1>;
>> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> > > + no-1-8-v;
>> > > + bus-width = <4>;
>> > > + status = "disabled";
>> > > +};
>> > > +
>> > > +&ohci1 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ohci2 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&ohci3 {
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&r_i2c {
>> > > + status = "okay";
>> > > +
>> > > + axp1530: pmic@36 {
>> > > + compatible = "x-powers,axp1530";
>> > > + reg = <0x36>;
>> > > + wakeup-source;
>> > > +
>> > > + regulators{
>> > > + reg_dcdc1: dcdc1 {
>> > > + regulator-name = "axp1530-dcdc1";
>> > > + regulator-min-microvolt = <500000>;
>> > > + regulator-max-microvolt = <3400000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_dcdc2: dcdc2 {
>> > > + regulator-name = "axp1530-dcdc2";
>> > > + regulator-min-microvolt = <500000>;
>> > > + regulator-max-microvolt = <1540000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-ramp-delay = <200>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_dcdc3: dcdc3 {
>> > > + regulator-name = "axp1530-dcdc3";
>> > > + regulator-min-microvolt = <500000>;
>> > > + regulator-max-microvolt = <1840000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_aldo1: ldo1 {
>> > > + regulator-name = "axp1530-aldo1";
>> > > + regulator-min-microvolt = <1800000>;
>> > > + regulator-max-microvolt = <1800000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > +
>> > > + reg_dldo1: ldo2 {
>> > > + regulator-name = "axp1530-dldo1";
>> > > + regulator-min-microvolt = <3300000>;
>> > > + regulator-max-microvolt = <3300000>;
>> > > + regulator-step-delay-us = <25>;
>> > > + regulator-final-delay-us = <50>;
>> > > + regulator-always-on;
>> > > + };
>> > > + };
>> > > + };
>> > > +};
>> > > +
>> > > +&uart0 {
>> > > + pinctrl-names = "default";
>> > > + pinctrl-0 = <&uart0_ph_pins>;
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&usbotg {
>> > > + /*
>> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
>> > > + * is not implemented: both CC pins are pulled to GND.
>> > > + * The VBUS pins power the device, so a fixed peripheral mode
>> > > + * is the best choice.
>> > > + * The board can be powered via GPIOs, in this case port0 *can*
>> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
>> > > + * then provided by the GPIOs. Any user of this setup would
>> > > + * need to adjust the DT accordingly: dr_mode set to "host",
>> > > + * enabling OHCI0 and EHCI0.
>> > > + */
>> > > + dr_mode = "peripheral";
>> > > + status = "okay";
>> > > +};
>> > > +
>> > > +&usbphy {
>> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> > > + status = "okay";
>> > > +};
>> >
>> >
>
Dear Andre,
I have read the schematic of M8P again to recheck a few things. The split of DTS may not be needed after all.
The 4 USB of H616 are used on both boards.
Where this changes is with Rpi CM4 and the usbotg switch is used alongside rpiboot switch to make eMMC of CM4 as host media so data can be loaded onto it.
I will adjust the DT in next revision accordingly.
Regards,
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 1/2] dt-bindings: arm: sunxi: Add BIQU CB1
2022-11-14 21:44 ` Martin Botka
@ 2022-11-15 9:59 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 38+ messages in thread
From: Krzysztof Kozlowski @ 2022-11-15 9:59 UTC (permalink / raw)
To: Martin Botka, martin.botka1
Cc: ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Andre Przywara,
Maxime Ripard, Andrew Lunn, Conley Lee, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel
On 14/11/2022 22:44, Martin Botka wrote:
> Add a name & compatible for BIQU CB1
>
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> ---
> Changes in V2:
> Add compatible and name to dt-bindings
> Changes in V3:
> None
> 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 3ad1cd50e3fe..d886924023f5 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: Biqu CB1
> + items:
> + - const: biqu,cb1
Undocumented vendor prefix. Did you run checkpatch?
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 1/2] dt-bindings: arm: sunxi: Add BIQU CB1
@ 2022-11-15 9:59 ` Krzysztof Kozlowski
0 siblings, 0 replies; 38+ messages in thread
From: Krzysztof Kozlowski @ 2022-11-15 9:59 UTC (permalink / raw)
To: Martin Botka, martin.botka1
Cc: ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Andre Przywara,
Maxime Ripard, Andrew Lunn, Conley Lee, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel
On 14/11/2022 22:44, Martin Botka wrote:
> Add a name & compatible for BIQU CB1
>
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> ---
> Changes in V2:
> Add compatible and name to dt-bindings
> Changes in V3:
> None
> 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 3ad1cd50e3fe..d886924023f5 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: Biqu CB1
> + items:
> + - const: biqu,cb1
Undocumented vendor prefix. Did you run checkpatch?
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-15 8:24 ` Martin Botka
@ 2022-11-15 10:33 ` Andre Przywara
-1 siblings, 0 replies; 38+ messages in thread
From: Andre Przywara @ 2022-11-15 10:33 UTC (permalink / raw)
To: Martin Botka
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On Tue, 15 Nov 2022 09:24:04 +0100
Martin Botka <martin.botka@somainline.org> wrote:
Hi,
> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
> >On Tue, 15 Nov 2022 00:44:46 +0100
> >Martin Botka <martin.botka1@gmail.com> wrote:
> >
> >Hi Martin,
> >
> >> I can totally understand how this can get confusing.
> >>
> >> Basically because of the Rpi shortage biqu decided to make an Rpi
> >> alternative.
> >>
> >> So they made CB1 which is compute module style board.
> >>
> >> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
> >> boards are:
> >>
> >> Rpi adapter which takes the Compute module style boards and turns them into
> >> SBC style with basically identical size and etc to Rpi 4.
> >>
> >> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
> >> they were made for Klipper use case which requires a computer or SBC
> >> (Usually Rpi4). They combined it into 1 board.
> >> Where you get the MCU and you can plug in CM4 or CB1
> >
> >Thanks for the explanations! I was guessing along those shortage lines,
> >since the H616 is quite a step down from the RPi4CM, though probably
> >still enough for driving a 3D printer.
> Mostly yes
> >
> >> All these boards are basically taking the pins and routing them to ports.
> >
> >Yes, this is what those SoM carrier boards do ;-)
> :)
> >
> >> There is nearly 0 chips for conversion or processing of the pins from CB1
> >> or CM4 thus i do not see a reason for having parent dtsi and dts for the
> >> adapter and Manta boards.
> >
> >And the DT does not need to describe "chips" only, a lot of DT nodes
> >are about connectors, and which ports and which exact pins (out of the
> >possible pinmuxes) are actually used. The SoM itself mostly exposes
> >just pins, and the board DT describes how these pins are used (GPIO or
> >special function, for instance).
> >
> >So did you try to split this up? How would that look?
>
> The main difference between adapter and Manta boards is that adapter has 4x USB.
So those are two double-type-A sockets? This is not really what the DT
below describes? It's perfectly fine to fix USB0 to host mode, we do this
on the Pine64 boards (both A64 and H6), for instance.
> Manta only has 3 and 1 otg. But it has a switch to disable or enable otg.
What does the switch do, exactly? By definition OTG works fine in both
ways. And there are pins in the connector to decide the role.
Allwinner actually goes one step further and provides a full HCI to the
same PHY that the MUSB OTG controller is connected to, so you don't need
to live with the sometimes limited performance of the MUSB host mode
(which we drive without DMA). Not sure if that is the case or a problem on
the RPi4.
> Im not opposed to splitting it up. It is probably a good idea.
> I dont see how to resolve that switch on manta boards tho.
If the Manta board is (almost) a superset of the Pi4B, then you can
include the latter from there. Look at sun50i-a64-pine64-lts.dts or
sun50i-h6-pine-h64-model-b.dts for examples.
Cheers,
Andre.
> >> The only exception to conversion are the LEDs on the boards but since both
> >> adapter and manta boards have them this yet again eliminates need for
> >> parent style DT.
> >>
> >> Best regards,
> >> Martin
> >>
> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
> >> wrote:
> >>
> >> > On Mon, 14 Nov 2022 22:44:49 +0100
> >> > Martin Botka <martin.botka@somainline.org> wrote:
> >> >
> >> > > CB1 is Compute Module style board that plugs into Rpi board style
> >> > adapter or
> >> > > Manta 3D printer boards (M4P/M8P).
> >> > >
> >> > > The board has:
> >> > > H616 SoC
> >> > > 1GB of RAM
> >> > > AXP313A PMIC
> >> > >
> >> > > And the actual boards that CB1 plugs in are just extension to it with
> >> > ports and
> >> > > thus are not split in DT.
> >> >
> >> > I don't really understand that sentence. There is some precedent for a
> >> > SoM/board split, look at the sun50i-a64-sopine or
> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
> >> > there are *two* boards available for the same CB1 SoM, the PI4B and the
> >> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
> >> > or two board .dts files.
> >> > I am just not sure whether that relation to the Pi4-CM is helpful or
> >> > just complicates things...
> >> >
> >> > Cheers,
> >> > Andre
> >> >
> >> > >
> >> > > Boards have:
> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
> >> > > SDcard slot for loading images.
> >> > > Ethernet port wired to the internal PHY.
> >> > > 2x HDMI 2.0.
> >> > > Power and Status LEDs.
> >> > >
> >> > > Currently working:
> >> > > Booting
> >> > > USB
> >> > > UART
> >> > >
> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
> >> > > ---
> >> > > Changes in V2:
> >> > > Add proper board compatible
> >> > > Add regulator prefix for vcc5v
> >> > > Drop okay status from PMIC
> >> > > Drop standby_param
> >> > > Changes in V3:
> >> > > Change copyright to me
> >> > > regulator_vcc5v to regulator-vcc5v
> >> > > Drop ehci0 and ohci0
> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
> >> > > 2 files changed, 179 insertions(+)
> >> > > create mode 100644
> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> > >
> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> >> > b/arch/arm64/boot/dts/allwinner/Makefile
> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> > > new file mode 100644
> >> > > index 000000000000..86b5aca9b53e
> >> > > --- /dev/null
> >> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> > > @@ -0,0 +1,178 @@
> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> >> > > +/*
> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> >> > > +
> >> > > + aliases {
> >> > > + serial0 = &uart0;
> >> > > + };
> >> > > +
> >> > > + chosen {
> >> > > + stdout-path = "serial0:115200n8";
> >> > > + };
> >> > > +
> >> > > + leds {
> >> > > + compatible = "gpio-leds";
> >> > > +
> >> > > + led-0 {
> >> > > + function = LED_FUNCTION_POWER;
> >> > > + color = <LED_COLOR_ID_RED>;
> >> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
> >> > > + default-state = "on";
> >> > > + };
> >> > > +
> >> > > + led-1 {
> >> > > + function = LED_FUNCTION_STATUS;
> >> > > + color = <LED_COLOR_ID_GREEN>;
> >> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
> >> > > + };
> >> > > + };
> >> > > +
> >> > > + 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 = <®_vcc5v>;
> >> > > + enable-active-high;
> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> >> > > + };
> >> > > +};
> >> > > +
> >> > > +&ehci1 {
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&ehci2 {
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&ehci3 {
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&mmc0 {
> >> > > + vmmc-supply = <®_dldo1>;
> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> >> > > + no-1-8-v;
> >> > > + bus-width = <4>;
> >> > > + status = "disabled";
> >> > > +};
> >> > > +
> >> > > +&ohci1 {
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&ohci2 {
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&ohci3 {
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&r_i2c {
> >> > > + status = "okay";
> >> > > +
> >> > > + axp1530: pmic@36 {
> >> > > + compatible = "x-powers,axp1530";
> >> > > + reg = <0x36>;
> >> > > + wakeup-source;
> >> > > +
> >> > > + regulators{
> >> > > + reg_dcdc1: dcdc1 {
> >> > > + regulator-name = "axp1530-dcdc1";
> >> > > + regulator-min-microvolt = <500000>;
> >> > > + regulator-max-microvolt = <3400000>;
> >> > > + regulator-step-delay-us = <25>;
> >> > > + regulator-final-delay-us = <50>;
> >> > > + regulator-always-on;
> >> > > + };
> >> > > +
> >> > > + reg_dcdc2: dcdc2 {
> >> > > + regulator-name = "axp1530-dcdc2";
> >> > > + regulator-min-microvolt = <500000>;
> >> > > + regulator-max-microvolt = <1540000>;
> >> > > + regulator-step-delay-us = <25>;
> >> > > + regulator-final-delay-us = <50>;
> >> > > + regulator-ramp-delay = <200>;
> >> > > + regulator-always-on;
> >> > > + };
> >> > > +
> >> > > + reg_dcdc3: dcdc3 {
> >> > > + regulator-name = "axp1530-dcdc3";
> >> > > + regulator-min-microvolt = <500000>;
> >> > > + regulator-max-microvolt = <1840000>;
> >> > > + regulator-step-delay-us = <25>;
> >> > > + regulator-final-delay-us = <50>;
> >> > > + regulator-always-on;
> >> > > + };
> >> > > +
> >> > > + reg_aldo1: ldo1 {
> >> > > + regulator-name = "axp1530-aldo1";
> >> > > + regulator-min-microvolt = <1800000>;
> >> > > + regulator-max-microvolt = <1800000>;
> >> > > + regulator-step-delay-us = <25>;
> >> > > + regulator-final-delay-us = <50>;
> >> > > + regulator-always-on;
> >> > > + };
> >> > > +
> >> > > + reg_dldo1: ldo2 {
> >> > > + regulator-name = "axp1530-dldo1";
> >> > > + regulator-min-microvolt = <3300000>;
> >> > > + regulator-max-microvolt = <3300000>;
> >> > > + regulator-step-delay-us = <25>;
> >> > > + regulator-final-delay-us = <50>;
> >> > > + regulator-always-on;
> >> > > + };
> >> > > + };
> >> > > + };
> >> > > +};
> >> > > +
> >> > > +&uart0 {
> >> > > + pinctrl-names = "default";
> >> > > + pinctrl-0 = <&uart0_ph_pins>;
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&usbotg {
> >> > > + /*
> >> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
> >> > > + * is not implemented: both CC pins are pulled to GND.
> >> > > + * The VBUS pins power the device, so a fixed peripheral mode
> >> > > + * is the best choice.
> >> > > + * The board can be powered via GPIOs, in this case port0 *can*
> >> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
> >> > > + * then provided by the GPIOs. Any user of this setup would
> >> > > + * need to adjust the DT accordingly: dr_mode set to "host",
> >> > > + * enabling OHCI0 and EHCI0.
> >> > > + */
> >> > > + dr_mode = "peripheral";
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&usbphy {
> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
> >> > > + status = "okay";
> >> > > +};
> >> >
> >> >
> >
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-15 10:33 ` Andre Przywara
0 siblings, 0 replies; 38+ messages in thread
From: Andre Przywara @ 2022-11-15 10:33 UTC (permalink / raw)
To: Martin Botka
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On Tue, 15 Nov 2022 09:24:04 +0100
Martin Botka <martin.botka@somainline.org> wrote:
Hi,
> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
> >On Tue, 15 Nov 2022 00:44:46 +0100
> >Martin Botka <martin.botka1@gmail.com> wrote:
> >
> >Hi Martin,
> >
> >> I can totally understand how this can get confusing.
> >>
> >> Basically because of the Rpi shortage biqu decided to make an Rpi
> >> alternative.
> >>
> >> So they made CB1 which is compute module style board.
> >>
> >> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
> >> boards are:
> >>
> >> Rpi adapter which takes the Compute module style boards and turns them into
> >> SBC style with basically identical size and etc to Rpi 4.
> >>
> >> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
> >> they were made for Klipper use case which requires a computer or SBC
> >> (Usually Rpi4). They combined it into 1 board.
> >> Where you get the MCU and you can plug in CM4 or CB1
> >
> >Thanks for the explanations! I was guessing along those shortage lines,
> >since the H616 is quite a step down from the RPi4CM, though probably
> >still enough for driving a 3D printer.
> Mostly yes
> >
> >> All these boards are basically taking the pins and routing them to ports.
> >
> >Yes, this is what those SoM carrier boards do ;-)
> :)
> >
> >> There is nearly 0 chips for conversion or processing of the pins from CB1
> >> or CM4 thus i do not see a reason for having parent dtsi and dts for the
> >> adapter and Manta boards.
> >
> >And the DT does not need to describe "chips" only, a lot of DT nodes
> >are about connectors, and which ports and which exact pins (out of the
> >possible pinmuxes) are actually used. The SoM itself mostly exposes
> >just pins, and the board DT describes how these pins are used (GPIO or
> >special function, for instance).
> >
> >So did you try to split this up? How would that look?
>
> The main difference between adapter and Manta boards is that adapter has 4x USB.
So those are two double-type-A sockets? This is not really what the DT
below describes? It's perfectly fine to fix USB0 to host mode, we do this
on the Pine64 boards (both A64 and H6), for instance.
> Manta only has 3 and 1 otg. But it has a switch to disable or enable otg.
What does the switch do, exactly? By definition OTG works fine in both
ways. And there are pins in the connector to decide the role.
Allwinner actually goes one step further and provides a full HCI to the
same PHY that the MUSB OTG controller is connected to, so you don't need
to live with the sometimes limited performance of the MUSB host mode
(which we drive without DMA). Not sure if that is the case or a problem on
the RPi4.
> Im not opposed to splitting it up. It is probably a good idea.
> I dont see how to resolve that switch on manta boards tho.
If the Manta board is (almost) a superset of the Pi4B, then you can
include the latter from there. Look at sun50i-a64-pine64-lts.dts or
sun50i-h6-pine-h64-model-b.dts for examples.
Cheers,
Andre.
> >> The only exception to conversion are the LEDs on the boards but since both
> >> adapter and manta boards have them this yet again eliminates need for
> >> parent style DT.
> >>
> >> Best regards,
> >> Martin
> >>
> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
> >> wrote:
> >>
> >> > On Mon, 14 Nov 2022 22:44:49 +0100
> >> > Martin Botka <martin.botka@somainline.org> wrote:
> >> >
> >> > > CB1 is Compute Module style board that plugs into Rpi board style
> >> > adapter or
> >> > > Manta 3D printer boards (M4P/M8P).
> >> > >
> >> > > The board has:
> >> > > H616 SoC
> >> > > 1GB of RAM
> >> > > AXP313A PMIC
> >> > >
> >> > > And the actual boards that CB1 plugs in are just extension to it with
> >> > ports and
> >> > > thus are not split in DT.
> >> >
> >> > I don't really understand that sentence. There is some precedent for a
> >> > SoM/board split, look at the sun50i-a64-sopine or
> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
> >> > there are *two* boards available for the same CB1 SoM, the PI4B and the
> >> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
> >> > or two board .dts files.
> >> > I am just not sure whether that relation to the Pi4-CM is helpful or
> >> > just complicates things...
> >> >
> >> > Cheers,
> >> > Andre
> >> >
> >> > >
> >> > > Boards have:
> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
> >> > > SDcard slot for loading images.
> >> > > Ethernet port wired to the internal PHY.
> >> > > 2x HDMI 2.0.
> >> > > Power and Status LEDs.
> >> > >
> >> > > Currently working:
> >> > > Booting
> >> > > USB
> >> > > UART
> >> > >
> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
> >> > > ---
> >> > > Changes in V2:
> >> > > Add proper board compatible
> >> > > Add regulator prefix for vcc5v
> >> > > Drop okay status from PMIC
> >> > > Drop standby_param
> >> > > Changes in V3:
> >> > > Change copyright to me
> >> > > regulator_vcc5v to regulator-vcc5v
> >> > > Drop ehci0 and ohci0
> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
> >> > > 2 files changed, 179 insertions(+)
> >> > > create mode 100644
> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> > >
> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> >> > b/arch/arm64/boot/dts/allwinner/Makefile
> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> > > new file mode 100644
> >> > > index 000000000000..86b5aca9b53e
> >> > > --- /dev/null
> >> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> > > @@ -0,0 +1,178 @@
> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> >> > > +/*
> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> >> > > +
> >> > > + aliases {
> >> > > + serial0 = &uart0;
> >> > > + };
> >> > > +
> >> > > + chosen {
> >> > > + stdout-path = "serial0:115200n8";
> >> > > + };
> >> > > +
> >> > > + leds {
> >> > > + compatible = "gpio-leds";
> >> > > +
> >> > > + led-0 {
> >> > > + function = LED_FUNCTION_POWER;
> >> > > + color = <LED_COLOR_ID_RED>;
> >> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
> >> > > + default-state = "on";
> >> > > + };
> >> > > +
> >> > > + led-1 {
> >> > > + function = LED_FUNCTION_STATUS;
> >> > > + color = <LED_COLOR_ID_GREEN>;
> >> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
> >> > > + };
> >> > > + };
> >> > > +
> >> > > + 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 = <®_vcc5v>;
> >> > > + enable-active-high;
> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> >> > > + };
> >> > > +};
> >> > > +
> >> > > +&ehci1 {
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&ehci2 {
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&ehci3 {
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&mmc0 {
> >> > > + vmmc-supply = <®_dldo1>;
> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> >> > > + no-1-8-v;
> >> > > + bus-width = <4>;
> >> > > + status = "disabled";
> >> > > +};
> >> > > +
> >> > > +&ohci1 {
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&ohci2 {
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&ohci3 {
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&r_i2c {
> >> > > + status = "okay";
> >> > > +
> >> > > + axp1530: pmic@36 {
> >> > > + compatible = "x-powers,axp1530";
> >> > > + reg = <0x36>;
> >> > > + wakeup-source;
> >> > > +
> >> > > + regulators{
> >> > > + reg_dcdc1: dcdc1 {
> >> > > + regulator-name = "axp1530-dcdc1";
> >> > > + regulator-min-microvolt = <500000>;
> >> > > + regulator-max-microvolt = <3400000>;
> >> > > + regulator-step-delay-us = <25>;
> >> > > + regulator-final-delay-us = <50>;
> >> > > + regulator-always-on;
> >> > > + };
> >> > > +
> >> > > + reg_dcdc2: dcdc2 {
> >> > > + regulator-name = "axp1530-dcdc2";
> >> > > + regulator-min-microvolt = <500000>;
> >> > > + regulator-max-microvolt = <1540000>;
> >> > > + regulator-step-delay-us = <25>;
> >> > > + regulator-final-delay-us = <50>;
> >> > > + regulator-ramp-delay = <200>;
> >> > > + regulator-always-on;
> >> > > + };
> >> > > +
> >> > > + reg_dcdc3: dcdc3 {
> >> > > + regulator-name = "axp1530-dcdc3";
> >> > > + regulator-min-microvolt = <500000>;
> >> > > + regulator-max-microvolt = <1840000>;
> >> > > + regulator-step-delay-us = <25>;
> >> > > + regulator-final-delay-us = <50>;
> >> > > + regulator-always-on;
> >> > > + };
> >> > > +
> >> > > + reg_aldo1: ldo1 {
> >> > > + regulator-name = "axp1530-aldo1";
> >> > > + regulator-min-microvolt = <1800000>;
> >> > > + regulator-max-microvolt = <1800000>;
> >> > > + regulator-step-delay-us = <25>;
> >> > > + regulator-final-delay-us = <50>;
> >> > > + regulator-always-on;
> >> > > + };
> >> > > +
> >> > > + reg_dldo1: ldo2 {
> >> > > + regulator-name = "axp1530-dldo1";
> >> > > + regulator-min-microvolt = <3300000>;
> >> > > + regulator-max-microvolt = <3300000>;
> >> > > + regulator-step-delay-us = <25>;
> >> > > + regulator-final-delay-us = <50>;
> >> > > + regulator-always-on;
> >> > > + };
> >> > > + };
> >> > > + };
> >> > > +};
> >> > > +
> >> > > +&uart0 {
> >> > > + pinctrl-names = "default";
> >> > > + pinctrl-0 = <&uart0_ph_pins>;
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&usbotg {
> >> > > + /*
> >> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
> >> > > + * is not implemented: both CC pins are pulled to GND.
> >> > > + * The VBUS pins power the device, so a fixed peripheral mode
> >> > > + * is the best choice.
> >> > > + * The board can be powered via GPIOs, in this case port0 *can*
> >> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
> >> > > + * then provided by the GPIOs. Any user of this setup would
> >> > > + * need to adjust the DT accordingly: dr_mode set to "host",
> >> > > + * enabling OHCI0 and EHCI0.
> >> > > + */
> >> > > + dr_mode = "peripheral";
> >> > > + status = "okay";
> >> > > +};
> >> > > +
> >> > > +&usbphy {
> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
> >> > > + status = "okay";
> >> > > +};
> >> >
> >> >
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-15 10:33 ` Andre Przywara
@ 2022-11-15 11:38 ` Martin Botka
-1 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 11:38 UTC (permalink / raw)
To: Andre Przywara
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>On Tue, 15 Nov 2022 09:24:04 +0100
>Martin Botka <martin.botka@somainline.org> wrote:
>
>Hi,
>
>> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>> >On Tue, 15 Nov 2022 00:44:46 +0100
>> >Martin Botka <martin.botka1@gmail.com> wrote:
>> >
>> >Hi Martin,
>> >
>> >> I can totally understand how this can get confusing.
>> >>
>> >> Basically because of the Rpi shortage biqu decided to make an Rpi
>> >> alternative.
>> >>
>> >> So they made CB1 which is compute module style board.
>> >>
>> >> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
>> >> boards are:
>> >>
>> >> Rpi adapter which takes the Compute module style boards and turns them into
>> >> SBC style with basically identical size and etc to Rpi 4.
>> >>
>> >> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
>> >> they were made for Klipper use case which requires a computer or SBC
>> >> (Usually Rpi4). They combined it into 1 board.
>> >> Where you get the MCU and you can plug in CM4 or CB1
>> >
>> >Thanks for the explanations! I was guessing along those shortage lines,
>> >since the H616 is quite a step down from the RPi4CM, though probably
>> >still enough for driving a 3D printer.
>> Mostly yes
>> >
>> >> All these boards are basically taking the pins and routing them to ports.
>> >
>> >Yes, this is what those SoM carrier boards do ;-)
>> :)
>> >
>> >> There is nearly 0 chips for conversion or processing of the pins from CB1
>> >> or CM4 thus i do not see a reason for having parent dtsi and dts for the
>> >> adapter and Manta boards.
>> >
>> >And the DT does not need to describe "chips" only, a lot of DT nodes
>> >are about connectors, and which ports and which exact pins (out of the
>> >possible pinmuxes) are actually used. The SoM itself mostly exposes
>> >just pins, and the board DT describes how these pins are used (GPIO or
>> >special function, for instance).
>> >
>> >So did you try to split this up? How would that look?
>>
>> The main difference between adapter and Manta boards is that adapter has 4x USB.
>
>So those are two double-type-A sockets? This is not really what the DT
>below describes? It's perfectly fine to fix USB0 to host mode, we do this
>on the Pine64 boards (both A64 and H6), for instance.
Yes. But the third and fourth is also used. Third is done in 2.54 4p connector (just pins on board) and fourth is connected directly to manta stm32 MCU. So all 4 are host.
>
>> Manta only has 3 and 1 otg. But it has a switch to disable or enable otg.
>
>What does the switch do, exactly? By definition OTG works fine in both
>ways. And there are pins in the connector to decide the role.
The switch is just signal pin for RS2227. Its the multiplexer i mentioned. It decides if we should have the pins wired to usb type C port or normally to stm32 MCU. Thats all it does.
>
>Allwinner actually goes one step further and provides a full HCI to the
>same PHY that the MUSB OTG controller is connected to, so you don't need
>to live with the sometimes limited performance of the MUSB host mode
>(which we drive without DMA). Not sure if that is the case or a problem on
>the RPi4.
>
>> Im not opposed to splitting it up. It is probably a good idea.
>> I dont see how to resolve that switch on manta boards tho.
>
>If the Manta board is (almost) a superset of the Pi4B, then you can
>include the latter from there. Look at sun50i-a64-pine64-lts.dts or
>sun50i-h6-pine-h64-model-b.dts for examples.
>
>Cheers,
>Andre.
>
Yep i will split it into SoM boards.
>> >> The only exception to conversion are the LEDs on the boards but since both
>> >> adapter and manta boards have them this yet again eliminates need for
>> >> parent style DT.
>> >>
>> >> Best regards,
>> >> Martin
>> >>
>> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
>> >> wrote:
>> >>
>> >> > On Mon, 14 Nov 2022 22:44:49 +0100
>> >> > Martin Botka <martin.botka@somainline.org> wrote:
>> >> >
>> >> > > CB1 is Compute Module style board that plugs into Rpi board style
>> >> > adapter or
>> >> > > Manta 3D printer boards (M4P/M8P).
>> >> > >
>> >> > > The board has:
>> >> > > H616 SoC
>> >> > > 1GB of RAM
>> >> > > AXP313A PMIC
>> >> > >
>> >> > > And the actual boards that CB1 plugs in are just extension to it with
>> >> > ports and
>> >> > > thus are not split in DT.
>> >> >
>> >> > I don't really understand that sentence. There is some precedent for a
>> >> > SoM/board split, look at the sun50i-a64-sopine or
>> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
>> >> > there are *two* boards available for the same CB1 SoM, the PI4B and the
>> >> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
>> >> > or two board .dts files.
>> >> > I am just not sure whether that relation to the Pi4-CM is helpful or
>> >> > just complicates things...
>> >> >
>> >> > Cheers,
>> >> > Andre
>> >> >
>> >> > >
>> >> > > Boards have:
>> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> >> > > SDcard slot for loading images.
>> >> > > Ethernet port wired to the internal PHY.
>> >> > > 2x HDMI 2.0.
>> >> > > Power and Status LEDs.
>> >> > >
>> >> > > Currently working:
>> >> > > Booting
>> >> > > USB
>> >> > > UART
>> >> > >
>> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> >> > > ---
>> >> > > Changes in V2:
>> >> > > Add proper board compatible
>> >> > > Add regulator prefix for vcc5v
>> >> > > Drop okay status from PMIC
>> >> > > Drop standby_param
>> >> > > Changes in V3:
>> >> > > Change copyright to me
>> >> > > regulator_vcc5v to regulator-vcc5v
>> >> > > Drop ehci0 and ohci0
>> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
>> >> > > 2 files changed, 179 insertions(+)
>> >> > > create mode 100644
>> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> > >
>> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> > b/arch/arm64/boot/dts/allwinner/Makefile
>> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> > > new file mode 100644
>> >> > > index 000000000000..86b5aca9b53e
>> >> > > --- /dev/null
>> >> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> > > @@ -0,0 +1,178 @@
>> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> >> > > +/*
>> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> >> > > +
>> >> > > + aliases {
>> >> > > + serial0 = &uart0;
>> >> > > + };
>> >> > > +
>> >> > > + chosen {
>> >> > > + stdout-path = "serial0:115200n8";
>> >> > > + };
>> >> > > +
>> >> > > + leds {
>> >> > > + compatible = "gpio-leds";
>> >> > > +
>> >> > > + led-0 {
>> >> > > + function = LED_FUNCTION_POWER;
>> >> > > + color = <LED_COLOR_ID_RED>;
>> >> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
>> >> > > + default-state = "on";
>> >> > > + };
>> >> > > +
>> >> > > + led-1 {
>> >> > > + function = LED_FUNCTION_STATUS;
>> >> > > + color = <LED_COLOR_ID_GREEN>;
>> >> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
>> >> > > + };
>> >> > > + };
>> >> > > +
>> >> > > + 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 = <®_vcc5v>;
>> >> > > + enable-active-high;
>> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>> >> > > + };
>> >> > > +};
>> >> > > +
>> >> > > +&ehci1 {
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&ehci2 {
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&ehci3 {
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&mmc0 {
>> >> > > + vmmc-supply = <®_dldo1>;
>> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> >> > > + no-1-8-v;
>> >> > > + bus-width = <4>;
>> >> > > + status = "disabled";
>> >> > > +};
>> >> > > +
>> >> > > +&ohci1 {
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&ohci2 {
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&ohci3 {
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&r_i2c {
>> >> > > + status = "okay";
>> >> > > +
>> >> > > + axp1530: pmic@36 {
>> >> > > + compatible = "x-powers,axp1530";
>> >> > > + reg = <0x36>;
>> >> > > + wakeup-source;
>> >> > > +
>> >> > > + regulators{
>> >> > > + reg_dcdc1: dcdc1 {
>> >> > > + regulator-name = "axp1530-dcdc1";
>> >> > > + regulator-min-microvolt = <500000>;
>> >> > > + regulator-max-microvolt = <3400000>;
>> >> > > + regulator-step-delay-us = <25>;
>> >> > > + regulator-final-delay-us = <50>;
>> >> > > + regulator-always-on;
>> >> > > + };
>> >> > > +
>> >> > > + reg_dcdc2: dcdc2 {
>> >> > > + regulator-name = "axp1530-dcdc2";
>> >> > > + regulator-min-microvolt = <500000>;
>> >> > > + regulator-max-microvolt = <1540000>;
>> >> > > + regulator-step-delay-us = <25>;
>> >> > > + regulator-final-delay-us = <50>;
>> >> > > + regulator-ramp-delay = <200>;
>> >> > > + regulator-always-on;
>> >> > > + };
>> >> > > +
>> >> > > + reg_dcdc3: dcdc3 {
>> >> > > + regulator-name = "axp1530-dcdc3";
>> >> > > + regulator-min-microvolt = <500000>;
>> >> > > + regulator-max-microvolt = <1840000>;
>> >> > > + regulator-step-delay-us = <25>;
>> >> > > + regulator-final-delay-us = <50>;
>> >> > > + regulator-always-on;
>> >> > > + };
>> >> > > +
>> >> > > + reg_aldo1: ldo1 {
>> >> > > + regulator-name = "axp1530-aldo1";
>> >> > > + regulator-min-microvolt = <1800000>;
>> >> > > + regulator-max-microvolt = <1800000>;
>> >> > > + regulator-step-delay-us = <25>;
>> >> > > + regulator-final-delay-us = <50>;
>> >> > > + regulator-always-on;
>> >> > > + };
>> >> > > +
>> >> > > + reg_dldo1: ldo2 {
>> >> > > + regulator-name = "axp1530-dldo1";
>> >> > > + regulator-min-microvolt = <3300000>;
>> >> > > + regulator-max-microvolt = <3300000>;
>> >> > > + regulator-step-delay-us = <25>;
>> >> > > + regulator-final-delay-us = <50>;
>> >> > > + regulator-always-on;
>> >> > > + };
>> >> > > + };
>> >> > > + };
>> >> > > +};
>> >> > > +
>> >> > > +&uart0 {
>> >> > > + pinctrl-names = "default";
>> >> > > + pinctrl-0 = <&uart0_ph_pins>;
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&usbotg {
>> >> > > + /*
>> >> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
>> >> > > + * is not implemented: both CC pins are pulled to GND.
>> >> > > + * The VBUS pins power the device, so a fixed peripheral mode
>> >> > > + * is the best choice.
>> >> > > + * The board can be powered via GPIOs, in this case port0 *can*
>> >> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
>> >> > > + * then provided by the GPIOs. Any user of this setup would
>> >> > > + * need to adjust the DT accordingly: dr_mode set to "host",
>> >> > > + * enabling OHCI0 and EHCI0.
>> >> > > + */
>> >> > > + dr_mode = "peripheral";
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&usbphy {
>> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> >> > > + status = "okay";
>> >> > > +};
>> >> >
>> >> >
>> >
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-15 11:38 ` Martin Botka
0 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 11:38 UTC (permalink / raw)
To: Andre Przywara
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>On Tue, 15 Nov 2022 09:24:04 +0100
>Martin Botka <martin.botka@somainline.org> wrote:
>
>Hi,
>
>> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>> >On Tue, 15 Nov 2022 00:44:46 +0100
>> >Martin Botka <martin.botka1@gmail.com> wrote:
>> >
>> >Hi Martin,
>> >
>> >> I can totally understand how this can get confusing.
>> >>
>> >> Basically because of the Rpi shortage biqu decided to make an Rpi
>> >> alternative.
>> >>
>> >> So they made CB1 which is compute module style board.
>> >>
>> >> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
>> >> boards are:
>> >>
>> >> Rpi adapter which takes the Compute module style boards and turns them into
>> >> SBC style with basically identical size and etc to Rpi 4.
>> >>
>> >> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
>> >> they were made for Klipper use case which requires a computer or SBC
>> >> (Usually Rpi4). They combined it into 1 board.
>> >> Where you get the MCU and you can plug in CM4 or CB1
>> >
>> >Thanks for the explanations! I was guessing along those shortage lines,
>> >since the H616 is quite a step down from the RPi4CM, though probably
>> >still enough for driving a 3D printer.
>> Mostly yes
>> >
>> >> All these boards are basically taking the pins and routing them to ports.
>> >
>> >Yes, this is what those SoM carrier boards do ;-)
>> :)
>> >
>> >> There is nearly 0 chips for conversion or processing of the pins from CB1
>> >> or CM4 thus i do not see a reason for having parent dtsi and dts for the
>> >> adapter and Manta boards.
>> >
>> >And the DT does not need to describe "chips" only, a lot of DT nodes
>> >are about connectors, and which ports and which exact pins (out of the
>> >possible pinmuxes) are actually used. The SoM itself mostly exposes
>> >just pins, and the board DT describes how these pins are used (GPIO or
>> >special function, for instance).
>> >
>> >So did you try to split this up? How would that look?
>>
>> The main difference between adapter and Manta boards is that adapter has 4x USB.
>
>So those are two double-type-A sockets? This is not really what the DT
>below describes? It's perfectly fine to fix USB0 to host mode, we do this
>on the Pine64 boards (both A64 and H6), for instance.
Yes. But the third and fourth is also used. Third is done in 2.54 4p connector (just pins on board) and fourth is connected directly to manta stm32 MCU. So all 4 are host.
>
>> Manta only has 3 and 1 otg. But it has a switch to disable or enable otg.
>
>What does the switch do, exactly? By definition OTG works fine in both
>ways. And there are pins in the connector to decide the role.
The switch is just signal pin for RS2227. Its the multiplexer i mentioned. It decides if we should have the pins wired to usb type C port or normally to stm32 MCU. Thats all it does.
>
>Allwinner actually goes one step further and provides a full HCI to the
>same PHY that the MUSB OTG controller is connected to, so you don't need
>to live with the sometimes limited performance of the MUSB host mode
>(which we drive without DMA). Not sure if that is the case or a problem on
>the RPi4.
>
>> Im not opposed to splitting it up. It is probably a good idea.
>> I dont see how to resolve that switch on manta boards tho.
>
>If the Manta board is (almost) a superset of the Pi4B, then you can
>include the latter from there. Look at sun50i-a64-pine64-lts.dts or
>sun50i-h6-pine-h64-model-b.dts for examples.
>
>Cheers,
>Andre.
>
Yep i will split it into SoM boards.
>> >> The only exception to conversion are the LEDs on the boards but since both
>> >> adapter and manta boards have them this yet again eliminates need for
>> >> parent style DT.
>> >>
>> >> Best regards,
>> >> Martin
>> >>
>> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
>> >> wrote:
>> >>
>> >> > On Mon, 14 Nov 2022 22:44:49 +0100
>> >> > Martin Botka <martin.botka@somainline.org> wrote:
>> >> >
>> >> > > CB1 is Compute Module style board that plugs into Rpi board style
>> >> > adapter or
>> >> > > Manta 3D printer boards (M4P/M8P).
>> >> > >
>> >> > > The board has:
>> >> > > H616 SoC
>> >> > > 1GB of RAM
>> >> > > AXP313A PMIC
>> >> > >
>> >> > > And the actual boards that CB1 plugs in are just extension to it with
>> >> > ports and
>> >> > > thus are not split in DT.
>> >> >
>> >> > I don't really understand that sentence. There is some precedent for a
>> >> > SoM/board split, look at the sun50i-a64-sopine or
>> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
>> >> > there are *two* boards available for the same CB1 SoM, the PI4B and the
>> >> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
>> >> > or two board .dts files.
>> >> > I am just not sure whether that relation to the Pi4-CM is helpful or
>> >> > just complicates things...
>> >> >
>> >> > Cheers,
>> >> > Andre
>> >> >
>> >> > >
>> >> > > Boards have:
>> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> >> > > SDcard slot for loading images.
>> >> > > Ethernet port wired to the internal PHY.
>> >> > > 2x HDMI 2.0.
>> >> > > Power and Status LEDs.
>> >> > >
>> >> > > Currently working:
>> >> > > Booting
>> >> > > USB
>> >> > > UART
>> >> > >
>> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> >> > > ---
>> >> > > Changes in V2:
>> >> > > Add proper board compatible
>> >> > > Add regulator prefix for vcc5v
>> >> > > Drop okay status from PMIC
>> >> > > Drop standby_param
>> >> > > Changes in V3:
>> >> > > Change copyright to me
>> >> > > regulator_vcc5v to regulator-vcc5v
>> >> > > Drop ehci0 and ohci0
>> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
>> >> > > 2 files changed, 179 insertions(+)
>> >> > > create mode 100644
>> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> > >
>> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> > b/arch/arm64/boot/dts/allwinner/Makefile
>> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> > > new file mode 100644
>> >> > > index 000000000000..86b5aca9b53e
>> >> > > --- /dev/null
>> >> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> > > @@ -0,0 +1,178 @@
>> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> >> > > +/*
>> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> >> > > +
>> >> > > + aliases {
>> >> > > + serial0 = &uart0;
>> >> > > + };
>> >> > > +
>> >> > > + chosen {
>> >> > > + stdout-path = "serial0:115200n8";
>> >> > > + };
>> >> > > +
>> >> > > + leds {
>> >> > > + compatible = "gpio-leds";
>> >> > > +
>> >> > > + led-0 {
>> >> > > + function = LED_FUNCTION_POWER;
>> >> > > + color = <LED_COLOR_ID_RED>;
>> >> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
>> >> > > + default-state = "on";
>> >> > > + };
>> >> > > +
>> >> > > + led-1 {
>> >> > > + function = LED_FUNCTION_STATUS;
>> >> > > + color = <LED_COLOR_ID_GREEN>;
>> >> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
>> >> > > + };
>> >> > > + };
>> >> > > +
>> >> > > + 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 = <®_vcc5v>;
>> >> > > + enable-active-high;
>> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>> >> > > + };
>> >> > > +};
>> >> > > +
>> >> > > +&ehci1 {
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&ehci2 {
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&ehci3 {
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&mmc0 {
>> >> > > + vmmc-supply = <®_dldo1>;
>> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> >> > > + no-1-8-v;
>> >> > > + bus-width = <4>;
>> >> > > + status = "disabled";
>> >> > > +};
>> >> > > +
>> >> > > +&ohci1 {
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&ohci2 {
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&ohci3 {
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&r_i2c {
>> >> > > + status = "okay";
>> >> > > +
>> >> > > + axp1530: pmic@36 {
>> >> > > + compatible = "x-powers,axp1530";
>> >> > > + reg = <0x36>;
>> >> > > + wakeup-source;
>> >> > > +
>> >> > > + regulators{
>> >> > > + reg_dcdc1: dcdc1 {
>> >> > > + regulator-name = "axp1530-dcdc1";
>> >> > > + regulator-min-microvolt = <500000>;
>> >> > > + regulator-max-microvolt = <3400000>;
>> >> > > + regulator-step-delay-us = <25>;
>> >> > > + regulator-final-delay-us = <50>;
>> >> > > + regulator-always-on;
>> >> > > + };
>> >> > > +
>> >> > > + reg_dcdc2: dcdc2 {
>> >> > > + regulator-name = "axp1530-dcdc2";
>> >> > > + regulator-min-microvolt = <500000>;
>> >> > > + regulator-max-microvolt = <1540000>;
>> >> > > + regulator-step-delay-us = <25>;
>> >> > > + regulator-final-delay-us = <50>;
>> >> > > + regulator-ramp-delay = <200>;
>> >> > > + regulator-always-on;
>> >> > > + };
>> >> > > +
>> >> > > + reg_dcdc3: dcdc3 {
>> >> > > + regulator-name = "axp1530-dcdc3";
>> >> > > + regulator-min-microvolt = <500000>;
>> >> > > + regulator-max-microvolt = <1840000>;
>> >> > > + regulator-step-delay-us = <25>;
>> >> > > + regulator-final-delay-us = <50>;
>> >> > > + regulator-always-on;
>> >> > > + };
>> >> > > +
>> >> > > + reg_aldo1: ldo1 {
>> >> > > + regulator-name = "axp1530-aldo1";
>> >> > > + regulator-min-microvolt = <1800000>;
>> >> > > + regulator-max-microvolt = <1800000>;
>> >> > > + regulator-step-delay-us = <25>;
>> >> > > + regulator-final-delay-us = <50>;
>> >> > > + regulator-always-on;
>> >> > > + };
>> >> > > +
>> >> > > + reg_dldo1: ldo2 {
>> >> > > + regulator-name = "axp1530-dldo1";
>> >> > > + regulator-min-microvolt = <3300000>;
>> >> > > + regulator-max-microvolt = <3300000>;
>> >> > > + regulator-step-delay-us = <25>;
>> >> > > + regulator-final-delay-us = <50>;
>> >> > > + regulator-always-on;
>> >> > > + };
>> >> > > + };
>> >> > > + };
>> >> > > +};
>> >> > > +
>> >> > > +&uart0 {
>> >> > > + pinctrl-names = "default";
>> >> > > + pinctrl-0 = <&uart0_ph_pins>;
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&usbotg {
>> >> > > + /*
>> >> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
>> >> > > + * is not implemented: both CC pins are pulled to GND.
>> >> > > + * The VBUS pins power the device, so a fixed peripheral mode
>> >> > > + * is the best choice.
>> >> > > + * The board can be powered via GPIOs, in this case port0 *can*
>> >> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
>> >> > > + * then provided by the GPIOs. Any user of this setup would
>> >> > > + * need to adjust the DT accordingly: dr_mode set to "host",
>> >> > > + * enabling OHCI0 and EHCI0.
>> >> > > + */
>> >> > > + dr_mode = "peripheral";
>> >> > > + status = "okay";
>> >> > > +};
>> >> > > +
>> >> > > +&usbphy {
>> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> >> > > + status = "okay";
>> >> > > +};
>> >> >
>> >> >
>> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-15 11:38 ` Martin Botka
@ 2022-11-15 14:27 ` Andre Przywara
-1 siblings, 0 replies; 38+ messages in thread
From: Andre Przywara @ 2022-11-15 14:27 UTC (permalink / raw)
To: Martin Botka
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On Tue, 15 Nov 2022 12:38:59 +0100
Martin Botka <martin.botka@somainline.org> wrote:
Hi Martin,
> On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
> >On Tue, 15 Nov 2022 09:24:04 +0100
> >Martin Botka <martin.botka@somainline.org> wrote:
> >
> >Hi,
> >
> >> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
> >> >On Tue, 15 Nov 2022 00:44:46 +0100
> >> >Martin Botka <martin.botka1@gmail.com> wrote:
> >> >
> >> >Hi Martin,
> >> >
> >> >> I can totally understand how this can get confusing.
> >> >>
> >> >> Basically because of the Rpi shortage biqu decided to make an Rpi
> >> >> alternative.
> >> >>
> >> >> So they made CB1 which is compute module style board.
> >> >>
> >> >> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
> >> >> boards are:
> >> >>
> >> >> Rpi adapter which takes the Compute module style boards and turns them into
> >> >> SBC style with basically identical size and etc to Rpi 4.
> >> >>
> >> >> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
> >> >> they were made for Klipper use case which requires a computer or SBC
> >> >> (Usually Rpi4). They combined it into 1 board.
> >> >> Where you get the MCU and you can plug in CM4 or CB1
> >> >
> >> >Thanks for the explanations! I was guessing along those shortage lines,
> >> >since the H616 is quite a step down from the RPi4CM, though probably
> >> >still enough for driving a 3D printer.
> >> Mostly yes
> >> >
> >> >> All these boards are basically taking the pins and routing them to ports.
> >> >
> >> >Yes, this is what those SoM carrier boards do ;-)
> >> :)
> >> >
> >> >> There is nearly 0 chips for conversion or processing of the pins from CB1
> >> >> or CM4 thus i do not see a reason for having parent dtsi and dts for the
> >> >> adapter and Manta boards.
> >> >
> >> >And the DT does not need to describe "chips" only, a lot of DT nodes
> >> >are about connectors, and which ports and which exact pins (out of the
> >> >possible pinmuxes) are actually used. The SoM itself mostly exposes
> >> >just pins, and the board DT describes how these pins are used (GPIO or
> >> >special function, for instance).
> >> >
> >> >So did you try to split this up? How would that look?
> >>
> >> The main difference between adapter and Manta boards is that adapter has 4x USB.
> >
> >So those are two double-type-A sockets? This is not really what the DT
> >below describes? It's perfectly fine to fix USB0 to host mode, we do this
> >on the Pine64 boards (both A64 and H6), for instance.
>
> Yes. But the third and fourth is also used. Third is done in 2.54 4p connector (just pins on board) and fourth is connected directly to manta stm32 MCU. So all 4 are host.
Wait, so you are talking about the Manta board now? I see two sockets, the
2.54mm headers and the STM32 there, but the Pi4B is quite different in
that respect: I see four(!) USB type-A sockets (two dual-port stacks).
Plus the CM4 connector seems to only have pins for one USB 2.0 port
(D-,D+). So is this a hub chip on the underside of the board, close to the
USB ports? Can you read the label of that chip?
And where are the other H616 USB pins routed to? Are they (ab-)using the
PCIe pins of the CM4 connector? Or are they actually not used at all, and
it's all one USB port through a by-4 hub?
If you have a running system, "lsusb -t" should give you a clue which host
ports are used and if there is a hub.
Cheers,
Andre
> >> Manta only has 3 and 1 otg. But it has a switch to disable or enable otg.
> >
> >What does the switch do, exactly? By definition OTG works fine in both
> >ways. And there are pins in the connector to decide the role.
> The switch is just signal pin for RS2227. Its the multiplexer i mentioned. It decides if we should have the pins wired to usb type C port or normally to stm32 MCU. Thats all it does.
> >
> >Allwinner actually goes one step further and provides a full HCI to the
> >same PHY that the MUSB OTG controller is connected to, so you don't need
> >to live with the sometimes limited performance of the MUSB host mode
> >(which we drive without DMA). Not sure if that is the case or a problem on
> >the RPi4.
> >
> >> Im not opposed to splitting it up. It is probably a good idea.
> >> I dont see how to resolve that switch on manta boards tho.
> >
> >If the Manta board is (almost) a superset of the Pi4B, then you can
> >include the latter from there. Look at sun50i-a64-pine64-lts.dts or
> >sun50i-h6-pine-h64-model-b.dts for examples.
> >
> >Cheers,
> >Andre.
> >
> Yep i will split it into SoM boards.
> >> >> The only exception to conversion are the LEDs on the boards but since both
> >> >> adapter and manta boards have them this yet again eliminates need for
> >> >> parent style DT.
> >> >>
> >> >> Best regards,
> >> >> Martin
> >> >>
> >> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
> >> >> wrote:
> >> >>
> >> >> > On Mon, 14 Nov 2022 22:44:49 +0100
> >> >> > Martin Botka <martin.botka@somainline.org> wrote:
> >> >> >
> >> >> > > CB1 is Compute Module style board that plugs into Rpi board style
> >> >> > adapter or
> >> >> > > Manta 3D printer boards (M4P/M8P).
> >> >> > >
> >> >> > > The board has:
> >> >> > > H616 SoC
> >> >> > > 1GB of RAM
> >> >> > > AXP313A PMIC
> >> >> > >
> >> >> > > And the actual boards that CB1 plugs in are just extension to it with
> >> >> > ports and
> >> >> > > thus are not split in DT.
> >> >> >
> >> >> > I don't really understand that sentence. There is some precedent for a
> >> >> > SoM/board split, look at the sun50i-a64-sopine or
> >> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
> >> >> > there are *two* boards available for the same CB1 SoM, the PI4B and the
> >> >> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
> >> >> > or two board .dts files.
> >> >> > I am just not sure whether that relation to the Pi4-CM is helpful or
> >> >> > just complicates things...
> >> >> >
> >> >> > Cheers,
> >> >> > Andre
> >> >> >
> >> >> > >
> >> >> > > Boards have:
> >> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
> >> >> > > SDcard slot for loading images.
> >> >> > > Ethernet port wired to the internal PHY.
> >> >> > > 2x HDMI 2.0.
> >> >> > > Power and Status LEDs.
> >> >> > >
> >> >> > > Currently working:
> >> >> > > Booting
> >> >> > > USB
> >> >> > > UART
> >> >> > >
> >> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
> >> >> > > ---
> >> >> > > Changes in V2:
> >> >> > > Add proper board compatible
> >> >> > > Add regulator prefix for vcc5v
> >> >> > > Drop okay status from PMIC
> >> >> > > Drop standby_param
> >> >> > > Changes in V3:
> >> >> > > Change copyright to me
> >> >> > > regulator_vcc5v to regulator-vcc5v
> >> >> > > Drop ehci0 and ohci0
> >> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> >> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
> >> >> > > 2 files changed, 179 insertions(+)
> >> >> > > create mode 100644
> >> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> >> > >
> >> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> >> >> > b/arch/arm64/boot/dts/allwinner/Makefile
> >> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
> >> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> >> > > new file mode 100644
> >> >> > > index 000000000000..86b5aca9b53e
> >> >> > > --- /dev/null
> >> >> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> >> > > @@ -0,0 +1,178 @@
> >> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> >> >> > > +/*
> >> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
> >> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> >> >> > > +
> >> >> > > + aliases {
> >> >> > > + serial0 = &uart0;
> >> >> > > + };
> >> >> > > +
> >> >> > > + chosen {
> >> >> > > + stdout-path = "serial0:115200n8";
> >> >> > > + };
> >> >> > > +
> >> >> > > + leds {
> >> >> > > + compatible = "gpio-leds";
> >> >> > > +
> >> >> > > + led-0 {
> >> >> > > + function = LED_FUNCTION_POWER;
> >> >> > > + color = <LED_COLOR_ID_RED>;
> >> >> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
> >> >> > > + default-state = "on";
> >> >> > > + };
> >> >> > > +
> >> >> > > + led-1 {
> >> >> > > + function = LED_FUNCTION_STATUS;
> >> >> > > + color = <LED_COLOR_ID_GREEN>;
> >> >> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
> >> >> > > + };
> >> >> > > + };
> >> >> > > +
> >> >> > > + 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 = <®_vcc5v>;
> >> >> > > + enable-active-high;
> >> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> >> >> > > + };
> >> >> > > +};
> >> >> > > +
> >> >> > > +&ehci1 {
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&ehci2 {
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&ehci3 {
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&mmc0 {
> >> >> > > + vmmc-supply = <®_dldo1>;
> >> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> >> >> > > + no-1-8-v;
> >> >> > > + bus-width = <4>;
> >> >> > > + status = "disabled";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&ohci1 {
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&ohci2 {
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&ohci3 {
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&r_i2c {
> >> >> > > + status = "okay";
> >> >> > > +
> >> >> > > + axp1530: pmic@36 {
> >> >> > > + compatible = "x-powers,axp1530";
> >> >> > > + reg = <0x36>;
> >> >> > > + wakeup-source;
> >> >> > > +
> >> >> > > + regulators{
> >> >> > > + reg_dcdc1: dcdc1 {
> >> >> > > + regulator-name = "axp1530-dcdc1";
> >> >> > > + regulator-min-microvolt = <500000>;
> >> >> > > + regulator-max-microvolt = <3400000>;
> >> >> > > + regulator-step-delay-us = <25>;
> >> >> > > + regulator-final-delay-us = <50>;
> >> >> > > + regulator-always-on;
> >> >> > > + };
> >> >> > > +
> >> >> > > + reg_dcdc2: dcdc2 {
> >> >> > > + regulator-name = "axp1530-dcdc2";
> >> >> > > + regulator-min-microvolt = <500000>;
> >> >> > > + regulator-max-microvolt = <1540000>;
> >> >> > > + regulator-step-delay-us = <25>;
> >> >> > > + regulator-final-delay-us = <50>;
> >> >> > > + regulator-ramp-delay = <200>;
> >> >> > > + regulator-always-on;
> >> >> > > + };
> >> >> > > +
> >> >> > > + reg_dcdc3: dcdc3 {
> >> >> > > + regulator-name = "axp1530-dcdc3";
> >> >> > > + regulator-min-microvolt = <500000>;
> >> >> > > + regulator-max-microvolt = <1840000>;
> >> >> > > + regulator-step-delay-us = <25>;
> >> >> > > + regulator-final-delay-us = <50>;
> >> >> > > + regulator-always-on;
> >> >> > > + };
> >> >> > > +
> >> >> > > + reg_aldo1: ldo1 {
> >> >> > > + regulator-name = "axp1530-aldo1";
> >> >> > > + regulator-min-microvolt = <1800000>;
> >> >> > > + regulator-max-microvolt = <1800000>;
> >> >> > > + regulator-step-delay-us = <25>;
> >> >> > > + regulator-final-delay-us = <50>;
> >> >> > > + regulator-always-on;
> >> >> > > + };
> >> >> > > +
> >> >> > > + reg_dldo1: ldo2 {
> >> >> > > + regulator-name = "axp1530-dldo1";
> >> >> > > + regulator-min-microvolt = <3300000>;
> >> >> > > + regulator-max-microvolt = <3300000>;
> >> >> > > + regulator-step-delay-us = <25>;
> >> >> > > + regulator-final-delay-us = <50>;
> >> >> > > + regulator-always-on;
> >> >> > > + };
> >> >> > > + };
> >> >> > > + };
> >> >> > > +};
> >> >> > > +
> >> >> > > +&uart0 {
> >> >> > > + pinctrl-names = "default";
> >> >> > > + pinctrl-0 = <&uart0_ph_pins>;
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&usbotg {
> >> >> > > + /*
> >> >> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
> >> >> > > + * is not implemented: both CC pins are pulled to GND.
> >> >> > > + * The VBUS pins power the device, so a fixed peripheral mode
> >> >> > > + * is the best choice.
> >> >> > > + * The board can be powered via GPIOs, in this case port0 *can*
> >> >> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
> >> >> > > + * then provided by the GPIOs. Any user of this setup would
> >> >> > > + * need to adjust the DT accordingly: dr_mode set to "host",
> >> >> > > + * enabling OHCI0 and EHCI0.
> >> >> > > + */
> >> >> > > + dr_mode = "peripheral";
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&usbphy {
> >> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> >
> >> >> >
> >> >
> >
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-15 14:27 ` Andre Przywara
0 siblings, 0 replies; 38+ messages in thread
From: Andre Przywara @ 2022-11-15 14:27 UTC (permalink / raw)
To: Martin Botka
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On Tue, 15 Nov 2022 12:38:59 +0100
Martin Botka <martin.botka@somainline.org> wrote:
Hi Martin,
> On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
> >On Tue, 15 Nov 2022 09:24:04 +0100
> >Martin Botka <martin.botka@somainline.org> wrote:
> >
> >Hi,
> >
> >> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
> >> >On Tue, 15 Nov 2022 00:44:46 +0100
> >> >Martin Botka <martin.botka1@gmail.com> wrote:
> >> >
> >> >Hi Martin,
> >> >
> >> >> I can totally understand how this can get confusing.
> >> >>
> >> >> Basically because of the Rpi shortage biqu decided to make an Rpi
> >> >> alternative.
> >> >>
> >> >> So they made CB1 which is compute module style board.
> >> >>
> >> >> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
> >> >> boards are:
> >> >>
> >> >> Rpi adapter which takes the Compute module style boards and turns them into
> >> >> SBC style with basically identical size and etc to Rpi 4.
> >> >>
> >> >> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
> >> >> they were made for Klipper use case which requires a computer or SBC
> >> >> (Usually Rpi4). They combined it into 1 board.
> >> >> Where you get the MCU and you can plug in CM4 or CB1
> >> >
> >> >Thanks for the explanations! I was guessing along those shortage lines,
> >> >since the H616 is quite a step down from the RPi4CM, though probably
> >> >still enough for driving a 3D printer.
> >> Mostly yes
> >> >
> >> >> All these boards are basically taking the pins and routing them to ports.
> >> >
> >> >Yes, this is what those SoM carrier boards do ;-)
> >> :)
> >> >
> >> >> There is nearly 0 chips for conversion or processing of the pins from CB1
> >> >> or CM4 thus i do not see a reason for having parent dtsi and dts for the
> >> >> adapter and Manta boards.
> >> >
> >> >And the DT does not need to describe "chips" only, a lot of DT nodes
> >> >are about connectors, and which ports and which exact pins (out of the
> >> >possible pinmuxes) are actually used. The SoM itself mostly exposes
> >> >just pins, and the board DT describes how these pins are used (GPIO or
> >> >special function, for instance).
> >> >
> >> >So did you try to split this up? How would that look?
> >>
> >> The main difference between adapter and Manta boards is that adapter has 4x USB.
> >
> >So those are two double-type-A sockets? This is not really what the DT
> >below describes? It's perfectly fine to fix USB0 to host mode, we do this
> >on the Pine64 boards (both A64 and H6), for instance.
>
> Yes. But the third and fourth is also used. Third is done in 2.54 4p connector (just pins on board) and fourth is connected directly to manta stm32 MCU. So all 4 are host.
Wait, so you are talking about the Manta board now? I see two sockets, the
2.54mm headers and the STM32 there, but the Pi4B is quite different in
that respect: I see four(!) USB type-A sockets (two dual-port stacks).
Plus the CM4 connector seems to only have pins for one USB 2.0 port
(D-,D+). So is this a hub chip on the underside of the board, close to the
USB ports? Can you read the label of that chip?
And where are the other H616 USB pins routed to? Are they (ab-)using the
PCIe pins of the CM4 connector? Or are they actually not used at all, and
it's all one USB port through a by-4 hub?
If you have a running system, "lsusb -t" should give you a clue which host
ports are used and if there is a hub.
Cheers,
Andre
> >> Manta only has 3 and 1 otg. But it has a switch to disable or enable otg.
> >
> >What does the switch do, exactly? By definition OTG works fine in both
> >ways. And there are pins in the connector to decide the role.
> The switch is just signal pin for RS2227. Its the multiplexer i mentioned. It decides if we should have the pins wired to usb type C port or normally to stm32 MCU. Thats all it does.
> >
> >Allwinner actually goes one step further and provides a full HCI to the
> >same PHY that the MUSB OTG controller is connected to, so you don't need
> >to live with the sometimes limited performance of the MUSB host mode
> >(which we drive without DMA). Not sure if that is the case or a problem on
> >the RPi4.
> >
> >> Im not opposed to splitting it up. It is probably a good idea.
> >> I dont see how to resolve that switch on manta boards tho.
> >
> >If the Manta board is (almost) a superset of the Pi4B, then you can
> >include the latter from there. Look at sun50i-a64-pine64-lts.dts or
> >sun50i-h6-pine-h64-model-b.dts for examples.
> >
> >Cheers,
> >Andre.
> >
> Yep i will split it into SoM boards.
> >> >> The only exception to conversion are the LEDs on the boards but since both
> >> >> adapter and manta boards have them this yet again eliminates need for
> >> >> parent style DT.
> >> >>
> >> >> Best regards,
> >> >> Martin
> >> >>
> >> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
> >> >> wrote:
> >> >>
> >> >> > On Mon, 14 Nov 2022 22:44:49 +0100
> >> >> > Martin Botka <martin.botka@somainline.org> wrote:
> >> >> >
> >> >> > > CB1 is Compute Module style board that plugs into Rpi board style
> >> >> > adapter or
> >> >> > > Manta 3D printer boards (M4P/M8P).
> >> >> > >
> >> >> > > The board has:
> >> >> > > H616 SoC
> >> >> > > 1GB of RAM
> >> >> > > AXP313A PMIC
> >> >> > >
> >> >> > > And the actual boards that CB1 plugs in are just extension to it with
> >> >> > ports and
> >> >> > > thus are not split in DT.
> >> >> >
> >> >> > I don't really understand that sentence. There is some precedent for a
> >> >> > SoM/board split, look at the sun50i-a64-sopine or
> >> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
> >> >> > there are *two* boards available for the same CB1 SoM, the PI4B and the
> >> >> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
> >> >> > or two board .dts files.
> >> >> > I am just not sure whether that relation to the Pi4-CM is helpful or
> >> >> > just complicates things...
> >> >> >
> >> >> > Cheers,
> >> >> > Andre
> >> >> >
> >> >> > >
> >> >> > > Boards have:
> >> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
> >> >> > > SDcard slot for loading images.
> >> >> > > Ethernet port wired to the internal PHY.
> >> >> > > 2x HDMI 2.0.
> >> >> > > Power and Status LEDs.
> >> >> > >
> >> >> > > Currently working:
> >> >> > > Booting
> >> >> > > USB
> >> >> > > UART
> >> >> > >
> >> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
> >> >> > > ---
> >> >> > > Changes in V2:
> >> >> > > Add proper board compatible
> >> >> > > Add regulator prefix for vcc5v
> >> >> > > Drop okay status from PMIC
> >> >> > > Drop standby_param
> >> >> > > Changes in V3:
> >> >> > > Change copyright to me
> >> >> > > regulator_vcc5v to regulator-vcc5v
> >> >> > > Drop ehci0 and ohci0
> >> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> >> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
> >> >> > > 2 files changed, 179 insertions(+)
> >> >> > > create mode 100644
> >> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> >> > >
> >> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> >> >> > b/arch/arm64/boot/dts/allwinner/Makefile
> >> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
> >> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> >> > > new file mode 100644
> >> >> > > index 000000000000..86b5aca9b53e
> >> >> > > --- /dev/null
> >> >> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> >> > > @@ -0,0 +1,178 @@
> >> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> >> >> > > +/*
> >> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
> >> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> >> >> > > +
> >> >> > > + aliases {
> >> >> > > + serial0 = &uart0;
> >> >> > > + };
> >> >> > > +
> >> >> > > + chosen {
> >> >> > > + stdout-path = "serial0:115200n8";
> >> >> > > + };
> >> >> > > +
> >> >> > > + leds {
> >> >> > > + compatible = "gpio-leds";
> >> >> > > +
> >> >> > > + led-0 {
> >> >> > > + function = LED_FUNCTION_POWER;
> >> >> > > + color = <LED_COLOR_ID_RED>;
> >> >> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
> >> >> > > + default-state = "on";
> >> >> > > + };
> >> >> > > +
> >> >> > > + led-1 {
> >> >> > > + function = LED_FUNCTION_STATUS;
> >> >> > > + color = <LED_COLOR_ID_GREEN>;
> >> >> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
> >> >> > > + };
> >> >> > > + };
> >> >> > > +
> >> >> > > + 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 = <®_vcc5v>;
> >> >> > > + enable-active-high;
> >> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> >> >> > > + };
> >> >> > > +};
> >> >> > > +
> >> >> > > +&ehci1 {
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&ehci2 {
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&ehci3 {
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&mmc0 {
> >> >> > > + vmmc-supply = <®_dldo1>;
> >> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> >> >> > > + no-1-8-v;
> >> >> > > + bus-width = <4>;
> >> >> > > + status = "disabled";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&ohci1 {
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&ohci2 {
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&ohci3 {
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&r_i2c {
> >> >> > > + status = "okay";
> >> >> > > +
> >> >> > > + axp1530: pmic@36 {
> >> >> > > + compatible = "x-powers,axp1530";
> >> >> > > + reg = <0x36>;
> >> >> > > + wakeup-source;
> >> >> > > +
> >> >> > > + regulators{
> >> >> > > + reg_dcdc1: dcdc1 {
> >> >> > > + regulator-name = "axp1530-dcdc1";
> >> >> > > + regulator-min-microvolt = <500000>;
> >> >> > > + regulator-max-microvolt = <3400000>;
> >> >> > > + regulator-step-delay-us = <25>;
> >> >> > > + regulator-final-delay-us = <50>;
> >> >> > > + regulator-always-on;
> >> >> > > + };
> >> >> > > +
> >> >> > > + reg_dcdc2: dcdc2 {
> >> >> > > + regulator-name = "axp1530-dcdc2";
> >> >> > > + regulator-min-microvolt = <500000>;
> >> >> > > + regulator-max-microvolt = <1540000>;
> >> >> > > + regulator-step-delay-us = <25>;
> >> >> > > + regulator-final-delay-us = <50>;
> >> >> > > + regulator-ramp-delay = <200>;
> >> >> > > + regulator-always-on;
> >> >> > > + };
> >> >> > > +
> >> >> > > + reg_dcdc3: dcdc3 {
> >> >> > > + regulator-name = "axp1530-dcdc3";
> >> >> > > + regulator-min-microvolt = <500000>;
> >> >> > > + regulator-max-microvolt = <1840000>;
> >> >> > > + regulator-step-delay-us = <25>;
> >> >> > > + regulator-final-delay-us = <50>;
> >> >> > > + regulator-always-on;
> >> >> > > + };
> >> >> > > +
> >> >> > > + reg_aldo1: ldo1 {
> >> >> > > + regulator-name = "axp1530-aldo1";
> >> >> > > + regulator-min-microvolt = <1800000>;
> >> >> > > + regulator-max-microvolt = <1800000>;
> >> >> > > + regulator-step-delay-us = <25>;
> >> >> > > + regulator-final-delay-us = <50>;
> >> >> > > + regulator-always-on;
> >> >> > > + };
> >> >> > > +
> >> >> > > + reg_dldo1: ldo2 {
> >> >> > > + regulator-name = "axp1530-dldo1";
> >> >> > > + regulator-min-microvolt = <3300000>;
> >> >> > > + regulator-max-microvolt = <3300000>;
> >> >> > > + regulator-step-delay-us = <25>;
> >> >> > > + regulator-final-delay-us = <50>;
> >> >> > > + regulator-always-on;
> >> >> > > + };
> >> >> > > + };
> >> >> > > + };
> >> >> > > +};
> >> >> > > +
> >> >> > > +&uart0 {
> >> >> > > + pinctrl-names = "default";
> >> >> > > + pinctrl-0 = <&uart0_ph_pins>;
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&usbotg {
> >> >> > > + /*
> >> >> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
> >> >> > > + * is not implemented: both CC pins are pulled to GND.
> >> >> > > + * The VBUS pins power the device, so a fixed peripheral mode
> >> >> > > + * is the best choice.
> >> >> > > + * The board can be powered via GPIOs, in this case port0 *can*
> >> >> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
> >> >> > > + * then provided by the GPIOs. Any user of this setup would
> >> >> > > + * need to adjust the DT accordingly: dr_mode set to "host",
> >> >> > > + * enabling OHCI0 and EHCI0.
> >> >> > > + */
> >> >> > > + dr_mode = "peripheral";
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > +&usbphy {
> >> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> >
> >> >> >
> >> >
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-15 14:27 ` Andre Przywara
@ 2022-11-15 14:48 ` Martin Botka
-1 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 14:48 UTC (permalink / raw)
To: Andre Przywara
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On November 15, 2022 3:27:14 PM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>On Tue, 15 Nov 2022 12:38:59 +0100
>Martin Botka <martin.botka@somainline.org> wrote:
>
>Hi Martin,
>
>> On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>> >On Tue, 15 Nov 2022 09:24:04 +0100
>> >Martin Botka <martin.botka@somainline.org> wrote:
>> >
>> >Hi,
>> >
>> >> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>> >> >On Tue, 15 Nov 2022 00:44:46 +0100
>> >> >Martin Botka <martin.botka1@gmail.com> wrote:
>> >> >
>> >> >Hi Martin,
>> >> >
>> >> >> I can totally understand how this can get confusing.
>> >> >>
>> >> >> Basically because of the Rpi shortage biqu decided to make an Rpi
>> >> >> alternative.
>> >> >>
>> >> >> So they made CB1 which is compute module style board.
>> >> >>
>> >> >> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
>> >> >> boards are:
>> >> >>
>> >> >> Rpi adapter which takes the Compute module style boards and turns them into
>> >> >> SBC style with basically identical size and etc to Rpi 4.
>> >> >>
>> >> >> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
>> >> >> they were made for Klipper use case which requires a computer or SBC
>> >> >> (Usually Rpi4). They combined it into 1 board.
>> >> >> Where you get the MCU and you can plug in CM4 or CB1
>> >> >
>> >> >Thanks for the explanations! I was guessing along those shortage lines,
>> >> >since the H616 is quite a step down from the RPi4CM, though probably
>> >> >still enough for driving a 3D printer.
>> >> Mostly yes
>> >> >
>> >> >> All these boards are basically taking the pins and routing them to ports.
>> >> >
>> >> >Yes, this is what those SoM carrier boards do ;-)
>> >> :)
>> >> >
>> >> >> There is nearly 0 chips for conversion or processing of the pins from CB1
>> >> >> or CM4 thus i do not see a reason for having parent dtsi and dts for the
>> >> >> adapter and Manta boards.
>> >> >
>> >> >And the DT does not need to describe "chips" only, a lot of DT nodes
>> >> >are about connectors, and which ports and which exact pins (out of the
>> >> >possible pinmuxes) are actually used. The SoM itself mostly exposes
>> >> >just pins, and the board DT describes how these pins are used (GPIO or
>> >> >special function, for instance).
>> >> >
>> >> >So did you try to split this up? How would that look?
>> >>
>> >> The main difference between adapter and Manta boards is that adapter has 4x USB.
>> >
>> >So those are two double-type-A sockets? This is not really what the DT
>> >below describes? It's perfectly fine to fix USB0 to host mode, we do this
>> >on the Pine64 boards (both A64 and H6), for instance.
>>
>> Yes. But the third and fourth is also used. Third is done in 2.54 4p connector (just pins on board) and fourth is connected directly to manta stm32 MCU. So all 4 are host.
>
>Wait, so you are talking about the Manta board now? I see two sockets, the
>2.54mm headers and the STM32 there, but the Pi4B is quite different in
>that respect: I see four(!) USB type-A sockets (two dual-port stacks).
>Plus the CM4 connector seems to only have pins for one USB 2.0 port
>(D-,D+). So is this a hub chip on the underside of the board, close to the
>USB ports? Can you read the label of that chip?
>And where are the other H616 USB pins routed to? Are they (ab-)using the
>PCIe pins of the CM4 connector? Or are they actually not used at all, and
>it's all one USB port through a by-4 hub?
>If you have a running system, "lsusb -t" should give you a clue which host
>ports are used and if there is a hub.
>
>Cheers,
>Andre
Hi Andre,
I do not own Rpi 4 adapter.
I can only check on Manta M8P as thats what BIQU provided. But it will be the same there probably.
I asked biqu to provide full schematic for the CB1 but didnt get a reply yet.
I will reply after i get home with the details
Best regards,
Martin
>
>> >> Manta only has 3 and 1 otg. But it has a switch to disable or enable otg.
>> >
>> >What does the switch do, exactly? By definition OTG works fine in both
>> >ways. And there are pins in the connector to decide the role.
>> The switch is just signal pin for RS2227. Its the multiplexer i mentioned. It decides if we should have the pins wired to usb type C port or normally to stm32 MCU. Thats all it does.
>> >
>> >Allwinner actually goes one step further and provides a full HCI to the
>> >same PHY that the MUSB OTG controller is connected to, so you don't need
>> >to live with the sometimes limited performance of the MUSB host mode
>> >(which we drive without DMA). Not sure if that is the case or a problem on
>> >the RPi4.
>> >
>> >> Im not opposed to splitting it up. It is probably a good idea.
>> >> I dont see how to resolve that switch on manta boards tho.
>> >
>> >If the Manta board is (almost) a superset of the Pi4B, then you can
>> >include the latter from there. Look at sun50i-a64-pine64-lts.dts or
>> >sun50i-h6-pine-h64-model-b.dts for examples.
>> >
>> >Cheers,
>> >Andre.
>> >
>> Yep i will split it into SoM boards.
>> >> >> The only exception to conversion are the LEDs on the boards but since both
>> >> >> adapter and manta boards have them this yet again eliminates need for
>> >> >> parent style DT.
>> >> >>
>> >> >> Best regards,
>> >> >> Martin
>> >> >>
>> >> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
>> >> >> wrote:
>> >> >>
>> >> >> > On Mon, 14 Nov 2022 22:44:49 +0100
>> >> >> > Martin Botka <martin.botka@somainline.org> wrote:
>> >> >> >
>> >> >> > > CB1 is Compute Module style board that plugs into Rpi board style
>> >> >> > adapter or
>> >> >> > > Manta 3D printer boards (M4P/M8P).
>> >> >> > >
>> >> >> > > The board has:
>> >> >> > > H616 SoC
>> >> >> > > 1GB of RAM
>> >> >> > > AXP313A PMIC
>> >> >> > >
>> >> >> > > And the actual boards that CB1 plugs in are just extension to it with
>> >> >> > ports and
>> >> >> > > thus are not split in DT.
>> >> >> >
>> >> >> > I don't really understand that sentence. There is some precedent for a
>> >> >> > SoM/board split, look at the sun50i-a64-sopine or
>> >> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
>> >> >> > there are *two* boards available for the same CB1 SoM, the PI4B and the
>> >> >> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
>> >> >> > or two board .dts files.
>> >> >> > I am just not sure whether that relation to the Pi4-CM is helpful or
>> >> >> > just complicates things...
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Andre
>> >> >> >
>> >> >> > >
>> >> >> > > Boards have:
>> >> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> >> >> > > SDcard slot for loading images.
>> >> >> > > Ethernet port wired to the internal PHY.
>> >> >> > > 2x HDMI 2.0.
>> >> >> > > Power and Status LEDs.
>> >> >> > >
>> >> >> > > Currently working:
>> >> >> > > Booting
>> >> >> > > USB
>> >> >> > > UART
>> >> >> > >
>> >> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> >> >> > > ---
>> >> >> > > Changes in V2:
>> >> >> > > Add proper board compatible
>> >> >> > > Add regulator prefix for vcc5v
>> >> >> > > Drop okay status from PMIC
>> >> >> > > Drop standby_param
>> >> >> > > Changes in V3:
>> >> >> > > Change copyright to me
>> >> >> > > regulator_vcc5v to regulator-vcc5v
>> >> >> > > Drop ehci0 and ohci0
>> >> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> >> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
>> >> >> > > 2 files changed, 179 insertions(+)
>> >> >> > > create mode 100644
>> >> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > >
>> >> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> > b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> >> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > > new file mode 100644
>> >> >> > > index 000000000000..86b5aca9b53e
>> >> >> > > --- /dev/null
>> >> >> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > > @@ -0,0 +1,178 @@
>> >> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> >> >> > > +/*
>> >> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> >> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> >> >> > > +
>> >> >> > > + aliases {
>> >> >> > > + serial0 = &uart0;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + chosen {
>> >> >> > > + stdout-path = "serial0:115200n8";
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + leds {
>> >> >> > > + compatible = "gpio-leds";
>> >> >> > > +
>> >> >> > > + led-0 {
>> >> >> > > + function = LED_FUNCTION_POWER;
>> >> >> > > + color = <LED_COLOR_ID_RED>;
>> >> >> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
>> >> >> > > + default-state = "on";
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + led-1 {
>> >> >> > > + function = LED_FUNCTION_STATUS;
>> >> >> > > + color = <LED_COLOR_ID_GREEN>;
>> >> >> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + 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 = <®_vcc5v>;
>> >> >> > > + enable-active-high;
>> >> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>> >> >> > > + };
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci1 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci2 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci3 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&mmc0 {
>> >> >> > > + vmmc-supply = <®_dldo1>;
>> >> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> >> >> > > + no-1-8-v;
>> >> >> > > + bus-width = <4>;
>> >> >> > > + status = "disabled";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci1 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci2 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci3 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&r_i2c {
>> >> >> > > + status = "okay";
>> >> >> > > +
>> >> >> > > + axp1530: pmic@36 {
>> >> >> > > + compatible = "x-powers,axp1530";
>> >> >> > > + reg = <0x36>;
>> >> >> > > + wakeup-source;
>> >> >> > > +
>> >> >> > > + regulators{
>> >> >> > > + reg_dcdc1: dcdc1 {
>> >> >> > > + regulator-name = "axp1530-dcdc1";
>> >> >> > > + regulator-min-microvolt = <500000>;
>> >> >> > > + regulator-max-microvolt = <3400000>;
>> >> >> > > + regulator-step-delay-us = <25>;
>> >> >> > > + regulator-final-delay-us = <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dcdc2: dcdc2 {
>> >> >> > > + regulator-name = "axp1530-dcdc2";
>> >> >> > > + regulator-min-microvolt = <500000>;
>> >> >> > > + regulator-max-microvolt = <1540000>;
>> >> >> > > + regulator-step-delay-us = <25>;
>> >> >> > > + regulator-final-delay-us = <50>;
>> >> >> > > + regulator-ramp-delay = <200>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dcdc3: dcdc3 {
>> >> >> > > + regulator-name = "axp1530-dcdc3";
>> >> >> > > + regulator-min-microvolt = <500000>;
>> >> >> > > + regulator-max-microvolt = <1840000>;
>> >> >> > > + regulator-step-delay-us = <25>;
>> >> >> > > + regulator-final-delay-us = <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_aldo1: ldo1 {
>> >> >> > > + regulator-name = "axp1530-aldo1";
>> >> >> > > + regulator-min-microvolt = <1800000>;
>> >> >> > > + regulator-max-microvolt = <1800000>;
>> >> >> > > + regulator-step-delay-us = <25>;
>> >> >> > > + regulator-final-delay-us = <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dldo1: ldo2 {
>> >> >> > > + regulator-name = "axp1530-dldo1";
>> >> >> > > + regulator-min-microvolt = <3300000>;
>> >> >> > > + regulator-max-microvolt = <3300000>;
>> >> >> > > + regulator-step-delay-us = <25>;
>> >> >> > > + regulator-final-delay-us = <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&uart0 {
>> >> >> > > + pinctrl-names = "default";
>> >> >> > > + pinctrl-0 = <&uart0_ph_pins>;
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&usbotg {
>> >> >> > > + /*
>> >> >> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
>> >> >> > > + * is not implemented: both CC pins are pulled to GND.
>> >> >> > > + * The VBUS pins power the device, so a fixed peripheral mode
>> >> >> > > + * is the best choice.
>> >> >> > > + * The board can be powered via GPIOs, in this case port0 *can*
>> >> >> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
>> >> >> > > + * then provided by the GPIOs. Any user of this setup would
>> >> >> > > + * need to adjust the DT accordingly: dr_mode set to "host",
>> >> >> > > + * enabling OHCI0 and EHCI0.
>> >> >> > > + */
>> >> >> > > + dr_mode = "peripheral";
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&usbphy {
>> >> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> >
>> >> >> >
>> >> >
>> >
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-15 14:48 ` Martin Botka
0 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 14:48 UTC (permalink / raw)
To: Andre Przywara
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On November 15, 2022 3:27:14 PM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>On Tue, 15 Nov 2022 12:38:59 +0100
>Martin Botka <martin.botka@somainline.org> wrote:
>
>Hi Martin,
>
>> On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>> >On Tue, 15 Nov 2022 09:24:04 +0100
>> >Martin Botka <martin.botka@somainline.org> wrote:
>> >
>> >Hi,
>> >
>> >> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>> >> >On Tue, 15 Nov 2022 00:44:46 +0100
>> >> >Martin Botka <martin.botka1@gmail.com> wrote:
>> >> >
>> >> >Hi Martin,
>> >> >
>> >> >> I can totally understand how this can get confusing.
>> >> >>
>> >> >> Basically because of the Rpi shortage biqu decided to make an Rpi
>> >> >> alternative.
>> >> >>
>> >> >> So they made CB1 which is compute module style board.
>> >> >>
>> >> >> And they made 3 other boards where CB1 or Rpi CM4 can be plugged in. The 3
>> >> >> boards are:
>> >> >>
>> >> >> Rpi adapter which takes the Compute module style boards and turns them into
>> >> >> SBC style with basically identical size and etc to Rpi 4.
>> >> >>
>> >> >> Then we have Manta M8P and M4P. These boards are MCUs for a 3D printer. But
>> >> >> they were made for Klipper use case which requires a computer or SBC
>> >> >> (Usually Rpi4). They combined it into 1 board.
>> >> >> Where you get the MCU and you can plug in CM4 or CB1
>> >> >
>> >> >Thanks for the explanations! I was guessing along those shortage lines,
>> >> >since the H616 is quite a step down from the RPi4CM, though probably
>> >> >still enough for driving a 3D printer.
>> >> Mostly yes
>> >> >
>> >> >> All these boards are basically taking the pins and routing them to ports.
>> >> >
>> >> >Yes, this is what those SoM carrier boards do ;-)
>> >> :)
>> >> >
>> >> >> There is nearly 0 chips for conversion or processing of the pins from CB1
>> >> >> or CM4 thus i do not see a reason for having parent dtsi and dts for the
>> >> >> adapter and Manta boards.
>> >> >
>> >> >And the DT does not need to describe "chips" only, a lot of DT nodes
>> >> >are about connectors, and which ports and which exact pins (out of the
>> >> >possible pinmuxes) are actually used. The SoM itself mostly exposes
>> >> >just pins, and the board DT describes how these pins are used (GPIO or
>> >> >special function, for instance).
>> >> >
>> >> >So did you try to split this up? How would that look?
>> >>
>> >> The main difference between adapter and Manta boards is that adapter has 4x USB.
>> >
>> >So those are two double-type-A sockets? This is not really what the DT
>> >below describes? It's perfectly fine to fix USB0 to host mode, we do this
>> >on the Pine64 boards (both A64 and H6), for instance.
>>
>> Yes. But the third and fourth is also used. Third is done in 2.54 4p connector (just pins on board) and fourth is connected directly to manta stm32 MCU. So all 4 are host.
>
>Wait, so you are talking about the Manta board now? I see two sockets, the
>2.54mm headers and the STM32 there, but the Pi4B is quite different in
>that respect: I see four(!) USB type-A sockets (two dual-port stacks).
>Plus the CM4 connector seems to only have pins for one USB 2.0 port
>(D-,D+). So is this a hub chip on the underside of the board, close to the
>USB ports? Can you read the label of that chip?
>And where are the other H616 USB pins routed to? Are they (ab-)using the
>PCIe pins of the CM4 connector? Or are they actually not used at all, and
>it's all one USB port through a by-4 hub?
>If you have a running system, "lsusb -t" should give you a clue which host
>ports are used and if there is a hub.
>
>Cheers,
>Andre
Hi Andre,
I do not own Rpi 4 adapter.
I can only check on Manta M8P as thats what BIQU provided. But it will be the same there probably.
I asked biqu to provide full schematic for the CB1 but didnt get a reply yet.
I will reply after i get home with the details
Best regards,
Martin
>
>> >> Manta only has 3 and 1 otg. But it has a switch to disable or enable otg.
>> >
>> >What does the switch do, exactly? By definition OTG works fine in both
>> >ways. And there are pins in the connector to decide the role.
>> The switch is just signal pin for RS2227. Its the multiplexer i mentioned. It decides if we should have the pins wired to usb type C port or normally to stm32 MCU. Thats all it does.
>> >
>> >Allwinner actually goes one step further and provides a full HCI to the
>> >same PHY that the MUSB OTG controller is connected to, so you don't need
>> >to live with the sometimes limited performance of the MUSB host mode
>> >(which we drive without DMA). Not sure if that is the case or a problem on
>> >the RPi4.
>> >
>> >> Im not opposed to splitting it up. It is probably a good idea.
>> >> I dont see how to resolve that switch on manta boards tho.
>> >
>> >If the Manta board is (almost) a superset of the Pi4B, then you can
>> >include the latter from there. Look at sun50i-a64-pine64-lts.dts or
>> >sun50i-h6-pine-h64-model-b.dts for examples.
>> >
>> >Cheers,
>> >Andre.
>> >
>> Yep i will split it into SoM boards.
>> >> >> The only exception to conversion are the LEDs on the boards but since both
>> >> >> adapter and manta boards have them this yet again eliminates need for
>> >> >> parent style DT.
>> >> >>
>> >> >> Best regards,
>> >> >> Martin
>> >> >>
>> >> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara <andre.przywara@arm.com>
>> >> >> wrote:
>> >> >>
>> >> >> > On Mon, 14 Nov 2022 22:44:49 +0100
>> >> >> > Martin Botka <martin.botka@somainline.org> wrote:
>> >> >> >
>> >> >> > > CB1 is Compute Module style board that plugs into Rpi board style
>> >> >> > adapter or
>> >> >> > > Manta 3D printer boards (M4P/M8P).
>> >> >> > >
>> >> >> > > The board has:
>> >> >> > > H616 SoC
>> >> >> > > 1GB of RAM
>> >> >> > > AXP313A PMIC
>> >> >> > >
>> >> >> > > And the actual boards that CB1 plugs in are just extension to it with
>> >> >> > ports and
>> >> >> > > thus are not split in DT.
>> >> >> >
>> >> >> > I don't really understand that sentence. There is some precedent for a
>> >> >> > SoM/board split, look at the sun50i-a64-sopine or
>> >> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this correctly, then
>> >> >> > there are *two* boards available for the same CB1 SoM, the PI4B and the
>> >> >> > Manta board? Which would a strong case for a SoM .dtsi, plus the one
>> >> >> > or two board .dts files.
>> >> >> > I am just not sure whether that relation to the Pi4-CM is helpful or
>> >> >> > just complicates things...
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Andre
>> >> >> >
>> >> >> > >
>> >> >> > > Boards have:
>> >> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> >> >> > > SDcard slot for loading images.
>> >> >> > > Ethernet port wired to the internal PHY.
>> >> >> > > 2x HDMI 2.0.
>> >> >> > > Power and Status LEDs.
>> >> >> > >
>> >> >> > > Currently working:
>> >> >> > > Booting
>> >> >> > > USB
>> >> >> > > UART
>> >> >> > >
>> >> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> >> >> > > ---
>> >> >> > > Changes in V2:
>> >> >> > > Add proper board compatible
>> >> >> > > Add regulator prefix for vcc5v
>> >> >> > > Drop okay status from PMIC
>> >> >> > > Drop standby_param
>> >> >> > > Changes in V3:
>> >> >> > > Change copyright to me
>> >> >> > > regulator_vcc5v to regulator-vcc5v
>> >> >> > > Drop ehci0 and ohci0
>> >> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> >> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 ++++++++++++++++++
>> >> >> > > 2 files changed, 179 insertions(+)
>> >> >> > > create mode 100644
>> >> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > >
>> >> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> > b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> >> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > > new file mode 100644
>> >> >> > > index 000000000000..86b5aca9b53e
>> >> >> > > --- /dev/null
>> >> >> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > > @@ -0,0 +1,178 @@
>> >> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> >> >> > > +/*
>> >> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> >> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> >> >> > > +
>> >> >> > > + aliases {
>> >> >> > > + serial0 = &uart0;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + chosen {
>> >> >> > > + stdout-path = "serial0:115200n8";
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + leds {
>> >> >> > > + compatible = "gpio-leds";
>> >> >> > > +
>> >> >> > > + led-0 {
>> >> >> > > + function = LED_FUNCTION_POWER;
>> >> >> > > + color = <LED_COLOR_ID_RED>;
>> >> >> > > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
>> >> >> > > + default-state = "on";
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + led-1 {
>> >> >> > > + function = LED_FUNCTION_STATUS;
>> >> >> > > + color = <LED_COLOR_ID_GREEN>;
>> >> >> > > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + 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 = <®_vcc5v>;
>> >> >> > > + enable-active-high;
>> >> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>> >> >> > > + };
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci1 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci2 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci3 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&mmc0 {
>> >> >> > > + vmmc-supply = <®_dldo1>;
>> >> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> >> >> > > + no-1-8-v;
>> >> >> > > + bus-width = <4>;
>> >> >> > > + status = "disabled";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci1 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci2 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci3 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&r_i2c {
>> >> >> > > + status = "okay";
>> >> >> > > +
>> >> >> > > + axp1530: pmic@36 {
>> >> >> > > + compatible = "x-powers,axp1530";
>> >> >> > > + reg = <0x36>;
>> >> >> > > + wakeup-source;
>> >> >> > > +
>> >> >> > > + regulators{
>> >> >> > > + reg_dcdc1: dcdc1 {
>> >> >> > > + regulator-name = "axp1530-dcdc1";
>> >> >> > > + regulator-min-microvolt = <500000>;
>> >> >> > > + regulator-max-microvolt = <3400000>;
>> >> >> > > + regulator-step-delay-us = <25>;
>> >> >> > > + regulator-final-delay-us = <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dcdc2: dcdc2 {
>> >> >> > > + regulator-name = "axp1530-dcdc2";
>> >> >> > > + regulator-min-microvolt = <500000>;
>> >> >> > > + regulator-max-microvolt = <1540000>;
>> >> >> > > + regulator-step-delay-us = <25>;
>> >> >> > > + regulator-final-delay-us = <50>;
>> >> >> > > + regulator-ramp-delay = <200>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dcdc3: dcdc3 {
>> >> >> > > + regulator-name = "axp1530-dcdc3";
>> >> >> > > + regulator-min-microvolt = <500000>;
>> >> >> > > + regulator-max-microvolt = <1840000>;
>> >> >> > > + regulator-step-delay-us = <25>;
>> >> >> > > + regulator-final-delay-us = <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_aldo1: ldo1 {
>> >> >> > > + regulator-name = "axp1530-aldo1";
>> >> >> > > + regulator-min-microvolt = <1800000>;
>> >> >> > > + regulator-max-microvolt = <1800000>;
>> >> >> > > + regulator-step-delay-us = <25>;
>> >> >> > > + regulator-final-delay-us = <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dldo1: ldo2 {
>> >> >> > > + regulator-name = "axp1530-dldo1";
>> >> >> > > + regulator-min-microvolt = <3300000>;
>> >> >> > > + regulator-max-microvolt = <3300000>;
>> >> >> > > + regulator-step-delay-us = <25>;
>> >> >> > > + regulator-final-delay-us = <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&uart0 {
>> >> >> > > + pinctrl-names = "default";
>> >> >> > > + pinctrl-0 = <&uart0_ph_pins>;
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&usbotg {
>> >> >> > > + /*
>> >> >> > > + * PHY0 pins are connected to a USB-C socket, but a role switch
>> >> >> > > + * is not implemented: both CC pins are pulled to GND.
>> >> >> > > + * The VBUS pins power the device, so a fixed peripheral mode
>> >> >> > > + * is the best choice.
>> >> >> > > + * The board can be powered via GPIOs, in this case port0 *can*
>> >> >> > > + * act as a host (with a cable/adapter ignoring CC), as VBUS is
>> >> >> > > + * then provided by the GPIOs. Any user of this setup would
>> >> >> > > + * need to adjust the DT accordingly: dr_mode set to "host",
>> >> >> > > + * enabling OHCI0 and EHCI0.
>> >> >> > > + */
>> >> >> > > + dr_mode = "peripheral";
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&usbphy {
>> >> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> >
>> >> >> >
>> >> >
>> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-15 14:27 ` Andre Przywara
@ 2022-11-15 16:31 ` Martin Botka
-1 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 16:31 UTC (permalink / raw)
To: Andre Przywara
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
Hi Andre,
Had a friend check on Rpi Adapter board for me. I dont exactly
like how they designed the board but what can we do.
USB works like this:
There is RS2229 which has USB2 connected to it and Type C.
RS2229 takes signal from the usbotg switch
The USB2 is then put to a hub via F1.s USB2.0 hub which then
goes to the 4 USB A ports.
This is basically the same as manta boards just that manta
boards have 1 USB always connected to the MCU. 2 are USB A
and 1 is 2.54mm 4P connector.
So all in all DT between Rpi adapter and Manta boards would
be identical.
So Andre what do you think about having the Rpi adapter and Manta
in single DT which would include the CB1 DTSI.
This way we dont have to differenciate between them as they are
quite literally identical as for ports and how they are wired.
It seems to be USB2 that is actually connected.
As for where the rest is wired.
From what i can see in downstream image and trough lsusb
nowhere. They are left alone...
Best Regards,
Martin
On Tue, Nov 15 2022 at 02:27:14 PM +00:00:00, Andre Przywara
<andre.przywara@arm.com> wrote:
> On Tue, 15 Nov 2022 12:38:59 +0100
> Martin Botka <martin.botka@somainline.org> wrote:
>
> Hi Martin,
>
>> On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara
>> <andre.przywara@arm.com> wrote:
>> >On Tue, 15 Nov 2022 09:24:04 +0100
>> >Martin Botka <martin.botka@somainline.org> wrote:
>> >
>> >Hi,
>> >
>> >> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara
>> <andre.przywara@arm.com> wrote:
>> >> >On Tue, 15 Nov 2022 00:44:46 +0100
>> >> >Martin Botka <martin.botka1@gmail.com> wrote:
>> >> >
>> >> >Hi Martin,
>> >> >
>> >> >> I can totally understand how this can get confusing.
>> >> >>
>> >> >> Basically because of the Rpi shortage biqu decided to make an
>> Rpi
>> >> >> alternative.
>> >> >>
>> >> >> So they made CB1 which is compute module style board.
>> >> >>
>> >> >> And they made 3 other boards where CB1 or Rpi CM4 can be
>> plugged in. The 3
>> >> >> boards are:
>> >> >>
>> >> >> Rpi adapter which takes the Compute module style boards and
>> turns them into
>> >> >> SBC style with basically identical size and etc to Rpi 4.
>> >> >>
>> >> >> Then we have Manta M8P and M4P. These boards are MCUs for a
>> 3D printer. But
>> >> >> they were made for Klipper use case which requires a computer
>> or SBC
>> >> >> (Usually Rpi4). They combined it into 1 board.
>> >> >> Where you get the MCU and you can plug in CM4 or CB1
>> >> >
>> >> >Thanks for the explanations! I was guessing along those
>> shortage lines,
>> >> >since the H616 is quite a step down from the RPi4CM, though
>> probably
>> >> >still enough for driving a 3D printer.
>> >> Mostly yes
>> >> >
>> >> >> All these boards are basically taking the pins and routing
>> them to ports.
>> >> >
>> >> >Yes, this is what those SoM carrier boards do ;-)
>> >> :)
>> >> >
>> >> >> There is nearly 0 chips for conversion or processing of the
>> pins from CB1
>> >> >> or CM4 thus i do not see a reason for having parent dtsi and
>> dts for the
>> >> >> adapter and Manta boards.
>> >> >
>> >> >And the DT does not need to describe "chips" only, a lot of DT
>> nodes
>> >> >are about connectors, and which ports and which exact pins (out
>> of the
>> >> >possible pinmuxes) are actually used. The SoM itself mostly
>> exposes
>> >> >just pins, and the board DT describes how these pins are used
>> (GPIO or
>> >> >special function, for instance).
>> >> >
>> >> >So did you try to split this up? How would that look?
>> >>
>> >> The main difference between adapter and Manta boards is that
>> adapter has 4x USB.
>> >
>> >So those are two double-type-A sockets? This is not really what
>> the DT
>> >below describes? It's perfectly fine to fix USB0 to host mode, we
>> do this
>> >on the Pine64 boards (both A64 and H6), for instance.
>>
>> Yes. But the third and fourth is also used. Third is done in 2.54
>> 4p connector (just pins on board) and fourth is connected directly
>> to manta stm32 MCU. So all 4 are host.
>
> Wait, so you are talking about the Manta board now? I see two
> sockets, the
> 2.54mm headers and the STM32 there, but the Pi4B is quite different in
> that respect: I see four(!) USB type-A sockets (two dual-port stacks).
> Plus the CM4 connector seems to only have pins for one USB 2.0 port
> (D-,D+). So is this a hub chip on the underside of the board, close
> to the
> USB ports? Can you read the label of that chip?
> And where are the other H616 USB pins routed to? Are they (ab-)using
> the
> PCIe pins of the CM4 connector? Or are they actually not used at all,
> and
> it's all one USB port through a by-4 hub?
> If you have a running system, "lsusb -t" should give you a clue which
> host
> ports are used and if there is a hub.
>
> Cheers,
> Andre
>
>> >> Manta only has 3 and 1 otg. But it has a switch to disable or
>> enable otg.
>> >
>> >What does the switch do, exactly? By definition OTG works fine in
>> both
>> >ways. And there are pins in the connector to decide the role.
>> The switch is just signal pin for RS2227. Its the multiplexer i
>> mentioned. It decides if we should have the pins wired to usb type C
>> port or normally to stm32 MCU. Thats all it does.
>> >
>> >Allwinner actually goes one step further and provides a full HCI
>> to the
>> >same PHY that the MUSB OTG controller is connected to, so you
>> don't need
>> >to live with the sometimes limited performance of the MUSB host
>> mode
>> >(which we drive without DMA). Not sure if that is the case or a
>> problem on
>> >the RPi4.
>> >
>> >> Im not opposed to splitting it up. It is probably a good idea.
>> >> I dont see how to resolve that switch on manta boards tho.
>> >
>> >If the Manta board is (almost) a superset of the Pi4B, then you can
>> >include the latter from there. Look at sun50i-a64-pine64-lts.dts or
>> >sun50i-h6-pine-h64-model-b.dts for examples.
>> >
>> >Cheers,
>> >Andre.
>> >
>> Yep i will split it into SoM boards.
>> >> >> The only exception to conversion are the LEDs on the boards
>> but since both
>> >> >> adapter and manta boards have them this yet again eliminates
>> need for
>> >> >> parent style DT.
>> >> >>
>> >> >> Best regards,
>> >> >> Martin
>> >> >>
>> >> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara
>> <andre.przywara@arm.com>
>> >> >> wrote:
>> >> >>
>> >> >> > On Mon, 14 Nov 2022 22:44:49 +0100
>> >> >> > Martin Botka <martin.botka@somainline.org> wrote:
>> >> >> >
>> >> >> > > CB1 is Compute Module style board that plugs into Rpi
>> board style
>> >> >> > adapter or
>> >> >> > > Manta 3D printer boards (M4P/M8P).
>> >> >> > >
>> >> >> > > The board has:
>> >> >> > > H616 SoC
>> >> >> > > 1GB of RAM
>> >> >> > > AXP313A PMIC
>> >> >> > >
>> >> >> > > And the actual boards that CB1 plugs in are just
>> extension to it with
>> >> >> > ports and
>> >> >> > > thus are not split in DT.
>> >> >> >
>> >> >> > I don't really understand that sentence. There is some
>> precedent for a
>> >> >> > SoM/board split, look at the sun50i-a64-sopine or
>> >> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this
>> correctly, then
>> >> >> > there are *two* boards available for the same CB1 SoM, the
>> PI4B and the
>> >> >> > Manta board? Which would a strong case for a SoM .dtsi,
>> plus the one
>> >> >> > or two board .dts files.
>> >> >> > I am just not sure whether that relation to the Pi4-CM is
>> helpful or
>> >> >> > just complicates things...
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Andre
>> >> >> >
>> >> >> > >
>> >> >> > > Boards have:
>> >> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> >> >> > > SDcard slot for loading images.
>> >> >> > > Ethernet port wired to the internal PHY.
>> >> >> > > 2x HDMI 2.0.
>> >> >> > > Power and Status LEDs.
>> >> >> > >
>> >> >> > > Currently working:
>> >> >> > > Booting
>> >> >> > > USB
>> >> >> > > UART
>> >> >> > >
>> >> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> >> >> > > ---
>> >> >> > > Changes in V2:
>> >> >> > > Add proper board compatible
>> >> >> > > Add regulator prefix for vcc5v
>> >> >> > > Drop okay status from PMIC
>> >> >> > > Drop standby_param
>> >> >> > > Changes in V3:
>> >> >> > > Change copyright to me
>> >> >> > > regulator_vcc5v to regulator-vcc5v
>> >> >> > > Drop ehci0 and ohci0
>> >> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> >> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
>> ++++++++++++++++++
>> >> >> > > 2 files changed, 179 insertions(+)
>> >> >> > > create mode 100644
>> >> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > >
>> >> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> > b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> >> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > > new file mode 100644
>> >> >> > > index 000000000000..86b5aca9b53e
>> >> >> > > --- /dev/null
>> >> >> > > +++
>> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > > @@ -0,0 +1,178 @@
>> >> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> >> >> > > +/*
>> >> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> >> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> >> >> > > +
>> >> >> > > + aliases {
>> >> >> > > + serial0 = &uart0;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + chosen {
>> >> >> > > + stdout-path = "serial0:115200n8";
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + leds {
>> >> >> > > + compatible = "gpio-leds";
>> >> >> > > +
>> >> >> > > + led-0 {
>> >> >> > > + function = LED_FUNCTION_POWER;
>> >> >> > > + color = <LED_COLOR_ID_RED>;
>> >> >> > > + gpios = <&pio 2 12
>> GPIO_ACTIVE_HIGH>; /* PC12 */
>> >> >> > > + default-state = "on";
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + led-1 {
>> >> >> > > + function = LED_FUNCTION_STATUS;
>> >> >> > > + color = <LED_COLOR_ID_GREEN>;
>> >> >> > > + gpios = <&pio 2 13
>> GPIO_ACTIVE_HIGH>; /* PC13 */
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + 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 = <®_vcc5v>;
>> >> >> > > + enable-active-high;
>> >> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /*
>> PC16 */
>> >> >> > > + };
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci1 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci2 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci3 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&mmc0 {
>> >> >> > > + vmmc-supply = <®_dldo1>;
>> >> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> >> >> > > + no-1-8-v;
>> >> >> > > + bus-width = <4>;
>> >> >> > > + status = "disabled";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci1 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci2 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci3 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&r_i2c {
>> >> >> > > + status = "okay";
>> >> >> > > +
>> >> >> > > + axp1530: pmic@36 {
>> >> >> > > + compatible = "x-powers,axp1530";
>> >> >> > > + reg = <0x36>;
>> >> >> > > + wakeup-source;
>> >> >> > > +
>> >> >> > > + regulators{
>> >> >> > > + reg_dcdc1: dcdc1 {
>> >> >> > > + regulator-name =
>> "axp1530-dcdc1";
>> >> >> > > + regulator-min-microvolt =
>> <500000>;
>> >> >> > > + regulator-max-microvolt =
>> <3400000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dcdc2: dcdc2 {
>> >> >> > > + regulator-name =
>> "axp1530-dcdc2";
>> >> >> > > + regulator-min-microvolt =
>> <500000>;
>> >> >> > > + regulator-max-microvolt =
>> <1540000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-ramp-delay =
>> <200>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dcdc3: dcdc3 {
>> >> >> > > + regulator-name =
>> "axp1530-dcdc3";
>> >> >> > > + regulator-min-microvolt =
>> <500000>;
>> >> >> > > + regulator-max-microvolt =
>> <1840000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_aldo1: ldo1 {
>> >> >> > > + regulator-name =
>> "axp1530-aldo1";
>> >> >> > > + regulator-min-microvolt =
>> <1800000>;
>> >> >> > > + regulator-max-microvolt =
>> <1800000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dldo1: ldo2 {
>> >> >> > > + regulator-name =
>> "axp1530-dldo1";
>> >> >> > > + regulator-min-microvolt =
>> <3300000>;
>> >> >> > > + regulator-max-microvolt =
>> <3300000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&uart0 {
>> >> >> > > + pinctrl-names = "default";
>> >> >> > > + pinctrl-0 = <&uart0_ph_pins>;
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&usbotg {
>> >> >> > > + /*
>> >> >> > > + * PHY0 pins are connected to a USB-C socket, but a
>> role switch
>> >> >> > > + * is not implemented: both CC pins are pulled to
>> GND.
>> >> >> > > + * The VBUS pins power the device, so a fixed
>> peripheral mode
>> >> >> > > + * is the best choice.
>> >> >> > > + * The board can be powered via GPIOs, in this case
>> port0 *can*
>> >> >> > > + * act as a host (with a cable/adapter ignoring
>> CC), as VBUS is
>> >> >> > > + * then provided by the GPIOs. Any user of this
>> setup would
>> >> >> > > + * need to adjust the DT accordingly: dr_mode set
>> to "host",
>> >> >> > > + * enabling OHCI0 and EHCI0.
>> >> >> > > + */
>> >> >> > > + dr_mode = "peripheral";
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&usbphy {
>> >> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> >
>> >> >> >
>> >> >
>> >
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-15 16:31 ` Martin Botka
0 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 16:31 UTC (permalink / raw)
To: Andre Przywara
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
Hi Andre,
Had a friend check on Rpi Adapter board for me. I dont exactly
like how they designed the board but what can we do.
USB works like this:
There is RS2229 which has USB2 connected to it and Type C.
RS2229 takes signal from the usbotg switch
The USB2 is then put to a hub via F1.s USB2.0 hub which then
goes to the 4 USB A ports.
This is basically the same as manta boards just that manta
boards have 1 USB always connected to the MCU. 2 are USB A
and 1 is 2.54mm 4P connector.
So all in all DT between Rpi adapter and Manta boards would
be identical.
So Andre what do you think about having the Rpi adapter and Manta
in single DT which would include the CB1 DTSI.
This way we dont have to differenciate between them as they are
quite literally identical as for ports and how they are wired.
It seems to be USB2 that is actually connected.
As for where the rest is wired.
From what i can see in downstream image and trough lsusb
nowhere. They are left alone...
Best Regards,
Martin
On Tue, Nov 15 2022 at 02:27:14 PM +00:00:00, Andre Przywara
<andre.przywara@arm.com> wrote:
> On Tue, 15 Nov 2022 12:38:59 +0100
> Martin Botka <martin.botka@somainline.org> wrote:
>
> Hi Martin,
>
>> On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara
>> <andre.przywara@arm.com> wrote:
>> >On Tue, 15 Nov 2022 09:24:04 +0100
>> >Martin Botka <martin.botka@somainline.org> wrote:
>> >
>> >Hi,
>> >
>> >> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara
>> <andre.przywara@arm.com> wrote:
>> >> >On Tue, 15 Nov 2022 00:44:46 +0100
>> >> >Martin Botka <martin.botka1@gmail.com> wrote:
>> >> >
>> >> >Hi Martin,
>> >> >
>> >> >> I can totally understand how this can get confusing.
>> >> >>
>> >> >> Basically because of the Rpi shortage biqu decided to make an
>> Rpi
>> >> >> alternative.
>> >> >>
>> >> >> So they made CB1 which is compute module style board.
>> >> >>
>> >> >> And they made 3 other boards where CB1 or Rpi CM4 can be
>> plugged in. The 3
>> >> >> boards are:
>> >> >>
>> >> >> Rpi adapter which takes the Compute module style boards and
>> turns them into
>> >> >> SBC style with basically identical size and etc to Rpi 4.
>> >> >>
>> >> >> Then we have Manta M8P and M4P. These boards are MCUs for a
>> 3D printer. But
>> >> >> they were made for Klipper use case which requires a computer
>> or SBC
>> >> >> (Usually Rpi4). They combined it into 1 board.
>> >> >> Where you get the MCU and you can plug in CM4 or CB1
>> >> >
>> >> >Thanks for the explanations! I was guessing along those
>> shortage lines,
>> >> >since the H616 is quite a step down from the RPi4CM, though
>> probably
>> >> >still enough for driving a 3D printer.
>> >> Mostly yes
>> >> >
>> >> >> All these boards are basically taking the pins and routing
>> them to ports.
>> >> >
>> >> >Yes, this is what those SoM carrier boards do ;-)
>> >> :)
>> >> >
>> >> >> There is nearly 0 chips for conversion or processing of the
>> pins from CB1
>> >> >> or CM4 thus i do not see a reason for having parent dtsi and
>> dts for the
>> >> >> adapter and Manta boards.
>> >> >
>> >> >And the DT does not need to describe "chips" only, a lot of DT
>> nodes
>> >> >are about connectors, and which ports and which exact pins (out
>> of the
>> >> >possible pinmuxes) are actually used. The SoM itself mostly
>> exposes
>> >> >just pins, and the board DT describes how these pins are used
>> (GPIO or
>> >> >special function, for instance).
>> >> >
>> >> >So did you try to split this up? How would that look?
>> >>
>> >> The main difference between adapter and Manta boards is that
>> adapter has 4x USB.
>> >
>> >So those are two double-type-A sockets? This is not really what
>> the DT
>> >below describes? It's perfectly fine to fix USB0 to host mode, we
>> do this
>> >on the Pine64 boards (both A64 and H6), for instance.
>>
>> Yes. But the third and fourth is also used. Third is done in 2.54
>> 4p connector (just pins on board) and fourth is connected directly
>> to manta stm32 MCU. So all 4 are host.
>
> Wait, so you are talking about the Manta board now? I see two
> sockets, the
> 2.54mm headers and the STM32 there, but the Pi4B is quite different in
> that respect: I see four(!) USB type-A sockets (two dual-port stacks).
> Plus the CM4 connector seems to only have pins for one USB 2.0 port
> (D-,D+). So is this a hub chip on the underside of the board, close
> to the
> USB ports? Can you read the label of that chip?
> And where are the other H616 USB pins routed to? Are they (ab-)using
> the
> PCIe pins of the CM4 connector? Or are they actually not used at all,
> and
> it's all one USB port through a by-4 hub?
> If you have a running system, "lsusb -t" should give you a clue which
> host
> ports are used and if there is a hub.
>
> Cheers,
> Andre
>
>> >> Manta only has 3 and 1 otg. But it has a switch to disable or
>> enable otg.
>> >
>> >What does the switch do, exactly? By definition OTG works fine in
>> both
>> >ways. And there are pins in the connector to decide the role.
>> The switch is just signal pin for RS2227. Its the multiplexer i
>> mentioned. It decides if we should have the pins wired to usb type C
>> port or normally to stm32 MCU. Thats all it does.
>> >
>> >Allwinner actually goes one step further and provides a full HCI
>> to the
>> >same PHY that the MUSB OTG controller is connected to, so you
>> don't need
>> >to live with the sometimes limited performance of the MUSB host
>> mode
>> >(which we drive without DMA). Not sure if that is the case or a
>> problem on
>> >the RPi4.
>> >
>> >> Im not opposed to splitting it up. It is probably a good idea.
>> >> I dont see how to resolve that switch on manta boards tho.
>> >
>> >If the Manta board is (almost) a superset of the Pi4B, then you can
>> >include the latter from there. Look at sun50i-a64-pine64-lts.dts or
>> >sun50i-h6-pine-h64-model-b.dts for examples.
>> >
>> >Cheers,
>> >Andre.
>> >
>> Yep i will split it into SoM boards.
>> >> >> The only exception to conversion are the LEDs on the boards
>> but since both
>> >> >> adapter and manta boards have them this yet again eliminates
>> need for
>> >> >> parent style DT.
>> >> >>
>> >> >> Best regards,
>> >> >> Martin
>> >> >>
>> >> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara
>> <andre.przywara@arm.com>
>> >> >> wrote:
>> >> >>
>> >> >> > On Mon, 14 Nov 2022 22:44:49 +0100
>> >> >> > Martin Botka <martin.botka@somainline.org> wrote:
>> >> >> >
>> >> >> > > CB1 is Compute Module style board that plugs into Rpi
>> board style
>> >> >> > adapter or
>> >> >> > > Manta 3D printer boards (M4P/M8P).
>> >> >> > >
>> >> >> > > The board has:
>> >> >> > > H616 SoC
>> >> >> > > 1GB of RAM
>> >> >> > > AXP313A PMIC
>> >> >> > >
>> >> >> > > And the actual boards that CB1 plugs in are just
>> extension to it with
>> >> >> > ports and
>> >> >> > > thus are not split in DT.
>> >> >> >
>> >> >> > I don't really understand that sentence. There is some
>> precedent for a
>> >> >> > SoM/board split, look at the sun50i-a64-sopine or
>> >> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this
>> correctly, then
>> >> >> > there are *two* boards available for the same CB1 SoM, the
>> PI4B and the
>> >> >> > Manta board? Which would a strong case for a SoM .dtsi,
>> plus the one
>> >> >> > or two board .dts files.
>> >> >> > I am just not sure whether that relation to the Pi4-CM is
>> helpful or
>> >> >> > just complicates things...
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Andre
>> >> >> >
>> >> >> > >
>> >> >> > > Boards have:
>> >> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> >> >> > > SDcard slot for loading images.
>> >> >> > > Ethernet port wired to the internal PHY.
>> >> >> > > 2x HDMI 2.0.
>> >> >> > > Power and Status LEDs.
>> >> >> > >
>> >> >> > > Currently working:
>> >> >> > > Booting
>> >> >> > > USB
>> >> >> > > UART
>> >> >> > >
>> >> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> >> >> > > ---
>> >> >> > > Changes in V2:
>> >> >> > > Add proper board compatible
>> >> >> > > Add regulator prefix for vcc5v
>> >> >> > > Drop okay status from PMIC
>> >> >> > > Drop standby_param
>> >> >> > > Changes in V3:
>> >> >> > > Change copyright to me
>> >> >> > > regulator_vcc5v to regulator-vcc5v
>> >> >> > > Drop ehci0 and ohci0
>> >> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> >> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
>> ++++++++++++++++++
>> >> >> > > 2 files changed, 179 insertions(+)
>> >> >> > > create mode 100644
>> >> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > >
>> >> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> > b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> >> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > > new file mode 100644
>> >> >> > > index 000000000000..86b5aca9b53e
>> >> >> > > --- /dev/null
>> >> >> > > +++
>> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > > @@ -0,0 +1,178 @@
>> >> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> >> >> > > +/*
>> >> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> >> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> >> >> > > +
>> >> >> > > + aliases {
>> >> >> > > + serial0 = &uart0;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + chosen {
>> >> >> > > + stdout-path = "serial0:115200n8";
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + leds {
>> >> >> > > + compatible = "gpio-leds";
>> >> >> > > +
>> >> >> > > + led-0 {
>> >> >> > > + function = LED_FUNCTION_POWER;
>> >> >> > > + color = <LED_COLOR_ID_RED>;
>> >> >> > > + gpios = <&pio 2 12
>> GPIO_ACTIVE_HIGH>; /* PC12 */
>> >> >> > > + default-state = "on";
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + led-1 {
>> >> >> > > + function = LED_FUNCTION_STATUS;
>> >> >> > > + color = <LED_COLOR_ID_GREEN>;
>> >> >> > > + gpios = <&pio 2 13
>> GPIO_ACTIVE_HIGH>; /* PC13 */
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + 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 = <®_vcc5v>;
>> >> >> > > + enable-active-high;
>> >> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /*
>> PC16 */
>> >> >> > > + };
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci1 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci2 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci3 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&mmc0 {
>> >> >> > > + vmmc-supply = <®_dldo1>;
>> >> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> >> >> > > + no-1-8-v;
>> >> >> > > + bus-width = <4>;
>> >> >> > > + status = "disabled";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci1 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci2 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci3 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&r_i2c {
>> >> >> > > + status = "okay";
>> >> >> > > +
>> >> >> > > + axp1530: pmic@36 {
>> >> >> > > + compatible = "x-powers,axp1530";
>> >> >> > > + reg = <0x36>;
>> >> >> > > + wakeup-source;
>> >> >> > > +
>> >> >> > > + regulators{
>> >> >> > > + reg_dcdc1: dcdc1 {
>> >> >> > > + regulator-name =
>> "axp1530-dcdc1";
>> >> >> > > + regulator-min-microvolt =
>> <500000>;
>> >> >> > > + regulator-max-microvolt =
>> <3400000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dcdc2: dcdc2 {
>> >> >> > > + regulator-name =
>> "axp1530-dcdc2";
>> >> >> > > + regulator-min-microvolt =
>> <500000>;
>> >> >> > > + regulator-max-microvolt =
>> <1540000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-ramp-delay =
>> <200>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dcdc3: dcdc3 {
>> >> >> > > + regulator-name =
>> "axp1530-dcdc3";
>> >> >> > > + regulator-min-microvolt =
>> <500000>;
>> >> >> > > + regulator-max-microvolt =
>> <1840000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_aldo1: ldo1 {
>> >> >> > > + regulator-name =
>> "axp1530-aldo1";
>> >> >> > > + regulator-min-microvolt =
>> <1800000>;
>> >> >> > > + regulator-max-microvolt =
>> <1800000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dldo1: ldo2 {
>> >> >> > > + regulator-name =
>> "axp1530-dldo1";
>> >> >> > > + regulator-min-microvolt =
>> <3300000>;
>> >> >> > > + regulator-max-microvolt =
>> <3300000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&uart0 {
>> >> >> > > + pinctrl-names = "default";
>> >> >> > > + pinctrl-0 = <&uart0_ph_pins>;
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&usbotg {
>> >> >> > > + /*
>> >> >> > > + * PHY0 pins are connected to a USB-C socket, but a
>> role switch
>> >> >> > > + * is not implemented: both CC pins are pulled to
>> GND.
>> >> >> > > + * The VBUS pins power the device, so a fixed
>> peripheral mode
>> >> >> > > + * is the best choice.
>> >> >> > > + * The board can be powered via GPIOs, in this case
>> port0 *can*
>> >> >> > > + * act as a host (with a cable/adapter ignoring
>> CC), as VBUS is
>> >> >> > > + * then provided by the GPIOs. Any user of this
>> setup would
>> >> >> > > + * need to adjust the DT accordingly: dr_mode set
>> to "host",
>> >> >> > > + * enabling OHCI0 and EHCI0.
>> >> >> > > + */
>> >> >> > > + dr_mode = "peripheral";
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&usbphy {
>> >> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> >
>> >> >> >
>> >> >
>> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-15 14:27 ` Andre Przywara
@ 2022-11-15 17:02 ` Martin Botka
-1 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 17:02 UTC (permalink / raw)
To: Andre Przywara
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On Tue, Nov 15 2022 at 02:27:14 PM +00:00:00, Andre Przywara
<andre.przywara@arm.com> wrote:
> On Tue, 15 Nov 2022 12:38:59 +0100
> Martin Botka <martin.botka@somainline.org> wrote:
>
> Hi Martin,
>
>> On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara
>> <andre.przywara@arm.com> wrote:
>> >On Tue, 15 Nov 2022 09:24:04 +0100
>> >Martin Botka <martin.botka@somainline.org> wrote:
>> >
>> >Hi,
>> >
>> >> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara
>> <andre.przywara@arm.com> wrote:
>> >> >On Tue, 15 Nov 2022 00:44:46 +0100
>> >> >Martin Botka <martin.botka1@gmail.com> wrote:
>> >> >
>> >> >Hi Martin,
>> >> >
>> >> >> I can totally understand how this can get confusing.
>> >> >>
>> >> >> Basically because of the Rpi shortage biqu decided to make an
>> Rpi
>> >> >> alternative.
>> >> >>
>> >> >> So they made CB1 which is compute module style board.
>> >> >>
>> >> >> And they made 3 other boards where CB1 or Rpi CM4 can be
>> plugged in. The 3
>> >> >> boards are:
>> >> >>
>> >> >> Rpi adapter which takes the Compute module style boards and
>> turns them into
>> >> >> SBC style with basically identical size and etc to Rpi 4.
>> >> >>
>> >> >> Then we have Manta M8P and M4P. These boards are MCUs for a
>> 3D printer. But
>> >> >> they were made for Klipper use case which requires a computer
>> or SBC
>> >> >> (Usually Rpi4). They combined it into 1 board.
>> >> >> Where you get the MCU and you can plug in CM4 or CB1
>> >> >
>> >> >Thanks for the explanations! I was guessing along those
>> shortage lines,
>> >> >since the H616 is quite a step down from the RPi4CM, though
>> probably
>> >> >still enough for driving a 3D printer.
>> >> Mostly yes
>> >> >
>> >> >> All these boards are basically taking the pins and routing
>> them to ports.
>> >> >
>> >> >Yes, this is what those SoM carrier boards do ;-)
>> >> :)
>> >> >
>> >> >> There is nearly 0 chips for conversion or processing of the
>> pins from CB1
>> >> >> or CM4 thus i do not see a reason for having parent dtsi and
>> dts for the
>> >> >> adapter and Manta boards.
>> >> >
>> >> >And the DT does not need to describe "chips" only, a lot of DT
>> nodes
>> >> >are about connectors, and which ports and which exact pins (out
>> of the
>> >> >possible pinmuxes) are actually used. The SoM itself mostly
>> exposes
>> >> >just pins, and the board DT describes how these pins are used
>> (GPIO or
>> >> >special function, for instance).
>> >> >
>> >> >So did you try to split this up? How would that look?
>> >>
>> >> The main difference between adapter and Manta boards is that
>> adapter has 4x USB.
>> >
>> >So those are two double-type-A sockets? This is not really what
>> the DT
>> >below describes? It's perfectly fine to fix USB0 to host mode, we
>> do this
>> >on the Pine64 boards (both A64 and H6), for instance.
>>
>> Yes. But the third and fourth is also used. Third is done in 2.54
>> 4p connector (just pins on board) and fourth is connected directly
>> to manta stm32 MCU. So all 4 are host.
>
> Wait, so you are talking about the Manta board now? I see two
> sockets, the
> 2.54mm headers and the STM32 there, but the Pi4B is quite different in
> that respect: I see four(!) USB type-A sockets (two dual-port stacks).
> Plus the CM4 connector seems to only have pins for one USB 2.0 port
> (D-,D+). So is this a hub chip on the underside of the board, close
> to the
> USB ports? Can you read the label of that chip?
> And where are the other H616 USB pins routed to? Are they (ab-)using
> the
> PCIe pins of the CM4 connector? Or are they actually not used at all,
> and
> it's all one USB port through a by-4 hub?
> If you have a running system, "lsusb -t" should give you a clue which
> host
> ports are used and if there is a hub.
>
> Cheers,
> Andre
>
>> >> Manta only has 3 and 1 otg. But it has a switch to disable or
>> enable otg.
>> >
>> >What does the switch do, exactly? By definition OTG works fine in
>> both
>> >ways. And there are pins in the connector to decide the role.
>> The switch is just signal pin for RS2227. Its the multiplexer i
>> mentioned. It decides if we should have the pins wired to usb type C
>> port or normally to stm32 MCU. Thats all it does.
>> >
>> >Allwinner actually goes one step further and provides a full HCI
>> to the
>> >same PHY that the MUSB OTG controller is connected to, so you
>> don't need
>> >to live with the sometimes limited performance of the MUSB host
>> mode
>> >(which we drive without DMA). Not sure if that is the case or a
>> problem on
>> >the RPi4.
>> >
>> >> Im not opposed to splitting it up. It is probably a good idea.
>> >> I dont see how to resolve that switch on manta boards tho.
>> >
>> >If the Manta board is (almost) a superset of the Pi4B, then you can
>> >include the latter from there. Look at sun50i-a64-pine64-lts.dts or
>> >sun50i-h6-pine-h64-model-b.dts for examples.
>> >
>> >Cheers,
>> >Andre.
>> >
>> Yep i will split it into SoM boards.
>> >> >> The only exception to conversion are the LEDs on the boards
>> but since both
>> >> >> adapter and manta boards have them this yet again eliminates
>> need for
>> >> >> parent style DT.
>> >> >>
>> >> >> Best regards,
>> >> >> Martin
>> >> >>
>> >> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara
>> <andre.przywara@arm.com>
>> >> >> wrote:
>> >> >>
>> >> >> > On Mon, 14 Nov 2022 22:44:49 +0100
>> >> >> > Martin Botka <martin.botka@somainline.org> wrote:
>> >> >> >
>> >> >> > > CB1 is Compute Module style board that plugs into Rpi
>> board style
>> >> >> > adapter or
>> >> >> > > Manta 3D printer boards (M4P/M8P).
>> >> >> > >
>> >> >> > > The board has:
>> >> >> > > H616 SoC
>> >> >> > > 1GB of RAM
>> >> >> > > AXP313A PMIC
>> >> >> > >
>> >> >> > > And the actual boards that CB1 plugs in are just
>> extension to it with
>> >> >> > ports and
>> >> >> > > thus are not split in DT.
>> >> >> >
>> >> >> > I don't really understand that sentence. There is some
>> precedent for a
>> >> >> > SoM/board split, look at the sun50i-a64-sopine or
>> >> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this
>> correctly, then
>> >> >> > there are *two* boards available for the same CB1 SoM, the
>> PI4B and the
>> >> >> > Manta board? Which would a strong case for a SoM .dtsi,
>> plus the one
>> >> >> > or two board .dts files.
>> >> >> > I am just not sure whether that relation to the Pi4-CM is
>> helpful or
>> >> >> > just complicates things...
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Andre
>> >> >> >
>> >> >> > >
>> >> >> > > Boards have:
>> >> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> >> >> > > SDcard slot for loading images.
>> >> >> > > Ethernet port wired to the internal PHY.
>> >> >> > > 2x HDMI 2.0.
>> >> >> > > Power and Status LEDs.
>> >> >> > >
>> >> >> > > Currently working:
>> >> >> > > Booting
>> >> >> > > USB
>> >> >> > > UART
>> >> >> > >
>> >> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> >> >> > > ---
>> >> >> > > Changes in V2:
>> >> >> > > Add proper board compatible
>> >> >> > > Add regulator prefix for vcc5v
>> >> >> > > Drop okay status from PMIC
>> >> >> > > Drop standby_param
>> >> >> > > Changes in V3:
>> >> >> > > Change copyright to me
>> >> >> > > regulator_vcc5v to regulator-vcc5v
>> >> >> > > Drop ehci0 and ohci0
>> >> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> >> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
>> ++++++++++++++++++
>> >> >> > > 2 files changed, 179 insertions(+)
>> >> >> > > create mode 100644
>> >> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > >
>> >> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> > b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> >> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > > new file mode 100644
>> >> >> > > index 000000000000..86b5aca9b53e
>> >> >> > > --- /dev/null
>> >> >> > > +++
>> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > > @@ -0,0 +1,178 @@
>> >> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> >> >> > > +/*
>> >> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> >> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> >> >> > > +
>> >> >> > > + aliases {
>> >> >> > > + serial0 = &uart0;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + chosen {
>> >> >> > > + stdout-path = "serial0:115200n8";
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + leds {
>> >> >> > > + compatible = "gpio-leds";
>> >> >> > > +
>> >> >> > > + led-0 {
>> >> >> > > + function = LED_FUNCTION_POWER;
>> >> >> > > + color = <LED_COLOR_ID_RED>;
>> >> >> > > + gpios = <&pio 2 12
>> GPIO_ACTIVE_HIGH>; /* PC12 */
>> >> >> > > + default-state = "on";
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + led-1 {
>> >> >> > > + function = LED_FUNCTION_STATUS;
>> >> >> > > + color = <LED_COLOR_ID_GREEN>;
>> >> >> > > + gpios = <&pio 2 13
>> GPIO_ACTIVE_HIGH>; /* PC13 */
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + 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 = <®_vcc5v>;
>> >> >> > > + enable-active-high;
>> >> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /*
>> PC16 */
>> >> >> > > + };
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci1 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci2 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci3 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&mmc0 {
>> >> >> > > + vmmc-supply = <®_dldo1>;
>> >> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> >> >> > > + no-1-8-v;
>> >> >> > > + bus-width = <4>;
>> >> >> > > + status = "disabled";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci1 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci2 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci3 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&r_i2c {
>> >> >> > > + status = "okay";
>> >> >> > > +
>> >> >> > > + axp1530: pmic@36 {
>> >> >> > > + compatible = "x-powers,axp1530";
>> >> >> > > + reg = <0x36>;
>> >> >> > > + wakeup-source;
>> >> >> > > +
>> >> >> > > + regulators{
>> >> >> > > + reg_dcdc1: dcdc1 {
>> >> >> > > + regulator-name =
>> "axp1530-dcdc1";
>> >> >> > > + regulator-min-microvolt =
>> <500000>;
>> >> >> > > + regulator-max-microvolt =
>> <3400000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dcdc2: dcdc2 {
>> >> >> > > + regulator-name =
>> "axp1530-dcdc2";
>> >> >> > > + regulator-min-microvolt =
>> <500000>;
>> >> >> > > + regulator-max-microvolt =
>> <1540000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-ramp-delay =
>> <200>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dcdc3: dcdc3 {
>> >> >> > > + regulator-name =
>> "axp1530-dcdc3";
>> >> >> > > + regulator-min-microvolt =
>> <500000>;
>> >> >> > > + regulator-max-microvolt =
>> <1840000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_aldo1: ldo1 {
>> >> >> > > + regulator-name =
>> "axp1530-aldo1";
>> >> >> > > + regulator-min-microvolt =
>> <1800000>;
>> >> >> > > + regulator-max-microvolt =
>> <1800000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dldo1: ldo2 {
>> >> >> > > + regulator-name =
>> "axp1530-dldo1";
>> >> >> > > + regulator-min-microvolt =
>> <3300000>;
>> >> >> > > + regulator-max-microvolt =
>> <3300000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&uart0 {
>> >> >> > > + pinctrl-names = "default";
>> >> >> > > + pinctrl-0 = <&uart0_ph_pins>;
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&usbotg {
>> >> >> > > + /*
>> >> >> > > + * PHY0 pins are connected to a USB-C socket, but a
>> role switch
>> >> >> > > + * is not implemented: both CC pins are pulled to
>> GND.
>> >> >> > > + * The VBUS pins power the device, so a fixed
>> peripheral mode
>> >> >> > > + * is the best choice.
>> >> >> > > + * The board can be powered via GPIOs, in this case
>> port0 *can*
>> >> >> > > + * act as a host (with a cable/adapter ignoring
>> CC), as VBUS is
>> >> >> > > + * then provided by the GPIOs. Any user of this
>> setup would
>> >> >> > > + * need to adjust the DT accordingly: dr_mode set
>> to "host",
>> >> >> > > + * enabling OHCI0 and EHCI0.
>> >> >> > > + */
>> >> >> > > + dr_mode = "peripheral";
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&usbphy {
>> >> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> >
>> >> >> >
>> >> >
>> >
>
And yes there should be CM4 and CB1 DT for these boards.
But since i do not own CM4. I will only create CB1 version of this DT.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-15 17:02 ` Martin Botka
0 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 17:02 UTC (permalink / raw)
To: Andre Przywara
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On Tue, Nov 15 2022 at 02:27:14 PM +00:00:00, Andre Przywara
<andre.przywara@arm.com> wrote:
> On Tue, 15 Nov 2022 12:38:59 +0100
> Martin Botka <martin.botka@somainline.org> wrote:
>
> Hi Martin,
>
>> On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara
>> <andre.przywara@arm.com> wrote:
>> >On Tue, 15 Nov 2022 09:24:04 +0100
>> >Martin Botka <martin.botka@somainline.org> wrote:
>> >
>> >Hi,
>> >
>> >> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara
>> <andre.przywara@arm.com> wrote:
>> >> >On Tue, 15 Nov 2022 00:44:46 +0100
>> >> >Martin Botka <martin.botka1@gmail.com> wrote:
>> >> >
>> >> >Hi Martin,
>> >> >
>> >> >> I can totally understand how this can get confusing.
>> >> >>
>> >> >> Basically because of the Rpi shortage biqu decided to make an
>> Rpi
>> >> >> alternative.
>> >> >>
>> >> >> So they made CB1 which is compute module style board.
>> >> >>
>> >> >> And they made 3 other boards where CB1 or Rpi CM4 can be
>> plugged in. The 3
>> >> >> boards are:
>> >> >>
>> >> >> Rpi adapter which takes the Compute module style boards and
>> turns them into
>> >> >> SBC style with basically identical size and etc to Rpi 4.
>> >> >>
>> >> >> Then we have Manta M8P and M4P. These boards are MCUs for a
>> 3D printer. But
>> >> >> they were made for Klipper use case which requires a computer
>> or SBC
>> >> >> (Usually Rpi4). They combined it into 1 board.
>> >> >> Where you get the MCU and you can plug in CM4 or CB1
>> >> >
>> >> >Thanks for the explanations! I was guessing along those
>> shortage lines,
>> >> >since the H616 is quite a step down from the RPi4CM, though
>> probably
>> >> >still enough for driving a 3D printer.
>> >> Mostly yes
>> >> >
>> >> >> All these boards are basically taking the pins and routing
>> them to ports.
>> >> >
>> >> >Yes, this is what those SoM carrier boards do ;-)
>> >> :)
>> >> >
>> >> >> There is nearly 0 chips for conversion or processing of the
>> pins from CB1
>> >> >> or CM4 thus i do not see a reason for having parent dtsi and
>> dts for the
>> >> >> adapter and Manta boards.
>> >> >
>> >> >And the DT does not need to describe "chips" only, a lot of DT
>> nodes
>> >> >are about connectors, and which ports and which exact pins (out
>> of the
>> >> >possible pinmuxes) are actually used. The SoM itself mostly
>> exposes
>> >> >just pins, and the board DT describes how these pins are used
>> (GPIO or
>> >> >special function, for instance).
>> >> >
>> >> >So did you try to split this up? How would that look?
>> >>
>> >> The main difference between adapter and Manta boards is that
>> adapter has 4x USB.
>> >
>> >So those are two double-type-A sockets? This is not really what
>> the DT
>> >below describes? It's perfectly fine to fix USB0 to host mode, we
>> do this
>> >on the Pine64 boards (both A64 and H6), for instance.
>>
>> Yes. But the third and fourth is also used. Third is done in 2.54
>> 4p connector (just pins on board) and fourth is connected directly
>> to manta stm32 MCU. So all 4 are host.
>
> Wait, so you are talking about the Manta board now? I see two
> sockets, the
> 2.54mm headers and the STM32 there, but the Pi4B is quite different in
> that respect: I see four(!) USB type-A sockets (two dual-port stacks).
> Plus the CM4 connector seems to only have pins for one USB 2.0 port
> (D-,D+). So is this a hub chip on the underside of the board, close
> to the
> USB ports? Can you read the label of that chip?
> And where are the other H616 USB pins routed to? Are they (ab-)using
> the
> PCIe pins of the CM4 connector? Or are they actually not used at all,
> and
> it's all one USB port through a by-4 hub?
> If you have a running system, "lsusb -t" should give you a clue which
> host
> ports are used and if there is a hub.
>
> Cheers,
> Andre
>
>> >> Manta only has 3 and 1 otg. But it has a switch to disable or
>> enable otg.
>> >
>> >What does the switch do, exactly? By definition OTG works fine in
>> both
>> >ways. And there are pins in the connector to decide the role.
>> The switch is just signal pin for RS2227. Its the multiplexer i
>> mentioned. It decides if we should have the pins wired to usb type C
>> port or normally to stm32 MCU. Thats all it does.
>> >
>> >Allwinner actually goes one step further and provides a full HCI
>> to the
>> >same PHY that the MUSB OTG controller is connected to, so you
>> don't need
>> >to live with the sometimes limited performance of the MUSB host
>> mode
>> >(which we drive without DMA). Not sure if that is the case or a
>> problem on
>> >the RPi4.
>> >
>> >> Im not opposed to splitting it up. It is probably a good idea.
>> >> I dont see how to resolve that switch on manta boards tho.
>> >
>> >If the Manta board is (almost) a superset of the Pi4B, then you can
>> >include the latter from there. Look at sun50i-a64-pine64-lts.dts or
>> >sun50i-h6-pine-h64-model-b.dts for examples.
>> >
>> >Cheers,
>> >Andre.
>> >
>> Yep i will split it into SoM boards.
>> >> >> The only exception to conversion are the LEDs on the boards
>> but since both
>> >> >> adapter and manta boards have them this yet again eliminates
>> need for
>> >> >> parent style DT.
>> >> >>
>> >> >> Best regards,
>> >> >> Martin
>> >> >>
>> >> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara
>> <andre.przywara@arm.com>
>> >> >> wrote:
>> >> >>
>> >> >> > On Mon, 14 Nov 2022 22:44:49 +0100
>> >> >> > Martin Botka <martin.botka@somainline.org> wrote:
>> >> >> >
>> >> >> > > CB1 is Compute Module style board that plugs into Rpi
>> board style
>> >> >> > adapter or
>> >> >> > > Manta 3D printer boards (M4P/M8P).
>> >> >> > >
>> >> >> > > The board has:
>> >> >> > > H616 SoC
>> >> >> > > 1GB of RAM
>> >> >> > > AXP313A PMIC
>> >> >> > >
>> >> >> > > And the actual boards that CB1 plugs in are just
>> extension to it with
>> >> >> > ports and
>> >> >> > > thus are not split in DT.
>> >> >> >
>> >> >> > I don't really understand that sentence. There is some
>> precedent for a
>> >> >> > SoM/board split, look at the sun50i-a64-sopine or
>> >> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this
>> correctly, then
>> >> >> > there are *two* boards available for the same CB1 SoM, the
>> PI4B and the
>> >> >> > Manta board? Which would a strong case for a SoM .dtsi,
>> plus the one
>> >> >> > or two board .dts files.
>> >> >> > I am just not sure whether that relation to the Pi4-CM is
>> helpful or
>> >> >> > just complicates things...
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Andre
>> >> >> >
>> >> >> > >
>> >> >> > > Boards have:
>> >> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> >> >> > > SDcard slot for loading images.
>> >> >> > > Ethernet port wired to the internal PHY.
>> >> >> > > 2x HDMI 2.0.
>> >> >> > > Power and Status LEDs.
>> >> >> > >
>> >> >> > > Currently working:
>> >> >> > > Booting
>> >> >> > > USB
>> >> >> > > UART
>> >> >> > >
>> >> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> >> >> > > ---
>> >> >> > > Changes in V2:
>> >> >> > > Add proper board compatible
>> >> >> > > Add regulator prefix for vcc5v
>> >> >> > > Drop okay status from PMIC
>> >> >> > > Drop standby_param
>> >> >> > > Changes in V3:
>> >> >> > > Change copyright to me
>> >> >> > > regulator_vcc5v to regulator-vcc5v
>> >> >> > > Drop ehci0 and ohci0
>> >> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> >> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
>> ++++++++++++++++++
>> >> >> > > 2 files changed, 179 insertions(+)
>> >> >> > > create mode 100644
>> >> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > >
>> >> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> > b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> >> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > > new file mode 100644
>> >> >> > > index 000000000000..86b5aca9b53e
>> >> >> > > --- /dev/null
>> >> >> > > +++
>> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> > > @@ -0,0 +1,178 @@
>> >> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> >> >> > > +/*
>> >> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> >> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> >> >> > > +
>> >> >> > > + aliases {
>> >> >> > > + serial0 = &uart0;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + chosen {
>> >> >> > > + stdout-path = "serial0:115200n8";
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + leds {
>> >> >> > > + compatible = "gpio-leds";
>> >> >> > > +
>> >> >> > > + led-0 {
>> >> >> > > + function = LED_FUNCTION_POWER;
>> >> >> > > + color = <LED_COLOR_ID_RED>;
>> >> >> > > + gpios = <&pio 2 12
>> GPIO_ACTIVE_HIGH>; /* PC12 */
>> >> >> > > + default-state = "on";
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + led-1 {
>> >> >> > > + function = LED_FUNCTION_STATUS;
>> >> >> > > + color = <LED_COLOR_ID_GREEN>;
>> >> >> > > + gpios = <&pio 2 13
>> GPIO_ACTIVE_HIGH>; /* PC13 */
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + 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 = <®_vcc5v>;
>> >> >> > > + enable-active-high;
>> >> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /*
>> PC16 */
>> >> >> > > + };
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci1 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci2 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ehci3 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&mmc0 {
>> >> >> > > + vmmc-supply = <®_dldo1>;
>> >> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> >> >> > > + no-1-8-v;
>> >> >> > > + bus-width = <4>;
>> >> >> > > + status = "disabled";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci1 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci2 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&ohci3 {
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&r_i2c {
>> >> >> > > + status = "okay";
>> >> >> > > +
>> >> >> > > + axp1530: pmic@36 {
>> >> >> > > + compatible = "x-powers,axp1530";
>> >> >> > > + reg = <0x36>;
>> >> >> > > + wakeup-source;
>> >> >> > > +
>> >> >> > > + regulators{
>> >> >> > > + reg_dcdc1: dcdc1 {
>> >> >> > > + regulator-name =
>> "axp1530-dcdc1";
>> >> >> > > + regulator-min-microvolt =
>> <500000>;
>> >> >> > > + regulator-max-microvolt =
>> <3400000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dcdc2: dcdc2 {
>> >> >> > > + regulator-name =
>> "axp1530-dcdc2";
>> >> >> > > + regulator-min-microvolt =
>> <500000>;
>> >> >> > > + regulator-max-microvolt =
>> <1540000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-ramp-delay =
>> <200>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dcdc3: dcdc3 {
>> >> >> > > + regulator-name =
>> "axp1530-dcdc3";
>> >> >> > > + regulator-min-microvolt =
>> <500000>;
>> >> >> > > + regulator-max-microvolt =
>> <1840000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_aldo1: ldo1 {
>> >> >> > > + regulator-name =
>> "axp1530-aldo1";
>> >> >> > > + regulator-min-microvolt =
>> <1800000>;
>> >> >> > > + regulator-max-microvolt =
>> <1800000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > +
>> >> >> > > + reg_dldo1: ldo2 {
>> >> >> > > + regulator-name =
>> "axp1530-dldo1";
>> >> >> > > + regulator-min-microvolt =
>> <3300000>;
>> >> >> > > + regulator-max-microvolt =
>> <3300000>;
>> >> >> > > + regulator-step-delay-us =
>> <25>;
>> >> >> > > + regulator-final-delay-us =
>> <50>;
>> >> >> > > + regulator-always-on;
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > + };
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&uart0 {
>> >> >> > > + pinctrl-names = "default";
>> >> >> > > + pinctrl-0 = <&uart0_ph_pins>;
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&usbotg {
>> >> >> > > + /*
>> >> >> > > + * PHY0 pins are connected to a USB-C socket, but a
>> role switch
>> >> >> > > + * is not implemented: both CC pins are pulled to
>> GND.
>> >> >> > > + * The VBUS pins power the device, so a fixed
>> peripheral mode
>> >> >> > > + * is the best choice.
>> >> >> > > + * The board can be powered via GPIOs, in this case
>> port0 *can*
>> >> >> > > + * act as a host (with a cable/adapter ignoring
>> CC), as VBUS is
>> >> >> > > + * then provided by the GPIOs. Any user of this
>> setup would
>> >> >> > > + * need to adjust the DT accordingly: dr_mode set
>> to "host",
>> >> >> > > + * enabling OHCI0 and EHCI0.
>> >> >> > > + */
>> >> >> > > + dr_mode = "peripheral";
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> > > +
>> >> >> > > +&usbphy {
>> >> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> >> >> > > + status = "okay";
>> >> >> > > +};
>> >> >> >
>> >> >> >
>> >> >
>> >
>
And yes there should be CM4 and CB1 DT for these boards.
But since i do not own CM4. I will only create CB1 version of this DT.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-15 17:02 ` Martin Botka
@ 2022-11-15 17:25 ` Andre Przywara
-1 siblings, 0 replies; 38+ messages in thread
From: Andre Przywara @ 2022-11-15 17:25 UTC (permalink / raw)
To: Martin Botka
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On Tue, 15 Nov 2022 18:02:43 +0100
Martin Botka <martin.botka@somainline.org> wrote:
> On Tue, Nov 15 2022 at 02:27:14 PM +00:00:00, Andre Przywara
> <andre.przywara@arm.com> wrote:
> > On Tue, 15 Nov 2022 12:38:59 +0100
> > Martin Botka <martin.botka@somainline.org> wrote:
> >
> > Hi Martin,
> >
> >> On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara
> >> <andre.przywara@arm.com> wrote:
> >> >On Tue, 15 Nov 2022 09:24:04 +0100
> >> >Martin Botka <martin.botka@somainline.org> wrote:
> >> >
> >> >Hi,
> >> >
> >> >> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara
> >> <andre.przywara@arm.com> wrote:
> >> >> >On Tue, 15 Nov 2022 00:44:46 +0100
> >> >> >Martin Botka <martin.botka1@gmail.com> wrote:
> >> >> >
> >> >> >Hi Martin,
> >> >> >
> >> >> >> I can totally understand how this can get confusing.
> >> >> >>
> >> >> >> Basically because of the Rpi shortage biqu decided to make an
> >> Rpi
> >> >> >> alternative.
> >> >> >>
> >> >> >> So they made CB1 which is compute module style board.
> >> >> >>
> >> >> >> And they made 3 other boards where CB1 or Rpi CM4 can be
> >> plugged in. The 3
> >> >> >> boards are:
> >> >> >>
> >> >> >> Rpi adapter which takes the Compute module style boards and
> >> turns them into
> >> >> >> SBC style with basically identical size and etc to Rpi 4.
> >> >> >>
> >> >> >> Then we have Manta M8P and M4P. These boards are MCUs for a
> >> 3D printer. But
> >> >> >> they were made for Klipper use case which requires a computer
> >> or SBC
> >> >> >> (Usually Rpi4). They combined it into 1 board.
> >> >> >> Where you get the MCU and you can plug in CM4 or CB1
> >> >> >
> >> >> >Thanks for the explanations! I was guessing along those
> >> shortage lines,
> >> >> >since the H616 is quite a step down from the RPi4CM, though
> >> probably
> >> >> >still enough for driving a 3D printer.
> >> >> Mostly yes
> >> >> >
> >> >> >> All these boards are basically taking the pins and routing
> >> them to ports.
> >> >> >
> >> >> >Yes, this is what those SoM carrier boards do ;-)
> >> >> :)
> >> >> >
> >> >> >> There is nearly 0 chips for conversion or processing of the
> >> pins from CB1
> >> >> >> or CM4 thus i do not see a reason for having parent dtsi and
> >> dts for the
> >> >> >> adapter and Manta boards.
> >> >> >
> >> >> >And the DT does not need to describe "chips" only, a lot of DT
> >> nodes
> >> >> >are about connectors, and which ports and which exact pins (out
> >> of the
> >> >> >possible pinmuxes) are actually used. The SoM itself mostly
> >> exposes
> >> >> >just pins, and the board DT describes how these pins are used
> >> (GPIO or
> >> >> >special function, for instance).
> >> >> >
> >> >> >So did you try to split this up? How would that look?
> >> >>
> >> >> The main difference between adapter and Manta boards is that
> >> adapter has 4x USB.
> >> >
> >> >So those are two double-type-A sockets? This is not really what
> >> the DT
> >> >below describes? It's perfectly fine to fix USB0 to host mode, we
> >> do this
> >> >on the Pine64 boards (both A64 and H6), for instance.
> >>
> >> Yes. But the third and fourth is also used. Third is done in 2.54
> >> 4p connector (just pins on board) and fourth is connected directly
> >> to manta stm32 MCU. So all 4 are host.
> >
> > Wait, so you are talking about the Manta board now? I see two
> > sockets, the
> > 2.54mm headers and the STM32 there, but the Pi4B is quite different in
> > that respect: I see four(!) USB type-A sockets (two dual-port stacks).
> > Plus the CM4 connector seems to only have pins for one USB 2.0 port
> > (D-,D+). So is this a hub chip on the underside of the board, close
> > to the
> > USB ports? Can you read the label of that chip?
> > And where are the other H616 USB pins routed to? Are they (ab-)using
> > the
> > PCIe pins of the CM4 connector? Or are they actually not used at all,
> > and
> > it's all one USB port through a by-4 hub?
> > If you have a running system, "lsusb -t" should give you a clue which
> > host
> > ports are used and if there is a hub.
> >
> > Cheers,
> > Andre
> >
> >> >> Manta only has 3 and 1 otg. But it has a switch to disable or
> >> enable otg.
> >> >
> >> >What does the switch do, exactly? By definition OTG works fine in
> >> both
> >> >ways. And there are pins in the connector to decide the role.
> >> The switch is just signal pin for RS2227. Its the multiplexer i
> >> mentioned. It decides if we should have the pins wired to usb type C
> >> port or normally to stm32 MCU. Thats all it does.
> >> >
> >> >Allwinner actually goes one step further and provides a full HCI
> >> to the
> >> >same PHY that the MUSB OTG controller is connected to, so you
> >> don't need
> >> >to live with the sometimes limited performance of the MUSB host
> >> mode
> >> >(which we drive without DMA). Not sure if that is the case or a
> >> problem on
> >> >the RPi4.
> >> >
> >> >> Im not opposed to splitting it up. It is probably a good idea.
> >> >> I dont see how to resolve that switch on manta boards tho.
> >> >
> >> >If the Manta board is (almost) a superset of the Pi4B, then you can
> >> >include the latter from there. Look at sun50i-a64-pine64-lts.dts or
> >> >sun50i-h6-pine-h64-model-b.dts for examples.
> >> >
> >> >Cheers,
> >> >Andre.
> >> >
> >> Yep i will split it into SoM boards.
> >> >> >> The only exception to conversion are the LEDs on the boards
> >> but since both
> >> >> >> adapter and manta boards have them this yet again eliminates
> >> need for
> >> >> >> parent style DT.
> >> >> >>
> >> >> >> Best regards,
> >> >> >> Martin
> >> >> >>
> >> >> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara
> >> <andre.przywara@arm.com>
> >> >> >> wrote:
> >> >> >>
> >> >> >> > On Mon, 14 Nov 2022 22:44:49 +0100
> >> >> >> > Martin Botka <martin.botka@somainline.org> wrote:
> >> >> >> >
> >> >> >> > > CB1 is Compute Module style board that plugs into Rpi
> >> board style
> >> >> >> > adapter or
> >> >> >> > > Manta 3D printer boards (M4P/M8P).
> >> >> >> > >
> >> >> >> > > The board has:
> >> >> >> > > H616 SoC
> >> >> >> > > 1GB of RAM
> >> >> >> > > AXP313A PMIC
> >> >> >> > >
> >> >> >> > > And the actual boards that CB1 plugs in are just
> >> extension to it with
> >> >> >> > ports and
> >> >> >> > > thus are not split in DT.
> >> >> >> >
> >> >> >> > I don't really understand that sentence. There is some
> >> precedent for a
> >> >> >> > SoM/board split, look at the sun50i-a64-sopine or
> >> >> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this
> >> correctly, then
> >> >> >> > there are *two* boards available for the same CB1 SoM, the
> >> PI4B and the
> >> >> >> > Manta board? Which would a strong case for a SoM .dtsi,
> >> plus the one
> >> >> >> > or two board .dts files.
> >> >> >> > I am just not sure whether that relation to the Pi4-CM is
> >> helpful or
> >> >> >> > just complicates things...
> >> >> >> >
> >> >> >> > Cheers,
> >> >> >> > Andre
> >> >> >> >
> >> >> >> > >
> >> >> >> > > Boards have:
> >> >> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
> >> >> >> > > SDcard slot for loading images.
> >> >> >> > > Ethernet port wired to the internal PHY.
> >> >> >> > > 2x HDMI 2.0.
> >> >> >> > > Power and Status LEDs.
> >> >> >> > >
> >> >> >> > > Currently working:
> >> >> >> > > Booting
> >> >> >> > > USB
> >> >> >> > > UART
> >> >> >> > >
> >> >> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
> >> >> >> > > ---
> >> >> >> > > Changes in V2:
> >> >> >> > > Add proper board compatible
> >> >> >> > > Add regulator prefix for vcc5v
> >> >> >> > > Drop okay status from PMIC
> >> >> >> > > Drop standby_param
> >> >> >> > > Changes in V3:
> >> >> >> > > Change copyright to me
> >> >> >> > > regulator_vcc5v to regulator-vcc5v
> >> >> >> > > Drop ehci0 and ohci0
> >> >> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> >> >> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
> >> ++++++++++++++++++
> >> >> >> > > 2 files changed, 179 insertions(+)
> >> >> >> > > create mode 100644
> >> >> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> >> >> > >
> >> >> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> >> >> >> > b/arch/arm64/boot/dts/allwinner/Makefile
> >> >> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
> >> >> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> >> >> > > new file mode 100644
> >> >> >> > > index 000000000000..86b5aca9b53e
> >> >> >> > > --- /dev/null
> >> >> >> > > +++
> >> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> >> >> > > @@ -0,0 +1,178 @@
> >> >> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> >> >> >> > > +/*
> >> >> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
> >> >> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> >> >> >> > > +
> >> >> >> > > + aliases {
> >> >> >> > > + serial0 = &uart0;
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + chosen {
> >> >> >> > > + stdout-path = "serial0:115200n8";
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + leds {
> >> >> >> > > + compatible = "gpio-leds";
> >> >> >> > > +
> >> >> >> > > + led-0 {
> >> >> >> > > + function = LED_FUNCTION_POWER;
> >> >> >> > > + color = <LED_COLOR_ID_RED>;
> >> >> >> > > + gpios = <&pio 2 12
> >> GPIO_ACTIVE_HIGH>; /* PC12 */
> >> >> >> > > + default-state = "on";
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + led-1 {
> >> >> >> > > + function = LED_FUNCTION_STATUS;
> >> >> >> > > + color = <LED_COLOR_ID_GREEN>;
> >> >> >> > > + gpios = <&pio 2 13
> >> GPIO_ACTIVE_HIGH>; /* PC13 */
> >> >> >> > > + };
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + 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 = <®_vcc5v>;
> >> >> >> > > + enable-active-high;
> >> >> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /*
> >> PC16 */
> >> >> >> > > + };
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&ehci1 {
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&ehci2 {
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&ehci3 {
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&mmc0 {
> >> >> >> > > + vmmc-supply = <®_dldo1>;
> >> >> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> >> >> >> > > + no-1-8-v;
> >> >> >> > > + bus-width = <4>;
> >> >> >> > > + status = "disabled";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&ohci1 {
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&ohci2 {
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&ohci3 {
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&r_i2c {
> >> >> >> > > + status = "okay";
> >> >> >> > > +
> >> >> >> > > + axp1530: pmic@36 {
> >> >> >> > > + compatible = "x-powers,axp1530";
> >> >> >> > > + reg = <0x36>;
> >> >> >> > > + wakeup-source;
> >> >> >> > > +
> >> >> >> > > + regulators{
> >> >> >> > > + reg_dcdc1: dcdc1 {
> >> >> >> > > + regulator-name =
> >> "axp1530-dcdc1";
> >> >> >> > > + regulator-min-microvolt =
> >> <500000>;
> >> >> >> > > + regulator-max-microvolt =
> >> <3400000>;
> >> >> >> > > + regulator-step-delay-us =
> >> <25>;
> >> >> >> > > + regulator-final-delay-us =
> >> <50>;
> >> >> >> > > + regulator-always-on;
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + reg_dcdc2: dcdc2 {
> >> >> >> > > + regulator-name =
> >> "axp1530-dcdc2";
> >> >> >> > > + regulator-min-microvolt =
> >> <500000>;
> >> >> >> > > + regulator-max-microvolt =
> >> <1540000>;
> >> >> >> > > + regulator-step-delay-us =
> >> <25>;
> >> >> >> > > + regulator-final-delay-us =
> >> <50>;
> >> >> >> > > + regulator-ramp-delay =
> >> <200>;
> >> >> >> > > + regulator-always-on;
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + reg_dcdc3: dcdc3 {
> >> >> >> > > + regulator-name =
> >> "axp1530-dcdc3";
> >> >> >> > > + regulator-min-microvolt =
> >> <500000>;
> >> >> >> > > + regulator-max-microvolt =
> >> <1840000>;
> >> >> >> > > + regulator-step-delay-us =
> >> <25>;
> >> >> >> > > + regulator-final-delay-us =
> >> <50>;
> >> >> >> > > + regulator-always-on;
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + reg_aldo1: ldo1 {
> >> >> >> > > + regulator-name =
> >> "axp1530-aldo1";
> >> >> >> > > + regulator-min-microvolt =
> >> <1800000>;
> >> >> >> > > + regulator-max-microvolt =
> >> <1800000>;
> >> >> >> > > + regulator-step-delay-us =
> >> <25>;
> >> >> >> > > + regulator-final-delay-us =
> >> <50>;
> >> >> >> > > + regulator-always-on;
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + reg_dldo1: ldo2 {
> >> >> >> > > + regulator-name =
> >> "axp1530-dldo1";
> >> >> >> > > + regulator-min-microvolt =
> >> <3300000>;
> >> >> >> > > + regulator-max-microvolt =
> >> <3300000>;
> >> >> >> > > + regulator-step-delay-us =
> >> <25>;
> >> >> >> > > + regulator-final-delay-us =
> >> <50>;
> >> >> >> > > + regulator-always-on;
> >> >> >> > > + };
> >> >> >> > > + };
> >> >> >> > > + };
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&uart0 {
> >> >> >> > > + pinctrl-names = "default";
> >> >> >> > > + pinctrl-0 = <&uart0_ph_pins>;
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&usbotg {
> >> >> >> > > + /*
> >> >> >> > > + * PHY0 pins are connected to a USB-C socket, but a
> >> role switch
> >> >> >> > > + * is not implemented: both CC pins are pulled to
> >> GND.
> >> >> >> > > + * The VBUS pins power the device, so a fixed
> >> peripheral mode
> >> >> >> > > + * is the best choice.
> >> >> >> > > + * The board can be powered via GPIOs, in this case
> >> port0 *can*
> >> >> >> > > + * act as a host (with a cable/adapter ignoring
> >> CC), as VBUS is
> >> >> >> > > + * then provided by the GPIOs. Any user of this
> >> setup would
> >> >> >> > > + * need to adjust the DT accordingly: dr_mode set
> >> to "host",
> >> >> >> > > + * enabling OHCI0 and EHCI0.
> >> >> >> > > + */
> >> >> >> > > + dr_mode = "peripheral";
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&usbphy {
> >> >> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >
> >
> And yes there should be CM4 and CB1 DT for these boards.
> But since i do not own CM4. I will only create CB1 version of this DT.
That's the interesting part: there is already a DT for the CM4:
arch/arm/boot/dts/bcm2711-rpi-cm4.dtsi
Theoretically you should be able to include this .dtsi instead of your
cb1.dtsi into the board .dts, and it should work(TM). Now I don't know if
this has ever been done before, but I would imagine this to not compile,
as the references are not the same, and the peripherals being rather
different anyway.
So let's for a moment pretend we can only plug the CB1 in ;-)
As for the same DT between the Manta and RPi4: let's just start with one.
If the other one is indeed identical (thought they look very different to
me!), we just might not bother with upstreaming the other one.
Should there be differences (which could be an LED wired differently), and
people care, we can always add a second .dts, and include the first one.
As to which board to upstream: I am a bit torn between the more practical
RPi4 board and the fact that you actually own the Manta board. I guess we
should play it safe, and you upstream what you have and can test.
Cheers,
Andre
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-15 17:25 ` Andre Przywara
0 siblings, 0 replies; 38+ messages in thread
From: Andre Przywara @ 2022-11-15 17:25 UTC (permalink / raw)
To: Martin Botka
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On Tue, 15 Nov 2022 18:02:43 +0100
Martin Botka <martin.botka@somainline.org> wrote:
> On Tue, Nov 15 2022 at 02:27:14 PM +00:00:00, Andre Przywara
> <andre.przywara@arm.com> wrote:
> > On Tue, 15 Nov 2022 12:38:59 +0100
> > Martin Botka <martin.botka@somainline.org> wrote:
> >
> > Hi Martin,
> >
> >> On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara
> >> <andre.przywara@arm.com> wrote:
> >> >On Tue, 15 Nov 2022 09:24:04 +0100
> >> >Martin Botka <martin.botka@somainline.org> wrote:
> >> >
> >> >Hi,
> >> >
> >> >> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara
> >> <andre.przywara@arm.com> wrote:
> >> >> >On Tue, 15 Nov 2022 00:44:46 +0100
> >> >> >Martin Botka <martin.botka1@gmail.com> wrote:
> >> >> >
> >> >> >Hi Martin,
> >> >> >
> >> >> >> I can totally understand how this can get confusing.
> >> >> >>
> >> >> >> Basically because of the Rpi shortage biqu decided to make an
> >> Rpi
> >> >> >> alternative.
> >> >> >>
> >> >> >> So they made CB1 which is compute module style board.
> >> >> >>
> >> >> >> And they made 3 other boards where CB1 or Rpi CM4 can be
> >> plugged in. The 3
> >> >> >> boards are:
> >> >> >>
> >> >> >> Rpi adapter which takes the Compute module style boards and
> >> turns them into
> >> >> >> SBC style with basically identical size and etc to Rpi 4.
> >> >> >>
> >> >> >> Then we have Manta M8P and M4P. These boards are MCUs for a
> >> 3D printer. But
> >> >> >> they were made for Klipper use case which requires a computer
> >> or SBC
> >> >> >> (Usually Rpi4). They combined it into 1 board.
> >> >> >> Where you get the MCU and you can plug in CM4 or CB1
> >> >> >
> >> >> >Thanks for the explanations! I was guessing along those
> >> shortage lines,
> >> >> >since the H616 is quite a step down from the RPi4CM, though
> >> probably
> >> >> >still enough for driving a 3D printer.
> >> >> Mostly yes
> >> >> >
> >> >> >> All these boards are basically taking the pins and routing
> >> them to ports.
> >> >> >
> >> >> >Yes, this is what those SoM carrier boards do ;-)
> >> >> :)
> >> >> >
> >> >> >> There is nearly 0 chips for conversion or processing of the
> >> pins from CB1
> >> >> >> or CM4 thus i do not see a reason for having parent dtsi and
> >> dts for the
> >> >> >> adapter and Manta boards.
> >> >> >
> >> >> >And the DT does not need to describe "chips" only, a lot of DT
> >> nodes
> >> >> >are about connectors, and which ports and which exact pins (out
> >> of the
> >> >> >possible pinmuxes) are actually used. The SoM itself mostly
> >> exposes
> >> >> >just pins, and the board DT describes how these pins are used
> >> (GPIO or
> >> >> >special function, for instance).
> >> >> >
> >> >> >So did you try to split this up? How would that look?
> >> >>
> >> >> The main difference between adapter and Manta boards is that
> >> adapter has 4x USB.
> >> >
> >> >So those are two double-type-A sockets? This is not really what
> >> the DT
> >> >below describes? It's perfectly fine to fix USB0 to host mode, we
> >> do this
> >> >on the Pine64 boards (both A64 and H6), for instance.
> >>
> >> Yes. But the third and fourth is also used. Third is done in 2.54
> >> 4p connector (just pins on board) and fourth is connected directly
> >> to manta stm32 MCU. So all 4 are host.
> >
> > Wait, so you are talking about the Manta board now? I see two
> > sockets, the
> > 2.54mm headers and the STM32 there, but the Pi4B is quite different in
> > that respect: I see four(!) USB type-A sockets (two dual-port stacks).
> > Plus the CM4 connector seems to only have pins for one USB 2.0 port
> > (D-,D+). So is this a hub chip on the underside of the board, close
> > to the
> > USB ports? Can you read the label of that chip?
> > And where are the other H616 USB pins routed to? Are they (ab-)using
> > the
> > PCIe pins of the CM4 connector? Or are they actually not used at all,
> > and
> > it's all one USB port through a by-4 hub?
> > If you have a running system, "lsusb -t" should give you a clue which
> > host
> > ports are used and if there is a hub.
> >
> > Cheers,
> > Andre
> >
> >> >> Manta only has 3 and 1 otg. But it has a switch to disable or
> >> enable otg.
> >> >
> >> >What does the switch do, exactly? By definition OTG works fine in
> >> both
> >> >ways. And there are pins in the connector to decide the role.
> >> The switch is just signal pin for RS2227. Its the multiplexer i
> >> mentioned. It decides if we should have the pins wired to usb type C
> >> port or normally to stm32 MCU. Thats all it does.
> >> >
> >> >Allwinner actually goes one step further and provides a full HCI
> >> to the
> >> >same PHY that the MUSB OTG controller is connected to, so you
> >> don't need
> >> >to live with the sometimes limited performance of the MUSB host
> >> mode
> >> >(which we drive without DMA). Not sure if that is the case or a
> >> problem on
> >> >the RPi4.
> >> >
> >> >> Im not opposed to splitting it up. It is probably a good idea.
> >> >> I dont see how to resolve that switch on manta boards tho.
> >> >
> >> >If the Manta board is (almost) a superset of the Pi4B, then you can
> >> >include the latter from there. Look at sun50i-a64-pine64-lts.dts or
> >> >sun50i-h6-pine-h64-model-b.dts for examples.
> >> >
> >> >Cheers,
> >> >Andre.
> >> >
> >> Yep i will split it into SoM boards.
> >> >> >> The only exception to conversion are the LEDs on the boards
> >> but since both
> >> >> >> adapter and manta boards have them this yet again eliminates
> >> need for
> >> >> >> parent style DT.
> >> >> >>
> >> >> >> Best regards,
> >> >> >> Martin
> >> >> >>
> >> >> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara
> >> <andre.przywara@arm.com>
> >> >> >> wrote:
> >> >> >>
> >> >> >> > On Mon, 14 Nov 2022 22:44:49 +0100
> >> >> >> > Martin Botka <martin.botka@somainline.org> wrote:
> >> >> >> >
> >> >> >> > > CB1 is Compute Module style board that plugs into Rpi
> >> board style
> >> >> >> > adapter or
> >> >> >> > > Manta 3D printer boards (M4P/M8P).
> >> >> >> > >
> >> >> >> > > The board has:
> >> >> >> > > H616 SoC
> >> >> >> > > 1GB of RAM
> >> >> >> > > AXP313A PMIC
> >> >> >> > >
> >> >> >> > > And the actual boards that CB1 plugs in are just
> >> extension to it with
> >> >> >> > ports and
> >> >> >> > > thus are not split in DT.
> >> >> >> >
> >> >> >> > I don't really understand that sentence. There is some
> >> precedent for a
> >> >> >> > SoM/board split, look at the sun50i-a64-sopine or
> >> >> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this
> >> correctly, then
> >> >> >> > there are *two* boards available for the same CB1 SoM, the
> >> PI4B and the
> >> >> >> > Manta board? Which would a strong case for a SoM .dtsi,
> >> plus the one
> >> >> >> > or two board .dts files.
> >> >> >> > I am just not sure whether that relation to the Pi4-CM is
> >> helpful or
> >> >> >> > just complicates things...
> >> >> >> >
> >> >> >> > Cheers,
> >> >> >> > Andre
> >> >> >> >
> >> >> >> > >
> >> >> >> > > Boards have:
> >> >> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
> >> >> >> > > SDcard slot for loading images.
> >> >> >> > > Ethernet port wired to the internal PHY.
> >> >> >> > > 2x HDMI 2.0.
> >> >> >> > > Power and Status LEDs.
> >> >> >> > >
> >> >> >> > > Currently working:
> >> >> >> > > Booting
> >> >> >> > > USB
> >> >> >> > > UART
> >> >> >> > >
> >> >> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
> >> >> >> > > ---
> >> >> >> > > Changes in V2:
> >> >> >> > > Add proper board compatible
> >> >> >> > > Add regulator prefix for vcc5v
> >> >> >> > > Drop okay status from PMIC
> >> >> >> > > Drop standby_param
> >> >> >> > > Changes in V3:
> >> >> >> > > Change copyright to me
> >> >> >> > > regulator_vcc5v to regulator-vcc5v
> >> >> >> > > Drop ehci0 and ohci0
> >> >> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> >> >> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
> >> ++++++++++++++++++
> >> >> >> > > 2 files changed, 179 insertions(+)
> >> >> >> > > create mode 100644
> >> >> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> >> >> > >
> >> >> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> >> >> >> > b/arch/arm64/boot/dts/allwinner/Makefile
> >> >> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
> >> >> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> >> >> > > new file mode 100644
> >> >> >> > > index 000000000000..86b5aca9b53e
> >> >> >> > > --- /dev/null
> >> >> >> > > +++
> >> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> >> >> > > @@ -0,0 +1,178 @@
> >> >> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> >> >> >> > > +/*
> >> >> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
> >> >> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> >> >> >> > > +
> >> >> >> > > + aliases {
> >> >> >> > > + serial0 = &uart0;
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + chosen {
> >> >> >> > > + stdout-path = "serial0:115200n8";
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + leds {
> >> >> >> > > + compatible = "gpio-leds";
> >> >> >> > > +
> >> >> >> > > + led-0 {
> >> >> >> > > + function = LED_FUNCTION_POWER;
> >> >> >> > > + color = <LED_COLOR_ID_RED>;
> >> >> >> > > + gpios = <&pio 2 12
> >> GPIO_ACTIVE_HIGH>; /* PC12 */
> >> >> >> > > + default-state = "on";
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + led-1 {
> >> >> >> > > + function = LED_FUNCTION_STATUS;
> >> >> >> > > + color = <LED_COLOR_ID_GREEN>;
> >> >> >> > > + gpios = <&pio 2 13
> >> GPIO_ACTIVE_HIGH>; /* PC13 */
> >> >> >> > > + };
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + 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 = <®_vcc5v>;
> >> >> >> > > + enable-active-high;
> >> >> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /*
> >> PC16 */
> >> >> >> > > + };
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&ehci1 {
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&ehci2 {
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&ehci3 {
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&mmc0 {
> >> >> >> > > + vmmc-supply = <®_dldo1>;
> >> >> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> >> >> >> > > + no-1-8-v;
> >> >> >> > > + bus-width = <4>;
> >> >> >> > > + status = "disabled";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&ohci1 {
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&ohci2 {
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&ohci3 {
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&r_i2c {
> >> >> >> > > + status = "okay";
> >> >> >> > > +
> >> >> >> > > + axp1530: pmic@36 {
> >> >> >> > > + compatible = "x-powers,axp1530";
> >> >> >> > > + reg = <0x36>;
> >> >> >> > > + wakeup-source;
> >> >> >> > > +
> >> >> >> > > + regulators{
> >> >> >> > > + reg_dcdc1: dcdc1 {
> >> >> >> > > + regulator-name =
> >> "axp1530-dcdc1";
> >> >> >> > > + regulator-min-microvolt =
> >> <500000>;
> >> >> >> > > + regulator-max-microvolt =
> >> <3400000>;
> >> >> >> > > + regulator-step-delay-us =
> >> <25>;
> >> >> >> > > + regulator-final-delay-us =
> >> <50>;
> >> >> >> > > + regulator-always-on;
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + reg_dcdc2: dcdc2 {
> >> >> >> > > + regulator-name =
> >> "axp1530-dcdc2";
> >> >> >> > > + regulator-min-microvolt =
> >> <500000>;
> >> >> >> > > + regulator-max-microvolt =
> >> <1540000>;
> >> >> >> > > + regulator-step-delay-us =
> >> <25>;
> >> >> >> > > + regulator-final-delay-us =
> >> <50>;
> >> >> >> > > + regulator-ramp-delay =
> >> <200>;
> >> >> >> > > + regulator-always-on;
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + reg_dcdc3: dcdc3 {
> >> >> >> > > + regulator-name =
> >> "axp1530-dcdc3";
> >> >> >> > > + regulator-min-microvolt =
> >> <500000>;
> >> >> >> > > + regulator-max-microvolt =
> >> <1840000>;
> >> >> >> > > + regulator-step-delay-us =
> >> <25>;
> >> >> >> > > + regulator-final-delay-us =
> >> <50>;
> >> >> >> > > + regulator-always-on;
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + reg_aldo1: ldo1 {
> >> >> >> > > + regulator-name =
> >> "axp1530-aldo1";
> >> >> >> > > + regulator-min-microvolt =
> >> <1800000>;
> >> >> >> > > + regulator-max-microvolt =
> >> <1800000>;
> >> >> >> > > + regulator-step-delay-us =
> >> <25>;
> >> >> >> > > + regulator-final-delay-us =
> >> <50>;
> >> >> >> > > + regulator-always-on;
> >> >> >> > > + };
> >> >> >> > > +
> >> >> >> > > + reg_dldo1: ldo2 {
> >> >> >> > > + regulator-name =
> >> "axp1530-dldo1";
> >> >> >> > > + regulator-min-microvolt =
> >> <3300000>;
> >> >> >> > > + regulator-max-microvolt =
> >> <3300000>;
> >> >> >> > > + regulator-step-delay-us =
> >> <25>;
> >> >> >> > > + regulator-final-delay-us =
> >> <50>;
> >> >> >> > > + regulator-always-on;
> >> >> >> > > + };
> >> >> >> > > + };
> >> >> >> > > + };
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&uart0 {
> >> >> >> > > + pinctrl-names = "default";
> >> >> >> > > + pinctrl-0 = <&uart0_ph_pins>;
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&usbotg {
> >> >> >> > > + /*
> >> >> >> > > + * PHY0 pins are connected to a USB-C socket, but a
> >> role switch
> >> >> >> > > + * is not implemented: both CC pins are pulled to
> >> GND.
> >> >> >> > > + * The VBUS pins power the device, so a fixed
> >> peripheral mode
> >> >> >> > > + * is the best choice.
> >> >> >> > > + * The board can be powered via GPIOs, in this case
> >> port0 *can*
> >> >> >> > > + * act as a host (with a cable/adapter ignoring
> >> CC), as VBUS is
> >> >> >> > > + * then provided by the GPIOs. Any user of this
> >> setup would
> >> >> >> > > + * need to adjust the DT accordingly: dr_mode set
> >> to "host",
> >> >> >> > > + * enabling OHCI0 and EHCI0.
> >> >> >> > > + */
> >> >> >> > > + dr_mode = "peripheral";
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> > > +
> >> >> >> > > +&usbphy {
> >> >> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
> >> >> >> > > + status = "okay";
> >> >> >> > > +};
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >
> >
> And yes there should be CM4 and CB1 DT for these boards.
> But since i do not own CM4. I will only create CB1 version of this DT.
That's the interesting part: there is already a DT for the CM4:
arch/arm/boot/dts/bcm2711-rpi-cm4.dtsi
Theoretically you should be able to include this .dtsi instead of your
cb1.dtsi into the board .dts, and it should work(TM). Now I don't know if
this has ever been done before, but I would imagine this to not compile,
as the references are not the same, and the peripherals being rather
different anyway.
So let's for a moment pretend we can only plug the CB1 in ;-)
As for the same DT between the Manta and RPi4: let's just start with one.
If the other one is indeed identical (thought they look very different to
me!), we just might not bother with upstreaming the other one.
Should there be differences (which could be an LED wired differently), and
people care, we can always add a second .dts, and include the first one.
As to which board to upstream: I am a bit torn between the more practical
RPi4 board and the fact that you actually own the Manta board. I guess we
should play it safe, and you upstream what you have and can test.
Cheers,
Andre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-15 17:25 ` Andre Przywara
@ 2022-11-15 17:32 ` Martin Botka
-1 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 17:32 UTC (permalink / raw)
To: Andre Przywara
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On November 15, 2022 6:25:01 PM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>On Tue, 15 Nov 2022 18:02:43 +0100
>Martin Botka <martin.botka@somainline.org> wrote:
>
>> On Tue, Nov 15 2022 at 02:27:14 PM +00:00:00, Andre Przywara
>> <andre.przywara@arm.com> wrote:
>> > On Tue, 15 Nov 2022 12:38:59 +0100
>> > Martin Botka <martin.botka@somainline.org> wrote:
>> >
>> > Hi Martin,
>> >
>> >> On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara
>> >> <andre.przywara@arm.com> wrote:
>> >> >On Tue, 15 Nov 2022 09:24:04 +0100
>> >> >Martin Botka <martin.botka@somainline.org> wrote:
>> >> >
>> >> >Hi,
>> >> >
>> >> >> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara
>> >> <andre.przywara@arm.com> wrote:
>> >> >> >On Tue, 15 Nov 2022 00:44:46 +0100
>> >> >> >Martin Botka <martin.botka1@gmail.com> wrote:
>> >> >> >
>> >> >> >Hi Martin,
>> >> >> >
>> >> >> >> I can totally understand how this can get confusing.
>> >> >> >>
>> >> >> >> Basically because of the Rpi shortage biqu decided to make an
>> >> Rpi
>> >> >> >> alternative.
>> >> >> >>
>> >> >> >> So they made CB1 which is compute module style board.
>> >> >> >>
>> >> >> >> And they made 3 other boards where CB1 or Rpi CM4 can be
>> >> plugged in. The 3
>> >> >> >> boards are:
>> >> >> >>
>> >> >> >> Rpi adapter which takes the Compute module style boards and
>> >> turns them into
>> >> >> >> SBC style with basically identical size and etc to Rpi 4.
>> >> >> >>
>> >> >> >> Then we have Manta M8P and M4P. These boards are MCUs for a
>> >> 3D printer. But
>> >> >> >> they were made for Klipper use case which requires a computer
>> >> or SBC
>> >> >> >> (Usually Rpi4). They combined it into 1 board.
>> >> >> >> Where you get the MCU and you can plug in CM4 or CB1
>> >> >> >
>> >> >> >Thanks for the explanations! I was guessing along those
>> >> shortage lines,
>> >> >> >since the H616 is quite a step down from the RPi4CM, though
>> >> probably
>> >> >> >still enough for driving a 3D printer.
>> >> >> Mostly yes
>> >> >> >
>> >> >> >> All these boards are basically taking the pins and routing
>> >> them to ports.
>> >> >> >
>> >> >> >Yes, this is what those SoM carrier boards do ;-)
>> >> >> :)
>> >> >> >
>> >> >> >> There is nearly 0 chips for conversion or processing of the
>> >> pins from CB1
>> >> >> >> or CM4 thus i do not see a reason for having parent dtsi and
>> >> dts for the
>> >> >> >> adapter and Manta boards.
>> >> >> >
>> >> >> >And the DT does not need to describe "chips" only, a lot of DT
>> >> nodes
>> >> >> >are about connectors, and which ports and which exact pins (out
>> >> of the
>> >> >> >possible pinmuxes) are actually used. The SoM itself mostly
>> >> exposes
>> >> >> >just pins, and the board DT describes how these pins are used
>> >> (GPIO or
>> >> >> >special function, for instance).
>> >> >> >
>> >> >> >So did you try to split this up? How would that look?
>> >> >>
>> >> >> The main difference between adapter and Manta boards is that
>> >> adapter has 4x USB.
>> >> >
>> >> >So those are two double-type-A sockets? This is not really what
>> >> the DT
>> >> >below describes? It's perfectly fine to fix USB0 to host mode, we
>> >> do this
>> >> >on the Pine64 boards (both A64 and H6), for instance.
>> >>
>> >> Yes. But the third and fourth is also used. Third is done in 2.54
>> >> 4p connector (just pins on board) and fourth is connected directly
>> >> to manta stm32 MCU. So all 4 are host.
>> >
>> > Wait, so you are talking about the Manta board now? I see two
>> > sockets, the
>> > 2.54mm headers and the STM32 there, but the Pi4B is quite different in
>> > that respect: I see four(!) USB type-A sockets (two dual-port stacks).
>> > Plus the CM4 connector seems to only have pins for one USB 2.0 port
>> > (D-,D+). So is this a hub chip on the underside of the board, close
>> > to the
>> > USB ports? Can you read the label of that chip?
>> > And where are the other H616 USB pins routed to? Are they (ab-)using
>> > the
>> > PCIe pins of the CM4 connector? Or are they actually not used at all,
>> > and
>> > it's all one USB port through a by-4 hub?
>> > If you have a running system, "lsusb -t" should give you a clue which
>> > host
>> > ports are used and if there is a hub.
>> >
>> > Cheers,
>> > Andre
>> >
>> >> >> Manta only has 3 and 1 otg. But it has a switch to disable or
>> >> enable otg.
>> >> >
>> >> >What does the switch do, exactly? By definition OTG works fine in
>> >> both
>> >> >ways. And there are pins in the connector to decide the role.
>> >> The switch is just signal pin for RS2227. Its the multiplexer i
>> >> mentioned. It decides if we should have the pins wired to usb type C
>> >> port or normally to stm32 MCU. Thats all it does.
>> >> >
>> >> >Allwinner actually goes one step further and provides a full HCI
>> >> to the
>> >> >same PHY that the MUSB OTG controller is connected to, so you
>> >> don't need
>> >> >to live with the sometimes limited performance of the MUSB host
>> >> mode
>> >> >(which we drive without DMA). Not sure if that is the case or a
>> >> problem on
>> >> >the RPi4.
>> >> >
>> >> >> Im not opposed to splitting it up. It is probably a good idea.
>> >> >> I dont see how to resolve that switch on manta boards tho.
>> >> >
>> >> >If the Manta board is (almost) a superset of the Pi4B, then you can
>> >> >include the latter from there. Look at sun50i-a64-pine64-lts.dts or
>> >> >sun50i-h6-pine-h64-model-b.dts for examples.
>> >> >
>> >> >Cheers,
>> >> >Andre.
>> >> >
>> >> Yep i will split it into SoM boards.
>> >> >> >> The only exception to conversion are the LEDs on the boards
>> >> but since both
>> >> >> >> adapter and manta boards have them this yet again eliminates
>> >> need for
>> >> >> >> parent style DT.
>> >> >> >>
>> >> >> >> Best regards,
>> >> >> >> Martin
>> >> >> >>
>> >> >> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara
>> >> <andre.przywara@arm.com>
>> >> >> >> wrote:
>> >> >> >>
>> >> >> >> > On Mon, 14 Nov 2022 22:44:49 +0100
>> >> >> >> > Martin Botka <martin.botka@somainline.org> wrote:
>> >> >> >> >
>> >> >> >> > > CB1 is Compute Module style board that plugs into Rpi
>> >> board style
>> >> >> >> > adapter or
>> >> >> >> > > Manta 3D printer boards (M4P/M8P).
>> >> >> >> > >
>> >> >> >> > > The board has:
>> >> >> >> > > H616 SoC
>> >> >> >> > > 1GB of RAM
>> >> >> >> > > AXP313A PMIC
>> >> >> >> > >
>> >> >> >> > > And the actual boards that CB1 plugs in are just
>> >> extension to it with
>> >> >> >> > ports and
>> >> >> >> > > thus are not split in DT.
>> >> >> >> >
>> >> >> >> > I don't really understand that sentence. There is some
>> >> precedent for a
>> >> >> >> > SoM/board split, look at the sun50i-a64-sopine or
>> >> >> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this
>> >> correctly, then
>> >> >> >> > there are *two* boards available for the same CB1 SoM, the
>> >> PI4B and the
>> >> >> >> > Manta board? Which would a strong case for a SoM .dtsi,
>> >> plus the one
>> >> >> >> > or two board .dts files.
>> >> >> >> > I am just not sure whether that relation to the Pi4-CM is
>> >> helpful or
>> >> >> >> > just complicates things...
>> >> >> >> >
>> >> >> >> > Cheers,
>> >> >> >> > Andre
>> >> >> >> >
>> >> >> >> > >
>> >> >> >> > > Boards have:
>> >> >> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> >> >> >> > > SDcard slot for loading images.
>> >> >> >> > > Ethernet port wired to the internal PHY.
>> >> >> >> > > 2x HDMI 2.0.
>> >> >> >> > > Power and Status LEDs.
>> >> >> >> > >
>> >> >> >> > > Currently working:
>> >> >> >> > > Booting
>> >> >> >> > > USB
>> >> >> >> > > UART
>> >> >> >> > >
>> >> >> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> >> >> >> > > ---
>> >> >> >> > > Changes in V2:
>> >> >> >> > > Add proper board compatible
>> >> >> >> > > Add regulator prefix for vcc5v
>> >> >> >> > > Drop okay status from PMIC
>> >> >> >> > > Drop standby_param
>> >> >> >> > > Changes in V3:
>> >> >> >> > > Change copyright to me
>> >> >> >> > > regulator_vcc5v to regulator-vcc5v
>> >> >> >> > > Drop ehci0 and ohci0
>> >> >> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> >> >> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
>> >> ++++++++++++++++++
>> >> >> >> > > 2 files changed, 179 insertions(+)
>> >> >> >> > > create mode 100644
>> >> >> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> >> > >
>> >> >> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> >> > b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> >> >> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> >> > > new file mode 100644
>> >> >> >> > > index 000000000000..86b5aca9b53e
>> >> >> >> > > --- /dev/null
>> >> >> >> > > +++
>> >> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> >> > > @@ -0,0 +1,178 @@
>> >> >> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> >> >> >> > > +/*
>> >> >> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> >> >> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> >> >> >> > > +
>> >> >> >> > > + aliases {
>> >> >> >> > > + serial0 = &uart0;
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + chosen {
>> >> >> >> > > + stdout-path = "serial0:115200n8";
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + leds {
>> >> >> >> > > + compatible = "gpio-leds";
>> >> >> >> > > +
>> >> >> >> > > + led-0 {
>> >> >> >> > > + function = LED_FUNCTION_POWER;
>> >> >> >> > > + color = <LED_COLOR_ID_RED>;
>> >> >> >> > > + gpios = <&pio 2 12
>> >> GPIO_ACTIVE_HIGH>; /* PC12 */
>> >> >> >> > > + default-state = "on";
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + led-1 {
>> >> >> >> > > + function = LED_FUNCTION_STATUS;
>> >> >> >> > > + color = <LED_COLOR_ID_GREEN>;
>> >> >> >> > > + gpios = <&pio 2 13
>> >> GPIO_ACTIVE_HIGH>; /* PC13 */
>> >> >> >> > > + };
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + 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 = <®_vcc5v>;
>> >> >> >> > > + enable-active-high;
>> >> >> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /*
>> >> PC16 */
>> >> >> >> > > + };
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&ehci1 {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&ehci2 {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&ehci3 {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&mmc0 {
>> >> >> >> > > + vmmc-supply = <®_dldo1>;
>> >> >> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> >> >> >> > > + no-1-8-v;
>> >> >> >> > > + bus-width = <4>;
>> >> >> >> > > + status = "disabled";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&ohci1 {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&ohci2 {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&ohci3 {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&r_i2c {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +
>> >> >> >> > > + axp1530: pmic@36 {
>> >> >> >> > > + compatible = "x-powers,axp1530";
>> >> >> >> > > + reg = <0x36>;
>> >> >> >> > > + wakeup-source;
>> >> >> >> > > +
>> >> >> >> > > + regulators{
>> >> >> >> > > + reg_dcdc1: dcdc1 {
>> >> >> >> > > + regulator-name =
>> >> "axp1530-dcdc1";
>> >> >> >> > > + regulator-min-microvolt =
>> >> <500000>;
>> >> >> >> > > + regulator-max-microvolt =
>> >> <3400000>;
>> >> >> >> > > + regulator-step-delay-us =
>> >> <25>;
>> >> >> >> > > + regulator-final-delay-us =
>> >> <50>;
>> >> >> >> > > + regulator-always-on;
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + reg_dcdc2: dcdc2 {
>> >> >> >> > > + regulator-name =
>> >> "axp1530-dcdc2";
>> >> >> >> > > + regulator-min-microvolt =
>> >> <500000>;
>> >> >> >> > > + regulator-max-microvolt =
>> >> <1540000>;
>> >> >> >> > > + regulator-step-delay-us =
>> >> <25>;
>> >> >> >> > > + regulator-final-delay-us =
>> >> <50>;
>> >> >> >> > > + regulator-ramp-delay =
>> >> <200>;
>> >> >> >> > > + regulator-always-on;
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + reg_dcdc3: dcdc3 {
>> >> >> >> > > + regulator-name =
>> >> "axp1530-dcdc3";
>> >> >> >> > > + regulator-min-microvolt =
>> >> <500000>;
>> >> >> >> > > + regulator-max-microvolt =
>> >> <1840000>;
>> >> >> >> > > + regulator-step-delay-us =
>> >> <25>;
>> >> >> >> > > + regulator-final-delay-us =
>> >> <50>;
>> >> >> >> > > + regulator-always-on;
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + reg_aldo1: ldo1 {
>> >> >> >> > > + regulator-name =
>> >> "axp1530-aldo1";
>> >> >> >> > > + regulator-min-microvolt =
>> >> <1800000>;
>> >> >> >> > > + regulator-max-microvolt =
>> >> <1800000>;
>> >> >> >> > > + regulator-step-delay-us =
>> >> <25>;
>> >> >> >> > > + regulator-final-delay-us =
>> >> <50>;
>> >> >> >> > > + regulator-always-on;
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + reg_dldo1: ldo2 {
>> >> >> >> > > + regulator-name =
>> >> "axp1530-dldo1";
>> >> >> >> > > + regulator-min-microvolt =
>> >> <3300000>;
>> >> >> >> > > + regulator-max-microvolt =
>> >> <3300000>;
>> >> >> >> > > + regulator-step-delay-us =
>> >> <25>;
>> >> >> >> > > + regulator-final-delay-us =
>> >> <50>;
>> >> >> >> > > + regulator-always-on;
>> >> >> >> > > + };
>> >> >> >> > > + };
>> >> >> >> > > + };
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&uart0 {
>> >> >> >> > > + pinctrl-names = "default";
>> >> >> >> > > + pinctrl-0 = <&uart0_ph_pins>;
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&usbotg {
>> >> >> >> > > + /*
>> >> >> >> > > + * PHY0 pins are connected to a USB-C socket, but a
>> >> role switch
>> >> >> >> > > + * is not implemented: both CC pins are pulled to
>> >> GND.
>> >> >> >> > > + * The VBUS pins power the device, so a fixed
>> >> peripheral mode
>> >> >> >> > > + * is the best choice.
>> >> >> >> > > + * The board can be powered via GPIOs, in this case
>> >> port0 *can*
>> >> >> >> > > + * act as a host (with a cable/adapter ignoring
>> >> CC), as VBUS is
>> >> >> >> > > + * then provided by the GPIOs. Any user of this
>> >> setup would
>> >> >> >> > > + * need to adjust the DT accordingly: dr_mode set
>> >> to "host",
>> >> >> >> > > + * enabling OHCI0 and EHCI0.
>> >> >> >> > > + */
>> >> >> >> > > + dr_mode = "peripheral";
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&usbphy {
>> >> >> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> >
>> >> >> >> >
>> >> >> >
>> >> >
>> >
>> And yes there should be CM4 and CB1 DT for these boards.
>> But since i do not own CM4. I will only create CB1 version of this DT.
>
>That's the interesting part: there is already a DT for the CM4:
>arch/arm/boot/dts/bcm2711-rpi-cm4.dtsi
>Theoretically you should be able to include this .dtsi instead of your
>cb1.dtsi into the board .dts, and it should work(TM). Now I don't know if
>this has ever been done before, but I would imagine this to not compile,
>as the references are not the same, and the peripherals being rather
>different anyway.
>So let's for a moment pretend we can only plug the CB1 in ;-)
>
>As for the same DT between the Manta and RPi4: let's just start with one.
>If the other one is indeed identical (thought they look very different to
>me!), we just might not bother with upstreaming the other one.
>Should there be differences (which could be an LED wired differently), and
>people care, we can always add a second .dts, and include the first one.
>
>As to which board to upstream: I am a bit torn between the more practical
>RPi4 board and the fact that you actually own the Manta board. I guess we
>should play it safe, and you upstream what you have and can test.
>
>Cheers,
>Andre
They do look different ofc. One has a full blown 3D printer board attached to it :) (which just occupies the 1 USB slot on the hub)
On the rest i fully agree.
Cheers,
Martin
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-15 17:32 ` Martin Botka
0 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 17:32 UTC (permalink / raw)
To: Andre Przywara
Cc: Martin Botka, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Maxime Ripard,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, Linux Kernel Mailing List
On November 15, 2022 6:25:01 PM GMT+01:00, Andre Przywara <andre.przywara@arm.com> wrote:
>On Tue, 15 Nov 2022 18:02:43 +0100
>Martin Botka <martin.botka@somainline.org> wrote:
>
>> On Tue, Nov 15 2022 at 02:27:14 PM +00:00:00, Andre Przywara
>> <andre.przywara@arm.com> wrote:
>> > On Tue, 15 Nov 2022 12:38:59 +0100
>> > Martin Botka <martin.botka@somainline.org> wrote:
>> >
>> > Hi Martin,
>> >
>> >> On November 15, 2022 11:33:07 AM GMT+01:00, Andre Przywara
>> >> <andre.przywara@arm.com> wrote:
>> >> >On Tue, 15 Nov 2022 09:24:04 +0100
>> >> >Martin Botka <martin.botka@somainline.org> wrote:
>> >> >
>> >> >Hi,
>> >> >
>> >> >> On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara
>> >> <andre.przywara@arm.com> wrote:
>> >> >> >On Tue, 15 Nov 2022 00:44:46 +0100
>> >> >> >Martin Botka <martin.botka1@gmail.com> wrote:
>> >> >> >
>> >> >> >Hi Martin,
>> >> >> >
>> >> >> >> I can totally understand how this can get confusing.
>> >> >> >>
>> >> >> >> Basically because of the Rpi shortage biqu decided to make an
>> >> Rpi
>> >> >> >> alternative.
>> >> >> >>
>> >> >> >> So they made CB1 which is compute module style board.
>> >> >> >>
>> >> >> >> And they made 3 other boards where CB1 or Rpi CM4 can be
>> >> plugged in. The 3
>> >> >> >> boards are:
>> >> >> >>
>> >> >> >> Rpi adapter which takes the Compute module style boards and
>> >> turns them into
>> >> >> >> SBC style with basically identical size and etc to Rpi 4.
>> >> >> >>
>> >> >> >> Then we have Manta M8P and M4P. These boards are MCUs for a
>> >> 3D printer. But
>> >> >> >> they were made for Klipper use case which requires a computer
>> >> or SBC
>> >> >> >> (Usually Rpi4). They combined it into 1 board.
>> >> >> >> Where you get the MCU and you can plug in CM4 or CB1
>> >> >> >
>> >> >> >Thanks for the explanations! I was guessing along those
>> >> shortage lines,
>> >> >> >since the H616 is quite a step down from the RPi4CM, though
>> >> probably
>> >> >> >still enough for driving a 3D printer.
>> >> >> Mostly yes
>> >> >> >
>> >> >> >> All these boards are basically taking the pins and routing
>> >> them to ports.
>> >> >> >
>> >> >> >Yes, this is what those SoM carrier boards do ;-)
>> >> >> :)
>> >> >> >
>> >> >> >> There is nearly 0 chips for conversion or processing of the
>> >> pins from CB1
>> >> >> >> or CM4 thus i do not see a reason for having parent dtsi and
>> >> dts for the
>> >> >> >> adapter and Manta boards.
>> >> >> >
>> >> >> >And the DT does not need to describe "chips" only, a lot of DT
>> >> nodes
>> >> >> >are about connectors, and which ports and which exact pins (out
>> >> of the
>> >> >> >possible pinmuxes) are actually used. The SoM itself mostly
>> >> exposes
>> >> >> >just pins, and the board DT describes how these pins are used
>> >> (GPIO or
>> >> >> >special function, for instance).
>> >> >> >
>> >> >> >So did you try to split this up? How would that look?
>> >> >>
>> >> >> The main difference between adapter and Manta boards is that
>> >> adapter has 4x USB.
>> >> >
>> >> >So those are two double-type-A sockets? This is not really what
>> >> the DT
>> >> >below describes? It's perfectly fine to fix USB0 to host mode, we
>> >> do this
>> >> >on the Pine64 boards (both A64 and H6), for instance.
>> >>
>> >> Yes. But the third and fourth is also used. Third is done in 2.54
>> >> 4p connector (just pins on board) and fourth is connected directly
>> >> to manta stm32 MCU. So all 4 are host.
>> >
>> > Wait, so you are talking about the Manta board now? I see two
>> > sockets, the
>> > 2.54mm headers and the STM32 there, but the Pi4B is quite different in
>> > that respect: I see four(!) USB type-A sockets (two dual-port stacks).
>> > Plus the CM4 connector seems to only have pins for one USB 2.0 port
>> > (D-,D+). So is this a hub chip on the underside of the board, close
>> > to the
>> > USB ports? Can you read the label of that chip?
>> > And where are the other H616 USB pins routed to? Are they (ab-)using
>> > the
>> > PCIe pins of the CM4 connector? Or are they actually not used at all,
>> > and
>> > it's all one USB port through a by-4 hub?
>> > If you have a running system, "lsusb -t" should give you a clue which
>> > host
>> > ports are used and if there is a hub.
>> >
>> > Cheers,
>> > Andre
>> >
>> >> >> Manta only has 3 and 1 otg. But it has a switch to disable or
>> >> enable otg.
>> >> >
>> >> >What does the switch do, exactly? By definition OTG works fine in
>> >> both
>> >> >ways. And there are pins in the connector to decide the role.
>> >> The switch is just signal pin for RS2227. Its the multiplexer i
>> >> mentioned. It decides if we should have the pins wired to usb type C
>> >> port or normally to stm32 MCU. Thats all it does.
>> >> >
>> >> >Allwinner actually goes one step further and provides a full HCI
>> >> to the
>> >> >same PHY that the MUSB OTG controller is connected to, so you
>> >> don't need
>> >> >to live with the sometimes limited performance of the MUSB host
>> >> mode
>> >> >(which we drive without DMA). Not sure if that is the case or a
>> >> problem on
>> >> >the RPi4.
>> >> >
>> >> >> Im not opposed to splitting it up. It is probably a good idea.
>> >> >> I dont see how to resolve that switch on manta boards tho.
>> >> >
>> >> >If the Manta board is (almost) a superset of the Pi4B, then you can
>> >> >include the latter from there. Look at sun50i-a64-pine64-lts.dts or
>> >> >sun50i-h6-pine-h64-model-b.dts for examples.
>> >> >
>> >> >Cheers,
>> >> >Andre.
>> >> >
>> >> Yep i will split it into SoM boards.
>> >> >> >> The only exception to conversion are the LEDs on the boards
>> >> but since both
>> >> >> >> adapter and manta boards have them this yet again eliminates
>> >> need for
>> >> >> >> parent style DT.
>> >> >> >>
>> >> >> >> Best regards,
>> >> >> >> Martin
>> >> >> >>
>> >> >> >> On Tue, Nov 15, 2022, 12:32 AM Andre Przywara
>> >> <andre.przywara@arm.com>
>> >> >> >> wrote:
>> >> >> >>
>> >> >> >> > On Mon, 14 Nov 2022 22:44:49 +0100
>> >> >> >> > Martin Botka <martin.botka@somainline.org> wrote:
>> >> >> >> >
>> >> >> >> > > CB1 is Compute Module style board that plugs into Rpi
>> >> board style
>> >> >> >> > adapter or
>> >> >> >> > > Manta 3D printer boards (M4P/M8P).
>> >> >> >> > >
>> >> >> >> > > The board has:
>> >> >> >> > > H616 SoC
>> >> >> >> > > 1GB of RAM
>> >> >> >> > > AXP313A PMIC
>> >> >> >> > >
>> >> >> >> > > And the actual boards that CB1 plugs in are just
>> >> extension to it with
>> >> >> >> > ports and
>> >> >> >> > > thus are not split in DT.
>> >> >> >> >
>> >> >> >> > I don't really understand that sentence. There is some
>> >> precedent for a
>> >> >> >> > SoM/board split, look at the sun50i-a64-sopine or
>> >> >> >> > sun50i-h5-emlid-neutis-n5 files. And if I see this
>> >> correctly, then
>> >> >> >> > there are *two* boards available for the same CB1 SoM, the
>> >> PI4B and the
>> >> >> >> > Manta board? Which would a strong case for a SoM .dtsi,
>> >> plus the one
>> >> >> >> > or two board .dts files.
>> >> >> >> > I am just not sure whether that relation to the Pi4-CM is
>> >> helpful or
>> >> >> >> > just complicates things...
>> >> >> >> >
>> >> >> >> > Cheers,
>> >> >> >> > Andre
>> >> >> >> >
>> >> >> >> > >
>> >> >> >> > > Boards have:
>> >> >> >> > > 4x (3x for Manta boards) USB and 1 USB OTG.
>> >> >> >> > > SDcard slot for loading images.
>> >> >> >> > > Ethernet port wired to the internal PHY.
>> >> >> >> > > 2x HDMI 2.0.
>> >> >> >> > > Power and Status LEDs.
>> >> >> >> > >
>> >> >> >> > > Currently working:
>> >> >> >> > > Booting
>> >> >> >> > > USB
>> >> >> >> > > UART
>> >> >> >> > >
>> >> >> >> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> >> >> >> > > ---
>> >> >> >> > > Changes in V2:
>> >> >> >> > > Add proper board compatible
>> >> >> >> > > Add regulator prefix for vcc5v
>> >> >> >> > > Drop okay status from PMIC
>> >> >> >> > > Drop standby_param
>> >> >> >> > > Changes in V3:
>> >> >> >> > > Change copyright to me
>> >> >> >> > > regulator_vcc5v to regulator-vcc5v
>> >> >> >> > > Drop ehci0 and ohci0
>> >> >> >> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> >> >> >> > > .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
>> >> ++++++++++++++++++
>> >> >> >> > > 2 files changed, 179 insertions(+)
>> >> >> >> > > create mode 100644
>> >> >> >> > arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> >> > >
>> >> >> >> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> >> > b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> >> > > index 6a96494a2e0a..223f1be73541 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-biqu-cb1.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-biqu-cb1.dts
>> >> >> >> > b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> >> > > new file mode 100644
>> >> >> >> > > index 000000000000..86b5aca9b53e
>> >> >> >> > > --- /dev/null
>> >> >> >> > > +++
>> >> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> >> >> > > @@ -0,0 +1,178 @@
>> >> >> >> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> >> >> >> > > +/*
>> >> >> >> > > + * Copyright (C) 2022 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 = "BIQU CB1";
>> >> >> >> > > + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> >> >> >> > > +
>> >> >> >> > > + aliases {
>> >> >> >> > > + serial0 = &uart0;
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + chosen {
>> >> >> >> > > + stdout-path = "serial0:115200n8";
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + leds {
>> >> >> >> > > + compatible = "gpio-leds";
>> >> >> >> > > +
>> >> >> >> > > + led-0 {
>> >> >> >> > > + function = LED_FUNCTION_POWER;
>> >> >> >> > > + color = <LED_COLOR_ID_RED>;
>> >> >> >> > > + gpios = <&pio 2 12
>> >> GPIO_ACTIVE_HIGH>; /* PC12 */
>> >> >> >> > > + default-state = "on";
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + led-1 {
>> >> >> >> > > + function = LED_FUNCTION_STATUS;
>> >> >> >> > > + color = <LED_COLOR_ID_GREEN>;
>> >> >> >> > > + gpios = <&pio 2 13
>> >> GPIO_ACTIVE_HIGH>; /* PC13 */
>> >> >> >> > > + };
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + 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 = <®_vcc5v>;
>> >> >> >> > > + enable-active-high;
>> >> >> >> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /*
>> >> PC16 */
>> >> >> >> > > + };
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&ehci1 {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&ehci2 {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&ehci3 {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&mmc0 {
>> >> >> >> > > + vmmc-supply = <®_dldo1>;
>> >> >> >> > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> >> >> >> > > + no-1-8-v;
>> >> >> >> > > + bus-width = <4>;
>> >> >> >> > > + status = "disabled";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&ohci1 {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&ohci2 {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&ohci3 {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&r_i2c {
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +
>> >> >> >> > > + axp1530: pmic@36 {
>> >> >> >> > > + compatible = "x-powers,axp1530";
>> >> >> >> > > + reg = <0x36>;
>> >> >> >> > > + wakeup-source;
>> >> >> >> > > +
>> >> >> >> > > + regulators{
>> >> >> >> > > + reg_dcdc1: dcdc1 {
>> >> >> >> > > + regulator-name =
>> >> "axp1530-dcdc1";
>> >> >> >> > > + regulator-min-microvolt =
>> >> <500000>;
>> >> >> >> > > + regulator-max-microvolt =
>> >> <3400000>;
>> >> >> >> > > + regulator-step-delay-us =
>> >> <25>;
>> >> >> >> > > + regulator-final-delay-us =
>> >> <50>;
>> >> >> >> > > + regulator-always-on;
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + reg_dcdc2: dcdc2 {
>> >> >> >> > > + regulator-name =
>> >> "axp1530-dcdc2";
>> >> >> >> > > + regulator-min-microvolt =
>> >> <500000>;
>> >> >> >> > > + regulator-max-microvolt =
>> >> <1540000>;
>> >> >> >> > > + regulator-step-delay-us =
>> >> <25>;
>> >> >> >> > > + regulator-final-delay-us =
>> >> <50>;
>> >> >> >> > > + regulator-ramp-delay =
>> >> <200>;
>> >> >> >> > > + regulator-always-on;
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + reg_dcdc3: dcdc3 {
>> >> >> >> > > + regulator-name =
>> >> "axp1530-dcdc3";
>> >> >> >> > > + regulator-min-microvolt =
>> >> <500000>;
>> >> >> >> > > + regulator-max-microvolt =
>> >> <1840000>;
>> >> >> >> > > + regulator-step-delay-us =
>> >> <25>;
>> >> >> >> > > + regulator-final-delay-us =
>> >> <50>;
>> >> >> >> > > + regulator-always-on;
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + reg_aldo1: ldo1 {
>> >> >> >> > > + regulator-name =
>> >> "axp1530-aldo1";
>> >> >> >> > > + regulator-min-microvolt =
>> >> <1800000>;
>> >> >> >> > > + regulator-max-microvolt =
>> >> <1800000>;
>> >> >> >> > > + regulator-step-delay-us =
>> >> <25>;
>> >> >> >> > > + regulator-final-delay-us =
>> >> <50>;
>> >> >> >> > > + regulator-always-on;
>> >> >> >> > > + };
>> >> >> >> > > +
>> >> >> >> > > + reg_dldo1: ldo2 {
>> >> >> >> > > + regulator-name =
>> >> "axp1530-dldo1";
>> >> >> >> > > + regulator-min-microvolt =
>> >> <3300000>;
>> >> >> >> > > + regulator-max-microvolt =
>> >> <3300000>;
>> >> >> >> > > + regulator-step-delay-us =
>> >> <25>;
>> >> >> >> > > + regulator-final-delay-us =
>> >> <50>;
>> >> >> >> > > + regulator-always-on;
>> >> >> >> > > + };
>> >> >> >> > > + };
>> >> >> >> > > + };
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&uart0 {
>> >> >> >> > > + pinctrl-names = "default";
>> >> >> >> > > + pinctrl-0 = <&uart0_ph_pins>;
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&usbotg {
>> >> >> >> > > + /*
>> >> >> >> > > + * PHY0 pins are connected to a USB-C socket, but a
>> >> role switch
>> >> >> >> > > + * is not implemented: both CC pins are pulled to
>> >> GND.
>> >> >> >> > > + * The VBUS pins power the device, so a fixed
>> >> peripheral mode
>> >> >> >> > > + * is the best choice.
>> >> >> >> > > + * The board can be powered via GPIOs, in this case
>> >> port0 *can*
>> >> >> >> > > + * act as a host (with a cable/adapter ignoring
>> >> CC), as VBUS is
>> >> >> >> > > + * then provided by the GPIOs. Any user of this
>> >> setup would
>> >> >> >> > > + * need to adjust the DT accordingly: dr_mode set
>> >> to "host",
>> >> >> >> > > + * enabling OHCI0 and EHCI0.
>> >> >> >> > > + */
>> >> >> >> > > + dr_mode = "peripheral";
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> > > +
>> >> >> >> > > +&usbphy {
>> >> >> >> > > + usb1_vbus-supply = <®_usb1_vbus>;
>> >> >> >> > > + status = "okay";
>> >> >> >> > > +};
>> >> >> >> >
>> >> >> >> >
>> >> >> >
>> >> >
>> >
>> And yes there should be CM4 and CB1 DT for these boards.
>> But since i do not own CM4. I will only create CB1 version of this DT.
>
>That's the interesting part: there is already a DT for the CM4:
>arch/arm/boot/dts/bcm2711-rpi-cm4.dtsi
>Theoretically you should be able to include this .dtsi instead of your
>cb1.dtsi into the board .dts, and it should work(TM). Now I don't know if
>this has ever been done before, but I would imagine this to not compile,
>as the references are not the same, and the peripherals being rather
>different anyway.
>So let's for a moment pretend we can only plug the CB1 in ;-)
>
>As for the same DT between the Manta and RPi4: let's just start with one.
>If the other one is indeed identical (thought they look very different to
>me!), we just might not bother with upstreaming the other one.
>Should there be differences (which could be an LED wired differently), and
>people care, we can always add a second .dts, and include the first one.
>
>As to which board to upstream: I am a bit torn between the more practical
>RPi4 board and the fact that you actually own the Manta board. I guess we
>should play it safe, and you upstream what you have and can test.
>
>Cheers,
>Andre
They do look different ofc. One has a full blown 3D printer board attached to it :) (which just occupies the 1 USB slot on the hub)
On the rest i fully agree.
Cheers,
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-14 22:54 ` Martin Botka
@ 2022-11-15 21:34 ` Jernej Škrabec
-1 siblings, 0 replies; 38+ messages in thread
From: Jernej Škrabec @ 2022-11-15 21:34 UTC (permalink / raw)
To: Martin Botka
Cc: martin.botka1, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Samuel Holland, Maxime Ripard, Andre Przywara,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
Dne ponedeljek, 14. november 2022 ob 23:54:46 CET je Martin Botka napisal(a):
> On Mon, Nov 14 2022 at 11:30:17 PM +01:00:00, Jernej Škrabec
>
> <jernej.skrabec@gmail.com> wrote:
> > Hi Martin,
> >
> > I was just writing new e-mail as response to v2. You should wait at
> > least a
> > day or two, usually more, before sending new version. Others will
> > likely have
> > some more comments. And there is also no rush. Until PMIC series is
> > merged,
> > this will not go anywhere. Since there is only this week until cut
> > off date for
> > DT updates for kernel 6.2, it's most likely that this will land in
> > 6.3. And
> > that gives as a few weeks (month) more.
>
> Yep. Was hoping for 5.2 thus the frequent updates. Will take it slow
> then since 5.3 :)
You're way too late for 5.x series :) Anyway, 6.2 would be possible if you
would have almost flawless patch with no additional dependencies, but that is
not the case here. I'll send DT pull requests for 6.2 at the end of this week.
Best regards,
Jernej
>
> > See comments below.
> >
> > Dne ponedeljek, 14. november 2022 ob 22:44:49 CET je Martin Botka
> >
> > napisal(a):
> >> CB1 is Compute Module style board that plugs into Rpi board style
> >>
> >> adapter or
> >>
> >> Manta 3D printer boards (M4P/M8P).
> >>
> >> The board has:
> >> H616 SoC
> >> 1GB of RAM
> >> AXP313A PMIC
> >>
> >> And the actual boards that CB1 plugs in are just extension to it
> >>
> >> with ports
> >>
> >> and thus are not split in DT.
> >>
> >> Boards have:
> >> 4x (3x for Manta boards) USB and 1 USB OTG.
> >> SDcard slot for loading images.
> >> Ethernet port wired to the internal PHY.
> >> 2x HDMI 2.0.
> >
> > H616 has only one HDMI output. Unless there is some additional chip
> > for some
> > conversion, only one HDMI port can work.
>
> Yes correct. But the Rpi adapter and Manta boards also support
> Rpi Compute Module 4 which has 2 HDMI outputs.
> The chip itself ofc doesnt support this on CB1. Same goes for DSI/CSI
> ports
> on the boards and the 4x USB on Rpi adapter.
>
> It is indeed a bit of a mess.
>
> >> Power and Status LEDs.
> >>
> >> Currently working:
> >> Booting
> >> USB
> >> UART
> >>
> >> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> >> ---
> >> Changes in V2:
> >> Add proper board compatible
> >> Add regulator prefix for vcc5v
> >> Drop okay status from PMIC
> >> Drop standby_param
> >> Changes in V3:
> >> Change copyright to me
> >> regulator_vcc5v to regulator-vcc5v
> >> Drop ehci0 and ohci0
> >>
> >> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> >> .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
> >>
> >> ++++++++++++++++++
> >>
> >> 2 files changed, 179 insertions(+)
> >> create mode 100644
> >>
> >> arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >>
> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> >> b/arch/arm64/boot/dts/allwinner/Makefile index
> >>
> >> 6a96494a2e0a..223f1be73541
> >>
> >> 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-biqu-cb1.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-biqu-cb1.dts
> >> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts new file
> >>
> >> mode
> >>
> >> 100644
> >> index 000000000000..86b5aca9b53e
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> @@ -0,0 +1,178 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> >> +/*
> >> + * Copyright (C) 2022 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 = "BIQU CB1";
> >> + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> >> +
> >> + aliases {
> >> + serial0 = &uart0;
> >> + };
> >> +
> >> + chosen {
> >> + stdout-path = "serial0:115200n8";
> >> + };
> >> +
> >> + leds {
> >> + compatible = "gpio-leds";
> >> +
> >> + led-0 {
> >> + function = LED_FUNCTION_POWER;
> >> + color = <LED_COLOR_ID_RED>;
> >> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /*
> >
> > PC12 */
> >
> >> + default-state = "on";
> >> + };
> >> +
> >> + led-1 {
> >> + function = LED_FUNCTION_STATUS;
> >> + color = <LED_COLOR_ID_GREEN>;
> >> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /*
> >
> > PC13 */
> >
> >> + };
> >> + };
> >> +
> >> + 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 = <®_vcc5v>;
> >> + enable-active-high;
> >> + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> >> + };
> >> +};
> >> +
> >> +&ehci1 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&ehci2 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&ehci3 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&mmc0 {
> >> + vmmc-supply = <®_dldo1>;
> >> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> >> + no-1-8-v;
> >
> > Above property is not needed. If you don't provide vqmmc-supply with
> > 1.8 V
> > regulator, it won't be used.
> >
> >> + bus-width = <4>;
> >> + status = "disabled";
> >
> > Why is set to disabled? If it's not a typo, remove whole node. It
> > could be
> > added later when it works.
>
> Would not removing it also make PMIC node useless as the regulators
> wont be used and thus
> should be technically removed ?
>
> >> +};
> >> +
> >> +&ohci1 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&ohci2 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&ohci3 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&r_i2c {
> >> + status = "okay";
> >> +
> >> + axp1530: pmic@36 {
> >> + compatible = "x-powers,axp1530";
> >
> > I just checked datasheet and it really seems that it supports only
> > I2C.
> > Anyway, rather than using axp1530 compatible, introduce axp313a
> > compatible
> > instead.
>
> Will do in V2 for drivers later.
>
> >> + reg = <0x36>;
> >> + wakeup-source;
> >> +
> >> + regulators{
> >> + reg_dcdc1: dcdc1 {
> >> + regulator-name = "axp1530-
dcdc1";
> >> + regulator-min-microvolt =
> >
> > <500000>;
> >
> >> + regulator-max-microvolt =
> >
> > <3400000>;
> >
> > This one is most likely used by CPU. If so, you should set
> > appropriate range
> > according to CPU needs, which are 810 - 1100 mV.
> >
> >> + regulator-step-delay-us = <25>;
> >> + regulator-final-delay-us = <50>;
> >> + regulator-always-on;
> >> + };
> >> +
> >> + reg_dcdc2: dcdc2 {
> >> + regulator-name = "axp1530-
dcdc2";
> >> + regulator-min-microvolt =
> >
> > <500000>;
> >
> >> + regulator-max-microvolt =
> >
> > <1540000>;
> >
> > This one is most likely used by GPU. Its range must also be adjusted
> > to GPU
> > needs.
> >
> >> + regulator-step-delay-us = <25>;
> >> + regulator-final-delay-us = <50>;
> >> + regulator-ramp-delay = <200>;
> >> + regulator-always-on;
> >> + };
> >> +
> >> + reg_dcdc3: dcdc3 {
> >> + regulator-name = "axp1530-
dcdc3";
> >> + regulator-min-microvolt =
> >
> > <500000>;
> >
> >> + regulator-max-microvolt =
> >
> > <1840000>;
> >
> > This one looks like it supplies DRAM. You should set both min and max
> > to
> > actual DRAM needs.
> >
> >> + regulator-step-delay-us = <25>;
> >> + regulator-final-delay-us = <50>;
> >> + regulator-always-on;
> >> + };
> >> +
> >> + reg_aldo1: ldo1 {
> >
> > ldo1 -> aldo1
> >
> >> + regulator-name = "axp1530-
aldo1";
> >> + regulator-min-microvolt =
> >
> > <1800000>;
> >
> >> + regulator-max-microvolt =
> >
> > <1800000>;
> >
> >> + regulator-step-delay-us = <25>;
> >> + regulator-final-delay-us = <50>;
> >> + regulator-always-on;
> >> + };
> >> +
> >> + reg_dldo1: ldo2 {
> >
> > ldo2 -> dldo1
> >
> > Another issue I see is that you marked all regulators with
> > regulator-always-
> > on; While this works, I don't think this faithfully represent HW. For
> > example,
> > GPU regulator will be enabled by GPU driver when needed, so it
> > shouldn't be
> > marked with always on.
> >
> > There is also RTCLDO, but without schematic it's impossible to say if
> > it is
> > used or not.
> >
> > There are at least a few clues in AXP313A datasheet about which
> > regulator is
> > used for what. See chapter 7.5 in
> > https://github.com/bigtreetech/CB1-Kernel/
> > blob/kernel-5.16/docs/AXP313A%20datasheet%20V0.1%20-
> > %2020201105_draft%20version.pdf
>
> As for regulators themselves. I have kept them as what downstream
> kernel specifies.
> But until I have schematic in hand and can confirm that they actually
> used the correct regulators in
> the correct place i will stick to stock values. If they in the end
> decide to not supply schematic or etc
> to the public i can test with adjusted values.
>
> > Best regards,
> > Jernej
> >
> >> + regulator-name = "axp1530-
dldo1";
> >> + regulator-min-microvolt =
> >
> > <3300000>;
> >
> >> + regulator-max-microvolt =
> >
> > <3300000>;
> >
> >> + regulator-step-delay-us = <25>;
> >> + regulator-final-delay-us = <50>;
> >> + regulator-always-on;
> >> + };
> >> + };
> >> + };
> >> +};
> >> +
> >> +&uart0 {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&uart0_ph_pins>;
> >> + status = "okay";
> >> +};
> >> +
> >> +&usbotg {
> >> + /*
> >> + * PHY0 pins are connected to a USB-C socket, but a role switch
> >> + * is not implemented: both CC pins are pulled to GND.
> >> + * The VBUS pins power the device, so a fixed peripheral mode
> >> + * is the best choice.
> >> + * The board can be powered via GPIOs, in this case port0 *can*
> >> + * act as a host (with a cable/adapter ignoring CC), as VBUS is
> >> + * then provided by the GPIOs. Any user of this setup would
> >> + * need to adjust the DT accordingly: dr_mode set to "host",
> >> + * enabling OHCI0 and EHCI0.
> >> + */
> >> + dr_mode = "peripheral";
> >> + status = "okay";
> >> +};
> >> +
> >> +&usbphy {
> >> + usb1_vbus-supply = <®_usb1_vbus>;
> >> + status = "okay";
> >> +};
>
> Best Regards,
> Martin
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-15 21:34 ` Jernej Škrabec
0 siblings, 0 replies; 38+ messages in thread
From: Jernej Škrabec @ 2022-11-15 21:34 UTC (permalink / raw)
To: Martin Botka
Cc: martin.botka1, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Samuel Holland, Maxime Ripard, Andre Przywara,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
Dne ponedeljek, 14. november 2022 ob 23:54:46 CET je Martin Botka napisal(a):
> On Mon, Nov 14 2022 at 11:30:17 PM +01:00:00, Jernej Škrabec
>
> <jernej.skrabec@gmail.com> wrote:
> > Hi Martin,
> >
> > I was just writing new e-mail as response to v2. You should wait at
> > least a
> > day or two, usually more, before sending new version. Others will
> > likely have
> > some more comments. And there is also no rush. Until PMIC series is
> > merged,
> > this will not go anywhere. Since there is only this week until cut
> > off date for
> > DT updates for kernel 6.2, it's most likely that this will land in
> > 6.3. And
> > that gives as a few weeks (month) more.
>
> Yep. Was hoping for 5.2 thus the frequent updates. Will take it slow
> then since 5.3 :)
You're way too late for 5.x series :) Anyway, 6.2 would be possible if you
would have almost flawless patch with no additional dependencies, but that is
not the case here. I'll send DT pull requests for 6.2 at the end of this week.
Best regards,
Jernej
>
> > See comments below.
> >
> > Dne ponedeljek, 14. november 2022 ob 22:44:49 CET je Martin Botka
> >
> > napisal(a):
> >> CB1 is Compute Module style board that plugs into Rpi board style
> >>
> >> adapter or
> >>
> >> Manta 3D printer boards (M4P/M8P).
> >>
> >> The board has:
> >> H616 SoC
> >> 1GB of RAM
> >> AXP313A PMIC
> >>
> >> And the actual boards that CB1 plugs in are just extension to it
> >>
> >> with ports
> >>
> >> and thus are not split in DT.
> >>
> >> Boards have:
> >> 4x (3x for Manta boards) USB and 1 USB OTG.
> >> SDcard slot for loading images.
> >> Ethernet port wired to the internal PHY.
> >> 2x HDMI 2.0.
> >
> > H616 has only one HDMI output. Unless there is some additional chip
> > for some
> > conversion, only one HDMI port can work.
>
> Yes correct. But the Rpi adapter and Manta boards also support
> Rpi Compute Module 4 which has 2 HDMI outputs.
> The chip itself ofc doesnt support this on CB1. Same goes for DSI/CSI
> ports
> on the boards and the 4x USB on Rpi adapter.
>
> It is indeed a bit of a mess.
>
> >> Power and Status LEDs.
> >>
> >> Currently working:
> >> Booting
> >> USB
> >> UART
> >>
> >> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> >> ---
> >> Changes in V2:
> >> Add proper board compatible
> >> Add regulator prefix for vcc5v
> >> Drop okay status from PMIC
> >> Drop standby_param
> >> Changes in V3:
> >> Change copyright to me
> >> regulator_vcc5v to regulator-vcc5v
> >> Drop ehci0 and ohci0
> >>
> >> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> >> .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
> >>
> >> ++++++++++++++++++
> >>
> >> 2 files changed, 179 insertions(+)
> >> create mode 100644
> >>
> >> arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >>
> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> >> b/arch/arm64/boot/dts/allwinner/Makefile index
> >>
> >> 6a96494a2e0a..223f1be73541
> >>
> >> 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-biqu-cb1.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-biqu-cb1.dts
> >> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts new file
> >>
> >> mode
> >>
> >> 100644
> >> index 000000000000..86b5aca9b53e
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
> >> @@ -0,0 +1,178 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> >> +/*
> >> + * Copyright (C) 2022 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 = "BIQU CB1";
> >> + compatible = "biqu,cb1", "allwinner,sun50i-h616";
> >> +
> >> + aliases {
> >> + serial0 = &uart0;
> >> + };
> >> +
> >> + chosen {
> >> + stdout-path = "serial0:115200n8";
> >> + };
> >> +
> >> + leds {
> >> + compatible = "gpio-leds";
> >> +
> >> + led-0 {
> >> + function = LED_FUNCTION_POWER;
> >> + color = <LED_COLOR_ID_RED>;
> >> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /*
> >
> > PC12 */
> >
> >> + default-state = "on";
> >> + };
> >> +
> >> + led-1 {
> >> + function = LED_FUNCTION_STATUS;
> >> + color = <LED_COLOR_ID_GREEN>;
> >> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /*
> >
> > PC13 */
> >
> >> + };
> >> + };
> >> +
> >> + 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 = <®_vcc5v>;
> >> + enable-active-high;
> >> + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> >> + };
> >> +};
> >> +
> >> +&ehci1 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&ehci2 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&ehci3 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&mmc0 {
> >> + vmmc-supply = <®_dldo1>;
> >> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> >> + no-1-8-v;
> >
> > Above property is not needed. If you don't provide vqmmc-supply with
> > 1.8 V
> > regulator, it won't be used.
> >
> >> + bus-width = <4>;
> >> + status = "disabled";
> >
> > Why is set to disabled? If it's not a typo, remove whole node. It
> > could be
> > added later when it works.
>
> Would not removing it also make PMIC node useless as the regulators
> wont be used and thus
> should be technically removed ?
>
> >> +};
> >> +
> >> +&ohci1 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&ohci2 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&ohci3 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&r_i2c {
> >> + status = "okay";
> >> +
> >> + axp1530: pmic@36 {
> >> + compatible = "x-powers,axp1530";
> >
> > I just checked datasheet and it really seems that it supports only
> > I2C.
> > Anyway, rather than using axp1530 compatible, introduce axp313a
> > compatible
> > instead.
>
> Will do in V2 for drivers later.
>
> >> + reg = <0x36>;
> >> + wakeup-source;
> >> +
> >> + regulators{
> >> + reg_dcdc1: dcdc1 {
> >> + regulator-name = "axp1530-
dcdc1";
> >> + regulator-min-microvolt =
> >
> > <500000>;
> >
> >> + regulator-max-microvolt =
> >
> > <3400000>;
> >
> > This one is most likely used by CPU. If so, you should set
> > appropriate range
> > according to CPU needs, which are 810 - 1100 mV.
> >
> >> + regulator-step-delay-us = <25>;
> >> + regulator-final-delay-us = <50>;
> >> + regulator-always-on;
> >> + };
> >> +
> >> + reg_dcdc2: dcdc2 {
> >> + regulator-name = "axp1530-
dcdc2";
> >> + regulator-min-microvolt =
> >
> > <500000>;
> >
> >> + regulator-max-microvolt =
> >
> > <1540000>;
> >
> > This one is most likely used by GPU. Its range must also be adjusted
> > to GPU
> > needs.
> >
> >> + regulator-step-delay-us = <25>;
> >> + regulator-final-delay-us = <50>;
> >> + regulator-ramp-delay = <200>;
> >> + regulator-always-on;
> >> + };
> >> +
> >> + reg_dcdc3: dcdc3 {
> >> + regulator-name = "axp1530-
dcdc3";
> >> + regulator-min-microvolt =
> >
> > <500000>;
> >
> >> + regulator-max-microvolt =
> >
> > <1840000>;
> >
> > This one looks like it supplies DRAM. You should set both min and max
> > to
> > actual DRAM needs.
> >
> >> + regulator-step-delay-us = <25>;
> >> + regulator-final-delay-us = <50>;
> >> + regulator-always-on;
> >> + };
> >> +
> >> + reg_aldo1: ldo1 {
> >
> > ldo1 -> aldo1
> >
> >> + regulator-name = "axp1530-
aldo1";
> >> + regulator-min-microvolt =
> >
> > <1800000>;
> >
> >> + regulator-max-microvolt =
> >
> > <1800000>;
> >
> >> + regulator-step-delay-us = <25>;
> >> + regulator-final-delay-us = <50>;
> >> + regulator-always-on;
> >> + };
> >> +
> >> + reg_dldo1: ldo2 {
> >
> > ldo2 -> dldo1
> >
> > Another issue I see is that you marked all regulators with
> > regulator-always-
> > on; While this works, I don't think this faithfully represent HW. For
> > example,
> > GPU regulator will be enabled by GPU driver when needed, so it
> > shouldn't be
> > marked with always on.
> >
> > There is also RTCLDO, but without schematic it's impossible to say if
> > it is
> > used or not.
> >
> > There are at least a few clues in AXP313A datasheet about which
> > regulator is
> > used for what. See chapter 7.5 in
> > https://github.com/bigtreetech/CB1-Kernel/
> > blob/kernel-5.16/docs/AXP313A%20datasheet%20V0.1%20-
> > %2020201105_draft%20version.pdf
>
> As for regulators themselves. I have kept them as what downstream
> kernel specifies.
> But until I have schematic in hand and can confirm that they actually
> used the correct regulators in
> the correct place i will stick to stock values. If they in the end
> decide to not supply schematic or etc
> to the public i can test with adjusted values.
>
> > Best regards,
> > Jernej
> >
> >> + regulator-name = "axp1530-
dldo1";
> >> + regulator-min-microvolt =
> >
> > <3300000>;
> >
> >> + regulator-max-microvolt =
> >
> > <3300000>;
> >
> >> + regulator-step-delay-us = <25>;
> >> + regulator-final-delay-us = <50>;
> >> + regulator-always-on;
> >> + };
> >> + };
> >> + };
> >> +};
> >> +
> >> +&uart0 {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&uart0_ph_pins>;
> >> + status = "okay";
> >> +};
> >> +
> >> +&usbotg {
> >> + /*
> >> + * PHY0 pins are connected to a USB-C socket, but a role switch
> >> + * is not implemented: both CC pins are pulled to GND.
> >> + * The VBUS pins power the device, so a fixed peripheral mode
> >> + * is the best choice.
> >> + * The board can be powered via GPIOs, in this case port0 *can*
> >> + * act as a host (with a cable/adapter ignoring CC), as VBUS is
> >> + * then provided by the GPIOs. Any user of this setup would
> >> + * need to adjust the DT accordingly: dr_mode set to "host",
> >> + * enabling OHCI0 and EHCI0.
> >> + */
> >> + dr_mode = "peripheral";
> >> + status = "okay";
> >> +};
> >> +
> >> +&usbphy {
> >> + usb1_vbus-supply = <®_usb1_vbus>;
> >> + status = "okay";
> >> +};
>
> Best Regards,
> Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
2022-11-15 21:34 ` Jernej Škrabec
@ 2022-11-15 21:42 ` Martin Botka
-1 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 21:42 UTC (permalink / raw)
To: Jernej Škrabec
Cc: martin.botka1, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Samuel Holland, Maxime Ripard, Andre Przywara,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
On November 15, 2022 10:34:49 PM GMT+01:00, "Jernej Škrabec" <jernej.skrabec@gmail.com> wrote:
>Dne ponedeljek, 14. november 2022 ob 23:54:46 CET je Martin Botka napisal(a):
>> On Mon, Nov 14 2022 at 11:30:17 PM +01:00:00, Jernej Škrabec
>>
>> <jernej.skrabec@gmail.com> wrote:
>> > Hi Martin,
>> >
>> > I was just writing new e-mail as response to v2. You should wait at
>> > least a
>> > day or two, usually more, before sending new version. Others will
>> > likely have
>> > some more comments. And there is also no rush. Until PMIC series is
>> > merged,
>> > this will not go anywhere. Since there is only this week until cut
>> > off date for
>> > DT updates for kernel 6.2, it's most likely that this will land in
>> > 6.3. And
>> > that gives as a few weeks (month) more.
>>
>> Yep. Was hoping for 5.2 thus the frequent updates. Will take it slow
>> then since 5.3 :)
>
>You're way too late for 5.x series :) Anyway, 6.2 would be possible if you
>would have almost flawless patch with no additional dependencies, but that is
>not the case here. I'll send DT pull requests for 6.2 at the end of this week.
>
>Best regards,
>Jernej
Hehe yea :)
Very understandable.
Cheers,
Martin
>
>>
>> > See comments below.
>> >
>> > Dne ponedeljek, 14. november 2022 ob 22:44:49 CET je Martin Botka
>> >
>> > napisal(a):
>> >> CB1 is Compute Module style board that plugs into Rpi board style
>> >>
>> >> adapter or
>> >>
>> >> Manta 3D printer boards (M4P/M8P).
>> >>
>> >> The board has:
>> >> H616 SoC
>> >> 1GB of RAM
>> >> AXP313A PMIC
>> >>
>> >> And the actual boards that CB1 plugs in are just extension to it
>> >>
>> >> with ports
>> >>
>> >> and thus are not split in DT.
>> >>
>> >> Boards have:
>> >> 4x (3x for Manta boards) USB and 1 USB OTG.
>> >> SDcard slot for loading images.
>> >> Ethernet port wired to the internal PHY.
>> >> 2x HDMI 2.0.
>> >
>> > H616 has only one HDMI output. Unless there is some additional chip
>> > for some
>> > conversion, only one HDMI port can work.
>>
>> Yes correct. But the Rpi adapter and Manta boards also support
>> Rpi Compute Module 4 which has 2 HDMI outputs.
>> The chip itself ofc doesnt support this on CB1. Same goes for DSI/CSI
>> ports
>> on the boards and the 4x USB on Rpi adapter.
>>
>> It is indeed a bit of a mess.
>>
>> >> Power and Status LEDs.
>> >>
>> >> Currently working:
>> >> Booting
>> >> USB
>> >> UART
>> >>
>> >> Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> >> ---
>> >> Changes in V2:
>> >> Add proper board compatible
>> >> Add regulator prefix for vcc5v
>> >> Drop okay status from PMIC
>> >> Drop standby_param
>> >> Changes in V3:
>> >> Change copyright to me
>> >> regulator_vcc5v to regulator-vcc5v
>> >> Drop ehci0 and ohci0
>> >>
>> >> arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> >> .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
>> >>
>> >> ++++++++++++++++++
>> >>
>> >> 2 files changed, 179 insertions(+)
>> >> create mode 100644
>> >>
>> >> arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >>
>> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> b/arch/arm64/boot/dts/allwinner/Makefile index
>> >>
>> >> 6a96494a2e0a..223f1be73541
>> >>
>> >> 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-biqu-cb1.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-biqu-cb1.dts
>> >> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts new file
>> >>
>> >> mode
>> >>
>> >> 100644
>> >> index 000000000000..86b5aca9b53e
>> >> --- /dev/null
>> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> @@ -0,0 +1,178 @@
>> >> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> >> +/*
>> >> + * Copyright (C) 2022 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 = "BIQU CB1";
>> >> + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> >> +
>> >> + aliases {
>> >> + serial0 = &uart0;
>> >> + };
>> >> +
>> >> + chosen {
>> >> + stdout-path = "serial0:115200n8";
>> >> + };
>> >> +
>> >> + leds {
>> >> + compatible = "gpio-leds";
>> >> +
>> >> + led-0 {
>> >> + function = LED_FUNCTION_POWER;
>> >> + color = <LED_COLOR_ID_RED>;
>> >> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /*
>> >
>> > PC12 */
>> >
>> >> + default-state = "on";
>> >> + };
>> >> +
>> >> + led-1 {
>> >> + function = LED_FUNCTION_STATUS;
>> >> + color = <LED_COLOR_ID_GREEN>;
>> >> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /*
>> >
>> > PC13 */
>> >
>> >> + };
>> >> + };
>> >> +
>> >> + 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 = <®_vcc5v>;
>> >> + enable-active-high;
>> >> + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>> >> + };
>> >> +};
>> >> +
>> >> +&ehci1 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&ehci2 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&ehci3 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&mmc0 {
>> >> + vmmc-supply = <®_dldo1>;
>> >> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> >> + no-1-8-v;
>> >
>> > Above property is not needed. If you don't provide vqmmc-supply with
>> > 1.8 V
>> > regulator, it won't be used.
>> >
>> >> + bus-width = <4>;
>> >> + status = "disabled";
>> >
>> > Why is set to disabled? If it's not a typo, remove whole node. It
>> > could be
>> > added later when it works.
>>
>> Would not removing it also make PMIC node useless as the regulators
>> wont be used and thus
>> should be technically removed ?
>>
>> >> +};
>> >> +
>> >> +&ohci1 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&ohci2 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&ohci3 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&r_i2c {
>> >> + status = "okay";
>> >> +
>> >> + axp1530: pmic@36 {
>> >> + compatible = "x-powers,axp1530";
>> >
>> > I just checked datasheet and it really seems that it supports only
>> > I2C.
>> > Anyway, rather than using axp1530 compatible, introduce axp313a
>> > compatible
>> > instead.
>>
>> Will do in V2 for drivers later.
>>
>> >> + reg = <0x36>;
>> >> + wakeup-source;
>> >> +
>> >> + regulators{
>> >> + reg_dcdc1: dcdc1 {
>> >> + regulator-name = "axp1530-
>dcdc1";
>> >> + regulator-min-microvolt =
>> >
>> > <500000>;
>> >
>> >> + regulator-max-microvolt =
>> >
>> > <3400000>;
>> >
>> > This one is most likely used by CPU. If so, you should set
>> > appropriate range
>> > according to CPU needs, which are 810 - 1100 mV.
>> >
>> >> + regulator-step-delay-us = <25>;
>> >> + regulator-final-delay-us = <50>;
>> >> + regulator-always-on;
>> >> + };
>> >> +
>> >> + reg_dcdc2: dcdc2 {
>> >> + regulator-name = "axp1530-
>dcdc2";
>> >> + regulator-min-microvolt =
>> >
>> > <500000>;
>> >
>> >> + regulator-max-microvolt =
>> >
>> > <1540000>;
>> >
>> > This one is most likely used by GPU. Its range must also be adjusted
>> > to GPU
>> > needs.
>> >
>> >> + regulator-step-delay-us = <25>;
>> >> + regulator-final-delay-us = <50>;
>> >> + regulator-ramp-delay = <200>;
>> >> + regulator-always-on;
>> >> + };
>> >> +
>> >> + reg_dcdc3: dcdc3 {
>> >> + regulator-name = "axp1530-
>dcdc3";
>> >> + regulator-min-microvolt =
>> >
>> > <500000>;
>> >
>> >> + regulator-max-microvolt =
>> >
>> > <1840000>;
>> >
>> > This one looks like it supplies DRAM. You should set both min and max
>> > to
>> > actual DRAM needs.
>> >
>> >> + regulator-step-delay-us = <25>;
>> >> + regulator-final-delay-us = <50>;
>> >> + regulator-always-on;
>> >> + };
>> >> +
>> >> + reg_aldo1: ldo1 {
>> >
>> > ldo1 -> aldo1
>> >
>> >> + regulator-name = "axp1530-
>aldo1";
>> >> + regulator-min-microvolt =
>> >
>> > <1800000>;
>> >
>> >> + regulator-max-microvolt =
>> >
>> > <1800000>;
>> >
>> >> + regulator-step-delay-us = <25>;
>> >> + regulator-final-delay-us = <50>;
>> >> + regulator-always-on;
>> >> + };
>> >> +
>> >> + reg_dldo1: ldo2 {
>> >
>> > ldo2 -> dldo1
>> >
>> > Another issue I see is that you marked all regulators with
>> > regulator-always-
>> > on; While this works, I don't think this faithfully represent HW. For
>> > example,
>> > GPU regulator will be enabled by GPU driver when needed, so it
>> > shouldn't be
>> > marked with always on.
>> >
>> > There is also RTCLDO, but without schematic it's impossible to say if
>> > it is
>> > used or not.
>> >
>> > There are at least a few clues in AXP313A datasheet about which
>> > regulator is
>> > used for what. See chapter 7.5 in
>> > https://github.com/bigtreetech/CB1-Kernel/
>> > blob/kernel-5.16/docs/AXP313A%20datasheet%20V0.1%20-
>> > %2020201105_draft%20version.pdf
>>
>> As for regulators themselves. I have kept them as what downstream
>> kernel specifies.
>> But until I have schematic in hand and can confirm that they actually
>> used the correct regulators in
>> the correct place i will stick to stock values. If they in the end
>> decide to not supply schematic or etc
>> to the public i can test with adjusted values.
>>
>> > Best regards,
>> > Jernej
>> >
>> >> + regulator-name = "axp1530-
>dldo1";
>> >> + regulator-min-microvolt =
>> >
>> > <3300000>;
>> >
>> >> + regulator-max-microvolt =
>> >
>> > <3300000>;
>> >
>> >> + regulator-step-delay-us = <25>;
>> >> + regulator-final-delay-us = <50>;
>> >> + regulator-always-on;
>> >> + };
>> >> + };
>> >> + };
>> >> +};
>> >> +
>> >> +&uart0 {
>> >> + pinctrl-names = "default";
>> >> + pinctrl-0 = <&uart0_ph_pins>;
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&usbotg {
>> >> + /*
>> >> + * PHY0 pins are connected to a USB-C socket, but a role switch
>> >> + * is not implemented: both CC pins are pulled to GND.
>> >> + * The VBUS pins power the device, so a fixed peripheral mode
>> >> + * is the best choice.
>> >> + * The board can be powered via GPIOs, in this case port0 *can*
>> >> + * act as a host (with a cable/adapter ignoring CC), as VBUS is
>> >> + * then provided by the GPIOs. Any user of this setup would
>> >> + * need to adjust the DT accordingly: dr_mode set to "host",
>> >> + * enabling OHCI0 and EHCI0.
>> >> + */
>> >> + dr_mode = "peripheral";
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&usbphy {
>> >> + usb1_vbus-supply = <®_usb1_vbus>;
>> >> + status = "okay";
>> >> +};
>>
>> Best Regards,
>> Martin
>
>
>
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
@ 2022-11-15 21:42 ` Martin Botka
0 siblings, 0 replies; 38+ messages in thread
From: Martin Botka @ 2022-11-15 21:42 UTC (permalink / raw)
To: Jernej Škrabec
Cc: martin.botka1, ~postmarketos/upstreaming, Konrad Dybcio,
AngeloGioacchino Del Regno, Marijn Suijten, Jami Kettunen,
Paul Bouchara, Jan Trmal, Tom, Rob Herring, Krzysztof Kozlowski,
Chen-Yu Tsai, Samuel Holland, Maxime Ripard, Andre Przywara,
Conley Lee, Andrew Lunn, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
On November 15, 2022 10:34:49 PM GMT+01:00, "Jernej Škrabec" <jernej.skrabec@gmail.com> wrote:
>Dne ponedeljek, 14. november 2022 ob 23:54:46 CET je Martin Botka napisal(a):
>> On Mon, Nov 14 2022 at 11:30:17 PM +01:00:00, Jernej Škrabec
>>
>> <jernej.skrabec@gmail.com> wrote:
>> > Hi Martin,
>> >
>> > I was just writing new e-mail as response to v2. You should wait at
>> > least a
>> > day or two, usually more, before sending new version. Others will
>> > likely have
>> > some more comments. And there is also no rush. Until PMIC series is
>> > merged,
>> > this will not go anywhere. Since there is only this week until cut
>> > off date for
>> > DT updates for kernel 6.2, it's most likely that this will land in
>> > 6.3. And
>> > that gives as a few weeks (month) more.
>>
>> Yep. Was hoping for 5.2 thus the frequent updates. Will take it slow
>> then since 5.3 :)
>
>You're way too late for 5.x series :) Anyway, 6.2 would be possible if you
>would have almost flawless patch with no additional dependencies, but that is
>not the case here. I'll send DT pull requests for 6.2 at the end of this week.
>
>Best regards,
>Jernej
Hehe yea :)
Very understandable.
Cheers,
Martin
>
>>
>> > See comments below.
>> >
>> > Dne ponedeljek, 14. november 2022 ob 22:44:49 CET je Martin Botka
>> >
>> > napisal(a):
>> >> CB1 is Compute Module style board that plugs into Rpi board style
>> >>
>> >> adapter or
>> >>
>> >> Manta 3D printer boards (M4P/M8P).
>> >>
>> >> The board has:
>> >> H616 SoC
>> >> 1GB of RAM
>> >> AXP313A PMIC
>> >>
>> >> And the actual boards that CB1 plugs in are just extension to it
>> >>
>> >> with ports
>> >>
>> >> and thus are not split in DT.
>> >>
>> >> Boards have:
>> >> 4x (3x for Manta boards) USB and 1 USB OTG.
>> >> SDcard slot for loading images.
>> >> Ethernet port wired to the internal PHY.
>> >> 2x HDMI 2.0.
>> >
>> > H616 has only one HDMI output. Unless there is some additional chip
>> > for some
>> > conversion, only one HDMI port can work.
>>
>> Yes correct. But the Rpi adapter and Manta boards also support
>> Rpi Compute Module 4 which has 2 HDMI outputs.
>> The chip itself ofc doesnt support this on CB1. Same goes for DSI/CSI
>> ports
>> on the boards and the 4x USB on Rpi adapter.
>>
>> It is indeed a bit of a mess.
>>
>> >> Power and Status LEDs.
>> >>
>> >> Currently working:
>> >> Booting
>> >> USB
>> >> UART
>> >>
>> >> Signed-off-by: Martin Botka <martin.botka@somainline.org>
>> >> ---
>> >> Changes in V2:
>> >> Add proper board compatible
>> >> Add regulator prefix for vcc5v
>> >> Drop okay status from PMIC
>> >> Drop standby_param
>> >> Changes in V3:
>> >> Change copyright to me
>> >> regulator_vcc5v to regulator-vcc5v
>> >> Drop ehci0 and ohci0
>> >>
>> >> arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> >> .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178
>> >>
>> >> ++++++++++++++++++
>> >>
>> >> 2 files changed, 179 insertions(+)
>> >> create mode 100644
>> >>
>> >> arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >>
>> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> b/arch/arm64/boot/dts/allwinner/Makefile index
>> >>
>> >> 6a96494a2e0a..223f1be73541
>> >>
>> >> 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-biqu-cb1.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-biqu-cb1.dts
>> >> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts new file
>> >>
>> >> mode
>> >>
>> >> 100644
>> >> index 000000000000..86b5aca9b53e
>> >> --- /dev/null
>> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts
>> >> @@ -0,0 +1,178 @@
>> >> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
>> >> +/*
>> >> + * Copyright (C) 2022 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 = "BIQU CB1";
>> >> + compatible = "biqu,cb1", "allwinner,sun50i-h616";
>> >> +
>> >> + aliases {
>> >> + serial0 = &uart0;
>> >> + };
>> >> +
>> >> + chosen {
>> >> + stdout-path = "serial0:115200n8";
>> >> + };
>> >> +
>> >> + leds {
>> >> + compatible = "gpio-leds";
>> >> +
>> >> + led-0 {
>> >> + function = LED_FUNCTION_POWER;
>> >> + color = <LED_COLOR_ID_RED>;
>> >> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /*
>> >
>> > PC12 */
>> >
>> >> + default-state = "on";
>> >> + };
>> >> +
>> >> + led-1 {
>> >> + function = LED_FUNCTION_STATUS;
>> >> + color = <LED_COLOR_ID_GREEN>;
>> >> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /*
>> >
>> > PC13 */
>> >
>> >> + };
>> >> + };
>> >> +
>> >> + 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 = <®_vcc5v>;
>> >> + enable-active-high;
>> >> + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
>> >> + };
>> >> +};
>> >> +
>> >> +&ehci1 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&ehci2 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&ehci3 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&mmc0 {
>> >> + vmmc-supply = <®_dldo1>;
>> >> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>> >> + no-1-8-v;
>> >
>> > Above property is not needed. If you don't provide vqmmc-supply with
>> > 1.8 V
>> > regulator, it won't be used.
>> >
>> >> + bus-width = <4>;
>> >> + status = "disabled";
>> >
>> > Why is set to disabled? If it's not a typo, remove whole node. It
>> > could be
>> > added later when it works.
>>
>> Would not removing it also make PMIC node useless as the regulators
>> wont be used and thus
>> should be technically removed ?
>>
>> >> +};
>> >> +
>> >> +&ohci1 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&ohci2 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&ohci3 {
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&r_i2c {
>> >> + status = "okay";
>> >> +
>> >> + axp1530: pmic@36 {
>> >> + compatible = "x-powers,axp1530";
>> >
>> > I just checked datasheet and it really seems that it supports only
>> > I2C.
>> > Anyway, rather than using axp1530 compatible, introduce axp313a
>> > compatible
>> > instead.
>>
>> Will do in V2 for drivers later.
>>
>> >> + reg = <0x36>;
>> >> + wakeup-source;
>> >> +
>> >> + regulators{
>> >> + reg_dcdc1: dcdc1 {
>> >> + regulator-name = "axp1530-
>dcdc1";
>> >> + regulator-min-microvolt =
>> >
>> > <500000>;
>> >
>> >> + regulator-max-microvolt =
>> >
>> > <3400000>;
>> >
>> > This one is most likely used by CPU. If so, you should set
>> > appropriate range
>> > according to CPU needs, which are 810 - 1100 mV.
>> >
>> >> + regulator-step-delay-us = <25>;
>> >> + regulator-final-delay-us = <50>;
>> >> + regulator-always-on;
>> >> + };
>> >> +
>> >> + reg_dcdc2: dcdc2 {
>> >> + regulator-name = "axp1530-
>dcdc2";
>> >> + regulator-min-microvolt =
>> >
>> > <500000>;
>> >
>> >> + regulator-max-microvolt =
>> >
>> > <1540000>;
>> >
>> > This one is most likely used by GPU. Its range must also be adjusted
>> > to GPU
>> > needs.
>> >
>> >> + regulator-step-delay-us = <25>;
>> >> + regulator-final-delay-us = <50>;
>> >> + regulator-ramp-delay = <200>;
>> >> + regulator-always-on;
>> >> + };
>> >> +
>> >> + reg_dcdc3: dcdc3 {
>> >> + regulator-name = "axp1530-
>dcdc3";
>> >> + regulator-min-microvolt =
>> >
>> > <500000>;
>> >
>> >> + regulator-max-microvolt =
>> >
>> > <1840000>;
>> >
>> > This one looks like it supplies DRAM. You should set both min and max
>> > to
>> > actual DRAM needs.
>> >
>> >> + regulator-step-delay-us = <25>;
>> >> + regulator-final-delay-us = <50>;
>> >> + regulator-always-on;
>> >> + };
>> >> +
>> >> + reg_aldo1: ldo1 {
>> >
>> > ldo1 -> aldo1
>> >
>> >> + regulator-name = "axp1530-
>aldo1";
>> >> + regulator-min-microvolt =
>> >
>> > <1800000>;
>> >
>> >> + regulator-max-microvolt =
>> >
>> > <1800000>;
>> >
>> >> + regulator-step-delay-us = <25>;
>> >> + regulator-final-delay-us = <50>;
>> >> + regulator-always-on;
>> >> + };
>> >> +
>> >> + reg_dldo1: ldo2 {
>> >
>> > ldo2 -> dldo1
>> >
>> > Another issue I see is that you marked all regulators with
>> > regulator-always-
>> > on; While this works, I don't think this faithfully represent HW. For
>> > example,
>> > GPU regulator will be enabled by GPU driver when needed, so it
>> > shouldn't be
>> > marked with always on.
>> >
>> > There is also RTCLDO, but without schematic it's impossible to say if
>> > it is
>> > used or not.
>> >
>> > There are at least a few clues in AXP313A datasheet about which
>> > regulator is
>> > used for what. See chapter 7.5 in
>> > https://github.com/bigtreetech/CB1-Kernel/
>> > blob/kernel-5.16/docs/AXP313A%20datasheet%20V0.1%20-
>> > %2020201105_draft%20version.pdf
>>
>> As for regulators themselves. I have kept them as what downstream
>> kernel specifies.
>> But until I have schematic in hand and can confirm that they actually
>> used the correct regulators in
>> the correct place i will stick to stock values. If they in the end
>> decide to not supply schematic or etc
>> to the public i can test with adjusted values.
>>
>> > Best regards,
>> > Jernej
>> >
>> >> + regulator-name = "axp1530-
>dldo1";
>> >> + regulator-min-microvolt =
>> >
>> > <3300000>;
>> >
>> >> + regulator-max-microvolt =
>> >
>> > <3300000>;
>> >
>> >> + regulator-step-delay-us = <25>;
>> >> + regulator-final-delay-us = <50>;
>> >> + regulator-always-on;
>> >> + };
>> >> + };
>> >> + };
>> >> +};
>> >> +
>> >> +&uart0 {
>> >> + pinctrl-names = "default";
>> >> + pinctrl-0 = <&uart0_ph_pins>;
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&usbotg {
>> >> + /*
>> >> + * PHY0 pins are connected to a USB-C socket, but a role switch
>> >> + * is not implemented: both CC pins are pulled to GND.
>> >> + * The VBUS pins power the device, so a fixed peripheral mode
>> >> + * is the best choice.
>> >> + * The board can be powered via GPIOs, in this case port0 *can*
>> >> + * act as a host (with a cable/adapter ignoring CC), as VBUS is
>> >> + * then provided by the GPIOs. Any user of this setup would
>> >> + * need to adjust the DT accordingly: dr_mode set to "host",
>> >> + * enabling OHCI0 and EHCI0.
>> >> + */
>> >> + dr_mode = "peripheral";
>> >> + status = "okay";
>> >> +};
>> >> +
>> >> +&usbphy {
>> >> + usb1_vbus-supply = <®_usb1_vbus>;
>> >> + status = "okay";
>> >> +};
>>
>> Best Regards,
>> Martin
>
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2022-11-15 21:44 UTC | newest]
Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-14 21:44 [PATCH v3 1/2] dt-bindings: arm: sunxi: Add BIQU CB1 Martin Botka
2022-11-14 21:44 ` Martin Botka
2022-11-14 21:44 ` [PATCH v3 2/2] arm64: dts: Add basic support for " Martin Botka
2022-11-14 21:44 ` Martin Botka
2022-11-14 22:30 ` Jernej Škrabec
2022-11-14 22:30 ` Jernej Škrabec
2022-11-14 22:54 ` Martin Botka
2022-11-14 22:54 ` Martin Botka
2022-11-15 21:34 ` Jernej Škrabec
2022-11-15 21:34 ` Jernej Škrabec
2022-11-15 21:42 ` Martin Botka
2022-11-15 21:42 ` Martin Botka
2022-11-14 23:31 ` Andre Przywara
2022-11-14 23:31 ` Andre Przywara
[not found] ` <CADQ2G_HXx59YYjNvhcNRonahgT3AcE_2BiU43vDJ3CRUGKwAKA@mail.gmail.com>
2022-11-15 0:54 ` Andre Przywara
2022-11-15 0:54 ` Andre Przywara
2022-11-15 8:24 ` Martin Botka
2022-11-15 8:24 ` Martin Botka
2022-11-15 10:33 ` Andre Przywara
2022-11-15 10:33 ` Andre Przywara
2022-11-15 11:38 ` Martin Botka
2022-11-15 11:38 ` Martin Botka
2022-11-15 14:27 ` Andre Przywara
2022-11-15 14:27 ` Andre Przywara
2022-11-15 14:48 ` Martin Botka
2022-11-15 14:48 ` Martin Botka
2022-11-15 16:31 ` Martin Botka
2022-11-15 16:31 ` Martin Botka
2022-11-15 17:02 ` Martin Botka
2022-11-15 17:02 ` Martin Botka
2022-11-15 17:25 ` Andre Przywara
2022-11-15 17:25 ` Andre Przywara
2022-11-15 17:32 ` Martin Botka
2022-11-15 17:32 ` Martin Botka
2022-11-15 9:55 ` Martin Botka
2022-11-15 9:55 ` Martin Botka
2022-11-15 9:59 ` [PATCH v3 1/2] dt-bindings: arm: sunxi: Add " Krzysztof Kozlowski
2022-11-15 9:59 ` Krzysztof Kozlowski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.