[PATCH u-boot, v2019.04-aspeed-openbmc v1 1/1] ARM: dts: Aspeed: Add Facebook common dts

[Patrick Williams]

On Fri, May 17, 2024 at 09:06:54AM +0930, Andrew Jeffery wrote:
> On Wed, 2024-05-15 at 21:37 -0500, Patrick Williams wrote:

> > > Right. It removes the nebulous "common" concept that might be upset by
> > > future changes.
> > 
> > I agree that just "common" is probably not appropriate because this
> > device tree only covers ast2600-based platforms.
> > 
> > We are trying to design our BMC hardware such that at a u-boot level,
> > the same device tree can be used for most of our platforms.
> > 
> 
> Seems sensible, but does this common design point have a name?
> Otherwise it feels like a "coincidently similar" relationship, which
> seems a bit ill-defined. Better to enumerate the specific platforms in
> that case.

I can make up a name if necessary I guess.

> >   This is
> > partially so we can avoid having to add new changes for u-boot for every
> > new platform.
> 
> Not having to write new drivers or define drastically different
> devicetrees feels like a useful goal. I don't feel tacking on a new
> compatible here is particularly onerous (not that it even matters in
> practice if you select only this specific devicetree in the u-boot
> build).
> 
> Just wondering if we can avoid nebulous concepts, and rather keep
> things concrete.

I realize the motivation was lost in what I wrote.

We are trying to balance a few constraints, mostly induced by the
project itself.

    1. The project has a refusal for any u-boot patches in
       openbmc/openbmc, but we want to have first class support for our
       machines.

    2. The project maintenance of u-boot is in poor shape and no where
       near the level of response or up-to-dateness of the kernel.

The motivation for not wanting to send a new device tree is mainly
workaround the poor pick-up rate for any u-boot patch request.

Prior to patches dated in March the last time any device tree change was
accepted into the openbmc u-boot tree was dated May 2023.  There was
even a devicetree sent to the mailing list by Joel himself that isn't in
the tree right now.  Our experience has been bad enough that we've taken to
just reusing the `ast2600-bletchley` or `ast2600-evb` on multiple platforms,
depending on what we can get working.  It seems to me [slightly] better to
reuse a tree with a generic / common name than to confusingly use
`bletchley` on multiple platforms, hence the proposal here.

In meta-facebook:

```
$ rg UBOOT_DEVICETREE | sed "s/.*://" | sort | uniq -c             
      2 UBOOT_DEVICETREE = "ast2500-evb"
      3 UBOOT_DEVICETREE = "ast2600-bletchley"
      2 UBOOT_DEVICETREE = "ast2600-evb"
```

I don't currently have a lot of faith that if we sent a trivial "add the
new compatible" that it would be accepted in a timely manner.

> > 
> > Should we do something like "facebook,ast2600-standard"?
> > 
> 
> I guess I'm trying to guard-rail the discussion from the position of
> the compatible strings should be documented in the DT schemas. Is this
> something that would pass review upstream?

I don't know?  We're so far removed from upstream at this point that I
see that as aspirational.  (Everyone using AST2600 is using u-boot
2019.04, which was 5 years ago.)

Having said all this, I would love to do things as "right" as possible
while still being able to make progress.  What is the right step?

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20240516/072dd118/attachment-0001.sig>