| Message ID | 20220815050815.22340-1-samuel@sholland.org |
|---|---|
| Headers | show |
| Series | riscv: Allwinner D1 platform support | expand |
On 8/15/22 12:12 PM, Conor.Dooley@microchip.com wrote: > On 15/08/2022 08:05, Conor Dooley wrote: >> Hey Samuel, >> Apologies for the last email, the first 5 patches in this series >> didn't correctly land in my inbox and I skimmed & replied to the >> wrong cover letter... I blame it being pre 8 AM ;) >> >> On 15/08/2022 06:08, Samuel Holland wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>> >>> This series adds the Kconfig/defconfig plumbing and devicetrees for a >>> range of Allwinner D1-based boards. Many features are already enabled, >>> including USB, Ethernet, and WiFi. >>> >>> The SoC devicetree uses bindings from the following series which have >>> not yet been merged: >>> - SRAM controller: >>> https://lore.kernel.org/lkml/20220815041248.53268-1-samuel@sholland.org/ >>> - NVMEM cell bits property change: >>> https://lore.kernel.org/lkml/20220814173656.11856-1-samuel@sholland.org/ >>> - In-package LDO regulators: >>> https://lore.kernel.org/lkml/20220815043436.20170-1-samuel@sholland.org/ >>> >>> All three of these are required to set the correct I/O domain voltages >>> in the pin controller, which I would consider important to have in the >>> initial version of the devicetree. >>> >>> The SoC devicetree does contain one small hack to avoid a dependency on >>> the audio codec binding, since that is not ready yet: the codec node >>> uses a bare "simple-mfd", "syscon" compatible. >> >> >> I tried this series on top of both 6.0-rc1 & next, but I saw a shed >> load of errors from dtbs_check. I'll take a look at the rest of the >> series later on, but just FYI. This time I did at least read the >> right cover letter and actually applied your dependent series.. >> /facepalm >> >> I have been trying to get riscv down to 0 warnings and would not be >> in favour of accepting patches that go in the other direction. >> (This patchset currently produces about 47 new warnings) Only 4 unique ones :) Thanks for checking this. I had done a couple of passes cleaning things up. The remaining warnings are the ones I was unsure how to fix. > FWIW this is what I see, LMK if I am missing something. > allwinner/sun20i-d1-lichee-rv.dtb: i2c@2502000: Unevaluated properties are not allowed ('dma-names', 'dmas' were unexpected) This one is new with dt-schema 2022.08.1 (I was previously on d1f3102e locally). I'm not sure if it is a bug in the binding or in the dt-schema tool. The warnings go away if I do: --- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml @@ -72,6 +72,7 @@ required: - interrupts allOf: + - $ref: /schemas/dma/dma.yaml# - $ref: /schemas/i2c/i2c-controller.yaml# - if: properties: But I wouldn't expect this to be necessary, since dma.yaml has "select: true". Compare the this with the UARTs. Neither serial/snps-dw-apb-uart.yaml nor serial/serial.yaml references any DMA properties, yet there is no warning for those. > allwinner/sun20i-d1-clockworkpi-v3.14.dtb: pmic@34: compatible: 'oneOf' conditional failed, one must be fixed: > allwinner/sun20i-d1-devterm-v3.14.dtb: pmic@34: compatible: 'oneOf' conditional failed, one must be fixed: The new compatible is in linux-next. I can add it to the cover letter for v2: https://lore.kernel.org/linux-devicetree/20220810013430.27061-1-samuel@sholland.org/ https://git.kernel.org/lee/mfd/c/97ecda0f615e > allwinner/sun20i-d1-lichee-rv.dtb: ethernet@4500000: Unevaluated properties are not allowed ('mdio', 'reset-names', 'resets' were unexpected) This showed up with a dt-schema update in the last year or so. This may be a bug in the binding? allwinner,sun8i-a83t-emac.yaml picks up these three properties from snps,dwmac.yaml, but does not have them in its own "properties" block. (resets and reset-names are even in "required"!) > allwinner/sun20i-d1-lichee-rv-86-panel-720p.dtb: ethernet@4500000: Unevaluated properties are not allowed ('phy-supply' was unexpected) > allwinner/sun20i-d1-dongshan-nezha-stu.dtb: ethernet@4500000: Unevaluated properties are not allowed ('phy-supply' was unexpected) I think this one is just flat out missing from the binding. It is present in the other two Allwinner Ethernet MAC bindings, but not this one. Regards, Samuel
Am Montag, 15. August 2022, 18:56:23 CEST schrieb Conor.Dooley@microchip.com: > On 15/08/2022 06:08, Samuel Holland wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > Allwinner manufactures the sunxi family of application processors. This > > includes the "sun8i" series of ARMv7 SoCs, the "sun50i" series of ARMv8 > > SoCs, and now the "sun20i" series of 64-bit RISC-V SoCs. > > > > The first SoC in the sun20i series is D1, containing a single T-HEAD > > C906 core. D1s is a low-pin-count variant of D1 with co-packaged DRAM. > > > > Most peripherals are shared across the entire chip family. In fact, the > > ARMv7 T113 SoC is pin-compatible and almost entirely register-compatible > > with the D1s. > > > > This means many existing device drivers can be reused. To facilitate > > this reuse, name the symbol ARCH_SUNXI, since that is what the existing > > drivers have as their dependency. > > Hey Samuel, > I think this and patch 12/12 with the defconfig changes should be > deferred until post LPC (which still leaves plenty of time for > making the 6.1 merge window). We already have like 4 different > approaches between the existing SOC_FOO symbols & two more when > D1 stuff and the Renesas stuff is considered. On the other hand, I don't really think it's that hard to change things after the fact? I.e. ARCH_SUNXI is pretty much set in stone anyway, so there isn't very much that _could_ change without affecting most driver subsystems in the kernel. So I don't think we'd actually need to wait with the Allwinner symbol. Heiko > Plan is to decide at LPC on one approach for what to do with > Kconfig.socs & to me it seems like a good idea to do what's being > done here - it's likely that further arm vendors will move and > keeping the common symbols makes a lot of sense to me... > > Thanks, > Conor. > > > > > Signed-off-by: Samuel Holland <samuel@sholland.org> > > --- > > > > arch/riscv/Kconfig.socs | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs > > index 69774bb362d6..1caacbfac1a5 100644 > > --- a/arch/riscv/Kconfig.socs > > +++ b/arch/riscv/Kconfig.socs > > @@ -1,5 +1,14 @@ > > menu "SoC selection" > > > > +config ARCH_SUNXI > > + bool "Allwinner sun20i SoCs" > > + select ERRATA_THEAD if MMU && !XIP_KERNEL > > + select SIFIVE_PLIC > > + select SUN4I_TIMER > > + help > > + This enables support for Allwinner sun20i platform hardware, > > + including boards based on the D1 and D1s SoCs. > > + > > config SOC_MICROCHIP_POLARFIRE > > bool "Microchip PolarFire SoCs" > > select MCHP_CLK_MPFS > > -- > > 2.35.1 > > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv >
On 16/08/2022 10:17, Heiko Stübner wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Am Montag, 15. August 2022, 18:56:23 CEST schrieb Conor.Dooley@microchip.com: >> On 15/08/2022 06:08, Samuel Holland wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>> >>> Allwinner manufactures the sunxi family of application processors. This >>> includes the "sun8i" series of ARMv7 SoCs, the "sun50i" series of ARMv8 >>> SoCs, and now the "sun20i" series of 64-bit RISC-V SoCs. >>> >>> The first SoC in the sun20i series is D1, containing a single T-HEAD >>> C906 core. D1s is a low-pin-count variant of D1 with co-packaged DRAM. >>> >>> Most peripherals are shared across the entire chip family. In fact, the >>> ARMv7 T113 SoC is pin-compatible and almost entirely register-compatible >>> with the D1s. >>> >>> This means many existing device drivers can be reused. To facilitate >>> this reuse, name the symbol ARCH_SUNXI, since that is what the existing >>> drivers have as their dependency. >> >> Hey Samuel, >> I think this and patch 12/12 with the defconfig changes should be >> deferred until post LPC (which still leaves plenty of time for >> making the 6.1 merge window). We already have like 4 different >> approaches between the existing SOC_FOO symbols & two more when >> D1 stuff and the Renesas stuff is considered. > > On the other hand, I don't really think it's that hard to change things > after the fact? I.e. ARCH_SUNXI is pretty much set in stone anyway, > so there isn't very much that _could_ change without affecting most > driver subsystems in the kernel. > > So I don't think we'd actually need to wait with the Allwinner symbol. True, but it'd be the same release anyway most likely so I don't think that there'd really be any waiting involved. I /like/ the idea of using ARCH_FOO rather than SOC_FOO as it's far more consistent across the kernel - it's more a question of not doing one thing here and another with the Renesas stuff to me. > > > Heiko > >> Plan is to decide at LPC on one approach for what to do with >> Kconfig.socs & to me it seems like a good idea to do what's being >> done here - it's likely that further arm vendors will move and >> keeping the common symbols makes a lot of sense to me... >> >> Thanks, >> Conor. >> >>> >>> Signed-off-by: Samuel Holland <samuel@sholland.org> >>> --- >>> >>> arch/riscv/Kconfig.socs | 9 +++++++++ >>> 1 file changed, 9 insertions(+) >>> >>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs >>> index 69774bb362d6..1caacbfac1a5 100644 >>> --- a/arch/riscv/Kconfig.socs >>> +++ b/arch/riscv/Kconfig.socs >>> @@ -1,5 +1,14 @@ >>> menu "SoC selection" >>> >>> +config ARCH_SUNXI >>> + bool "Allwinner sun20i SoCs" >>> + select ERRATA_THEAD if MMU && !XIP_KERNEL >>> + select SIFIVE_PLIC >>> + select SUN4I_TIMER >>> + help >>> + This enables support for Allwinner sun20i platform hardware, >>> + including boards based on the D1 and D1s SoCs. >>> + >>> config SOC_MICROCHIP_POLARFIRE >>> bool "Microchip PolarFire SoCs" >>> select MCHP_CLK_MPFS >>> -- >>> 2.35.1 >>> >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv >> > > > >
On Tue, 16 Aug 2022 12:42:39 +0300 Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: Hi, > On 16/08/2022 12:25, Jernej Škrabec wrote: > > Dne torek, 16. avgust 2022 ob 11:12:05 CEST je Heiko Stübner napisal(a): > >> Am Dienstag, 16. August 2022, 09:49:58 CEST schrieb Jernej Škrabec: > >>> Dne torek, 16. avgust 2022 ob 09:41:45 CEST je Krzysztof Kozlowski > > napisal(a): > >>>> On 15/08/2022 08:08, Samuel Holland wrote: > >>>>> + > >>>>> + de: display-engine { > >>>>> + compatible = "allwinner,sun20i-d1-display-engine"; > >>>>> + allwinner,pipelines = <&mixer0>, <&mixer1>; > >>>>> + status = "disabled"; > >>>>> + }; > >>>>> + > >>>>> + osc24M: osc24M-clk { > >>>> > >>>> lowercase > >>>> > >>>>> + compatible = "fixed-clock"; > >>>>> + clock-frequency = <24000000>; > >>>> > >>>> This is a property of the board, not SoC. > >>> > >>> SoC needs 24 MHz oscillator for correct operation, so each and every board > >>> has it. Having it here simplifies board DT files. > >> > >> I guess the oscillator is a separate component on each board, right? > > > > Correct. > > > >> And DT obvious is meant to describe the hardware - independently from > >> implementation-specific choices. > > > > There is no choice in this case. 24 MHz crystal has to be present. > > > > FWIW, including crystal node in SoC specific DTSI is already common pattern in > > Allwinner ARM SoC DTSI files. > > > >> > >> Starting to discuss which exceptions to allow then might lead to even more > >> exceptions. > >> > >> Also having to look for a board-component in the soc dtsi also is surprising > >> if one gets to the party later on :-) . > > > > As I said, if one is accustomed to Allwinner ARM DT development, it would be > > more surprising to include 24 MHz crystal node in each and every board DT. > > It's same everywhere. Allwinner, Exynos, iMX, Qualcomm. Everywhere this > is a part of the board, so even if oscillator frequency is fixed (as in > 99% of cases although some SoCs I think might just allow to implement > one of few), still this is a property of the board. Because: > 1. DTSI describes the SoC part, not board. > 2. So the DTS developer is a bit more conscious about his design. 1) is certainly true, but indeed most platforms put the base crystal oscillator in the SoC .dtsi: I just sampled Rockchip (rk3399.dtsi, rk356x.dtsi, rk3328.dtsi), Amlogic (meson-g12-common.dtsi), ActionSemi (s[79]00.dtsi), Qualcomm (msm8916.dtsi, sm8450.dtsi, sc7180.dtsi), Freescale (imx8mm.dtsi, imx8qxp.dtsi), Realtek (rtd129x.dtsi), Broadcom (bcm283x.dtsi), Mediatek (mt8183.dtsi, mt8516.dtsi). The list probably goes on (I just stopped here). I think one reason might be that this is so central to the whole SoC operation, that it's already referenced multiple times in the base .dtsi. And having a yet unresolved reference in the .dtsi looks dodgy. NVidia seems to omit a base oscillator (maybe it's implicit in their binding design), Marvell doesn't use a fixed-clock (but still puts their base clock in armada-37xx.dtsi). Exynos and Renesas put a *stub* fixed-clock in the .dtsi, and set the frequency in the board .dts files. Would this be a compromise? Cheers, Andre > Keeping things in SoC DTSI just because it simplifies DTS is not correct > IMHO. So again - like in several other cases - minimum the frequency is > property of the board, not the SoC DTSI. > > Everywhere. Allwinner is not special to receive exceptions. > > Best regards, > Krzysztof >
On 16/08/2022 14:11, Krzysztof Kozlowski wrote: >> >> I think one reason might be that this is so central to the whole SoC >> operation, that it's already referenced multiple times in the base .dtsi. >> And having a yet unresolved reference in the .dtsi looks dodgy. >> >> NVidia seems to omit a base oscillator (maybe it's implicit in their >> binding design), Marvell doesn't use a fixed-clock (but still puts their >> base clock in armada-37xx.dtsi). >> >> Exynos and Renesas put a *stub* fixed-clock in the .dtsi, and set the >> frequency in the board .dts files. Would this be a compromise? > > This is exactly what I said before. The clock frequency is a property of > the board. Feel free to keep the rest of the clock in the SoC DTSI to > reduce duplication, but at minimum the clock should go to the board. s/minimum the clock should go to the board/minimum the clock frequency should go to the board./ Best regards, Krzysztof
On Mon, 15 Aug 2022 00:08:05 -0500, Samuel Holland wrote: > The C906 and C910 are RISC-V CPU cores from T-HEAD Semiconductor. > Notably, the C906 core is used in the Allwinner D1 SoC. > > Signed-off-by: Samuel Holland <samuel@sholland.org> > --- > > Documentation/devicetree/bindings/riscv/cpus.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring <robh@kernel.org>
Hey Samuel, Finally got around to giving this a go with the fix for loading modules which is mostly what was blocking me before.. On 15/08/2022 06:08, Samuel Holland wrote: > "D1 Nezha" is Allwinner's first-party development board for the D1 SoC. > It was shipped with 512M, 1G, or 2G of DDR3. It supports onboard audio, I am really not keen on the way you have things, with the memory nodes removed from the device tree. I know your preferred flow for booting these things might be to pass the dtb up from U-Boot, but I think the devicetree in the kernel should be usable in a standalone manner, even if that is the barest-minimum memory config. I did figure out all of my issues getting booted, thanks partly to Heiko. The U-Boot dtb being misaligned was part of it as was my initramfs with some stale sunxi modules in it causing RCU stalls.. so sorry for the noise on that front (and thanks again to Heiko!). Modulo the memory node, since I had to hack that in to get things working & I do not want to have to keep doing: Tested-by: Conor Dooley <conor.dooley@microchip.com> Thanks & apologies again for the modules-related issues - it was hard to debug that one since module loading was broken on RISC-V at the time. Conor. > HDMI, gigabit Ethernet, WiFi and Bluetooth, USB 2.0 host and OTG ports, > plus low-speed I/O from the SoC and a GPIO expander chip. > > Most other D1 boards copied the Nezha's power tree, with the 1.8V rail > powered by the SoCs internal LDOA, analog domains powered by ALDO, and > the rest of the board powered by always-on fixed regulators. Some (but > not all) boards also copied the PWM CPU regulator. To avoid duplication, > factor out the out the regulator references that are common across all > known boards. > > Signed-off-by: Samuel Holland <samuel@sholland.org> > --- > > arch/riscv/boot/dts/allwinner/Makefile | 1 + > .../sun20i-d1-common-regulators.dtsi | 51 ++++++ > .../boot/dts/allwinner/sun20i-d1-nezha.dts | 171 ++++++++++++++++++ > 3 files changed, 223 insertions(+) > create mode 100644 arch/riscv/boot/dts/allwinner/sun20i-d1-common-regulators.dtsi > create mode 100644 arch/riscv/boot/dts/allwinner/sun20i-d1-nezha.dts > > diff --git a/arch/riscv/boot/dts/allwinner/Makefile b/arch/riscv/boot/dts/allwinner/Makefile > index f66554cd5c45..b0a15e8c8d82 100644 > --- a/arch/riscv/boot/dts/allwinner/Makefile > +++ b/arch/riscv/boot/dts/allwinner/Makefile > @@ -1 +1,2 @@ > # SPDX-License-Identifier: GPL-2.0 > +dtb-$(CONFIG_ARCH_SUNXI) += sun20i-d1-nezha.dtb > diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1-common-regulators.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1-common-regulators.dtsi > new file mode 100644 > index 000000000000..143a3e710c3c > --- /dev/null > +++ b/arch/riscv/boot/dts/allwinner/sun20i-d1-common-regulators.dtsi > @@ -0,0 +1,51 @@ > +// SPDX-License-Identifier: (GPL-2.0+ or MIT) > +// Copyright (C) 2021-2022 Samuel Holland <samuel@sholland.org> > + > +/ { > + reg_vcc: vcc { > + compatible = "regulator-fixed"; > + regulator-name = "vcc"; > + regulator-min-microvolt = <5000000>; > + regulator-max-microvolt = <5000000>; > + }; > + > + reg_vcc_3v3: vcc-3v3 { > + compatible = "regulator-fixed"; > + regulator-name = "vcc-3v3"; > + regulator-min-microvolt = <3300000>; > + regulator-max-microvolt = <3300000>; > + vin-supply = <®_vcc>; > + }; > +}; > + > +&lradc { > + vref-supply = <®_aldo>; > +}; > + > +&pio { > + vcc-pb-supply = <®_vcc_3v3>; > + vcc-pc-supply = <®_vcc_3v3>; > + vcc-pd-supply = <®_vcc_3v3>; > + vcc-pe-supply = <®_vcc_3v3>; > + vcc-pf-supply = <®_vcc_3v3>; > + vcc-pg-supply = <®_vcc_3v3>; > +}; > + > +®_aldo { > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <1800000>; > + vdd33-supply = <®_vcc_3v3>; > +}; > + > +®_hpldo { > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <1800000>; > + hpldoin-supply = <®_vcc_3v3>; > +}; > + > +®_ldoa { > + regulator-always-on; > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <1800000>; > + ldo-in-supply = <®_vcc_3v3>; > +}; > diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1-nezha.dts b/arch/riscv/boot/dts/allwinner/sun20i-d1-nezha.dts > new file mode 100644 > index 000000000000..df865ee15fcf > --- /dev/null > +++ b/arch/riscv/boot/dts/allwinner/sun20i-d1-nezha.dts > @@ -0,0 +1,171 @@ > +// SPDX-License-Identifier: (GPL-2.0+ or MIT) > +// Copyright (C) 2021-2022 Samuel Holland <samuel@sholland.org> > + > +/dts-v1/; > + > +#include <dt-bindings/gpio/gpio.h> > +#include <dt-bindings/input/input.h> > + > +#include "sun20i-d1.dtsi" > +#include "sun20i-d1-common-regulators.dtsi" > + > +/ { > + model = "Allwinner D1 Nezha"; > + compatible = "allwinner,d1-nezha", "allwinner,sun20i-d1"; > + > + aliases { > + ethernet0 = &emac; > + ethernet1 = &xr829; > + mmc0 = &mmc0; > + serial0 = &uart0; > + }; > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > + > + reg_usbvbus: usbvbus { > + compatible = "regulator-fixed"; > + regulator-name = "usbvbus"; > + regulator-min-microvolt = <5000000>; > + regulator-max-microvolt = <5000000>; > + gpio = <&pio 3 19 GPIO_ACTIVE_HIGH>; /* PD19 */ > + enable-active-high; > + vin-supply = <®_vcc>; > + }; > + > + /* > + * This regulator is PWM-controlled, but the PWM controller is not > + * yet supported, so fix the regulator to its default voltage. > + */ > + reg_vdd_cpu: vdd-cpu { > + compatible = "regulator-fixed"; > + regulator-name = "vdd-cpu"; > + regulator-min-microvolt = <1100000>; > + regulator-max-microvolt = <1100000>; > + vin-supply = <®_vcc>; > + }; > + > + wifi_pwrseq: wifi-pwrseq { > + compatible = "mmc-pwrseq-simple"; > + reset-gpios = <&pio 6 12 GPIO_ACTIVE_LOW>; /* PG12 */ > + }; > +}; > + > +&cpu0 { > + cpu-supply = <®_vdd_cpu>; > +}; > + > +&ehci0 { > + status = "okay"; > +}; > + > +&ehci1 { > + status = "okay"; > +}; > + > +&emac { > + pinctrl-0 = <&rgmii_pe_pins>; > + pinctrl-names = "default"; > + phy-handle = <&ext_rgmii_phy>; > + phy-mode = "rgmii-id"; > + phy-supply = <®_vcc_3v3>; > + status = "okay"; > +}; > + > +&i2c2 { > + pinctrl-0 = <&i2c2_pb0_pins>; > + pinctrl-names = "default"; > + status = "okay"; > + > + pcf8574a: gpio@38 { > + compatible = "nxp,pcf8574a"; > + reg = <0x38>; > + interrupt-parent = <&pio>; > + interrupts = <1 2 IRQ_TYPE_LEVEL_LOW>; /* PB2 */ > + interrupt-controller; > + gpio-controller; > + #gpio-cells = <2>; > + #interrupt-cells = <2>; > + }; > +}; > + > +&lradc { > + status = "okay"; > + > + button-160 { > + label = "OK"; > + linux,code = <KEY_OK>; > + channel = <0>; > + voltage = <160000>; > + }; > +}; > + > +&mdio { > + ext_rgmii_phy: ethernet-phy@1 { > + compatible = "ethernet-phy-ieee802.3-c22"; > + reg = <1>; > + }; > +}; > + > +&mmc0 { > + bus-width = <4>; > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */ > + disable-wp; > + vmmc-supply = <®_vcc_3v3>; > + vqmmc-supply = <®_vcc_3v3>; > + pinctrl-0 = <&mmc0_pins>; > + pinctrl-names = "default"; > + status = "okay"; > +}; > + > +&mmc1 { > + bus-width = <4>; > + mmc-pwrseq = <&wifi_pwrseq>; > + non-removable; > + vmmc-supply = <®_vcc_3v3>; > + vqmmc-supply = <®_vcc_3v3>; > + pinctrl-0 = <&mmc1_pins>; > + pinctrl-names = "default"; > + status = "okay"; > + > + xr829: wifi@1 { > + reg = <1>; > + }; > +}; > + > +&ohci0 { > + status = "okay"; > +}; > + > +&ohci1 { > + status = "okay"; > +}; > + > +&uart0 { > + pinctrl-0 = <&uart0_pb8_pins>; > + pinctrl-names = "default"; > + status = "okay"; > +}; > + > +&uart1 { > + uart-has-rtscts; > + pinctrl-0 = <&uart1_pg6_pins>, <&uart1_pg8_rts_cts_pins>; > + pinctrl-names = "default"; > + status = "okay"; > + > + /* XR829 bluetooth is connected here */ > +}; > + > +&usb_otg { > + dr_mode = "otg"; > + status = "okay"; > +}; > + > +&usbphy { > + usb0_id_det-gpios = <&pio 3 21 GPIO_ACTIVE_HIGH>; /* PD21 */ > + usb0_vbus_det-gpios = <&pio 3 20 GPIO_ACTIVE_HIGH>; /* PD20 */ > + usb0_vbus-supply = <®_usbvbus>; > + usb1_vbus-supply = <®_vcc>; > + status = "okay"; > +};
在 2022-08-19星期五的 22:10 +0000，Conor.Dooley@microchip.com写道： > Hey Samuel, > > Finally got around to giving this a go with the fix for loading > modules which is mostly what was blocking me before.. > > On 15/08/2022 06:08, Samuel Holland wrote: > > "D1 Nezha" is Allwinner's first-party development board for the D1 > > SoC. > > It was shipped with 512M, 1G, or 2G of DDR3. It supports onboard > > audio, BTW I assume 512MB version is never publicly available, it's only some early samples that have the circuit of one of the DDR chips broken. > > I am really not keen on the way you have things, with the memory > nodes removed from the device tree. I know your preferred flow > for booting these things might be to pass the dtb up from U-Boot, > but I think the devicetree in the kernel should be usable in a > standalone manner, even if that is the barest-minimum memory > config. W/o interception of BL, I think there're more complex situations of the memory, e.g. some part of the memory is reserved. > > I did figure out all of my issues getting booted, thanks partly > to Heiko. The U-Boot dtb being misaligned was part of it as was > my initramfs with some stale sunxi modules in it causing RCU > stalls.. so sorry for the noise on that front (and thanks again > to Heiko!). > > Modulo the memory node, since I had to hack that in to get things > working & I do not want to have to keep doing: > Tested-by: Conor Dooley <conor.dooley@microchip.com> > > Thanks & apologies again for the modules-related issues - it was > hard to debug that one since module loading was broken on RISC-V > at the time. > Conor. > > > HDMI, gigabit Ethernet, WiFi and Bluetooth, USB 2.0 host and OTG > > ports, > > plus low-speed I/O from the SoC and a GPIO expander chip. > > > > Most other D1 boards copied the Nezha's power tree, with the 1.8V > > rail > > powered by the SoCs internal LDOA, analog domains powered by ALDO, > > and > > the rest of the board powered by always-on fixed regulators. Some > > (but > > not all) boards also copied the PWM CPU regulator. To avoid > > duplication, > > factor out the out the regulator references that are common across > > all > > known boards. > > > > Signed-off-by: Samuel Holland <samuel@sholland.org> > > --- > > > > arch/riscv/boot/dts/allwinner/Makefile | 1 + > > .../sun20i-d1-common-regulators.dtsi | 51 ++++++ > > .../boot/dts/allwinner/sun20i-d1-nezha.dts | 171 > > ++++++++++++++++++ > > 3 files changed, 223 insertions(+) > > create mode 100644 arch/riscv/boot/dts/allwinner/sun20i-d1-common- > > regulators.dtsi > > create mode 100644 arch/riscv/boot/dts/allwinner/sun20i-d1- > > nezha.dts > > > > diff --git a/arch/riscv/boot/dts/allwinner/Makefile > > b/arch/riscv/boot/dts/allwinner/Makefile > > index f66554cd5c45..b0a15e8c8d82 100644 > > --- a/arch/riscv/boot/dts/allwinner/Makefile > > +++ b/arch/riscv/boot/dts/allwinner/Makefile > > @@ -1 +1,2 @@ > > # SPDX-License-Identifier: GPL-2.0 > > +dtb-$(CONFIG_ARCH_SUNXI) += sun20i-d1-nezha.dtb > > diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1-common- > > regulators.dtsi b/arch/riscv/boot/dts/allwinner/sun20i-d1-common- > > regulators.dtsi > > new file mode 100644 > > index 000000000000..143a3e710c3c > > --- /dev/null > > +++ b/arch/riscv/boot/dts/allwinner/sun20i-d1-common- > > regulators.dtsi > > @@ -0,0 +1,51 @@ > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT) > > +// Copyright (C) 2021-2022 Samuel Holland <samuel@sholland.org> > > + > > +/ { > > + reg_vcc: vcc { > > + compatible = "regulator-fixed"; > > + regulator-name = "vcc"; > > + regulator-min-microvolt = <5000000>; > > + regulator-max-microvolt = <5000000>; > > + }; > > + > > + reg_vcc_3v3: vcc-3v3 { > > + compatible = "regulator-fixed"; > > + regulator-name = "vcc-3v3"; > > + regulator-min-microvolt = <3300000>; > > + regulator-max-microvolt = <3300000>; > > + vin-supply = <®_vcc>; > > + }; > > +}; > > + > > +&lradc { > > + vref-supply = <®_aldo>; > > +}; > > + > > +&pio { > > + vcc-pb-supply = <®_vcc_3v3>; > > + vcc-pc-supply = <®_vcc_3v3>; > > + vcc-pd-supply = <®_vcc_3v3>; > > + vcc-pe-supply = <®_vcc_3v3>; > > + vcc-pf-supply = <®_vcc_3v3>; > > + vcc-pg-supply = <®_vcc_3v3>; > > +}; > > + > > +®_aldo { > > + regulator-min-microvolt = <1800000>; > > + regulator-max-microvolt = <1800000>; > > + vdd33-supply = <®_vcc_3v3>; > > +}; > > + > > +®_hpldo { > > + regulator-min-microvolt = <1800000>; > > + regulator-max-microvolt = <1800000>; > > + hpldoin-supply = <®_vcc_3v3>; > > +}; > > + > > +®_ldoa { > > + regulator-always-on; > > + regulator-min-microvolt = <1800000>; > > + regulator-max-microvolt = <1800000>; > > + ldo-in-supply = <®_vcc_3v3>; > > +}; > > diff --git a/arch/riscv/boot/dts/allwinner/sun20i-d1-nezha.dts > > b/arch/riscv/boot/dts/allwinner/sun20i-d1-nezha.dts > > new file mode 100644 > > index 000000000000..df865ee15fcf > > --- /dev/null > > +++ b/arch/riscv/boot/dts/allwinner/sun20i-d1-nezha.dts > > @@ -0,0 +1,171 @@ > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT) > > +// Copyright (C) 2021-2022 Samuel Holland <samuel@sholland.org> > > + > > +/dts-v1/; > > + > > +#include <dt-bindings/gpio/gpio.h> > > +#include <dt-bindings/input/input.h> > > + > > +#include "sun20i-d1.dtsi" > > +#include "sun20i-d1-common-regulators.dtsi" > > + > > +/ { > > + model = "Allwinner D1 Nezha"; > > + compatible = "allwinner,d1-nezha", "allwinner,sun20i-d1"; > > + > > + aliases { > > + ethernet0 = &emac; > > + ethernet1 = &xr829; > > + mmc0 = &mmc0; > > + serial0 = &uart0; > > + }; > > + > > + chosen { > > + stdout-path = "serial0:115200n8"; > > + }; > > + > > + reg_usbvbus: usbvbus { > > + compatible = "regulator-fixed"; > > + regulator-name = "usbvbus"; > > + regulator-min-microvolt = <5000000>; > > + regulator-max-microvolt = <5000000>; > > + gpio = <&pio 3 19 GPIO_ACTIVE_HIGH>; /* PD19 */ > > + enable-active-high; > > + vin-supply = <®_vcc>; > > + }; > > + > > + /* > > + * This regulator is PWM-controlled, but the PWM controller > > is not > > + * yet supported, so fix the regulator to its default > > voltage. > > + */ > > + reg_vdd_cpu: vdd-cpu { > > + compatible = "regulator-fixed"; > > + regulator-name = "vdd-cpu"; > > + regulator-min-microvolt = <1100000>; > > + regulator-max-microvolt = <1100000>; > > + vin-supply = <®_vcc>; > > + }; > > + > > + wifi_pwrseq: wifi-pwrseq { > > + compatible = "mmc-pwrseq-simple"; > > + reset-gpios = <&pio 6 12 GPIO_ACTIVE_LOW>; /* PG12 > > */ > > + }; > > +}; > > + > > +&cpu0 { > > + cpu-supply = <®_vdd_cpu>; > > +}; > > + > > +&ehci0 { > > + status = "okay"; > > +}; > > + > > +&ehci1 { > > + status = "okay"; > > +}; > > + > > +&emac { > > + pinctrl-0 = <&rgmii_pe_pins>; > > + pinctrl-names = "default"; > > + phy-handle = <&ext_rgmii_phy>; > > + phy-mode = "rgmii-id"; > > + phy-supply = <®_vcc_3v3>; > > + status = "okay"; > > +}; > > + > > +&i2c2 { > > + pinctrl-0 = <&i2c2_pb0_pins>; > > + pinctrl-names = "default"; > > + status = "okay"; > > + > > + pcf8574a: gpio@38 { > > + compatible = "nxp,pcf8574a"; > > + reg = <0x38>; > > + interrupt-parent = <&pio>; > > + interrupts = <1 2 IRQ_TYPE_LEVEL_LOW>; /* PB2 */ > > + interrupt-controller; > > + gpio-controller; > > + #gpio-cells = <2>; > > + #interrupt-cells = <2>; > > + }; > > +}; > > + > > +&lradc { > > + status = "okay"; > > + > > + button-160 { > > + label = "OK"; > > + linux,code = <KEY_OK>; > > + channel = <0>; > > + voltage = <160000>; > > + }; > > +}; > > + > > +&mdio { > > + ext_rgmii_phy: ethernet-phy@1 { > > + compatible = "ethernet-phy-ieee802.3-c22"; > > + reg = <1>; > > + }; > > +}; > > + > > +&mmc0 { > > + bus-width = <4>; > > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */ > > + disable-wp; > > + vmmc-supply = <®_vcc_3v3>; > > + vqmmc-supply = <®_vcc_3v3>; > > + pinctrl-0 = <&mmc0_pins>; > > + pinctrl-names = "default"; > > + status = "okay"; > > +}; > > + > > +&mmc1 { > > + bus-width = <4>; > > + mmc-pwrseq = <&wifi_pwrseq>; > > + non-removable; > > + vmmc-supply = <®_vcc_3v3>; > > + vqmmc-supply = <®_vcc_3v3>; > > + pinctrl-0 = <&mmc1_pins>; > > + pinctrl-names = "default"; > > + status = "okay"; > > + > > + xr829: wifi@1 { > > + reg = <1>; > > + }; > > +}; > > + > > +&ohci0 { > > + status = "okay"; > > +}; > > + > > +&ohci1 { > > + status = "okay"; > > +}; > > + > > +&uart0 { > > + pinctrl-0 = <&uart0_pb8_pins>; > > + pinctrl-names = "default"; > > + status = "okay"; > > +}; > > + > > +&uart1 { > > + uart-has-rtscts; > > + pinctrl-0 = <&uart1_pg6_pins>, <&uart1_pg8_rts_cts_pins>; > > + pinctrl-names = "default"; > > + status = "okay"; > > + > > + /* XR829 bluetooth is connected here */ > > +}; > > + > > +&usb_otg { > > + dr_mode = "otg"; > > + status = "okay"; > > +}; > > + > > +&usbphy { > > + usb0_id_det-gpios = <&pio 3 21 GPIO_ACTIVE_HIGH>; /* PD21 > > */ > > + usb0_vbus_det-gpios = <&pio 3 20 GPIO_ACTIVE_HIGH>; /* PD20 > > */ > > + usb0_vbus-supply = <®_usbvbus>; > > + usb1_vbus-supply = <®_vcc>; > > + status = "okay"; > > +};
>>>>> "Samuel" == Samuel Holland <samuel@sholland.org> writes: > "D1 Nezha" is Allwinner's first-party development board for the D1 SoC. > It was shipped with 512M, 1G, or 2G of DDR3. It supports onboard audio, > HDMI, gigabit Ethernet, WiFi and Bluetooth, USB 2.0 host and OTG ports, > plus low-speed I/O from the SoC and a GPIO expander chip. > Most other D1 boards copied the Nezha's power tree, with the 1.8V rail > powered by the SoCs internal LDOA, analog domains powered by ALDO, and > the rest of the board powered by always-on fixed regulators. Some (but > not all) boards also copied the PWM CPU regulator. To avoid duplication, > factor out the out the regulator references that are common across all NIT: s/out the out the/out the/
Hi Conor, On 8/19/22 5:10 PM, Conor.Dooley@microchip.com wrote: > Finally got around to giving this a go with the fix for loading > modules which is mostly what was blocking me before.. > > On 15/08/2022 06:08, Samuel Holland wrote: >> "D1 Nezha" is Allwinner's first-party development board for the D1 SoC. >> It was shipped with 512M, 1G, or 2G of DDR3. It supports onboard audio, > > I am really not keen on the way you have things, with the memory > nodes removed from the device tree. I know your preferred flow > for booting these things might be to pass the dtb up from U-Boot, > but I think the devicetree in the kernel should be usable in a > standalone manner, even if that is the barest-minimum memory > config. That is simply not possible to guarantee. As an obvious example, consider the MangoPi MQ-Pro board with socketed DRAM: https://twitter.com/mangopi_sbc/status/1516225559214583808 But focusing on the /memory node misses the bigger picture. The DTB is passed through _all_ of the firmware stages, and gets patched by every one of them: - SPL/boot0 adds the /memory node with the detected DRAM size. If the in-tree DTS has a "minimum memory config" (which for a board with socketed DRAM means the smallest possible die), I guarantee people will use it and complain about missing DRAM. - The SBI implementation reserves memory for itself and any possible secure partitions. Right now, booting happens to work without the reserved-memory node because the SBI implementation is loaded at the beginning of RAM, and Linux ignores RAM below the kernel load address. However, memory-constrained devices (e.g. D1s) will need to get those 2 MiB back by loading the kernel at the start of DRAM and SBI at the end of DRAM. Then the reserved-memory node becomes quite important. It also adds nodes for CPU idle states, since the available states and their latencies depend on the SBI implementation. It also reserves devices used by it or by a secure partition. And it is responsible for extracting data (e.g. MAC addresses) from "secure" eFuses which the OS may not have access to. - U-Boot adds other information, like boot arguments, the address of the initramfs and framebuffer, etc. These are less of a concern because of course U-Boot can patch these in to a DTB loaded from disk, but they are relevant if you want to load a DTB from a later bootloader like GRUB. If you load a DTB from disk, you lose all of the changes made by the earlier firmware stages. On ARM, U-Boot tries to work around this by copying a few specific bits of information from the firmware DTB to the DTB loaded from disk. But this misses the point that the SBI implementation can modify *any* part of the DTB. (So in practice U-Boot on ARM already loses CPU idle states and reserved memory nodes that were added by the PSCI implementation.) As an extreme example, consider paravirtualization, where only a small subset of DRAM and peripherals may be made available to any one OS partition. Fundamentally, I reserve the right to make arbitrary changes to the DTB in the SBI implementation, and thus I cannot condone using the DTBs generated from the Linux source tree for any purpose other than validation. Regards, Samuel