Add a 128M layout for the BMC flash chip we didn't boot from. Including
this allows the user to write to each partition on the alternate spi
chip. This dtsi follows the existing standard of using the same layout
as non alt version and prepending `alt` to each partition's name.

Testing: Include this in msx4 and cat size, offsets and name
```
for devdir in /sys/class/mtd/mtd*; do
>     [[ -d $devdir && -r $devdir/name ]] || continue
>     name=$(<"$devdir/name")
>     [[ $name == alt* ]] || continue
>
>     size=$(<"$devdir/size")
>     offset=0
>     [[ -r $devdir/offset ]] && offset=$(<"$devdir/offset")
>
>     dev=$(basename "$devdir")
>     printf "%s name=%s offset=0x%X size=0x%X\n" "$dev" "$name" \
>        "$offset" "$size"
> done
mtd10 name=alt-rofs offset=0xA00000 size=0x5600000
mtd11 name=alt-rwfs offset=0x6000000 size=0x2000000
mtd7 name=alt-u-boot offset=0x0 size=0xE0000
mtd8 name=alt-u-boot-env offset=0xE0000 size=0x20000
mtd9 name=alt-kernel offset=0x100000 size=0x900000
```

Also ran dtbs_check on an existing dts with this included.

Signed-off-by: Marc Olberding <molberding@nvidia.com>
---
Add a layout for an alternate 128M flash layout. This is
useful for the aspeed ast2500[2] and ast2600[1] SoCs,
where it has the ability to boot from one of two spi chips,
nominally the primary and backup SPIs. Adding a layout allows userspace
to flash the alternate spi by partition and switch over to it, allowing
lower downtime for firmware flash, or for updating the primary
flash from the golden backup flash. This is already an established
scheme for the 32M and 64M layouts, where the layout is the same
but each partition has `alt` prepended to its name. This allows
userspace to just prepend alt to the images in the update process
to specify which flash chip to update.

References:

[1] https://www.aspeedtech.com/server_ast2600/
[2] https://www.aspeedtech.com/server_ast2500/
---
 .../dts/aspeed/openbmc-flash-layout-128-alt.dtsi   | 32 ++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed/openbmc-flash-layout-128-alt.dtsi b/arch/arm/boot/dts/aspeed/openbmc-flash-layout-128-alt.dtsi
new file mode 100644
index 0000000000000000000000000000000000000000..08ce2eab472c3da4aa3d841adb0eb1c971e6a25a
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/openbmc-flash-layout-128-alt.dtsi
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+partitions {
+	compatible = "fixed-partitions";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	u-boot@0 {
+		reg = <0x0 0xe0000>; // 896KB
+		label = "alt-u-boot";
+	};
+
+	u-boot-env@e0000 {
+		reg = <0xe0000 0x20000>; // 128KB
+		label = "alt-u-boot-env";
+	};
+
+	kernel@100000 {
+		reg = <0x100000 0x900000>; // 9MB
+		label = "alt-kernel";
+	};
+
+	rofs@a00000 {
+		reg = <0xa00000 0x5600000>; // 86MB
+		label = "alt-rofs";
+	};
+
+	rwfs@6000000 {
+		reg = <0x6000000 0x2000000>; // 32MB
+		label = "alt-rwfs";
+	};
+};

---
base-commit: d358e5254674b70f34c847715ca509e46eb81e6f
change-id: 20251211-alt-128-layout-221a40665f08

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

On Thu, 2025-12-11 at 13:35 -0800, Marc Olberding wrote:
> Add a 128M layout for the BMC flash chip we didn't boot from.
> Including
> this allows the user to write to each partition on the alternate spi
> chip. This dtsi follows the existing standard of using the same
> layout
> as non alt version and prepending `alt` to each partition's name.
> 
> Testing: Include this in msx4 and cat size, offsets and name
> ```
> for devdir in /sys/class/mtd/mtd*; do
> >     [[ -d $devdir && -r $devdir/name ]] || continue
> >     name=$(<"$devdir/name")
> >     [[ $name == alt* ]] || continue
> > 
> >     size=$(<"$devdir/size")
> >     offset=0
> >     [[ -r $devdir/offset ]] && offset=$(<"$devdir/offset")
> > 
> >     dev=$(basename "$devdir")
> >     printf "%s name=%s offset=0x%X size=0x%X\n" "$dev" "$name" \
> >        "$offset" "$size"
> > done
> mtd10 name=alt-rofs offset=0xA00000 size=0x5600000
> mtd11 name=alt-rwfs offset=0x6000000 size=0x2000000
> mtd7 name=alt-u-boot offset=0x0 size=0xE0000
> mtd8 name=alt-u-boot-env offset=0xE0000 size=0x20000
> mtd9 name=alt-kernel offset=0x100000 size=0x900000
> ```
> 
> Also ran dtbs_check on an existing dts with this included.
> 
> Signed-off-by: Marc Olberding <molberding@nvidia.com>
> ---
> Add a layout for an alternate 128M flash layout. This is
> useful for the aspeed ast2500[2] and ast2600[1] SoCs,
> where it has the ability to boot from one of two spi chips,
> nominally the primary and backup SPIs. Adding a layout allows
> userspace
> to flash the alternate spi by partition and switch over to it,
> allowing
> lower downtime for firmware flash, or for updating the primary
> flash from the golden backup flash. This is already an established
> scheme for the 32M and 64M layouts, where the layout is the same
> but each partition has `alt` prepended to its name. This allows
> userspace to just prepend alt to the images in the update process
> to specify which flash chip to update.
> 
> References:
> 
> [1] https://www.aspeedtech.com/server_ast2600/
> [2] https://www.aspeedtech.com/server_ast2500/
> ---
>  .../dts/aspeed/openbmc-flash-layout-128-alt.dtsi   | 32
> ++++++++++++++++++++++
>  1 file changed, 32 insertions(+)

This may be fine, but please add it in a series that also introduces a
board that consumes it.

Andrew

On Thu, Dec 18, 2025 at 09:29:44AM +1030, Andrew Jeffery wrote:
> On Thu, 2025-12-11 at 13:35 -0800, Marc Olberding wrote:
> > Add a 128M layout for the BMC flash chip we didn't boot from.
> > Including
> > this allows the user to write to each partition on the alternate spi
> > chip. This dtsi follows the existing standard of using the same
> > layout
> > as non alt version and prepending `alt` to each partition's name.
> > 
... 
> This may be fine, but please add it in a series that also introduces a
> board that consumes it.
> 
> Andrew

Ack, I wasn't sure how to handle this, since the MSX4 hasn't merged to
master for upstream yet, its just been merged into the openbmc tree.
I can either just hold off on this patch or update the msx4 series.
I'm assuming that including this in a patch targetted to the openbmc tree
is a nonstarter. Any thoughts here?

Thanks,
Marc

On Wed, 2025-12-17 at 15:13 -0800, Marc Olberding wrote:
> On Thu, Dec 18, 2025 at 09:29:44AM +1030, Andrew Jeffery wrote:
> > On Thu, 2025-12-11 at 13:35 -0800, Marc Olberding wrote:
> > > Add a 128M layout for the BMC flash chip we didn't boot from.
> > > Including
> > > this allows the user to write to each partition on the alternate spi
> > > chip. This dtsi follows the existing standard of using the same
> > > layout
> > > as non alt version and prepending `alt` to each partition's name.
> > > 
> ... 
> > This may be fine, but please add it in a series that also introduces a
> > board that consumes it.
> > 
> > Andrew
> 
> Ack, I wasn't sure how to handle this, since the MSX4 hasn't merged to
> master for upstream yet, its just been merged into the openbmc tree.

I've applied it:

https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux.git/commit/?h=aspeed/arm/dt&id=f28674fab34f07fff9612c3f390d3699bfe8ed90

It will be part of v6.20 (via pull-request to the SoC tree).

> I can either just hold off on this patch or update the msx4 series.
> I'm assuming that including this in a patch targetted to the openbmc tree
> is a nonstarter. Any thoughts here?

Send patches based on the bmc tree's aspeed/arm/dt branch (i.e. the
branch containing the commit linked above). Your work is going to land
there anyway, so no need to strictly base your work on Linus' master
branch (though this is generally reasonable when there are no other
dependencies).

Andrew