<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 4, 2016 at 8:54 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">Hello !<br>
<span class=""><br>
On 11/03/2016 09:44 PM, Maxim Sloyko wrote:<br>
> Hi Cedric,<br>
><br>
> My manager (Rick Alther) mentioned that you were working on some<br>
> minimal "upstreamable" commit for Aspeed in U-Boot. How far were<br>
> you able to get?<br>
<br>
</span>Please check :<br>
<br>
<a href="https://github.com/openbmc/u-boot/wiki" rel="noreferrer" target="_blank">https://github.com/openbmc/u-<wbr>boot/wiki</a><br>
<br>
This is where we track the ugly details and here is my tree :<br>
<br>
<a href="https://github.com/legoater/u-boot/commits/v2016.11-aspeed-openbmc" rel="noreferrer" target="_blank">https://github.com/legoater/u-<wbr>boot/commits/v2016.11-aspeed-<wbr>openbmc</a><br>
<br>
Patch one is the "minimum" we have been working on with Joel these<br>
last 6 months to :<br>
<br>
* make it compatible with upstream<br>
* extract all exoticisms<br>
* extract funky drivers<br>
* isolate ugly hacks<br>
<br>
I think we are at a point where we need to rewrite bits of lowlevel_init<br>
or move them later on in the code. This big asm routines does :<br>
<br>
* LPC patching for ast2300 (we can kill that)<br>
* uart init (if SDRAM calibration is done, easy we can keep)<br>
* SDRAM calibration (we could use static calibration values instead)<br>
* SDRAM size calculation (may be we can move that in a C part)<br>
* video clock setting (one reg setting)<br>
* JTAG master (one reg setting)<br>
* RMII/RGMII clock setting (one reg setting)<br>
* GPIO massive reset (not sure if this is useful, should ask Andrew)<br>
* SPI Calibration (I have done in C so we can move)<br></blockquote><div><br></div><div>Yes, I looked at it too and it does not look like any of that has any business being in lowlevel_init, let alone being implemented in asm.</div><div><br></div><div>Did you try moving this whole function further down the init sequence? board_early_init_f might be a good candidate. It might cause problems because it does not restore registers properly, but should be an easy fix --</div><div>at this point we would already have stack setup for us (need to be configured via CONFIG_SYS_INIT_SP_ADDR to point to the top of SRAM) and even have a basic malloc (need to be configured). This would make calling into C somewhat easier. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> This is also what I was thinking of doing, so we should be able to join forces on this.<br>
><br>
> I talked to Simon Glass recently (he's an active contributor to mainline U-Boot)<br>
> and basically that's the path that he also recommended -- just getting minimal amount<br>
> of code in, that can just boot to a prompt. He also said that DRAM driver would have<br>
> to be part of it.<br>
<br>
</span>yes. See my comments above.<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 board, minimum<br>
> amount of supporting code, debug serial console init,<br>
<br>
</span>yes. that is patch one above, in which we still need to cleanup<br>
stuff in the .S part.<br>
<span class=""><br>
> 2. DDR3/DDR4 driver. This is the biggest part of what we have in platform.S now. A lot<br>
> of work, but relatively straightforward, just rewrite ~1.5k lines of assembly in C.<br>
<br>
</span>I am not sure this is feasible, AFAIK, you can not call C. I might<br>
be wrong.<br></blockquote><div><br></div><div>You can. I tried it and it works. We just need stack (see above). Even if moving the whole lowlevel_init further down will prove too hard, we can at least call</div><div><br></div><div>mov sp, =TOP_OF_SRAM</div><div><br></div><div>at top of lowlevel_init. after this you can write (and call into) pretty complicated C functions. This is what I've tried in my early experiments.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Personally, I don't have preference on who does what, as long as we don't step on each<br>
> other's toes. It would probably be easier for me to take (1), because I can easily talk<br>
> to two people who are in our time zone and have a lot of mainline U-Boot experience.<br>
><br>
> Thoughts?<br>
<br>
</span>you could send patches on top of my tree to cleanup what ever<br>
part you want in lowlevel_init. when lowlevel_init reaches a<br>
minimum acceptable level, with a full patchset working on top<br>
of it, I think we can send for review. Then, we will work on<br>
the next details :<br>
<br>
* extra settings<br>
* spi/nor driver<br>
* ftgmac100 extensions for Aspeed<br>
* NCSI support<br>
* DTS support<br>
* etc.<br>
<br>
There is also a massive hack on the ast2500 mmu disablement in<br>
the core part of u-boot that I don't understand. So we could<br>
try to fix now or ask help when the patchset is sent.<br>
<br>
<br>
Cheers,<br>
<br>
C.<br>
</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>