[U-Boot] arm: General questions for new board support: Aspeed AST2400

[U-Boot] arm: General questions for new board support: Aspeed AST2400

[Teddy Reed]

Hello everyone!

I've been working on board support for Apeed's AST2400 SoC. Myself and
several other board users are just about finished with a cleanup up
the vendor's SDK code, trying to transform it into something capable
of merging into mainline.

This SoC is used as the Open Compute OpenBMC implementation for
Facebook and IBM's boards. The AST2400 is used in 5+ board
configurations that I know of, 4 of which are also Open Compute
platforms. If you're curious, my WIP branch is here:
https://github.com/theopolis/u-boot-openbmc/commits/v2016.03-openbmc-r3
and tells a very short story about the refactoring and merging of
Facebook's Open Compute board configurations.

There's quite a bit of code there, about 3000+ LoC for the AST2400
ARM926EJS CPU, its platform initialization, DDR3 calibration, and
I2C/NIC drivers. If you don't mind, I'd like some feedback on how to
move forward with merging board support. :)

My (very basic) plan would be to submit a 'large' patch that includes
the CPU/board initialization code, along with the 4 board
configurations. In subsequent patches we can merge the I2C and NIC
support. I2C and the NIC drivers aren't critical to the OpenBMC
platform within U-Boot so they are less of a priority, though still a
nice to have. That initial patch will include the ARM ASM DDR3
calibration code, and some not-so-best-practices within platform
initialization (pre-C runtime). There is a reason for this, though it
maybe not the best one. One of the boards, the Open Compute Yosemite,
controls several compute nodes, and depending on some GPIO
configuration will need to redirect 'very' early UART messages.

The DDR3 calibration is needed to support the several variations of
the AST2400. If it is not possible to merge this code for one reason
or another I would need to perform some serious coordination between
the board users. The SoC specification is unfortunately under NDA so
collecting and testing calibration values from the various board users
is not something I feel safe shouldering.

If we are able to merge given these two considerations it will allow
both the Facebook and IBM teams to iterate and track development much
quicker, it would be awesome! I know of several other forks that are
improving and adding Aspeed-related drivers. There are also upcoming
development teams interested in OpenBMC work that would love having
the AST2400 code in mainline too. And, in the near future a newer
AST2500 will come on online-- and would benefit from having the
AST2400 code to iterate upon. The AST2400 boards will remain in a
production capacity for next 3/4 years so we need both.

Thanks so much in advance!
-Teddy

-- 
Teddy Reed V

[U-Boot] arm: General questions for new board support: Aspeed AST2400

[Marek Vasut]

On 06/03/2016 06:29 PM, Teddy Reed wrote:
> Hello everyone!

Hi!

> I've been working on board support for Apeed's AST2400 SoC. Myself and
> several other board users are just about finished with a cleanup up
> the vendor's SDK code, trying to transform it into something capable
> of merging into mainline.
> 
> This SoC is used as the Open Compute OpenBMC implementation for
> Facebook and IBM's boards. The AST2400 is used in 5+ board
> configurations that I know of, 4 of which are also Open Compute
> platforms. If you're curious, my WIP branch is here:
> https://github.com/theopolis/u-boot-openbmc/commits/v2016.03-openbmc-r3
> and tells a very short story about the refactoring and merging of
> Facebook's Open Compute board configurations.
> 
> There's quite a bit of code there, about 3000+ LoC for the AST2400
> ARM926EJS CPU, its platform initialization, DDR3 calibration, and
> I2C/NIC drivers. If you don't mind, I'd like some feedback on how to
> move forward with merging board support. :)

CCing Tom.

> My (very basic) plan would be to submit a 'large' patch that includes
> the CPU/board initialization code, along with the 4 board
> configurations.

Please no huge patches. Split it at least into core ast2400 support
(stuff which goes into arch/ ) , drivers and boards . Each board should
go in a separate patch. Otherwise it's really impossible to review it.

> In subsequent patches we can merge the I2C and NIC
> support. I2C and the NIC drivers aren't critical to the OpenBMC
> platform within U-Boot so they are less of a priority, though still a
> nice to have.

OK

> That initial patch will include the ARM ASM DDR3
> calibration code

Can the DDR3 init code be rewritten into C or is there some limitation
on that platform why it's in assembler ?

>, and some not-so-best-practices within platform
> initialization (pre-C runtime). There is a reason for this, though it
> maybe not the best one. One of the boards, the Open Compute Yosemite,
> controls several compute nodes, and depending on some GPIO
> configuration will need to redirect 'very' early UART messages.

That can be done in the lowlevel_init hook , so that is okayish.

> The DDR3 calibration is needed to support the several variations of
> the AST2400. If it is not possible to merge this code for one reason
> or another I would need to perform some serious coordination between
> the board users. The SoC specification is unfortunately under NDA so
> collecting and testing calibration values from the various board users
> is not something I feel safe shouldering.

I guess that's mostly OK if it's only a matter of per-board parameters.

> If we are able to merge given these two considerations it will allow
> both the Facebook and IBM teams to iterate and track development much
> quicker, it would be awesome! I know of several other forks that are
> improving and adding Aspeed-related drivers. There are also upcoming
> development teams interested in OpenBMC work that would love having
> the AST2400 code in mainline too. And, in the near future a newer
> AST2500 will come on online-- and would benefit from having the
> AST2400 code to iterate upon. The AST2400 boards will remain in a
> production capacity for next 3/4 years so we need both.

OK, cool.

> Thanks so much in advance!
> -Teddy
> 


-- 
Best regards,
Marek Vasut