From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dinh Nguyen Date: Wed, 8 Oct 2014 08:18:10 -0500 Subject: [U-Boot] [SoCFPGA] next steps In-Reply-To: <201410071445.50854.marex@denx.de> References: <201410071445.50854.marex@denx.de> Message-ID: <54353992.8030906@opensource.altera.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Marek, On 10/7/14, 7:45 AM, Marek Vasut wrote: > Hey, > > given that we now have most of the u-boot socfpga stuff in mainline, I decided > it would be a good idea to list what we're still missing and we should also > decide how to move on now. Thanks for all of your hard work on this! > > First thing I should probably clarify is the late acceptance of the socfpga > patches. This is certainly not something we do regularly and is one of the > worst possible practices to do, but this time it felt rather important to get > the platform in shape, so this exception happened. Furthermore, all of the code > in u-boot-socfpga should be based on u-boot-arm and should be submitted through > the u-boot-arm repository, not directly to u-boot . > > As you probably noticed, there is a lot of topic branches in the u-boot-socfpga > [1] repository, each of them with a date tag. This decision came to be so that > rebasing of a branch can be avoided. I will most likely garbage-collect the old > and useless topic branches at some point, when they become irrelevant due to the > code being merged into u-boot-arm/master (and then to u-boot/master). > > I think that's about it for the organization part. Now for the remaining part, > we are still missing a few things. Some of them are ready, some of them, not so > much: > > SPL: This is something we still miss from mainline. We will need to discuss > this thoroughly, but one thing is obvious already -- we need to figure > out how to interoperate with Quartus resp. the bsp-editor generated > header files to assemble the SPL properly. Have you or anyone else already started on this work? If not, then this is an area that I can start to work on. > USB: This is scheduled for the next merge window. The DWC2 driver is cleaned > up and seems to be in rather good state. The USB driver currently resides > in [2] > EPCQ: This is something I prepared and tested real quick. The EPCS/EPCQ SPI NOR > can be operated via the Altera SPI driver, which is currently unused at > all and thus suffering bitrot. The current cleanup is here [3] > NET: Does the SoCDK use EMAC0 or EMAC1 ? I believe we still have this issue > open, I recall Chin was complaining about this. The SoCDK is using EMAC1. BR, Dinh