From: Tao Ren <rentao.bupt@gmail.com>
Add initial device tree for the Meta (Facebook) Darwin AST2600 BMC.
Darwin is Meta's rack switch platform with an AST2600 BMC integrated for
health monitoring purpose.
Signed-off-by: Tao Ren <rentao.bupt@gmail.com>
---
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../dts/aspeed/aspeed-bmc-facebook-darwin.dts | 92 +++++++++++++++++++
2 files changed, 93 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts
diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index 2e5f4833a073..debbfc0151f8 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-facebook-bletchley.dtb \
aspeed-bmc-facebook-catalina.dtb \
aspeed-bmc-facebook-cmm.dtb \
+ aspeed-bmc-facebook-darwin.dtb \
aspeed-bmc-facebook-elbert.dtb \
aspeed-bmc-facebook-fuji.dtb \
aspeed-bmc-facebook-galaxy100.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts
new file mode 100644
index 000000000000..f902230dada3
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2021 Facebook Inc.
+
+/dts-v1/;
+
+#include "ast2600-facebook-netbmc-common.dtsi"
+
+/ {
+ model = "Facebook Darwin BMC";
+ compatible = "facebook,darwin-bmc", "aspeed,ast2600";
+
+ aliases {
+ serial0 = &uart5;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ };
+
+ chosen {
+ stdout-path = &uart5;
+ };
+
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
+ <&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
+ <&adc1 0>, <&adc1 1>, <&adc1 2>, <&adc1 3>,
+ <&adc1 4>, <&adc1 5>, <&adc1 6>, <&adc1 7>;
+ };
+
+ spi_gpio: spi {
+ num-chipselects = <1>;
+ cs-gpios = <&gpio0 ASPEED_GPIO(X, 0) GPIO_ACTIVE_LOW>;
+ };
+};
+
+/*
+ * BMC's "mac3" controller is connected to BCM53134P's IMP_RGMII port
+ * directly (fixed link, no PHY in between).
+ * Note: BMC's "mdio0" controller is connected to BCM53134P's MDIO
+ * interface, and the MDIO channel will be enabled in dts later (when
+ * "bcm53xx" driver's probe failure is solved on the platform).
+ */
+&mac3 {
+ status = "okay";
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii4_default>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+&i2c0 {
+ eeprom@50 {
+ compatible = "atmel,24c512";
+ reg = <0x50>;
+ };
+};
+
+&adc0 {
+ ref_voltage = <2500>;
+ status = "okay";
+
+ pinctrl-0 = <&pinctrl_adc0_default &pinctrl_adc1_default
+ &pinctrl_adc2_default &pinctrl_adc3_default
+ &pinctrl_adc4_default &pinctrl_adc5_default
+ &pinctrl_adc6_default &pinctrl_adc7_default>;
+};
+
+&adc1 {
+ ref_voltage = <2500>;
+ status = "okay";
+
+ pinctrl-0 = <&pinctrl_adc8_default &pinctrl_adc9_default
+ &pinctrl_adc10_default &pinctrl_adc11_default
+ &pinctrl_adc12_default &pinctrl_adc13_default
+ &pinctrl_adc14_default &pinctrl_adc15_default>;
+};
+
+&emmc_controller {
+ status = "okay";
+};
+
+&emmc {
+ status = "okay";
+
+ non-removable;
+ max-frequency = <25000000>;
+ bus-width = <4>;
+};
--
2.47.1On 02/07/2025 07:04, rentao.bupt@gmail.com wrote:
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts
> new file mode 100644
> index 000000000000..f902230dada3
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright (c) 2021 Facebook Inc.
> +
> +/dts-v1/;
> +
> +#include "ast2600-facebook-netbmc-common.dtsi"
> +
> +/ {
> + model = "Facebook Darwin BMC";
> + compatible = "facebook,darwin-bmc", "aspeed,ast2600";
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
It does not look like you tested the DTS against bindings. Please run
`make dtbs_check W=1` (see
Documentation/devicetree/bindings/writing-schema.rst or
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
for instructions).
Maybe you need to update your dtschema and yamllint. Don't rely on
distro packages for dtschema and be sure you are using the latest
released dtschema.
Best regards,
Krzysztof
On Wed, Jul 02, 2025 at 09:50:56AM +0200, Krzysztof Kozlowski wrote:
> On 02/07/2025 07:04, rentao.bupt@gmail.com wrote:
> > diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts
> > new file mode 100644
> > index 000000000000..f902230dada3
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts
> > @@ -0,0 +1,92 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +// Copyright (c) 2021 Facebook Inc.
> > +
> > +/dts-v1/;
> > +
> > +#include "ast2600-facebook-netbmc-common.dtsi"
> > +
> > +/ {
> > + model = "Facebook Darwin BMC";
> > + compatible = "facebook,darwin-bmc", "aspeed,ast2600";
>
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> patches and (probably) fix more warnings. Some warnings can be ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.
>
> It does not look like you tested the DTS against bindings. Please run
> `make dtbs_check W=1` (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
> Maybe you need to update your dtschema and yamllint. Don't rely on
> distro packages for dtschema and be sure you are using the latest
> released dtschema.
>
>
>
> Best regards,
> Krzysztof
Hi Krzysztof,
Thank you for the detailed instructions, and I can see the warnings from
my side now. I'm working on the fix, and will try to send out v2 by this
week.
Thanks,
Tao
On Tue, Jul 01, 2025 at 10:04:16PM -0700, rentao.bupt@gmail.com wrote:
> From: Tao Ren <rentao.bupt@gmail.com>
>
> Add initial device tree for the Meta (Facebook) Darwin AST2600 BMC.
>
> Darwin is Meta's rack switch platform with an AST2600 BMC integrated for
> health monitoring purpose.
>
> Signed-off-by: Tao Ren <rentao.bupt@gmail.com>
> ---
> arch/arm/boot/dts/aspeed/Makefile | 1 +
> .../dts/aspeed/aspeed-bmc-facebook-darwin.dts | 92 +++++++++++++++++++
> 2 files changed, 93 insertions(+)
> create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts
>
> diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
> index 2e5f4833a073..debbfc0151f8 100644
> --- a/arch/arm/boot/dts/aspeed/Makefile
> +++ b/arch/arm/boot/dts/aspeed/Makefile
> @@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-bmc-facebook-bletchley.dtb \
> aspeed-bmc-facebook-catalina.dtb \
> aspeed-bmc-facebook-cmm.dtb \
> + aspeed-bmc-facebook-darwin.dtb \
> aspeed-bmc-facebook-elbert.dtb \
> aspeed-bmc-facebook-fuji.dtb \
> aspeed-bmc-facebook-galaxy100.dtb \
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts
> new file mode 100644
> index 000000000000..f902230dada3
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright (c) 2021 Facebook Inc.
> +
> +/dts-v1/;
> +
> +#include "ast2600-facebook-netbmc-common.dtsi"
> +
> +/ {
> + model = "Facebook Darwin BMC";
> + compatible = "facebook,darwin-bmc", "aspeed,ast2600";
> +
> + aliases {
> + serial0 = &uart5;
> + serial1 = &uart1;
> + serial2 = &uart2;
> + serial3 = &uart3;
> + };
> +
> + chosen {
> + stdout-path = &uart5;
> + };
> +
> + iio-hwmon {
> + compatible = "iio-hwmon";
> + io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
> + <&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
> + <&adc1 0>, <&adc1 1>, <&adc1 2>, <&adc1 3>,
> + <&adc1 4>, <&adc1 5>, <&adc1 6>, <&adc1 7>;
> + };
> +
> + spi_gpio: spi {
> + num-chipselects = <1>;
> + cs-gpios = <&gpio0 ASPEED_GPIO(X, 0) GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> +/*
> + * BMC's "mac3" controller is connected to BCM53134P's IMP_RGMII port
> + * directly (fixed link, no PHY in between).
> + * Note: BMC's "mdio0" controller is connected to BCM53134P's MDIO
> + * interface, and the MDIO channel will be enabled in dts later (when
> + * "bcm53xx" driver's probe failure is solved on the platform).
> + */
> +&mac3 {
> + status = "okay";
> + phy-mode = "rgmii";
How do RGMII delays work? Connections to switches have to be handled
different to PHYs, to avoid double delays. But is there extra long
clock lines? Or are you expecting the switch to add the delays?
Andrew
On Wed, Jul 02, 2025 at 09:40:40AM +0200, Andrew Lunn wrote:
> On Tue, Jul 01, 2025 at 10:04:16PM -0700, rentao.bupt@gmail.com wrote:
> > From: Tao Ren <rentao.bupt@gmail.com>
> >
> > Add initial device tree for the Meta (Facebook) Darwin AST2600 BMC.
> >
> > Darwin is Meta's rack switch platform with an AST2600 BMC integrated for
> > health monitoring purpose.
> >
> > Signed-off-by: Tao Ren <rentao.bupt@gmail.com>
> > ---
> > arch/arm/boot/dts/aspeed/Makefile | 1 +
> > .../dts/aspeed/aspeed-bmc-facebook-darwin.dts | 92 +++++++++++++++++++
> > 2 files changed, 93 insertions(+)
> > create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts
> >
> > diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
> > index 2e5f4833a073..debbfc0151f8 100644
> > --- a/arch/arm/boot/dts/aspeed/Makefile
> > +++ b/arch/arm/boot/dts/aspeed/Makefile
> > @@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
> > aspeed-bmc-facebook-bletchley.dtb \
> > aspeed-bmc-facebook-catalina.dtb \
> > aspeed-bmc-facebook-cmm.dtb \
> > + aspeed-bmc-facebook-darwin.dtb \
> > aspeed-bmc-facebook-elbert.dtb \
> > aspeed-bmc-facebook-fuji.dtb \
> > aspeed-bmc-facebook-galaxy100.dtb \
> > diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts
> > new file mode 100644
> > index 000000000000..f902230dada3
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-darwin.dts
> > @@ -0,0 +1,92 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +// Copyright (c) 2021 Facebook Inc.
> > +
> > +/dts-v1/;
> > +
> > +#include "ast2600-facebook-netbmc-common.dtsi"
> > +
> > +/ {
> > + model = "Facebook Darwin BMC";
> > + compatible = "facebook,darwin-bmc", "aspeed,ast2600";
> > +
> > + aliases {
> > + serial0 = &uart5;
> > + serial1 = &uart1;
> > + serial2 = &uart2;
> > + serial3 = &uart3;
> > + };
> > +
> > + chosen {
> > + stdout-path = &uart5;
> > + };
> > +
> > + iio-hwmon {
> > + compatible = "iio-hwmon";
> > + io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
> > + <&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
> > + <&adc1 0>, <&adc1 1>, <&adc1 2>, <&adc1 3>,
> > + <&adc1 4>, <&adc1 5>, <&adc1 6>, <&adc1 7>;
> > + };
> > +
> > + spi_gpio: spi {
> > + num-chipselects = <1>;
> > + cs-gpios = <&gpio0 ASPEED_GPIO(X, 0) GPIO_ACTIVE_LOW>;
> > + };
> > +};
> > +
> > +/*
> > + * BMC's "mac3" controller is connected to BCM53134P's IMP_RGMII port
> > + * directly (fixed link, no PHY in between).
> > + * Note: BMC's "mdio0" controller is connected to BCM53134P's MDIO
> > + * interface, and the MDIO channel will be enabled in dts later (when
> > + * "bcm53xx" driver's probe failure is solved on the platform).
> > + */
> > +&mac3 {
> > + status = "okay";
> > + phy-mode = "rgmii";
>
> How do RGMII delays work? Connections to switches have to be handled
> different to PHYs, to avoid double delays. But is there extra long
> clock lines? Or are you expecting the switch to add the delays?
>
> Andrew
Hi Andrew,
The delays are introduced in BMC MAC by setting SCU control registers in
u-boot. The delays on the switch side are disabled.
I will add some comments for the delays in v2 (after addressing the dts
schema warnings). Is that okay?
Thanks,
Tao
> > How do RGMII delays work? Connections to switches have to be handled
> > different to PHYs, to avoid double delays. But is there extra long
> > clock lines? Or are you expecting the switch to add the delays?
> >
> > Andrew
>
> Hi Andrew,
>
> The delays are introduced in BMC MAC by setting SCU control registers in
> u-boot. The delays on the switch side are disabled.
Sorry, but not acceptable. This is something i've been NACKing Aspeed
DT patches for. You need the MAC driver to interpret the phy-mode and
program the SCU control register as needed.
Since you have the MAC introducing the delays, you want phy-mode
'rgmii-id'.
If you want to submit some DT now, drop the ethernet node. This is
what others have been doing while waiting for Aspeed to fix their MAC
driver. Having said that, i've not seen any progress from Aspeed, so
it either needs their customers to apply more pressure, or somebody in
the community to just fix it and submit patches.
Andrew
---
pw-bot: cr
On Thu, Jul 03, 2025 at 09:58:48AM +0200, Andrew Lunn wrote: > > > How do RGMII delays work? Connections to switches have to be handled > > > different to PHYs, to avoid double delays. But is there extra long > > > clock lines? Or are you expecting the switch to add the delays? > > > > > > Andrew > > > > Hi Andrew, > > > > The delays are introduced in BMC MAC by setting SCU control registers in > > u-boot. The delays on the switch side are disabled. > > Sorry, but not acceptable. This is something i've been NACKing Aspeed > DT patches for. You need the MAC driver to interpret the phy-mode and > program the SCU control register as needed. > > Since you have the MAC introducing the delays, you want phy-mode > 'rgmii-id'. > > If you want to submit some DT now, drop the ethernet node. This is > what others have been doing while waiting for Aspeed to fix their MAC > driver. Having said that, i've not seen any progress from Aspeed, so > it either needs their customers to apply more pressure, or somebody in > the community to just fix it and submit patches. > > Andrew Hi Andrew, Got it, and thanks for sharing the context. I will reach out to ASPEED offline to see if they are actively working on the MAC fix, or if I have enough knowledge to work out the patch. Thanks, Tao
> Hi Andrew, > > Got it, and thanks for sharing the context. > > I will reach out to ASPEED offline to see if they are actively working > on the MAC fix, or if I have enough knowledge to work out the patch. There was some discussion about what needs to be done a couple of months ago. Look for emails from aspeed and IBM. Andrew
On Fri, Jul 04, 2025 at 09:37:20AM +0200, Andrew Lunn wrote: > > Hi Andrew, > > > > Got it, and thanks for sharing the context. > > > > I will reach out to ASPEED offline to see if they are actively working > > on the MAC fix, or if I have enough knowledge to work out the patch. > > There was some discussion about what needs to be done a couple of > months ago. Look for emails from aspeed and IBM. > > Andrew Hi Andrew, I guess you are referring to the discussions in patch "ARM: dts: aspeed: system1: Add RGMII support", and I can find more of your suggestions in the thread. I will remove mac controller from my v2 for now, and will add it back when the delay support is added to the MAC driver. Thanks again. - Tao
© 2016 - 2025 Red Hat, Inc.