No subject

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.

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?

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?

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.

Regards

Charles

--047d7b6dcbf6a9e76404f8b03d47--