[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