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

[Joel Stanley]

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.

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

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

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

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?

Cheers,

Joel