U-Boot upstreaming

Cédric Le Goater clg at kaod.org
Sat Nov 5 04:35:16 AEDT 2016


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. 



More information about the openbmc mailing list