u-boot:rsa adds rsa3072 algorithm

u-boot:rsa adds rsa3072 algorithm

[Jamin Lin]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

Hi Joel and OpenBMC team,

This patch was applied to u-boot/master, http://patchwork.ozlabs.org/project/uboot/patch/20220119082323.4567-2-jamin_lin@aspeedtech.com/
Commit   2a4b0d5890deb0c973f8db7bb03adad96aff1050
https://github.com/u-boot/u-boot/commit/2a4b0d5890deb0c973f8db7bb03adad96aff1050
Could you please help to backport the patch to the openbmc/u-boot tree?
Thanks-Jamin


************* Email Confidentiality Notice ********************
DISCLAIMER:
This message (and any attachments) may contain legally privileged and/or other confidential information. If you have received it in error, please notify the sender by reply e-mail and immediately delete the e-mail and any attachments without copying or disclosing the contents. Thank you.


[-- Attachment #2: Type: text/html, Size: 3528 bytes --]

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

[Joel Stanley]

Hi Jamin,

On Mon, 7 Feb 2022 at 02:26, Jamin Lin <jamin_lin@aspeedtech.com> wrote:
>
> Hi Joel and OpenBMC team,
>
>
>
> This patch was applied to u-boot/master, http://patchwork.ozlabs.org/project/uboot/patch/20220119082323.4567-2-jamin_lin@aspeedtech.com/
>
> Commit   2a4b0d5890deb0c973f8db7bb03adad96aff1050
>
> https://github.com/u-boot/u-boot/commit/2a4b0d5890deb0c973f8db7bb03adad96aff1050
>
> Could you please help to backport the patch to the openbmc/u-boot tree?

Sure, I can do that.

I'd like to start a discussion about the u-boot trees and how we
maintain them. Currently we have:

 - upstream; partial 2600 support
 - aspeed-master-v2019.04, SDK tree maintained by ASPEED
 - v2019.04-aspeed-openbmc, openbmc maintained by Joel. Based on SDK tree

In the past I was putting code in the openbmc tree so we could use it
for bringup, and trying to send pull requests to the SDK tree.

Now you're sending patches upstream (excellent!) and sending me
requests to merge into the openbmc tree.

I would like to see fewer trees.

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?

In the medium term, we should start using upstream releases. There may
still be some downstream code (as we have for Linux in our dev
branches), but this will go to zero over time.

Please let me know your thoughts.

Cheers,

Joel

Re: u-boot:rsa adds rsa3072 algorithm

[Joel Stanley]

On Mon, 7 Feb 2022 at 02:26, Jamin Lin <jamin_lin@aspeedtech.com> wrote:
> This patch was applied to u-boot/master, http://patchwork.ozlabs.org/project/uboot/patch/20220119082323.4567-2-jamin_lin@aspeedtech.com/
>
> Commit   2a4b0d5890deb0c973f8db7bb03adad96aff1050
>
> https://github.com/u-boot/u-boot/commit/2a4b0d5890deb0c973f8db7bb03adad96aff1050
>
> Could you please help to backport the patch to the openbmc/u-boot tree?

This patch doesn't apply cleanly. Can you send a backport to the list?
Please be sure to test that it applies, builds and runs against the
v2019.04-aspeed-openbmc tree.

Cheers,

Joel

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

[Jamin Lin]

+ Ryan, ChiaWei and Dylan

************* Email Confidentiality Notice ********************
DISCLAIMER:
This message (and any attachments) may contain legally privileged and/or other confidential information. If you have received it in error, please notify the sender by reply e-mail and immediately delete the e-mail and any attachments without copying or disclosing the contents. Thank you.

-----Original Message-----
From: Joel Stanley <joel@jms.id.au> 
Sent: Monday, February 7, 2022 2:03 PM
To: Jamin Lin <jamin_lin@aspeedtech.com>
Cc: openbmc@lists.ozlabs.org; Troy Lee <troy_lee@aspeedtech.com>; Steven Lee <steven_lee@aspeedtech.com>; Andrew Jeffery <andrew@aj.id.au>
Subject: Openbmc u-boot trees (was Re: u-boot:rsa adds rsa3072 algorithm)

Hi Jamin,

On Mon, 7 Feb 2022 at 02:26, Jamin Lin <jamin_lin@aspeedtech.com> wrote:
>
> Hi Joel and OpenBMC team,
>
>
>
> This patch was applied to u-boot/master, 
> http://patchwork.ozlabs.org/project/uboot/patch/20220119082323.4567-2-
> jamin_lin@aspeedtech.com/
>
> Commit   2a4b0d5890deb0c973f8db7bb03adad96aff1050
>
> https://github.com/u-boot/u-boot/commit/2a4b0d5890deb0c973f8db7bb03ada
> d96aff1050
>
> Could you please help to backport the patch to the openbmc/u-boot tree?

Sure, I can do that.

I'd like to start a discussion about the u-boot trees and how we maintain them. Currently we have:

 - upstream; partial 2600 support
 - aspeed-master-v2019.04, SDK tree maintained by ASPEED
 - v2019.04-aspeed-openbmc, openbmc maintained by Joel. Based on SDK tree

In the past I was putting code in the openbmc tree so we could use it for bringup, and trying to send pull requests to the SDK tree.

Now you're sending patches upstream (excellent!) and sending me requests to merge into the openbmc tree.

I would like to see fewer trees.

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?

In the medium term, we should start using upstream releases. There may still be some downstream code (as we have for Linux in our dev branches), but this will go to zero over time.

Please let me know your thoughts.

Cheers,

Joel

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

[ChiaWei Wang]

> From: Jamin Lin <jamin_lin@aspeedtech.com>
> Sent: Monday, February 7, 2022 3:02 PM
> 
> + Ryan, ChiaWei and Dylan
> 
> ************* Email Confidentiality Notice ********************
> DISCLAIMER:
> This message (and any attachments) may contain legally privileged and/or
> other confidential information. If you have received it in error, please notify
> the sender by reply e-mail and immediately delete the e-mail and any
> attachments without copying or disclosing the contents. Thank you.
> 
> -----Original Message-----
> From: Joel Stanley <joel@jms.id.au>
> Sent: Monday, February 7, 2022 2:03 PM
> To: Jamin Lin <jamin_lin@aspeedtech.com>
> Cc: openbmc@lists.ozlabs.org; Troy Lee <troy_lee@aspeedtech.com>; Steven
> Lee <steven_lee@aspeedtech.com>; Andrew Jeffery <andrew@aj.id.au>
> Subject: Openbmc u-boot trees (was Re: u-boot:rsa adds rsa3072 algorithm)
> 
> Hi Jamin,
> 
> On Mon, 7 Feb 2022 at 02:26, Jamin Lin <jamin_lin@aspeedtech.com> wrote:
> >
> > Hi Joel and OpenBMC team,
> >
> >
> >
> > This patch was applied to u-boot/master,
> > http://patchwork.ozlabs.org/project/uboot/patch/20220119082323.4567-2-
> > jamin_lin@aspeedtech.com/
> >
> > Commit   2a4b0d5890deb0c973f8db7bb03adad96aff1050
> >
> >
> https://github.com/u-boot/u-boot/commit/2a4b0d5890deb0c973f8db7bb03ad
> a
> > d96aff1050
> >
> > Could you please help to backport the patch to the openbmc/u-boot tree?
> 
> Sure, I can do that.
> 
> I'd like to start a discussion about the u-boot trees and how we maintain them.
> Currently we have:
> 
>  - upstream; partial 2600 support
>  - aspeed-master-v2019.04, SDK tree maintained by ASPEED
>  - v2019.04-aspeed-openbmc, openbmc maintained by Joel. Based on SDK tree
> 
> In the past I was putting code in the openbmc tree so we could use it for
> bringup, and trying to send pull requests to the SDK tree.
> 
> Now you're sending patches upstream (excellent!) and sending me requests to
> merge into the openbmc tree.
> 
> I would like to see fewer trees.
> 
> 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?

Yes.
Are we going to do this through PRs as usual?

> 
> In the medium term, we should start using upstream releases. There may still
> be some downstream code (as we have for Linux in our dev branches), but this
> will go to zero over time.

Agree.
We are also working on upstreaming fundamental drivers to U-Boot mainline.
Once it is sufficient for most frequently used booting paths, Aspeed will start using it.

Regards,
Chiawei

Re: u-boot:rsa adds rsa3072 algorithm

[Jamin Lin]

The 02/07/2022 06:11, Joel Stanley wrote:
> On Mon, 7 Feb 2022 at 02:26, Jamin Lin <jamin_lin@aspeedtech.com> wrote:
> > This patch was applied to u-boot/master, http://patchwork.ozlabs.org/project/uboot/patch/20220119082323.4567-2-jamin_lin@aspeedtech.com/
> >
> > Commit   2a4b0d5890deb0c973f8db7bb03adad96aff1050
> >
> > https://github.com/u-boot/u-boot/commit/2a4b0d5890deb0c973f8db7bb03adad96aff1050
> >
> > Could you please help to backport the patch to the openbmc/u-boot tree?
> 
> This patch doesn't apply cleanly. Can you send a backport to the list?
> Please be sure to test that it applies, builds and runs against the
> v2019.04-aspeed-openbmc tree.
> 
> Cheers,
> 
> Joel

I send the new patch and ready for review.
Thanks-Jamin

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

[Joel Stanley]

On Wed, 9 Feb 2022 at 02:29, ChiaWei Wang <chiawei_wang@aspeedtech.com> wrote:
> > I would like to see fewer trees.
> >
> > 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?
>
> Yes.
> Are we going to do this through PRs as usual?

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

We need to work out how to arrange the defconfigs. Would you like to
see openbmc using one of the defconfigs you maintain, or should we
keep a seperate one?

configs/evb-ast2600-cot_defconfig
configs/evb-ast2600_defconfig
configs/evb-ast2600-ecc_defconfig
configs/evb-ast2600-emmc_defconfig
configs/evb-ast2600-spl_defconfig
configs/evb-ast2600-spl-ecc_defconfig
configs/evb-ast2600-spl-ncsi_defconfig
configs/evb-ast2600-spl-tiny_defconfig

The openbmc ones are here:

configs/ast2600_openbmc_defconfig
configs/ast2600_openbmc_spl_defconfig
configs/ast2600_openbmc_spl_emmc_defconfig

The openbmc and openbmc_spl defconfigs are legacy and not tested by
myself. I actively maintain the openbmc_spl_emmc configuration as it
supports the rainier/everest

> > In the medium term, we should start using upstream releases. There may still
> > be some downstream code (as we have for Linux in our dev branches), but this
> > will go to zero over time.
>
> Agree.
> We are also working on upstreaming fundamental drivers to U-Boot mainline.
> Once it is sufficient for most frequently used booting paths, Aspeed will start using it.

Excellent. Thank you for your work in this area.

Cheers,

Joel

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

[ChiaWei Wang]

> From: Joel Stanley <joel@jms.id.au>
> Sent: Friday, February 11, 2022 10:11 AM
> 
> On Wed, 9 Feb 2022 at 02:29, ChiaWei Wang
> <chiawei_wang@aspeedtech.com> wrote:
> > > I would like to see fewer trees.
> > >
> > > 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?
> >
> > Yes.
> > Are we going to do this through PRs as usual?
> 
> 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
> 
> We need to work out how to arrange the defconfigs. Would you like to see
> openbmc using one of the defconfigs you maintain, or should we keep a
> seperate one?
> 
> configs/evb-ast2600-cot_defconfig
> configs/evb-ast2600_defconfig
> configs/evb-ast2600-ecc_defconfig
> configs/evb-ast2600-emmc_defconfig
> configs/evb-ast2600-spl_defconfig
> configs/evb-ast2600-spl-ecc_defconfig
> configs/evb-ast2600-spl-ncsi_defconfig
> configs/evb-ast2600-spl-tiny_defconfig

These evb-ast2600-xxx defconfigs are still used by Aspeed customers who are not moving on to OpenBMC yet.
Let's keep them separated until the legacy Aspeed SDK is phased out.
After then, we can work on merging these defconfigs with those of openbmc for simplicity.

Regards,
Chiawei

> 
> The openbmc ones are here:
> 
> configs/ast2600_openbmc_defconfig
> configs/ast2600_openbmc_spl_defconfig
> configs/ast2600_openbmc_spl_emmc_defconfig
> 
> The openbmc and openbmc_spl defconfigs are legacy and not tested by myself.
> I actively maintain the openbmc_spl_emmc configuration as it supports the
> rainier/everest
> 
> > > In the medium term, we should start using upstream releases. There
> > > may still be some downstream code (as we have for Linux in our dev
> > > branches), but this will go to zero over time.
> >
> > Agree.
> > We are also working on upstreaming fundamental drivers to U-Boot
> mainline.
> > Once it is sufficient for most frequently used booting paths, Aspeed will start
> using it.
> 
> Excellent. Thank you for your work in this area.

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

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 2475 bytes --]

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@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]