[PATCH u-boot 0/2] aspeed: Add support for msx4

[PATCH u-boot 0/2] aspeed: Add support for msx4

[Marc Olberding]

Add a board file and dts for msx4. the board file is required
as the BMC is strapped for ABR boot support, and this functionality
isn't desired as support in linux is lacking. In order to enable
BMC boot reliably, a board file that disables the FMC_WDT2 is
included.

Patch 1 adds support for the board file. To opt into this support
you can set CONFIG_TARGET_AST2600_MSX4 in your config.

Patch 2 adds the devicetree for this board.

Signed-off-by: Marc Olberding <molberding@nvidia.com>
---
Marc Olberding (2):
      Add a new board for the gigabyte msx4
      arch: arm: dts: Add dts for the nvidia msx4 board

 arch/arm/dts/Makefile                    |   1 +
 arch/arm/dts/ast2600-msx4-bmc-nvidia.dts | 111 +++++++++++++++++++++++++++++++
 arch/arm/mach-aspeed/ast2600/Kconfig     |   9 +++
 board/aspeed/ast2600_msx4/Kconfig        |  13 ++++
 board/aspeed/ast2600_msx4/Makefile       |   1 +
 board/aspeed/ast2600_msx4/msx4.c         |  77 +++++++++++++++++++++
 6 files changed, 212 insertions(+)
---
base-commit: 8e15f5c0b1e7b11296ae6c88b686e65d509237d0
change-id: 20251107-msx4-cad1e2e4fa39

Best regards,
-- 
Marc Olberding <molberding@nvidia.com>

[PATCH u-boot 1/2] Add a new board for the gigabyte msx4

[Marc Olberding]

Adds a new board for the gigabyte msx4. The primary
difference is just that we disable the fmc_wdt2 in
early board init

Signed-off-by: Marc Olberding <molberding@nvidia.com>
---
 arch/arm/mach-aspeed/ast2600/Kconfig |  9 +++++
 board/aspeed/ast2600_msx4/Kconfig    | 13 ++++++
 board/aspeed/ast2600_msx4/Makefile   |  1 +
 board/aspeed/ast2600_msx4/msx4.c     | 77 ++++++++++++++++++++++++++++++++++++
 4 files changed, 100 insertions(+)

diff --git a/arch/arm/mach-aspeed/ast2600/Kconfig b/arch/arm/mach-aspeed/ast2600/Kconfig
index decf263627fa6ed83123a25268d278fc0f7add2a..6779b000a6ba23dcc4b59515196ecc67d4f429d5 100644
--- a/arch/arm/mach-aspeed/ast2600/Kconfig
+++ b/arch/arm/mach-aspeed/ast2600/Kconfig
@@ -37,6 +37,14 @@ config TARGET_AST2600_IBM
 	help
 	  AST2600-IBM is IBM boards for AST2600 BMC based P0WER10+ servers
 
+config TARGET_AST2600_MSX4
+	bool "AST2600-MSX4"
+	depends on ASPEED_AST2600
+	help
+	  AST2600-MSX4 is an Nvidia board for an AST2600 BMC based Intel server.
+	  It is nominally similar to the EVB, but it turns off support for
+	  FMC_WDT2
+
 config TARGET_AST2600_INTEL
 	bool "AST2600-INTEL"
 	depends on ASPEED_AST2600
@@ -66,6 +74,7 @@ source "board/aspeed/slt_ast2600/Kconfig"
 source "board/aspeed/ast2600_ibm/Kconfig"
 source "board/aspeed/ast2600_intel/Kconfig"
 source "board/aspeed/ast2600_dcscm/Kconfig"
+source "board/aspeed/ast2600_msx4/Kconfig"
 source "board/qualcomm/dc-scm-v1/Kconfig"
 
 endif
diff --git a/board/aspeed/ast2600_msx4/Kconfig b/board/aspeed/ast2600_msx4/Kconfig
new file mode 100644
index 0000000000000000000000000000000000000000..9096e60aaad31db89998e2d8af8b0adff1f1a62e
--- /dev/null
+++ b/board/aspeed/ast2600_msx4/Kconfig
@@ -0,0 +1,13 @@
+if TARGET_AST2600_MSX4
+
+config SYS_BOARD
+    default "ast2600_msx4"
+
+config SYS_VENDOR
+    default "aspeed"
+
+config SYS_CONFIG_NAME
+    string "board configuration name"
+    default ast2600_msx4
+
+endif
diff --git a/board/aspeed/ast2600_msx4/Makefile b/board/aspeed/ast2600_msx4/Makefile
new file mode 100644
index 0000000000000000000000000000000000000000..7a01cbec85dafa25a59bbe13534c7f5f36abdc81
--- /dev/null
+++ b/board/aspeed/ast2600_msx4/Makefile
@@ -0,0 +1 @@
+obj-y += msx4.o
diff --git a/board/aspeed/ast2600_msx4/msx4.c b/board/aspeed/ast2600_msx4/msx4.c
new file mode 100644
index 0000000000000000000000000000000000000000..ce249886ca008e01f9b3b7d81d35eef12ec9eca4
--- /dev/null
+++ b/board/aspeed/ast2600_msx4/msx4.c
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) Nvidia
+ */
+#include <common.h>
+#include <asm/io.h>
+
+#define ESPI_BASE	0x1e6ee000
+#define SCU_BASE	0x1e6e2000
+
+static void __maybe_unused disable_fmc_wdt(void)
+{
+	u32 reg;
+
+	reg = readl(ASPEED_FMC_WDT2);
+	reg &= ~(0x1);
+	writel(reg, ASPEED_FMC_WDT2);
+}
+
+static void __maybe_unused espi_init(void)
+{
+	u32 reg;
+
+	/* skip eSPI init if LPC mode is selected */
+	reg = readl(SCU_BASE + 0x510);
+	if (reg & BIT(6))
+		return;
+
+	/*
+	 * Aspeed STRONGLY NOT recommend to use eSPI early init.
+	 *
+	 * This eSPI early init sequence merely set OOB_FREE. It
+	 * is NOT able to actually handle OOB requests from PCH.
+	 *
+	 * During the power on stage, PCH keep waiting OOB_FREE
+	 * to continue its booting. In general, OOB_FREE is set
+	 * when BMC firmware is ready. That is, the eSPI kernel
+	 * driver is mounted and ready to serve eSPI. However,
+	 * it means that PCH must wait until BMC kernel ready.
+	 *
+	 * For customers that request PCH booting as soon as
+	 * possible. You may use this early init to set OOB_FREE
+	 * to prevent PCH from blocking by OOB_FREE before BMC
+	 * kernel ready.
+	 *
+	 * If you are not sure what you are doing, DO NOT use it.
+	 */
+	reg = readl(ESPI_BASE + 0x000);
+	reg |= 0xef;
+	writel(reg, ESPI_BASE + 0x000);
+
+	writel(0x0, ESPI_BASE + 0x110);
+	writel(0x0, ESPI_BASE + 0x114);
+
+	reg = readl(ESPI_BASE + 0x00c);
+	reg |= 0x80000000;
+	writel(reg, ESPI_BASE + 0x00c);
+
+	writel(0xffffffff, ESPI_BASE + 0x094);
+	writel(0x1, ESPI_BASE + 0x100);
+	writel(0x1, ESPI_BASE + 0x120);
+
+	reg = readl(ESPI_BASE + 0x080);
+	reg |= 0x50;
+	writel(reg, ESPI_BASE + 0x080);
+
+	reg = readl(ESPI_BASE + 0x000);
+	reg |= 0x10;
+	writel(reg, ESPI_BASE + 0x000);
+}
+
+int board_early_init_f(void)
+{
+	espi_init();
+	disable_fmc_wdt();
+	return 0;
+}

-- 
2.34.1

[PATCH u-boot 2/2] arch: arm: dts: Add dts for the nvidia msx4 board

[Marc Olberding]

Adds a dts for the nvidia msx4 board, a granite rapids based motherboard

Signed-off-by: Marc Olberding <molberding@nvidia.com>
---
 arch/arm/dts/Makefile                    |   1 +
 arch/arm/dts/ast2600-msx4-bmc-nvidia.dts | 111 +++++++++++++++++++++++++++++++
 2 files changed, 112 insertions(+)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dbb2fafc4f4c13302a02875cd678477ab95334cb..aebc5b60abc6b267669650be098315f5d5715074 100755
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -689,6 +689,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	ast2600-facebook.dtb \
 	ast2600-fpga.dtb \
 	ast2600-gb200nvl-bmc-nvidia.dtb \
+        ast2600-msx4-bmc-nvidia.dtb \
 	ast2600-greatlakes.dtb \
 	ast2600-intel.dtb \
 	ast2600-intel.dtb \
diff --git a/arch/arm/dts/ast2600-msx4-bmc-nvidia.dts b/arch/arm/dts/ast2600-msx4-bmc-nvidia.dts
new file mode 100644
index 0000000000000000000000000000000000000000..a3b258d99939dd4f6e465f35cb9413f8a703cc8c
--- /dev/null
+++ b/arch/arm/dts/ast2600-msx4-bmc-nvidia.dts
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: GPL-2.0+
+/dts-v1/;
+
+#include "ast2600-u-boot.dtsi"
+
+/ {
+	model = "AST2600 MSX4 BMC";
+	compatible = "aspeed,ast2600-msx4", "aspeed,ast2600";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x40000000>;
+	};
+
+	chosen {
+		stdout-path = &uart5;
+	};
+
+	aliases {
+		spi0 = &fmc;
+		ethernet0 = &mac0;
+	};
+
+	cpus {
+		cpu@0 {
+			clock-frequency = <800000000>;
+		};
+		cpu@1 {
+			clock-frequency = <800000000>;
+		};
+	};
+};
+
+&display_port {
+	status = "okay";
+};
+
+&fmc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fmcquad_default>;
+	status = "okay";
+
+	flash@0 {
+		status = "okay";
+		spi-max-frequency = <10000000>;
+		spi-tx-bus-width = <2>;
+		spi-rx-bus-width = <2>;
+	};
+
+	flash@1 {
+		status = "okay";
+		spi-max-frequency = <10000000>;
+		spi-tx-bus-width = <1>;
+		spi-rx-bus-width = <1>;
+	};
+};
+
+&hace {
+	status = "okay";
+};
+
+&mac0 {
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy3>;
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_rgmii1_default>;
+	status = "okay";
+};
+
+&mdio {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_mdio4_default>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	ethphy3: ethernet-phy@0 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <2>;
+	};
+};
+
+&scu {
+	mac0-clk-delay = <0x1d 0x0a
+			  0x1d 0x0a
+			  0x1d 0x0a>;
+};
+
+&sdrammc {
+	clock-frequency = <400000000>;
+	aspeed,ecc-enabled;
+	aspeed,ecc-size-mb = <0>;
+};
+
+&uart5 {
+	u-boot,dm-pre-reloc;
+	status = "okay";
+};
+
+&wdt1 {
+	status = "okay";
+};
+
+&wdt2 {
+	status = "okay";
+};
+
+&wdt3 {
+	status = "okay";
+};

-- 
2.34.1

Re: [PATCH u-boot 0/2] aspeed: Add support for msx4

[Andrew Jeffery]

Hi Marc,

On Fri, 2025-11-21 at 16:02 -0800, Marc Olberding wrote:
> Add a board file and dts for msx4. the board file is required
> as the BMC is strapped for ABR boot support, and this functionality
> isn't desired as support in linux is lacking.
> 

Can you expand on this? What's missing?

>  In order to enable
> BMC boot reliably, a board file that disables the FMC_WDT2 is
> included.

Hmm. Can we do this without requiring a board file?


Andrew

Re: [PATCH u-boot 1/2] Add a new board for the gigabyte msx4

[Andrew Jeffery]

On Fri, 2025-11-21 at 16:02 -0800, Marc Olberding wrote:
> Adds a new board for the gigabyte msx4. The primary
> difference is just that we disable the fmc_wdt2 in
> early board init
> 
> Signed-off-by: Marc Olberding <molberding@nvidia.com>
> ---
>  arch/arm/mach-aspeed/ast2600/Kconfig |  9 +++++
>  board/aspeed/ast2600_msx4/Kconfig    | 13 ++++++
>  board/aspeed/ast2600_msx4/Makefile   |  1 +
>  board/aspeed/ast2600_msx4/msx4.c     | 77 ++++++++++++++++++++++++++++++++++++
>  4 files changed, 100 insertions(+)
> 
> diff --git a/arch/arm/mach-aspeed/ast2600/Kconfig b/arch/arm/mach-aspeed/ast2600/Kconfig
> index decf263627fa6ed83123a25268d278fc0f7add2a..6779b000a6ba23dcc4b59515196ecc67d4f429d5 100644
> --- a/arch/arm/mach-aspeed/ast2600/Kconfig
> +++ b/arch/arm/mach-aspeed/ast2600/Kconfig
> @@ -37,6 +37,14 @@ config TARGET_AST2600_IBM
>  	help
>  	  AST2600-IBM is IBM boards for AST2600 BMC based P0WER10+ servers
>  
> +config TARGET_AST2600_MSX4
> +	bool "AST2600-MSX4"
> +	depends on ASPEED_AST2600
> +	help
> +	  AST2600-MSX4 is an Nvidia board for an AST2600 BMC based Intel server.
> +	  It is nominally similar to the EVB, but it turns off support for
> +	  FMC_WDT2
> +
>  config TARGET_AST2600_INTEL
>  	bool "AST2600-INTEL"
>  	depends on ASPEED_AST2600
> @@ -66,6 +74,7 @@ source "board/aspeed/slt_ast2600/Kconfig"
>  source "board/aspeed/ast2600_ibm/Kconfig"
>  source "board/aspeed/ast2600_intel/Kconfig"
>  source "board/aspeed/ast2600_dcscm/Kconfig"
> +source "board/aspeed/ast2600_msx4/Kconfig"
>  source "board/qualcomm/dc-scm-v1/Kconfig"
>  
>  endif
> diff --git a/board/aspeed/ast2600_msx4/Kconfig b/board/aspeed/ast2600_msx4/Kconfig
> new file mode 100644
> index 0000000000000000000000000000000000000000..9096e60aaad31db89998e2d8af8b0adff1f1a62e
> --- /dev/null
> +++ b/board/aspeed/ast2600_msx4/Kconfig
> @@ -0,0 +1,13 @@
> +if TARGET_AST2600_MSX4
> +
> +config SYS_BOARD
> +    default "ast2600_msx4"
> +
> +config SYS_VENDOR
> +    default "aspeed"
> +
> +config SYS_CONFIG_NAME
> +    string "board configuration name"
> +    default ast2600_msx4
> +
> +endif
> diff --git a/board/aspeed/ast2600_msx4/Makefile b/board/aspeed/ast2600_msx4/Makefile
> new file mode 100644
> index 0000000000000000000000000000000000000000..7a01cbec85dafa25a59bbe13534c7f5f36abdc81
> --- /dev/null
> +++ b/board/aspeed/ast2600_msx4/Makefile
> @@ -0,0 +1 @@
> +obj-y += msx4.o
> diff --git a/board/aspeed/ast2600_msx4/msx4.c b/board/aspeed/ast2600_msx4/msx4.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..ce249886ca008e01f9b3b7d81d35eef12ec9eca4
> --- /dev/null
> +++ b/board/aspeed/ast2600_msx4/msx4.c
> @@ -0,0 +1,77 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) Nvidia
> + */
> +#include <common.h>
> +#include <asm/io.h>
> +
> +#define ESPI_BASE	0x1e6ee000
> +#define SCU_BASE	0x1e6e2000
> +
> +static void __maybe_unused disable_fmc_wdt(void)
> +{
> +	u32 reg;
> +
> +	reg = readl(ASPEED_FMC_WDT2);
> +	reg &= ~(0x1);
> +	writel(reg, ASPEED_FMC_WDT2);
> +}

Can we rather add support to the SPI driver, and disable it via a
devicetree property?

That way the option is available to other platforms and minimises the
spread of board file code.

> +
> +static void __maybe_unused espi_init(void)
> +{
> +	u32 reg;
> +
> +	/* skip eSPI init if LPC mode is selected */
> +	reg = readl(SCU_BASE + 0x510);
> +	if (reg & BIT(6))
> +		return;
> +
> +	/*
> +	 * Aspeed STRONGLY NOT recommend to use eSPI early init.
> +	 *
> +	 * This eSPI early init sequence merely set OOB_FREE. It
> +	 * is NOT able to actually handle OOB requests from PCH.
> +	 *
> +	 * During the power on stage, PCH keep waiting OOB_FREE
> +	 * to continue its booting. In general, OOB_FREE is set
> +	 * when BMC firmware is ready. That is, the eSPI kernel
> +	 * driver is mounted and ready to serve eSPI. However,
> +	 * it means that PCH must wait until BMC kernel ready.
> +	 *
> +	 * For customers that request PCH booting as soon as
> +	 * possible. You may use this early init to set OOB_FREE
> +	 * to prevent PCH from blocking by OOB_FREE before BMC
> +	 * kernel ready.
> +	 *
> +	 * If you are not sure what you are doing, DO NOT use it.
> +	 */
> +	reg = readl(ESPI_BASE + 0x000);
> +	reg |= 0xef;
> +	writel(reg, ESPI_BASE + 0x000);
> +
> +	writel(0x0, ESPI_BASE + 0x110);
> +	writel(0x0, ESPI_BASE + 0x114);
> +
> +	reg = readl(ESPI_BASE + 0x00c);
> +	reg |= 0x80000000;
> +	writel(reg, ESPI_BASE + 0x00c);
> +
> +	writel(0xffffffff, ESPI_BASE + 0x094);
> +	writel(0x1, ESPI_BASE + 0x100);
> +	writel(0x1, ESPI_BASE + 0x120);
> +
> +	reg = readl(ESPI_BASE + 0x080);
> +	reg |= 0x50;
> +	writel(reg, ESPI_BASE + 0x080);
> +
> +	reg = readl(ESPI_BASE + 0x000);
> +	reg |= 0x10;
> +	writel(reg, ESPI_BASE + 0x000);

What is the behavioural difference to what's in
board/aspeed/ast2600_intel/intel.c? It's a little annoying to tell
because intel.c uses macro symbols for the register offsets where
you've open-coded the values here.

Can we try to make the implementation common?

Andrew

Re: [PATCH u-boot 0/2] aspeed: Add support for msx4

[Marc Olberding]

On Wed, Nov 26, 2025 at 10:52:51AM +1030, Andrew Jeffery wrote:
> Hi Marc,
Hi Andrew
> On Fri, 2025-11-21 at 16:02 -0800, Marc Olberding wrote:
> > Add a board file and dts for msx4. the board file is required
> > as the BMC is strapped for ABR boot support, and this functionality
> > isn't desired as support in linux is lacking.
> > 
> 
> Can you expand on this? What's missing?

As far as I could tell, support to pet and eventually disable the FMC_WDT2
doesn't exist in the linux kernel (I'm happy to be wrong, I'm not in love with this workaround)

So when the 2600 is strapped for dual SPI ABR, we just end up boot looping
between the two spi flashes, since no one pets the wdt.

This patch just disables this support altogether.

> >  In order to enable
> > BMC boot reliably, a board file that disables the FMC_WDT2 is
> > included.
> 
> Hmm. Can we do this without requiring a board file?

I didn't see a great way short of writing a driver for the watchdog,
which wouldn't be a bad idea, but we'd then have to go write up linux support for it.
I think those are both worthy goals, but the support today is nonexistent, and
this at least prevents people from bricking their BMCs.

We could put it into the u-boot env through calls to mw, but that seems worse,
its pretty easy to corrupt the u-boot env, and in that case we'll end up with
a brick.

Let me know if you have any better ideas.

Thanks,
Marc

Re: [PATCH u-boot 1/2] Add a new board for the gigabyte msx4

[Marc Olberding]

On Wed, Nov 26, 2025 at 11:00:33AM +1030, Andrew Jeffery wrote:
> On Fri, 2025-11-21 at 16:02 -0800, Marc Olberding wrote:
> > +}
> 
> Can we rather add support to the SPI driver, and disable it via a
> devicetree property?
> 
> That way the option is available to other platforms and minimises the
> spread of board file code.

I think that's reasonable, and I can put up a patchset for that.

are you okay with something like:
```
&fmc {
	status = "okay";
	fmc-wdt2-disable;
....
};
```

as the target config? or potentially drop the extra fmc...

For what its worth, WDT2 is actually disabled in the platform.S for the 2600
but its disabled by an #if 0 preproc directive. I think dealing with this in the driver
is a good idea and relatively low lift. In the response to the cover letter I had asked
for any ideas without reading this email :). I'll get this patch set up, thanks for the
feedback. 
> 
> What is the behavioural difference to what's in
> board/aspeed/ast2600_intel/intel.c? It's a little annoying to tell
> because intel.c uses macro symbols for the register offsets where
> you've open-coded the values here.
> 
> Can we try to make the implementation common?
> 
> Andrew

It's functionally the same, and to be honest this code is proliferated across
at least 3 board files. I can certainly make a helper function,
but I don't have access to test all of the boards. If you're happy with
it being "correct by inspection that it does the same thing" and "it builds",
I can move these board files over to using the common helper.

Thanks
Marc

Re: [PATCH u-boot 1/2] Add a new board for the gigabyte msx4

[Andrew Jeffery]

On Tue, 2025-11-25 at 17:30 -0800, Marc Olberding wrote:
> On Wed, Nov 26, 2025 at 11:00:33AM +1030, Andrew Jeffery wrote:
> > On Fri, 2025-11-21 at 16:02 -0800, Marc Olberding wrote:
> > > +}
> > 
> > Can we rather add support to the SPI driver, and disable it via a
> > devicetree property?
> > 
> > That way the option is available to other platforms and minimises the
> > spread of board file code.
> 
> I think that's reasonable, and I can put up a patchset for that.
> 
> are you okay with something like:
> ```
> &fmc {
> 	status = "okay";
> 	fmc-wdt2-disable;
> ....
> };
> ```
> 
> as the target config? or potentially drop the extra fmc...

It would be best to prefix it. What do you think of `aspeed,disable-
watchdog`?

> 
> For what its worth, WDT2 is actually disabled in the platform.S for the 2600
> but its disabled by an #if 0 preproc directive. I think dealing with this in the driver
> is a good idea and relatively low lift. In the response to the cover letter I had asked
> for any ideas without reading this email :). I'll get this patch set up, thanks for the
> feedback. 
> > 
> > What is the behavioural difference to what's in
> > board/aspeed/ast2600_intel/intel.c? It's a little annoying to tell
> > because intel.c uses macro symbols for the register offsets where
> > you've open-coded the values here.
> > 
> > Can we try to make the implementation common?
> > 
> > Andrew
> 
> It's functionally the same, and to be honest this code is proliferated across
> at least 3 board files. I can certainly make a helper function,
> but I don't have access to test all of the boards. If you're happy with
> it being "correct by inspection that it does the same thing" and "it builds",
> I can move these board files over to using the common helper.

Let's get the code centralised, make the MSX4 using that centralised
code, and then follow with patches converting the other platforms. Make
sure to CC maintainers of the other affected platforms where you can,
and if things are okay by inspection and no-one screams, I'll apply
them all. Otherwise we can just apply the first couple and quibble over
what we do about the other platforms in slow-time.

Andrew

Re: [PATCH u-boot 0/2] aspeed: Add support for msx4

[Andrew Jeffery]

On Tue, 2025-11-25 at 17:20 -0800, Marc Olberding wrote:
> On Wed, Nov 26, 2025 at 10:52:51AM +1030, Andrew Jeffery wrote:
> > Hi Marc,
> Hi Andrew
> > On Fri, 2025-11-21 at 16:02 -0800, Marc Olberding wrote:
> > > Add a board file and dts for msx4. the board file is required
> > > as the BMC is strapped for ABR boot support, and this functionality
> > > isn't desired as support in linux is lacking.
> > > 
> > 
> > Can you expand on this? What's missing?
> 
> As far as I could tell, support to pet and eventually disable the FMC_WDT2
> doesn't exist in the linux kernel (I'm happy to be wrong, I'm not in love with this workaround)
> 
> So when the 2600 is strapped for dual SPI ABR, we just end up boot looping
> between the two spi flashes, since no one pets the wdt.
> 
> This patch just disables this support altogether.

Hmm, yeah, I think I recall disabling it in a u-boot environment script
back at IBM. Maybe Eddie can track down whether that's still the case.

Andrew

Re: [PATCH u-boot 1/2] Add a new board for the gigabyte msx4

[Marc Olberding]

On Tue, Dec 02, 2025 at 09:44:54AM +1030, Andrew Jeffery wrote:
> On Tue, 2025-11-25 at 17:30 -0800, Marc Olberding wrote:
> > On Wed, Nov 26, 2025 at 11:00:33AM +1030, Andrew Jeffery wrote:
> > > On Fri, 2025-11-21 at 16:02 -0800, Marc Olberding wrote:
> > are you okay with something like:
> > ```
> > &fmc {
> > 	status = "okay";
> > 	fmc-wdt2-disable;
> > ....
> > };
> > ```
> > 
> > as the target config? or potentially drop the extra fmc...
> 
> It would be best to prefix it. What do you think of `aspeed,disable-
> watchdog`?

I'm fine with aspeed,disable-watchdog. My only concern is that watchdog
is a little ambiguous for this, but maybe there is value in being
able to reuse the bindings for other things. This is a special watchdog
for the FMC, as opposed to the general purpose watchdogs present elsewhere.

maybe `aspeed,disable-fmc-watchdog` ?

That said, I'm not ready to fight to the grave, whatever you think is reasonable
is fine with me. I'm more interested in having this work and being reusable
for people.

> > 
> > It's functionally the same, and to be honest this code is proliferated across
> > at least 3 board files. I can certainly make a helper function,
> > but I don't have access to test all of the boards. If you're happy with
> > it being "correct by inspection that it does the same thing" and "it builds",
> > I can move these board files over to using the common helper.
> 
> Let's get the code centralised, make the MSX4 using that centralised
> code, and then follow with patches converting the other platforms. Make
> sure to CC maintainers of the other affected platforms where you can,
> and if things are okay by inspection and no-one screams, I'll apply
> them all. Otherwise we can just apply the first couple and quibble over
> what we do about the other platforms in slow-time.
> 
> Andrew

ACK. with the change for the FMC WDT2 to be handled by the driver,
we can actually just reuse the 2600evb board file (which is the default
for openbmc builds as far as I can tell). I can move the evb code over
to using this, test that on the MSX4 and then we can slow roll the rest.

Thanks
Marc

Re: [PATCH u-boot 1/2] Add a new board for the gigabyte msx4

[Andrew Jeffery]

On Mon, 2025-12-01 at 15:33 -0800, Marc Olberding wrote:
> On Tue, Dec 02, 2025 at 09:44:54AM +1030, Andrew Jeffery wrote:
> > On Tue, 2025-11-25 at 17:30 -0800, Marc Olberding wrote:
> > > On Wed, Nov 26, 2025 at 11:00:33AM +1030, Andrew Jeffery wrote:
> > > > On Fri, 2025-11-21 at 16:02 -0800, Marc Olberding wrote:
> > > are you okay with something like:
> > > ```
> > > &fmc {
> > > 	status = "okay";
> > > 	fmc-wdt2-disable;
> > > ....
> > > };
> > > ```
> > > 
> > > as the target config? or potentially drop the extra fmc...
> > 
> > It would be best to prefix it. What do you think of `aspeed,disable-
> > watchdog`?
> 
> I'm fine with aspeed,disable-watchdog. My only concern is that watchdog
> is a little ambiguous for this, but maybe there is value in being
> able to reuse the bindings for other things. This is a special watchdog
> for the FMC, as opposed to the general purpose watchdogs present elsewhere.

Right, however the idea is we specify it with respect to the fmc
compatible strings, so that itself limits the scope of the property (in
that it's only applicable on the FMC DT node and not any other node
such as the generic watchdog nodes).

> 
> maybe `aspeed,disable-fmc-watchdog` ?
> 
> That said, I'm not ready to fight to the grave, whatever you think is reasonable
> is fine with me. I'm more interested in having this work and being reusable
> for people.
> 
> > > 
> > > It's functionally the same, and to be honest this code is proliferated across
> > > at least 3 board files. I can certainly make a helper function,
> > > but I don't have access to test all of the boards. If you're happy with
> > > it being "correct by inspection that it does the same thing" and "it builds",
> > > I can move these board files over to using the common helper.
> > 
> > Let's get the code centralised, make the MSX4 using that centralised
> > code, and then follow with patches converting the other platforms. Make
> > sure to CC maintainers of the other affected platforms where you can,
> > and if things are okay by inspection and no-one screams, I'll apply
> > them all. Otherwise we can just apply the first couple and quibble over
> > what we do about the other platforms in slow-time.
> > 
> > Andrew
> 
> ACK. with the change for the FMC WDT2 to be handled by the driver,
> we can actually just reuse the 2600evb board file (which is the default
> for openbmc builds as far as I can tell). I can move the evb code over
> to using this, test that on the MSX4 and then we can slow roll the rest.
> 

Sounds great.

Thanks,

Andrew