| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <EEA966B5-E8C3-4A65-A6AE-FF2F9410F088@somainline.org>
Date: Tue, 15 Nov 2022 10:55:24 +0100
From: Martin Botka <martin.botka@...ainline.org>
To: Andre Przywara <andre.przywara@....com>,
Martin Botka <martin.botka1@...il.com>
CC: ~postmarketos/upstreaming@...ts.sr.ht,
Konrad Dybcio <konrad.dybcio@...ainline.org>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...ainline.org>,
Marijn Suijten <marijn.suijten@...ainline.org>,
Jami Kettunen <jamipkettunen@...ainline.org>,
Paul Bouchara <paul.bouchara@...ainline.org>,
Jan Trmal <jtrmal@...il.com>, Tom <takuya@...uya.tech>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Samuel Holland <samuel@...lland.org>,
Maxime Ripard <maxime@...no.tech>,
Conley Lee <conleylee@...mail.com>,
Andrew Lunn <andrew@...n.ch>,
devicetree <devicetree@...r.kernel.org>,
linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1
On November 15, 2022 1:54:29 AM GMT+01:00, Andre Przywara <andre.przywara@....com> wrote:
>On Tue, 15 Nov 2022 00:44:46 +0100
>Martin Botka <martin.botka1@...il.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@....com>
>> wrote:
>>
>> > On Mon, 14 Nov 2022 22:44:49 +0100
>> > Martin Botka <martin.botka@...ainline.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@...ainline.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@...ainline.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
Powered by blists - more mailing lists