From: Patrick Williams <patrick@stwcx.xyz>
To: Andrew Jeffery <andrew@codeconstruct.com.au>
Cc: openbmc@lists.ozlabs.org, Joel Stanley <joel@jms.id.au>,
Peter Yin <peteryin.openbmc@gmail.com>
Subject: Re: [PATCH u-boot, v2019.04-aspeed-openbmc v1 1/1] ARM: dts: Aspeed: Add Facebook common dts
Date: Thu, 16 May 2024 20:19:50 -0500 [thread overview]
Message-ID: <ZkawtsDBMGT-rTJx@heinlein.vulture-banana.ts.net> (raw)
In-Reply-To: <242c8e796123208e3a3d133a292b8409a03c0e89.camel@codeconstruct.com.au>
[-- Attachment #1: Type: text/plain, Size: 3428 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-05-17 1:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-13 14:49 [PATCH u-boot, v2019.04-aspeed-openbmc v1 1/1] ARM: dts: Aspeed: Add Facebook common dts Peter Yin
2024-05-13 23:52 ` Andrew Jeffery
2024-05-15 9:41 ` Peter Yin
2024-05-16 1:00 ` Andrew Jeffery
2024-05-16 2:37 ` Patrick Williams
2024-05-16 23:36 ` Andrew Jeffery
2024-05-17 1:19 ` Patrick Williams [this message]
2024-05-17 1:30 ` Andrew Jeffery
2024-05-17 1:59 ` Patrick Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZkawtsDBMGT-rTJx@heinlein.vulture-banana.ts.net \
--to=patrick@stwcx.xyz \
--cc=andrew@codeconstruct.com.au \
--cc=joel@jms.id.au \
--cc=openbmc@lists.ozlabs.org \
--cc=peteryin.openbmc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.