Aspeed u-boot trees

Aspeed u-boot trees

[Joel Stanley]

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?

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

Cheers,

Joel

Re: Aspeed u-boot trees

[Teddy Reed]

Thanks for summarizing Joel!

On Fri, Apr 15, 2016 at 9:12 PM, Joel Stanley <joel@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

Re: Aspeed u-boot trees

[Joel Stanley]

On Sat, Apr 16, 2016 at 4:20 PM, Teddy Reed <teddy@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

Re: Aspeed u-boot trees

[Teddy Reed]

On Mon, Apr 18, 2016 at 6:57 PM, Joel Stanley <joel@jms.id.au> wrote:
> On Sat, Apr 16, 2016 at 4:20 PM, Teddy Reed <teddy@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