U-Boot upstreaming

[Cédric Le Goater]

On 11/04/2016 06:21 PM, Maxim Sloyko wrote:
> 
> 
> On Fri, Nov 4, 2016 at 9:08 AM, Cédric Le Goater <clg at kaod.org <mailto: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 <mailto: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.

Thanks a lot. 

If that helps, openbmc/qemu now supports the SDRAM calibration 
on the AST2400 so it can be used to track how the registers are 
set. It won't replace real HW.

Cheers,

C.