Openbmc u-boot trees (was Re: u-boot:rsa adds rsa3072 algorithm)

[Patrick Williams]

Hi Joel,

On Fri, Feb 11, 2022 at 02:11:12AM +0000, Joel Stanley wrote:
> On Wed, 9 Feb 2022 at 02:29, ChiaWei Wang <chiawei_wang at aspeedtech.com> wrote:
> > > In the short term, one option is we put all of the openbmc patches in the SDK,
> > > and continue using that for openbmc. Would this work for aspeed?
...
> Works for me. I've sent two PRs with the obvious changes:
> 
>  https://github.com/AspeedTech-BMC/u-boot/pull/9
> 
>  https://github.com/AspeedTech-BMC/u-boot/pull/8

I can't tell for certain, but are you proposing that our recipes would now
exclusively point to AspeedTech-BMC?  Or would we still point them at
openbmc/u-boot?

I have a few concerns about pointing at AspeedTech-BMC:

    a. This seems to conflict with our existing guildlines for meta-layer data
       and some of the stronger guidelines we are close to consensus on with:

           https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/51099

    b. We seem to be farther from commonality between Aspeed and Nuvoton (and
       any other future vendors that might surface) by taking this approach.

    c. This is different from how we handle the kernel and seems to tie us
       more specifically to the whims of the vendor, especially around updates.
       We're already working off an early 2019 snapshot.  I recognize that the
       current maintainership structure is additional burden on you, but is it
       possible someone else from the community might be interested in assisting
       here?

    d. We're prohibiting patches in any meta-layer (and already explicitly block
       them from passing CI), but new machines often require at least DTS
       changes to u-boot.  Is Aspeed committed to taking up DTS changes at a
       similar pace to what the community needs?  What are the requirements for
       those changes (by Aspeed)?  What is the process for them and is it to be
       documented in our project anywhere, since what appears to be a PR-based
       proposal deviates from our typical "use Gerrit or do it like upstream"
       model?

I think most of these are manageable as long as we understand what the
expectation is (and document it as appropriate).  It may require some wording
changes to our guidelines and/or modifications to our guideline-validating
scripts.  The one that is most worrying to me is (d) especially around the
potential pace of acceptance of new machines.

-- 
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/20220216/f3390f3d/attachment.sig>