U-Boot upstreaming

[Cédric Le Goater]

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.

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.

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

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