<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 4, 2016 at 9:08 AM, Cédric Le Goater <span dir="ltr"><<a href="mailto:clg@kaod.org" target="_blank">clg@kaod.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/04/2016 01:09 AM, Joel Stanley wrote:<br>
> Hi Maxim,<br>
><br>
> On Fri, Nov 4, 2016 at 7:14 AM, Maxim Sloyko <<a href="mailto:maxims@google.com">maxims@google.com</a>> wrote:<br>
>> Hi Cedric,<br>
>><br>
>> My manager (Rick Alther) mentioned that you were working on some minimal<br>
>> "upstreamable" commit for Aspeed in U-Boot. How far were you able to get?<br>
>><br>
>> This is also what I was thinking of doing, so we should be able to join<br>
>> forces on this.<br>
>><br>
>> I talked to Simon Glass recently (he's an active contributor to mainline<br>
>> U-Boot) and basically that's the path that he also recommended -- just<br>
>> getting minimal amount of code in, that can just boot to a prompt. He also<br>
>> said that DRAM driver would have to be part of it.<br>
><br>
> I agree. The downside here is Cedric has done a lot of work in<br>
> cleaning up the Aspeed SDK code already, so we don't want to throw<br>
> away the good stuff he's done.<br></span></blockquote><div><br></div><div>Why would that be thrown away? The idea is to prepare minimum amount of stuff required for the first commit upstream.</div><div>The rest won't be thrown away, it will just follow.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>half of that work is yours, Joel.<br>
<span class=""><br>
>> So, the way I see it, there are two big chunks of work here:<br>
>>  1. Setting up the whole structure. This would include actually adding a<br>
>> board, minimum amount of supporting code, debug serial console init,<br>
><br>
> I have a tree where I've started pulling the build scaffolding -<br>
> kconfig, makefiles, etc - out of the patch we have.<br>
><br>
> The second part of it is writing a clean serial driver. The hardware a<br>
> pretty standard layout, so I imagine we don't need to do much here.<br>
> Perhaps doing some calculations based on the clock speed to set a baud<br>
> rate.<br>
><br>
>>  2. DDR3/DDR4 driver. This is the biggest part of what we have in platform.S<br>
>> now. A lot of work, but relatively straightforward, just rewrite ~1.5k lines<br>
>> of assembly in C.<br>
><br>
> Our concern with rewriting this is future maintainability. If we<br>
> rewrite it, it becomes harder to incorporate fixes and new hardware<br>
> support from Aspeed SDKs.<br>
<br>
</span>Yes that is one big concern I think. The platform*.s files are<br>
exactly the one shipped by Aspeed.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> On the other hand, there's no way we can upstream it as-is. So lets<br>
> re-write it in C, and where we can document parts of the<br>
> reimplementation with reference to the assembly so making updates is<br>
> possible.<br>
><br>
>><br>
>> Personally, I don't have preference on who does what, as long as we don't<br>
>> step on each other's toes. It would probably be easier for me to take (1),<br>
>> because I can easily talk to two people who are in our time zone and have a<br>
>> lot of mainline U-Boot experience.<br>
<br>
</span>sure.<br>
<span class=""><br>
> I think we've got a good handle on (1), however I'll let Cedric<br>
> comment as to what he would prefer to work on.<br>
<br>
</span>My main concern is keeping a full patchset working with the HW<br>
we have. I don't think there is much value in pushing mainline<br>
some code we don't use because it is too far away from our<br>
current need. So whatever we send should be used in our openbmc<br>
tree, but not in the stable branch of course.<br>
<br>
As said in the other email, I think we are at point where we<br>
should dismantle lowlevel_init in little parts.<br>
<br>
Maxim, may be you could take a look at the SDRAM calibration ?<br>
<br>
This is the biggest part when this is done, the rest should<br>
flow.<br></blockquote><div><br></div><div>Sounds good to me, I'll start pulling out SDRAM part out.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<br>
C.<br>
<div class="HOEnZb"><div class="h5"><br>
> Note that this work is continuing on from some work done by Teddy<br>
> several months ago. He has a tree here:<br>
><br>
>  <a href="https://github.com/theopolis/u-boot-openbmc/tree/v2016.03-openbmc-r3" rel="noreferrer" target="_blank">https://github.com/theopolis/<wbr>u-boot-openbmc/tree/v2016.03-<wbr>openbmc-r3</a><br>
><br>
> Cheers,<br>
><br>
> Joel<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div><b>M</b>axim <b>S</b>loyko</div></div>
</div></div>