[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