Aspeed u-boot trees

[Teddy Reed]

Thanks for summarizing Joel!

On Fri, Apr 15, 2016 at 9:12 PM, Joel Stanley <joel at jms.id.au> wrote:
> Hello All,
>
> I wanted everyone who has been helping out with u-boot to get on the
> same page. We have a few trees floating around, and the last thing we
> want is to be doubling up on work.
>
> Ted's tree
>  - ast2400 patches that Facebook were using
>  - rebased on 2016.03
>  - cleanups
>  - https://github.com/theopolis/u-boot-openbmc/tree/v2016.03-openbmc-r1
>
> Cedric's tree:
>  - ast2400 patches that the IBM team were using
>  - rebased on 2016.03+
>  - https://github.com/legoater/u-boot
>
> Joel's tree
>  - Cedric's tree, after deleting a lot of unused code
>  - https://github.com/shenki/u-boot/tree/aspeed/openbmc-cleanups
>
> Finally, I took a copy of Aspeed's latest BSP that supports the
> ast2500 as well as SoCs supported by the existing code and pushed it:
>
>   https://github.com/shenki/u-boot/tree/v2013.01-aspeed-ast2500
>
> This tree is somewhat cleaner than the previous. It groups boards in
> generation 3, 4, and 5. This is an attractive option for focusing our
> cleanup and upstream efforts from here.
>
> Ted, what are your plans for your tree? Do you have time, or would you
> like some help?
>

I have a lot of time to spend with u-boot and I'm happy to help
however possible.
In tandem with the QEMU and kernel work you've done, it would be best
to begin upstreaming to u-boot.

I'd like to organize 3 patches to upstream:
Patch 1: I can attempt to bundle the most basic set of patches from
the various trees which are based on v2016.03 for the 2400 boards. My
goal for the first patch is the simplest possible bit of code, based
on the 2400 SDK.
Patch 2: From there we can iterate with support for 2500 and include
the fixups Cedric has to the ASPEED-provided SDK code.
Patch 3+4: Finally, in a perhaps another two patches we can add the
Palmetto and Facebook board support.

I have one concern with this approach (aside from eagerly waiting for
your constructive criticism!):
The SDK provides helpful system level tests (SLTs) that we use
internally quite often. I want to continue having them available, but
u-boot does not facilitate this from what I can tell. They definitely
should be removed from the CPU and board definitions-- they might be
ok as u-boot commands. They could also be amalgamated into a command
suite. That said, CPU/board specific commands are very rare.

Any recommendations on how to support the SLTs within u-boot, or
perhaps recommendations or examples on how folks "vendor in" these
sorts of tests? Ideally they would still exist in the output u-boot
code for validation testing and runtime debugging.

> Cedric, I think you have some cycles available to do some u-boot work.
> Which tree do you think is best to work from?

-- 
Teddy Reed V