Aspeed u-boot trees

Joel Stanley joel at jms.id.au
Tue Apr 19 11:57:13 AEST 2016


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

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

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

Cheers,

Joel


More information about the openbmc mailing list