On Thu, May 8, 2014 at 10:24 PM, Chin Liang See <cl...@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
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot