U-Boot upstream, patch and maintain model and plan for OpenBMC

[Dan Zhang]

Hi Joel,

> -----Original Message-----
> From: Joel Stanley <joel at jms.id.au>
> Sent: Thursday, January 9, 2020 2:09 PM
> To: Dan Zhang <zhdaniel at fb.com>; Cédric Le Goater <clg at kaod.org>
> Cc: openbmc at lists.ozlabs.org; Andrew Jeffery <andrew at aj.id.au>
> Subject: Re: U-Boot upstream, patch and maintain model and plan for
> OpenBMC
> 
> Hi Dan,
> 
> On Thu, 9 Jan 2020 at 21:51, Dan Zhang <zhdaniel at fb.com> wrote:
> >
> > I am writing to see how can I align and contribute to the U-Boot
> development for OpenBMC.
> 
> Great to hear from you again. I know we spoke about this at OSFC,
> apologies for not finding time to chat since then.
> 
Thank you for your prompt reply and sharing your plan. It is nice to hear from you also.

> > OpenBMC supported platforms ( IBM witherspoon: tacoma and rainier) are
> using new Aspeed SDK (https://github.com/AspeedTech-BMC/u-
> boot/tree/aspeed-dev-v2019.04).
> > In my new project, I am planning to use this SDK also.
> > I believe it will be benefit to align with and contribute to OpenBMC
> community regarding upstream, patch and maintain this new SDK.
> 
> Yes, that would be great.
> 
> > Thus, I have some open questions about OpenBMC communities' u-boot
> developing model and/or plan:
> > 1. Will U-Boot also follow Kernel's developing model for OpenBMC?
> > Kernel developing model ( my understanding )
> > individual contributor actively aligned with OpenBMC about the kernel
> patch upstreaming plan and status,
> > and OpenBMC kernel maintainers will pull-in and/or backports the accepted
> patches to all supported kernel versions.
> 
> I think this makes sense. Would you be happy following this model?
Yes, I am happy to follow this model.

> 
> > All supported kernel versions will be maintained on corresponding branches
> in https://github.com/openbmc/linux  OpenBMC fork.
> >
> > 2. Will, eventually, u-boot code of OpenBMC be maintained in
> https://github.com/openbmc/u-boot OpenBMC fork? or kept in BSP/SDK
> vendor's u-boot fork?
> 
> Eventually, we hope to have all of our code upstream, and not require
> an openbmc fork. While this is a work in progress I suggest we use
> openbmc/u-boot, but work closely with the vendors to ensure fixes and
> new features are sent upstream and applied to the openbmc tree.
> 
Agree. 

> I have spent some time working on a patchset suitable for upstream
> that supports the ast2600. It contains support for:
> 
>  - dram training
>  - clocking/reset
>  - pinmux
>  - gpio
>  - ftgmac100 with phy
> 
> I am still working on:
> 
>  - ncsi: I see broadcast traffic. Debugging why the NIC does not
> respond to NCSI packets
>  - spi-nor: patches from Cedric, but I have not integrated them into my tree
> 
> We have mmc support upstream. I have not tested this yet.
I would love to help on test this. We will have eMMC support in both AST2500
and AST2600 platforms.

> 
> I will publish this tree in the coming days, and send it to the u-boot
> lists for review. As long as testing goes well, we will switch to that
> for the ast2600 platforms in OpenBMC.
Great, I will keep eye on u-boot list , and will be happy to help in review. 

> 
> I propose we support the ast2500 platforms with the same tree.
> 
> I would ask that someone step forward to add ast2400 support, and in
> the mean time it will use the existing tree.
> 
> How does this plan sound to you? Is there an area you would like to
> take ownership of?
Yes. My original plan is: In addition to AST2600 platform, migrate our AST2500 platforms 
to use the new SDK also. At the same time prepare patches to upstream the new SDK. 
As you have been working on upstreaming new SDK. I think I can be help in have your upstreaming
patchsets to support ast2500 platforms.

As for support AST2400, this is in my work list also, but quite low priority. 

> 
> Cheers,
> 
> Joel