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