[U-Boot] arm: General questions for new board support: Aspeed AST2400
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
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
participants (2)
-
Marek Vasut -
Teddy Reed