* [PATCH u-boot 0/2] aspeed: Add support for msx4
@ 2025-11-22 0:02 Marc Olberding
2025-11-22 0:02 ` [PATCH u-boot 1/2] Add a new board for the gigabyte msx4 Marc Olberding
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Marc Olberding @ 2025-11-22 0:02 UTC (permalink / raw)
To: joel, andrew, openbmc
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>
^ permalink raw reply [flat|nested] 11+ messages in thread* [PATCH u-boot 1/2] Add a new board for the gigabyte msx4 2025-11-22 0:02 [PATCH u-boot 0/2] aspeed: Add support for msx4 Marc Olberding @ 2025-11-22 0:02 ` Marc Olberding 2025-11-26 0:30 ` Andrew Jeffery 2025-11-22 0:02 ` [PATCH u-boot 2/2] arch: arm: dts: Add dts for the nvidia msx4 board Marc Olberding 2025-11-26 0:22 ` [PATCH u-boot 0/2] aspeed: Add support for msx4 Andrew Jeffery 2 siblings, 1 reply; 11+ messages in thread From: Marc Olberding @ 2025-11-22 0:02 UTC (permalink / raw) To: joel, andrew, openbmc 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH u-boot 1/2] Add a new board for the gigabyte msx4 2025-11-22 0:02 ` [PATCH u-boot 1/2] Add a new board for the gigabyte msx4 Marc Olberding @ 2025-11-26 0:30 ` Andrew Jeffery 2025-11-26 1:30 ` Marc Olberding 0 siblings, 1 reply; 11+ messages in thread From: Andrew Jeffery @ 2025-11-26 0:30 UTC (permalink / raw) To: Marc Olberding, joel, openbmc 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH u-boot 1/2] Add a new board for the gigabyte msx4 2025-11-26 0:30 ` Andrew Jeffery @ 2025-11-26 1:30 ` Marc Olberding 2025-12-01 23:14 ` Andrew Jeffery 0 siblings, 1 reply; 11+ messages in thread From: Marc Olberding @ 2025-11-26 1:30 UTC (permalink / raw) To: Andrew Jeffery; +Cc: joel, openbmc 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH u-boot 1/2] Add a new board for the gigabyte msx4 2025-11-26 1:30 ` Marc Olberding @ 2025-12-01 23:14 ` Andrew Jeffery 2025-12-01 23:33 ` Marc Olberding 0 siblings, 1 reply; 11+ messages in thread From: Andrew Jeffery @ 2025-12-01 23:14 UTC (permalink / raw) To: Marc Olberding; +Cc: joel, openbmc 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH u-boot 1/2] Add a new board for the gigabyte msx4 2025-12-01 23:14 ` Andrew Jeffery @ 2025-12-01 23:33 ` Marc Olberding 2025-12-01 23:43 ` Andrew Jeffery 0 siblings, 1 reply; 11+ messages in thread From: Marc Olberding @ 2025-12-01 23:33 UTC (permalink / raw) To: Andrew Jeffery; +Cc: joel, openbmc 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH u-boot 1/2] Add a new board for the gigabyte msx4 2025-12-01 23:33 ` Marc Olberding @ 2025-12-01 23:43 ` Andrew Jeffery 0 siblings, 0 replies; 11+ messages in thread From: Andrew Jeffery @ 2025-12-01 23:43 UTC (permalink / raw) To: Marc Olberding; +Cc: joel, openbmc 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH u-boot 2/2] arch: arm: dts: Add dts for the nvidia msx4 board 2025-11-22 0:02 [PATCH u-boot 0/2] aspeed: Add support for msx4 Marc Olberding 2025-11-22 0:02 ` [PATCH u-boot 1/2] Add a new board for the gigabyte msx4 Marc Olberding @ 2025-11-22 0:02 ` Marc Olberding 2025-11-26 0:22 ` [PATCH u-boot 0/2] aspeed: Add support for msx4 Andrew Jeffery 2 siblings, 0 replies; 11+ messages in thread From: Marc Olberding @ 2025-11-22 0:02 UTC (permalink / raw) To: joel, andrew, openbmc 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 = <ðphy3>; + + 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH u-boot 0/2] aspeed: Add support for msx4 2025-11-22 0:02 [PATCH u-boot 0/2] aspeed: Add support for msx4 Marc Olberding 2025-11-22 0:02 ` [PATCH u-boot 1/2] Add a new board for the gigabyte msx4 Marc Olberding 2025-11-22 0:02 ` [PATCH u-boot 2/2] arch: arm: dts: Add dts for the nvidia msx4 board Marc Olberding @ 2025-11-26 0:22 ` Andrew Jeffery 2025-11-26 1:20 ` Marc Olberding 2 siblings, 1 reply; 11+ messages in thread From: Andrew Jeffery @ 2025-11-26 0:22 UTC (permalink / raw) To: Marc Olberding, joel, openbmc 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH u-boot 0/2] aspeed: Add support for msx4 2025-11-26 0:22 ` [PATCH u-boot 0/2] aspeed: Add support for msx4 Andrew Jeffery @ 2025-11-26 1:20 ` Marc Olberding 2025-12-01 23:24 ` Andrew Jeffery 0 siblings, 1 reply; 11+ messages in thread From: Marc Olberding @ 2025-11-26 1:20 UTC (permalink / raw) To: Andrew Jeffery; +Cc: joel, openbmc 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH u-boot 0/2] aspeed: Add support for msx4 2025-11-26 1:20 ` Marc Olberding @ 2025-12-01 23:24 ` Andrew Jeffery 0 siblings, 0 replies; 11+ messages in thread From: Andrew Jeffery @ 2025-12-01 23:24 UTC (permalink / raw) To: Marc Olberding, Eddie James; +Cc: joel, openbmc 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2025-12-01 23:43 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-11-22 0:02 [PATCH u-boot 0/2] aspeed: Add support for msx4 Marc Olberding 2025-11-22 0:02 ` [PATCH u-boot 1/2] Add a new board for the gigabyte msx4 Marc Olberding 2025-11-26 0:30 ` Andrew Jeffery 2025-11-26 1:30 ` Marc Olberding 2025-12-01 23:14 ` Andrew Jeffery 2025-12-01 23:33 ` Marc Olberding 2025-12-01 23:43 ` Andrew Jeffery 2025-11-22 0:02 ` [PATCH u-boot 2/2] arch: arm: dts: Add dts for the nvidia msx4 board Marc Olberding 2025-11-26 0:22 ` [PATCH u-boot 0/2] aspeed: Add support for msx4 Andrew Jeffery 2025-11-26 1:20 ` Marc Olberding 2025-12-01 23:24 ` Andrew Jeffery
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox