U-Boot upstreaming

[Joel Stanley]

Hi Maxim,

On Fri, Nov 4, 2016 at 7:14 AM, Maxim Sloyko <maxims at google.com> wrote:
> Hi Cedric,
>
> My manager (Rick Alther) mentioned that you were working on some minimal
> "upstreamable" commit for Aspeed in U-Boot. How far were you able to get?
>
> This is also what I was thinking of doing, so we should be able to join
> forces on this.
>
> I talked to Simon Glass recently (he's an active contributor to mainline
> U-Boot) and basically that's the path that he also recommended -- just
> getting minimal amount of code in, that can just boot to a prompt. He also
> said that DRAM driver would have to be part of it.

I agree. The downside here is Cedric has done a lot of work in
cleaning up the Aspeed SDK code already, so we don't want to throw
away the good stuff he's done.

>
> So, the way I see it, there are two big chunks of work here:
>  1. Setting up the whole structure. This would include actually adding a
> board, minimum amount of supporting code, debug serial console init,

I have a tree where I've started pulling the build scaffolding -
kconfig, makefiles, etc - out of the patch we have.

The second part of it is writing a clean serial driver. The hardware a
pretty standard layout, so I imagine we don't need to do much here.
Perhaps doing some calculations based on the clock speed to set a baud
rate.

>  2. DDR3/DDR4 driver. This is the biggest part of what we have in platform.S
> now. A lot of work, but relatively straightforward, just rewrite ~1.5k lines
> of assembly in C.

Our concern with rewriting this is future maintainability. If we
rewrite it, it becomes harder to incorporate fixes and new hardware
support from Aspeed SDKs.

On the other hand, there's no way we can upstream it as-is. So lets
re-write it in C, and where we can document parts of the
reimplementation with reference to the assembly so making updates is
possible.

>
> Personally, I don't have preference on who does what, as long as we don't
> step on each other's toes. It would probably be easier for me to take (1),
> because I can easily talk to two people who are in our time zone and have a
> lot of mainline U-Boot experience.

I think we've got a good handle on (1), however I'll let Cedric
comment as to what he would prefer to work on.

Note that this work is continuing on from some work done by Teddy
several months ago. He has a tree here:

 https://github.com/theopolis/u-boot-openbmc/tree/v2016.03-openbmc-r3

Cheers,

Joel