[U-Boot] Mainline u-boot SPL for socfpga

[Chin Liang See <clsee@altera.com>]

Hi Charles,


On Tue, 2014-05-06 at 12:22 +1200, Charles Manning wrote:
> Hello
> 
> 
> I am trying to understand the state of the socfpga preloader in
> mainline u-boot.
> 
> 
> From what I see, this is broken and perhaps has never worked.
> 
> 
> When I build the code in u-boot-socfpga I get a healthy working
> u-boot-spl.bin of approx 45kbytes.
> 
> 
> When I build the mainline u-boot code I get a broken u-boot-spl.bin of
> approx 3kbytes.
> 
> 
> It seems the mainline u-boot is missing stuff, including the
> all-critical sdram initialisation without which the SPL is useless.
> 
> 
As of now, we have most of the drivers already upstreamed to main line.
The missing piece here are the SDRAM driver. The SDRAM driver poses a
big challenge as its now licensed under BSD-3 clause. I am still working
with legal team to look into potential to make it GPL license.


> So, I have a few related questions:
> 
> 
> 1. The SDRAM init code, like other SocFPGA "hand-off" files is
> generated by the Altera tools. Since it is not hand written, and is
> not compliant with u-boot coding style. Is it more important to
> preserve coding style and have a broken SPL than it is to have a
> working SPL and broken code?
> 

The SDRAM handoff files generated by tools is not compliance as the
original code developer doesn't familiar with open source world. But if
you look into the SDRAM handoff files within rocketboard.org git, the
existing code already updated. I enhanced the code to ensure it meet
with basic coding standard. But further enhancement is needed and
on-going now.

> 
> 2. Is there a practical "half-way" compromise whereby the generated
> code is run through lindent and we just accept that this is as good as
> it gets?
> 
> 
The on-going plan now is to use the enhanced SDRAM handoff file at
rocketboard.org. From there, we want to streamline the driver by
removing unused code. Once its ready, we will upstream this file.


> 3. Can we get some sort of coding style waiver, considering that this
> code is off in a board file and does not impact on anyone working on
> anything other than socfpga (indeed nobody even working on socfpga
> even reads it).
> 
> 
> Clearly significant hand editing generated code makes for a very
> broken workflow, but running it through an automated step like lindent
> is Ok from a workflow point of view.
> 
> 
> Unless this can be resolved we end up with a situation where people
> working on SocFPGA are forced to fork for practical reasons.


I believe it would be tough to get the waiver. Nevertheless, we are
further enhancing the handoff files to a state which is good for
upstreaming. At same time, I am also working with tools team to ensure
all these enhancement is putting back to original code.

Thanks

Chin Liang
> 
> 
> Regards
> 
> 
> Charles
> 
> 
>