From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Sat, 04 Jun 2016 01:02:21 +0200 Subject: [U-Boot] arm: General questions for new board support: Aspeed AST2400 In-Reply-To: References: Message-ID: <57520C7D.5080002@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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