[U-Boot] [SoCFPGA] next steps

[Dinh Nguyen <dinguyen@opensource.altera.com>]

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