| Message ID | 20240321-cn9130-som-v1-2-711127a409ae@solid-run.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: dts: add description for solidrun cn9130 som and clearfog boards | expand |
On Thu, Mar 21, 2024 at 10:47:12PM +0100, Josua Mayer wrote: > Add description for the SolidRun CN9130 SoM, and Clearfog Base / Pro > reference boards. > > The SoM has been designed as a pin-compatible replacement for the older > Armada 388 based SoM. Therefore it supports the same boards and a > similar feature set. > > Most notable upgrades: > - 4x Cortex-A72 > - 10Gbps SFP > - Both eMMC and SD supported at the same time > > The developer first supporting this product at SolidRun decided to use > different filenames for the DTBs: Armada 388 uses the full > "clearfog" string while cn9130 uses the abbreviation "cf". > This name is already hard-coded in pre-installed vendor u-boot and can > not be changed easily. > > NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE: > CN9130 SoM has a different footprint from Armada 388 SoM. > Components on the carrier board below the SoM may collide causing > damage, such as on Clearfog Base. > > Signed-off-by: Josua Mayer <josua@solid-run.com> > --- > arch/arm64/boot/dts/marvell/Makefile | 2 + > arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 138 ++++++++++++++ > arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 249 +++++++++++++++++++++++++ > arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 198 ++++++++++++++++++++ > arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 160 ++++++++++++++++ > 5 files changed, 747 insertions(+) > > diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile > index 99b8cb3c49e1..019f2251d696 100644 > --- a/arch/arm64/boot/dts/marvell/Makefile > +++ b/arch/arm64/boot/dts/marvell/Makefile > @@ -28,3 +28,5 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb > dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb > dtb-$(CONFIG_ARCH_MVEBU) += ac5x-rd-carrier-cn9131.dtb > dtb-$(CONFIG_ARCH_MVEBU) += ac5-98dx35xx-rd.dtb > +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-base.dtb > +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-pro.dtb > diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts > new file mode 100644 > index 000000000000..b0067940d5e4 > --- /dev/null > +++ b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts > @@ -0,0 +1,138 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> > + * > + * DTS for SolidRun CN9130 Clearfog Base. > + * > + */ > + > +/dts-v1/; > + > +#include <dt-bindings/input/input.h> > + > +#include "cn9130.dtsi" > +#include "cn9130-sr-som.dtsi" > +#include "cn9130-cf.dtsi" > + > +/ { > + model = "SolidRun CN9130 Clearfog Base"; > + compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1", > + "solidrun,cn9130-sr-som","marvell,cn9130", > + "marvell,armada-ap807-quad", "marvell,armada-ap807"; > + > + gpio-keys { > + compatible = "gpio-keys"; > + pinctrl-0 = <&rear_button_pins>; > + pinctrl-names = "default"; > + > + button-0 { > + /* The rear SW3 button */ > + label = "Rear Button"; > + gpios = <&cp0_gpio1 31 GPIO_ACTIVE_LOW>; > + linux,can-disable; > + linux,code = <BTN_0>; > + }; > + }; > + > + rfkill-m2-gnss { > + compatible = "rfkill-gpio"; > + label = "m.2 GNSS"; > + radio-type = "gps"; > + /* rfkill-gpio inverts internally */ > + shutdown-gpios = <&expander0 9 GPIO_ACTIVE_HIGH>; > + }; > + > + /* M.2 is B-keyed, so w-disable is for WWAN */ > + rfkill-m2-wwan { > + compatible = "rfkill-gpio"; > + label = "m.2 WWAN"; > + radio-type = "wwan"; > + /* rfkill-gpio inverts internally */ > + shutdown-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>; > + }; > +}; > + > +/* SRDS #3 - SGMII 1GE */ > +&cp0_eth1 { > + phy = <&phy1>; > + phys = <&cp0_comphy3 1>; > + phy-mode = "sgmii"; > + status = "okay"; > +}; > + > +&cp0_eth2_phy { > + /* > + * Configure LEDs: > + * - LED[0]: link/activity: On/blink (green) > + * - LED[1]: link is 100/1000Mbps: On (yellow) > + * - LED[2]: high impedance (floating) > + */ > + marvell,reg-init = <3 16 0xf000 0x0a61>; Sorry, but no. List the LEDs in the PHY node, and they can then be controlled via /sys/class/leds. arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. Andrew
Am 21.03.24 um 22:59 schrieb Andrew Lunn: > On Thu, Mar 21, 2024 at 10:47:12PM +0100, Josua Mayer wrote: >> Add description for the SolidRun CN9130 SoM, and Clearfog Base / Pro >> reference boards. >> >> The SoM has been designed as a pin-compatible replacement for the older >> Armada 388 based SoM. Therefore it supports the same boards and a >> similar feature set. >> >> Most notable upgrades: >> - 4x Cortex-A72 >> - 10Gbps SFP >> - Both eMMC and SD supported at the same time >> >> The developer first supporting this product at SolidRun decided to use >> different filenames for the DTBs: Armada 388 uses the full >> "clearfog" string while cn9130 uses the abbreviation "cf". >> This name is already hard-coded in pre-installed vendor u-boot and can >> not be changed easily. >> >> NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE: >> CN9130 SoM has a different footprint from Armada 388 SoM. >> Components on the carrier board below the SoM may collide causing >> damage, such as on Clearfog Base. >> >> Signed-off-by: Josua Mayer <josua@solid-run.com> >> --- >> arch/arm64/boot/dts/marvell/Makefile | 2 + >> arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 138 ++++++++++++++ >> arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 249 +++++++++++++++++++++++++ >> arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 198 ++++++++++++++++++++ >> arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 160 ++++++++++++++++ >> 5 files changed, 747 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile >> index 99b8cb3c49e1..019f2251d696 100644 >> --- a/arch/arm64/boot/dts/marvell/Makefile >> +++ b/arch/arm64/boot/dts/marvell/Makefile >> @@ -28,3 +28,5 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb >> dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb >> dtb-$(CONFIG_ARCH_MVEBU) += ac5x-rd-carrier-cn9131.dtb >> dtb-$(CONFIG_ARCH_MVEBU) += ac5-98dx35xx-rd.dtb >> +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-base.dtb >> +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-pro.dtb >> diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts >> new file mode 100644 >> index 000000000000..b0067940d5e4 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts >> @@ -0,0 +1,138 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> >> + * >> + * DTS for SolidRun CN9130 Clearfog Base. >> + * >> + */ >> + >> +/dts-v1/; >> + >> +#include <dt-bindings/input/input.h> >> + >> +#include "cn9130.dtsi" >> +#include "cn9130-sr-som.dtsi" >> +#include "cn9130-cf.dtsi" >> + >> +/ { >> + model = "SolidRun CN9130 Clearfog Base"; >> + compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1", >> + "solidrun,cn9130-sr-som","marvell,cn9130", >> + "marvell,armada-ap807-quad", "marvell,armada-ap807"; >> + >> + gpio-keys { >> + compatible = "gpio-keys"; >> + pinctrl-0 = <&rear_button_pins>; >> + pinctrl-names = "default"; >> + >> + button-0 { >> + /* The rear SW3 button */ >> + label = "Rear Button"; >> + gpios = <&cp0_gpio1 31 GPIO_ACTIVE_LOW>; >> + linux,can-disable; >> + linux,code = <BTN_0>; >> + }; >> + }; >> + >> + rfkill-m2-gnss { >> + compatible = "rfkill-gpio"; >> + label = "m.2 GNSS"; >> + radio-type = "gps"; >> + /* rfkill-gpio inverts internally */ >> + shutdown-gpios = <&expander0 9 GPIO_ACTIVE_HIGH>; >> + }; >> + >> + /* M.2 is B-keyed, so w-disable is for WWAN */ >> + rfkill-m2-wwan { >> + compatible = "rfkill-gpio"; >> + label = "m.2 WWAN"; >> + radio-type = "wwan"; >> + /* rfkill-gpio inverts internally */ >> + shutdown-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>; >> + }; >> +}; >> + >> +/* SRDS #3 - SGMII 1GE */ >> +&cp0_eth1 { >> + phy = <&phy1>; >> + phys = <&cp0_comphy3 1>; >> + phy-mode = "sgmii"; >> + status = "okay"; >> +}; >> + >> +&cp0_eth2_phy { >> + /* >> + * Configure LEDs: >> + * - LED[0]: link/activity: On/blink (green) >> + * - LED[1]: link is 100/1000Mbps: On (yellow) >> + * - LED[2]: high impedance (floating) >> + */ >> + marvell,reg-init = <3 16 0xf000 0x0a61>; > Sorry, but no. List the LEDs in the PHY node, and they can then be > controlled via /sys/class/leds. May I ask more precisely the motivation? Does this replace the phy's builtin automatic led control? > arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. I will investigate it. My main motivation for tweaking the led controls was to make them all consistent across the two boards: - LEDs under control of PHYs on cpu mdio bus - LEDs under control of ethernet switch on mdio bus - LEDs under control of ethernet phy on external mdio bus behind ethernet switch It looks as if the marvell phy driver supports led subnodes, The switch driver does not. Finally one phy can only be written to but not read, the cpu can never know its link state. So I prefer (for the Clearfog Pro) board to explicitly use the phys autonomous management of LEDs. Is that still possible if I added led subnodes?
> > Sorry, but no. List the LEDs in the PHY node, and they can then be > > controlled via /sys/class/leds. > May I ask more precisely the motivation? > Does this replace the phy's builtin automatic led control? > > arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. > > I will investigate it. > > My main motivation for tweaking the led controls was to make them all consistent across the two boards: > - LEDs under control of PHYs on cpu mdio bus > - LEDs under control of ethernet switch on mdio bus > - LEDs under control of ethernet phy on external mdio bus behind ethernet switch > > It looks as if the marvell phy driver supports led subnodes, > The switch driver does not. https://lwn.net/Articles/965775/ There has been quite a bit of interest in mv88e6xxx driver support, so i expect support for other families outside of 6352 will be added after it has been merged, and it is not difficult code to write. > Finally one phy can only be written to but not read, > the cpu can never know its link state. O.K. That one cannot use the LED infrastructure in a meaningful way. > So I prefer (for the Clearfog Pro) board to explicitly use the phys > autonomous management of LEDs. > Is that still possible if I added led subnodes? You can combine both. The horrible marvell,reg-init will be applied first. The generic LED code will then take over controlling the LEDs. For the discrete PHYs, the generic LED code can make use of the hardware offload support to read back the hardware configuration and configure itself to match. The switch code is missing hardware offload at the moment. So it cannot read back the current configuration. However, it is simple code to add, and the discrete code is a good example to follow. marvell,reg-init is not going to go away, because of backwards compatibility with old DT blobs. But in general, i expect all vendor proprietary methods of configuring LEDs to be deprecated and replaced with the vendor neutral /sys/class/leds. Andrew
Am 22.03.24 um 14:11 schrieb Andrew Lunn: >>> Sorry, but no. List the LEDs in the PHY node, and they can then be >>> controlled via /sys/class/leds. >> May I ask more precisely the motivation? >> Does this replace the phy's builtin automatic led control? >>> arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. >> I will investigate it. >> >> My main motivation for tweaking the led controls was to make them all consistent across the two boards: >> - LEDs under control of PHYs on cpu mdio bus >> - LEDs under control of ethernet switch on mdio bus >> - LEDs under control of ethernet phy on external mdio bus behind ethernet switch >> >> It looks as if the marvell phy driver supports led subnodes, >> The switch driver does not. > https://lwn.net/Articles/965775/ Great! > > There has been quite a bit of interest in mv88e6xxx driver support, so > i expect support for other families outside of 6352 will be added > after it has been merged, and it is not difficult code to write. > >> Finally one phy can only be written to but not read, >> the cpu can never know its link state. > O.K. That one cannot use the LED infrastructure in a meaningful way. > >> So I prefer (for the Clearfog Pro) board to explicitly use the phys >> autonomous management of LEDs. >> Is that still possible if I added led subnodes? > You can combine both. The horrible marvell,reg-init will be applied > first. The generic LED code will then take over controlling the LEDs. I (currently) can't put in the led node e.g. linux,default-trigger = "link100|link1000|tx|rx"; Right? > > For the discrete PHYs, the generic LED code can make use of the > hardware offload support to read back the hardware configuration and > configure itself to match. The switch code is missing hardware offload > at the moment. So it cannot read back the current > configuration. However, it is simple code to add, and the discrete > code is a good example to follow. > > marvell,reg-init is not going to go away, because of backwards > compatibility with old DT blobs. But in general, i expect all vendor > proprietary methods of configuring LEDs to be deprecated and replaced > with the vendor neutral /sys/class/leds. Sounds good.
> I (currently) can't put in the led node e.g. > linux,default-trigger = "link100|link1000|tx|rx"; > Right? No. The trigger will be 'netdev'. Or 'heartbeat', or 'kbd-numlock'. They are just LEDs, they can be used for anything. While testing some of this code i had the keyboard numlock indicating network packets, since it easier to see than the RJ45 socket... The same applies the other way. The RJ45 LEDs are just Linux LEDs, they can be used for anything... I do have some code adding additional properties for the blink reason. However, it is very debatable if it belongs in DT. DT describes hardware, not configuration of hardware. Do you actually have labels on the case indicating what the LEDs mean? It could be we describe the label, which is hardware, not the configuration of the LED, which is policy from user space. Andrew
Am 22.03.24 um 16:49 schrieb Andrew Lunn: >> I (currently) can't put in the led node e.g. >> linux,default-trigger = "link100|link1000|tx|rx"; >> Right? > No. The trigger will be 'netdev'. Or 'heartbeat', or > 'kbd-numlock'. OK. > They are just LEDs, they can be used for > anything. While testing some of this code i had the keyboard numlock > indicating network packets, since it easier to see than the RJ45 > socket... The same applies the other way. The RJ45 LEDs are just Linux > LEDs, they can be used for anything... > > I do have some code adding additional properties for the blink > reason. However, it is very debatable if it belongs in DT. DT > describes hardware, not configuration of hardware. > > Do you actually have labels on the case indicating what the LEDs mean? > It could be we describe the label, which is hardware, not the > configuration of the LED, which is policy from user space. I have seen it on customer products, and I have seen it in manuals, and it can help in customer support. Personally I would want it for consistency reasons, so that even if hardware engineers confused 0 and 1 I can ensure consistent behaviour out of the box. It could be the vendor recommended or intended configuration ...
Am 22.03.24 um 16:38 schrieb Josua Mayer: > For the discrete PHYs, the generic LED code can make use of the > hardware offload support to read back the hardware configuration and > configure itself to match. The switch code is missing hardware offload > at the moment. So it cannot read back the current > configuration. However, it is simple code to add, and the discrete > code is a good example to follow. I have prototyped this on top of your patch-set, supporting offload for a single mode. It works as explained by you - first after boot-up the LEDs are executing their default function autonomously. When I set trigger netdev, I can see offloaded property is 1, and when I enable extra bits offload turns off. For Clearfog Base I have added the requested LED descriptions, it should be ready now. The Pro version I could 1) submit new version with only phy leds 2) wait (not preferred) 3) submit new version with an separate patch adding switch leds (can hold of ack on it till the fait of your patch-set becomes clear)
On Fri, Mar 22, 2024 at 06:14:38PM +0000, Josua Mayer wrote: > Am 22.03.24 um 16:38 schrieb Josua Mayer: > > For the discrete PHYs, the generic LED code can make use of the > > hardware offload support to read back the hardware configuration and > > configure itself to match. The switch code is missing hardware offload > > at the moment. So it cannot read back the current > > configuration. However, it is simple code to add, and the discrete > > code is a good example to follow. > I have prototyped this on top of your patch-set, supporting offload > for a single mode. > It works as explained by you - first after boot-up the LEDs > are executing their default function autonomously. > > When I set trigger netdev, I can see offloaded property is 1, > and when I enable extra bits offload turns off. > > > For Clearfog Base I have added the requested LED descriptions, > it should be ready now. > > The Pro version I could > 1) submit new version with only phy leds > 2) wait (not preferred) > 3) submit new version with an separate patch adding switch leds > (can hold of ack on it till the fait of your patch-set becomes clear) You probably need to wait whatever. We are in the merge window. Many maintainers don't accept patches during these two weeks. They want you to submit against -rc1 once it is released. And there is no rush. The next merge window is not for another 7 weeks or so. Gregory will accept patches for mvebu for around 5 of those weeks. Andrew
diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile index 99b8cb3c49e1..019f2251d696 100644 --- a/arch/arm64/boot/dts/marvell/Makefile +++ b/arch/arm64/boot/dts/marvell/Makefile @@ -28,3 +28,5 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb dtb-$(CONFIG_ARCH_MVEBU) += ac5x-rd-carrier-cn9131.dtb dtb-$(CONFIG_ARCH_MVEBU) += ac5-98dx35xx-rd.dtb +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-base.dtb +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-pro.dtb diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts new file mode 100644 index 000000000000..b0067940d5e4 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts @@ -0,0 +1,138 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> + * + * DTS for SolidRun CN9130 Clearfog Base. + * + */ + +/dts-v1/; + +#include <dt-bindings/input/input.h> + +#include "cn9130.dtsi" +#include "cn9130-sr-som.dtsi" +#include "cn9130-cf.dtsi" + +/ { + model = "SolidRun CN9130 Clearfog Base"; + compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1", + "solidrun,cn9130-sr-som","marvell,cn9130", + "marvell,armada-ap807-quad", "marvell,armada-ap807"; + + gpio-keys { + compatible = "gpio-keys"; + pinctrl-0 = <&rear_button_pins>; + pinctrl-names = "default"; + + button-0 { + /* The rear SW3 button */ + label = "Rear Button"; + gpios = <&cp0_gpio1 31 GPIO_ACTIVE_LOW>; + linux,can-disable; + linux,code = <BTN_0>; + }; + }; + + rfkill-m2-gnss { + compatible = "rfkill-gpio"; + label = "m.2 GNSS"; + radio-type = "gps"; + /* rfkill-gpio inverts internally */ + shutdown-gpios = <&expander0 9 GPIO_ACTIVE_HIGH>; + }; + + /* M.2 is B-keyed, so w-disable is for WWAN */ + rfkill-m2-wwan { + compatible = "rfkill-gpio"; + label = "m.2 WWAN"; + radio-type = "wwan"; + /* rfkill-gpio inverts internally */ + shutdown-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>; + }; +}; + +/* SRDS #3 - SGMII 1GE */ +&cp0_eth1 { + phy = <&phy1>; + phys = <&cp0_comphy3 1>; + phy-mode = "sgmii"; + status = "okay"; +}; + +&cp0_eth2_phy { + /* + * Configure LEDs: + * - LED[0]: link/activity: On/blink (green) + * - LED[1]: link is 100/1000Mbps: On (yellow) + * - LED[2]: high impedance (floating) + */ + marvell,reg-init = <3 16 0xf000 0x0a61>; +}; + +&cp0_gpio1 { + sim-select-hog { + gpio-hog; + gpios = <27 GPIO_ACTIVE_HIGH>; + output-high; + line-name = "sim-select"; + }; +}; + +&cp0_mdio { + phy1: ethernet-phy@1 { + reg = <1>; + /* + * Configure LEDs: + * - LED[0]: link/activity: On/blink (green) + * - LED[1]: link is 100/1000Mbps: On (yellow) + * - LED[2]: high impedance (floating) + * + * Polarity: On = low, Off = high (not hi-z) + */ + marvell,reg-init = <3 16 0xf000 0x0a61>, + <3 17 0x003f 0x000a>; + }; +}; + +&cp0_pinctrl { + pinctrl-0 = <&sim_select_pins>; + pintrl-names = "default"; + + rear_button_pins: cp0-rear-button-pins { + marvell,pins = "mpp31"; + marvell,function = "gpio"; + }; + + sim_select_pins: cp0-sim-select-pins { + marvell,pins = "mpp27"; + marvell,function = "gpio"; + }; +}; + +/* + * SRDS #4 - USB 3.0 host on M.2 connector + * USB-2.0 Host on Type-A connector + */ +&cp0_usb3_1 { + phys = <&cp0_comphy4 1>, <&cp0_utmi1>; + phy-names = "comphy", "utmi"; + dr_mode = "host"; + status = "okay"; +}; + +&expander0 { + m2-full-card-power-off-hog { + gpio-hog; + gpios = <2 GPIO_ACTIVE_LOW>; + output-low; + line-name = "m2-full-card-power-off"; + }; + + m2-reset-hog { + gpio-hog; + gpios = <10 GPIO_ACTIVE_LOW>; + output-low; + line-name = "m2-reset"; + }; +}; diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts new file mode 100644 index 000000000000..f7733f6a89b8 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts @@ -0,0 +1,249 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> + * + * DTS for SolidRun CN9130 Clearfog Pro. + * + */ + +/dts-v1/; + +#include <dt-bindings/input/input.h> + +#include "cn9130.dtsi" +#include "cn9130-sr-som.dtsi" +#include "cn9130-cf.dtsi" + +/ { + model = "SolidRun CN9130 Clearfog Pro"; + compatible = "solidrun,clearfog-pro-a1", "solidrun,clearfog-a1", + "solidrun,cn9130-sr-som","marvell,cn9130", + "marvell,armada-ap807-quad", "marvell,armada-ap807"; + + gpio-keys { + compatible = "gpio-keys"; + pinctrl-0 = <&rear_button_pins>; + pinctrl-names = "default"; + + button-0 { + /* The rear SW3 button */ + label = "Rear Button"; + gpios = <&cp0_gpio2 0 GPIO_ACTIVE_LOW>; + linux,can-disable; + linux,code = <BTN_0>; + }; + }; + + /* mini-pcie w-disable could be either wlan or wwan */ + rfkill-mpcie1-xxan { + compatible = "rfkill-gpio"; + label = "mPCI-e WLAN (CON2)"; + radio-type = "wlan"; + /* rfkill-gpio inverts internally */ + shutdown-gpios = <&expander0 7 GPIO_ACTIVE_HIGH>; + }; +}; + +/* SRDS #3 - SGMII 1GE to L2 switch */ +&cp0_eth1 { + phys = <&cp0_comphy3 1>; + phy-mode = "sgmii"; + status = "okay"; + + fixed-link { + speed = <1000>; + full-duplex; + }; +}; + +&cp0_eth2_phy { + /* + * Configure LEDs similar to switch ports: + * - LED[0]: link/activity: On/blink (green) + * - LED[1]: link is 100/1000Mbps: On (red) + * - LED[2]: high impedance (floating) + * + * Switch port defaults: + * - LED0: link/activity: On/blink (green) + * - LED1: link is 1000Mbps: On (red) + * + * Identical configuration is impossible. + */ + marvell,reg-init = <3 16 0xf000 0x0a61>; +}; + +&cp0_mdio { + ethernet-switch@4 { + compatible = "marvell,mv88e6085"; + reg = <4>; + pinctrl-0 = <&dsa_clk_pins &dsa_pins>; + pinctrl-names = "default"; + reset-gpios = <&cp0_gpio1 27 GPIO_ACTIVE_LOW>; + interrupt-parent = <&cp0_gpio1>; + interrupts = <29 IRQ_TYPE_EDGE_FALLING>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-port@0 { + reg = <0>; + label = "lan5"; + phy = <&switch0phy0>; + }; + + ethernet-port@1 { + reg = <1>; + label = "lan4"; + phy = <&switch0phy1>; + }; + + ethernet-port@2 { + reg = <2>; + label = "lan3"; + phy = <&switch0phy2>; + }; + + ethernet-port@3 { + reg = <3>; + label = "lan2"; + phy = <&switch0phy3>; + }; + + ethernet-port@4 { + reg = <4>; + label = "lan1"; + phy = <&switch0phy4>; + }; + + ethernet-port@5 { + reg = <5>; + ethernet = <&cp0_eth1>; + phy-mode = "sgmii"; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + + ethernet-port@6 { + reg = <6>; + label = "lan6"; + phy-mode = "rgmii"; + + /* + * Because of mdio address conflict the + * external phy is not readable. + * Force a fixed link instead. + */ + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + switch0phy0: ethernet-phy@0 { + reg = <0x0>; + }; + + switch0phy1: ethernet-phy@1 { + reg = <0x1>; + /* + * Indirectly configure LEDs for port + * lan6 using external phy. + * Internal PHYs are not using page 3, + * therefore writing to it is safe. + */ + marvell,reg-init = <3 16 0xf000 0x0a61>; + }; + + switch0phy2: ethernet-phy@2 { + reg = <0x2>; + }; + + switch0phy3: ethernet-phy@3 { + reg = <0x3>; + }; + + switch0phy4: ethernet-phy@4 { + reg = <0x4>; + }; + }; + + /* + * There is an external phy on the switch mdio bus. + * Because its mdio address collides with internal phys, + * it is not readable. + * + * mdio-external { + * compatible = "marvell,mv88e6xxx-mdio-external"; + * #address-cells = <1>; + * #size-cells = <0>; + * + * ethernet-phy@1 { + * reg = <0x1>; + * }; + * }; + */ + }; +}; + +/* SRDS #4 - miniPCIe (CON2) */ +&cp0_pcie1 { + num-lanes = <1>; + phys = <&cp0_comphy4 1>; + /* dw-pcie inverts internally */ + reset-gpios = <&expander0 2 GPIO_ACTIVE_HIGH>; + status = "okay"; +}; + +&cp0_pinctrl { + dsa_clk_pins: cp0-dsa-clk-pins { + marvell,pins = "mpp40"; + marvell,function = "synce1"; + }; + + dsa_pins: cp0-dsa-pins { + marvell,pins = "mpp27", "mpp29"; + marvell,function = "gpio"; + }; + + rear_button_pins: cp0-rear-button-pins { + marvell,pins = "mpp32"; + marvell,function = "gpio"; + }; +}; + +/* + * USB-2.0 Host on Type-A connector + */ +&cp0_usb3_1 { + phys = <&cp0_utmi1>; + phy-names = "utmi"; + dr_mode = "host"; + status = "okay"; +}; + +&expander0 { + /* CON2 */ + pcie1-0-clkreq-hog { + gpio-hog; + gpios = <4 GPIO_ACTIVE_LOW>; + input; + line-name = "pcie1.0-clkreq"; + }; + + /* CON2 */ + pcie1-0-w-disable-hog { + gpio-hog; + gpios = <7 GPIO_ACTIVE_LOW>; + output-low; + line-name = "pcie1.0-w-disable"; + }; +}; diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi b/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi new file mode 100644 index 000000000000..1aaa0d916e75 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi @@ -0,0 +1,198 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> + * + * DTS for common base of SolidRun CN9130 Clearfog Base and Pro. + * + */ + +/ { + model = "SolidRun CN9130 Clearfog"; + compatible = "solidrun,clearfog-a1", + "solidrun,cn9130-sr-som","marvell,cn9130", + "marvell,armada-ap807-quad", "marvell,armada-ap807"; + + aliases { + i2c1 = &cp0_i2c1; + mmc1 = &cp0_sdhci0; + }; + + reg_usb3_vbus0: regulator-usb3-vbus0 { + compatible = "regulator-fixed"; + regulator-name = "vbus0"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + gpio = <&expander0 6 GPIO_ACTIVE_LOW>; + }; + + sfp: sfp { + compatible = "sff,sfp"; + i2c-bus = <&cp0_i2c1>; + los-gpios = <&expander0 12 GPIO_ACTIVE_HIGH>; + mod-def0-gpios = <&expander0 15 GPIO_ACTIVE_LOW>; + tx-disable-gpios = <&expander0 14 GPIO_ACTIVE_HIGH>; + tx-fault-gpios = <&expander0 13 GPIO_ACTIVE_HIGH>; + maximum-power-milliwatt = <2000>; + }; +}; + +/* SRDS #2 - SFP+ 10GE */ +&cp0_eth0 { + managed = "in-band-status"; + phys = <&cp0_comphy2 0>; + phy-mode = "10gbase-r"; + sfp = <&sfp>; + status = "okay"; +}; + +&cp0_i2c0 { + expander0: gpio-expander@20 { + compatible = "nxp,pca9555"; + reg = <0x20>; + gpio-controller; + #gpio-cells = <2>; + pinctrl-0 = <&expander0_pins>; + pinctrl-names = "default"; + interrupt-parent = <&cp0_gpio1>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + + /* CON3 */ + pcie2-0-clkreq-hog { + gpio-hog; + gpios = <0 GPIO_ACTIVE_LOW>; + input; + line-name = "pcie2.0-clkreq"; + }; + + /* CON3 */ + pcie2-0-w-disable-hog { + gpio-hog; + gpios = <3 GPIO_ACTIVE_LOW>; + output-low; + line-name = "pcie2.0-w-disable"; + }; + + usb3-ilimit-hog { + gpio-hog; + gpios = <5 GPIO_ACTIVE_LOW>; + input; + line-name = "usb3-current-limit"; + }; + + m2-devslp-hog { + gpio-hog; + gpios = <11 GPIO_ACTIVE_HIGH>; + output-low; + line-name = "m.2 devslp"; + }; + }; + + /* The MCP3021 supports standard and fast modes */ + adc@4c { + compatible = "microchip,mcp3021"; + reg = <0x4c>; + }; + + carrier_eeprom: eeprom@52 { + compatible = "atmel,24c02"; + reg = <0x52>; + pagesize = <8>; + }; +}; + +&cp0_i2c1 { + /* + * Routed to SFP, M.2, mikrobus, and miniPCIe + * SFP limits this to 100kHz, and requires an AT24C01A/02/04 with + * address pins tied low, which takes addresses 0x50 and 0x51. + * Mikrobus doesn't specify beyond an I2C bus being present. + * PCIe uses ARP to assign addresses, or 0x63-0x64. + */ + clock-frequency = <100000>; + pinctrl-0 = <&cp0_i2c1_pins>; + pinctrl-names = "default"; + status = "okay"; +}; + +/* SRDS #5 - miniPCIe (CON3) */ +&cp0_pcie2 { + num-lanes = <1>; + phys = <&cp0_comphy5 2>; + /* dw-pcie inverts internally */ + reset-gpios = <&expander0 1 GPIO_ACTIVE_HIGH>; + status = "okay"; +}; + +&cp0_pinctrl { + cp0_i2c1_pins: cp0-i2c1-pins { + marvell,pins = "mpp35", "mpp36"; + marvell,function = "i2c1"; + }; + + cp0_mmc0_pins: cp0-mmc0-pins { + marvell,pins = "mpp43", "mpp56", "mpp57", "mpp58", + "mpp59", "mpp60", "mpp61"; + marvell,function = "sdio"; + }; + + mikro_spi_pins: cp0-spi1-cs1-pins { + marvell,pins = "mpp12"; + marvell,function = "spi1"; + }; + + mikro_uart_pins: cp0-uart-pins { + marvell,pins = "mpp2", "mpp3"; + marvell,function = "uart1"; + }; + + expander0_pins: cp0-expander0-pins { + marvell,pins = "mpp4"; + marvell,function = "gpio"; + }; +}; + +/* SRDS #0 - SATA on M.2 connector */ +&cp0_sata0 { + phys = <&cp0_comphy0 1>; + status = "okay"; + + /* only port 1 is available */ + /delete-node/ sata-port@0; +}; + +/* microSD */ +&cp0_sdhci0 { + pinctrl-0 = <&cp0_mmc0_pins>; + pinctrl-names = "default"; + bus-width = <4>; + no-1-8-v; + status = "okay"; +}; + +&cp0_spi1 { + /* CS1 for mikrobus */ + pinctrl-0 = <&cp0_spi1_pins &mikro_spi_pins>; +}; + +/* + * SRDS #1 - 3.0 Host on Type-A connector + * USB-2.0 Host on mPCI-e connector (CON3) + */ +&cp0_usb3_0 { + phys = <&cp0_comphy1 0>, <&cp0_utmi0>; + phy-names = "comphy", "utmi"; + vbus-supply = <®_usb3_vbus0>; + dr_mode = "host"; + status = "okay"; +}; + +&cp0_utmi { + status = "okay"; +}; + +/* mikrobus uart */ +&cp0_uart0 { + pinctrl-0 = <&mikro_uart_pins>; + pinctrl-names = "default"; + status = "okay"; +}; diff --git a/arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi b/arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi new file mode 100644 index 000000000000..f151a2a399c1 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi @@ -0,0 +1,160 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> + * + */ + +#include <dt-bindings/gpio/gpio.h> + +/ { + model = "SolidRun CN9130 SoM"; + compatible = "solidrun,cn9130-sr-som", "marvell,cn9130", + "marvell,armada-ap807-quad", "marvell,armada-ap807"; + + aliases { + /* label nics like armada-388 som */ + ethernet0 = &cp0_eth2; + ethernet1 = &cp0_eth1; + ethernet2 = &cp0_eth0; + i2c0 = &cp0_i2c0; + mmc0 = &ap_sdhci0; + rtc0 = &cp0_rtc; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; + + v_1_8: regulator-1-8 { + compatible = "regulator-fixed"; + regulator-name = "1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + /* requires assembly of R9307 */ + vhv: regulator-vhv-1-8 { + compatible = "regulator-fixed"; + regulator-name = "vhv-1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + pinctrl-0 = <&cp0_reg_vhv_pins>; + pinctrl-names = "default"; + gpio = <&cp0_gpio2 9 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; +}; + +&ap_pinctrl { + ap_mmc0_pins: ap-mmc0-pins { + marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3", "mpp4", "mpp5", + "mpp6", "mpp7", "mpp8", "mpp9", "mpp10", "mpp12"; + marvell,function = "sdio"; + /* + * mpp12 is emmc reset, function should be sdio (hw_rst), + * but pinctrl-mvebu does not support this. + * + * From pinctrl-mvebu.h: + * "The name will be used to switch to this setting in DT description, e.g. + * marvell,function = "uart2". subname is only for debugging purposes." + */ + }; +}; + +&ap_sdhci0 { + bus-width = <8>; + pinctrl-0 = <&ap_mmc0_pins>; + pinctrl-names = "default"; + vqmmc-supply = <&v_1_8>; + status = "okay"; +}; + +&cp0_ethernet { + status = "okay"; +}; + +/* for assembly with phy */ +&cp0_eth2 { + pinctrl-names = "default"; + pinctrl-0 = <&cp0_eth2_pins>; + phy-mode = "rgmii-id"; + phy = <&cp0_eth2_phy>; + status = "okay"; +}; + +&cp0_i2c0 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&cp0_i2c0_pins>; + clock-frequency = <100000>; + status = "okay"; + + som_eeprom: eeprom@53 { + compatible = "atmel,24c02"; + reg = <0x53>; + pagesize = <8>; + }; +}; + +&cp0_mdio { + status = "okay"; + pinctrl-0 = <&cp0_mdio_pins>; + + /* assembly option */ + cp0_eth2_phy: ethernet-phy@0 { + reg = <0>; + }; +}; + +&cp0_spi1 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&cp0_spi1_pins>; + + flash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + spi-max-frequency = <10000000>; + }; +}; + +&cp0_syscon0 { + cp0_pinctrl: pinctrl { + compatible = "marvell,cp115-standalone-pinctrl"; + + cp0_eth2_pins: cp0-ge2-rgmii-pins { + marvell,pins = "mpp44", "mpp45", "mpp46", "mpp47", + "mpp48", "mpp49", "mpp50", "mpp51", + "mpp52", "mpp53", "mpp54", "mpp55"; + /* docs call it "ge2", but cp110-pinctrl "ge1" */ + marvell,function = "ge1"; + }; + + cp0_i2c0_pins: cp0-i2c0-pins { + marvell,pins = "mpp37", "mpp38"; + marvell,function = "i2c0"; + }; + + cp0_mdio_pins: cp0-mdio-pins { + marvell,pins = "mpp40", "mpp41"; + marvell,function = "ge"; + }; + + cp0_spi1_pins: cp0-spi1-pins { + marvell,pins = "mpp13", "mpp14", "mpp15", "mpp16"; + marvell,function = "spi1"; + }; + + cp0_reg_vhv_pins: cp0-reg-vhv-pins { + marvell,pins = "mpp41"; + marvell,function = "gpio"; + }; + }; +}; + +/* AP default console */ +&uart0 { + pinctrl-0 = <&uart0_pins>; + pinctrl-names = "default"; + status = "okay"; +};
Add description for the SolidRun CN9130 SoM, and Clearfog Base / Pro reference boards. The SoM has been designed as a pin-compatible replacement for the older Armada 388 based SoM. Therefore it supports the same boards and a similar feature set. Most notable upgrades: - 4x Cortex-A72 - 10Gbps SFP - Both eMMC and SD supported at the same time The developer first supporting this product at SolidRun decided to use different filenames for the DTBs: Armada 388 uses the full "clearfog" string while cn9130 uses the abbreviation "cf". This name is already hard-coded in pre-installed vendor u-boot and can not be changed easily. NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE: CN9130 SoM has a different footprint from Armada 388 SoM. Components on the carrier board below the SoM may collide causing damage, such as on Clearfog Base. Signed-off-by: Josua Mayer <josua@solid-run.com> --- arch/arm64/boot/dts/marvell/Makefile | 2 + arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 138 ++++++++++++++ arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 249 +++++++++++++++++++++++++ arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 198 ++++++++++++++++++++ arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 160 ++++++++++++++++ 5 files changed, 747 insertions(+)