U-Boot upstreaming

[Maxim Sloyko]

On Fri, Nov 4, 2016 at 9:08 AM, Cédric Le Goater <clg at kaod.org> wrote:

> On 11/04/2016 01:09 AM, Joel Stanley wrote:
> > 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.
>

Why would that be thrown away? The idea is to prepare minimum amount of
stuff required for the first commit upstream.
The rest won't be thrown away, it will just follow.


>
> half of that work is yours, Joel.
>
> >> 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.
>
> Yes that is one big concern I think. The platform*.s files are
> exactly the one shipped by Aspeed.
>

Since they are not helping, I don't see any other way. We will just have to
look at their diffs and incorporate those fixes in our tree. I would take
this option any day over having to make fixes in platform.s, if we need to
change something.


>
> > 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.
>
> sure.
>
> > 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.
>
> My main concern is keeping a full patchset working with the HW
> we have. I don't think there is much value in pushing mainline
> some code we don't use because it is too far away from our
> current need. So whatever we send should be used in our openbmc
> tree, but not in the stable branch of course.
>
> As said in the other email, I think we are at point where we
> should dismantle lowlevel_init in little parts.
>
> Maxim, may be you could take a look at the SDRAM calibration ?
>
> This is the biggest part when this is done, the rest should
> flow.
>

Sounds good to me, I'll start pulling out SDRAM part out.


>
> Cheers,
>
> C.
>
> > 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
>
>


-- 
*M*axim *S*loyko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161104/28e99ef3/attachment.html>