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

[Charles Manning]

On Thu, May 8, 2014 at 10:24 PM, Chin Liang See <clsee at altera.com> wrote:

> 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.
>

What is really needed is that the hand-off files are actually generated as
compliant code.

Enhancing and hand-editing then checking in machine generated code is a
broken work-flow because:

1) It has to be redone every time the code is regenerated.
2) There are so many changes that it is impossible to check for errors and
diff for changes.

>
> >
> > 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.
>
> That might work if it is a once-off exercise that places the sdram code
in  arch/arm/cpu/armv7/socfpga

The only stuff that should really be in a board/xxx directory is
board-specific stuff and "tuning files".

In other words:
* sequence.c (a file of over 11000 lines of C code) should be in
arch/.../scofpga
* sequencer_auto_ac_init.c (300 lines of board-specific register config
values) should be in board/.../socfpga


> > 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.
>

Maybe splitting the code better as I suggest above would make this far
simpler.

If the board specific part of the hand-offs is reduced to just header files
and register
config tables, then it is a trivial matter to run them through an extra
**automated** step
to produce a compliant file.

Apart from gaining the mainstreaming, this would  also make it far easier
to create configs
for different boards (eg. sockit board would just become a few hundred
lines of register configs and not 13 thousand lines of code - most of that
duplicated between platforms).


Regards

Charles