Aspeed u-boot trees

[Teddy Reed]

On Mon, Apr 18, 2016 at 6:57 PM, Joel Stanley <joel at jms.id.au> wrote:
> On Sat, Apr 16, 2016 at 4:20 PM, Teddy Reed <teddy at prosauce.org> wrote:
>> 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.
>
> Great to hear! We'll let you push ahead with your work for a week or
> two, and then see where we're at.
>
>> 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.
>
> This sounds good. I recommend taking a look at the ast2500 support
> tree, as I think we want to move to using the g4/g5 naming for our
> platforms, and then we have the specific boards like ast2400-palmetto,
> etc. I plan on doing something similar for the kernel; you can see my
> current hacks here:
>
>  https://github.com/shenki/linux/commits/ast2400/base
>
> This is the u-boot tree with ast2500 support:
>
>  https://github.com/shenki/u-boot/tree/v2013.01-aspeed-ast2500
>

Ok perfect, I'm aiming for something you can test in two days. My
initial refactors failed miserably, but now I'm doing a CB
(continuous-brick) on our most complicated board, the Yosemite-- and
making a bit of progress with the SDK cleanup and SPI driver refactor.

>> Patch 3+4: Finally, in a perhaps another two patches we can add the
>> Palmetto and Facebook board support.
>
> Let me know whenever you want some testing. I have a palmetto with
> socketed SPI flash on my desk; it's handy for recovering from
> accidental bricking :)
>
>> 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.
>
> Could they be standalone payloads that u-boot runs? I can see how this
> would introduce it's own challenges, but it would decouple you from
> u-boot.
>
> I had a poke around the chromiumos u-boot, and they appear to keep a
> top level directory with their own hacks in it.
>

Good suggestion, I'll take a look!

> That's a tough one. Perhaps we could start a discussion on the u-boot list?
>

TBH I haven't researched or dug at all into out-of-tree application
builds. There might be existing tooling already. :D
I'll reach out to the mailing list after I do some homework later this week.

> Cheers,
>
> Joel

Take care!
-Ted