U-Boot upstreaming

[Maxim Sloyko]

On Thu, Nov 3, 2016 at 5:09 PM, Joel Stanley <joel at jms.id.au> 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.
>
>>
>> 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.

To set clock speed properly we would also need clock drivers, which
might also be needed by SDRAM driver. We also might need watchdog
driver to properly implement reset_cpu (via sysreset driver,
probably). And all of these need a device tree.

It's great that things are moving out of the assembly file, but we
also need to move everything in the "u-boot way" direction.

Creating a device tree and implementing some basic drivers (clocks,
WDT) would be a good place to start.

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



-- 
Maxim Sloyko