U-Boot upstreaming

[Maxim Sloyko]

On Fri, Nov 4, 2016 at 8:54 AM, Cédric Le Goater <clg at kaod.org> wrote:

> Hello !
>
> On 11/03/2016 09:44 PM, Maxim Sloyko 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?
>
> Please check :
>
>   https://github.com/openbmc/u-boot/wiki
>
> This is where we track the ugly details and here is my tree :
>
>    https://github.com/legoater/u-boot/commits/v2016.11-aspeed-openbmc
>
> Patch one is the "minimum" we have been working on with Joel these
> last 6 months to :
>
>  * make it compatible with upstream
>  * extract all exoticisms
>  * extract funky drivers
>  * isolate ugly hacks
>
> I think we are at a point where we need to rewrite bits of lowlevel_init
> or move them later on in the code. This big asm routines does :
>
>  * LPC patching for ast2300 (we can kill that)
>  * uart init (if SDRAM calibration is done, easy we can keep)
>  * SDRAM calibration (we could use static calibration values instead)
>  * SDRAM size calculation (may be we can move that in a C part)
>  * video clock setting (one reg setting)
>  * JTAG master (one reg setting)
>  * RMII/RGMII clock setting (one reg setting)
>  * GPIO massive reset (not sure if this is useful, should ask Andrew)
>  * SPI Calibration (I have done in C so we can move)
>

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.

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


>
> > 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.
>
> yes. See my comments above.
>
> > 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,
>
> yes. that is patch one above, in which we still need to cleanup
> stuff in the .S part.
>
> >  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.
>
> I am not sure this is feasible, AFAIK, you can not call C. I might
> be wrong.
>

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

mov sp, =TOP_OF_SRAM

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.


>
> > 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.
> >
> > Thoughts?
>
> you could send patches on top of my tree to cleanup what ever
> part you want in lowlevel_init. when lowlevel_init reaches a
> minimum acceptable level, with a full patchset working on top
> of it, I think we can send for review. Then, we will work on
> the next details :
>
>  * extra settings
>  * spi/nor driver
>  * ftgmac100 extensions for Aspeed
>  * NCSI support
>  * DTS support
>  * etc.
>
> There is also a massive hack on the ast2500 mmu disablement in
> the core part of u-boot that I don't understand. So we could
> try to fix now or ask help when the patchset is sent.
>
>
> Cheers,
>
> C.
>



-- 
*M*axim *S*loyko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161104/2b214850/attachment-0001.html>