[U-Boot] [PATCH 2/2] Changes to move hawkboard to the new infrastructure.

[Sughosh Ganu]

hi Christian,
On Tue Jan 10, 2012 at 09:15:14AM +0100, Christian Riesch wrote:
> Hi Sughosh and Tom,
> 
> On Tuesday, January 10, 2012, Sughosh Ganu <urwithsughosh at gmail.com> wrote:
> > On Mon Jan 09, 2012 at 04:30:56PM -0700, Tom Rini wrote:
> >> On 01/09/2012 11:28 AM, Sughosh Ganu wrote:
> >
> > <snip>
> >
> >> > --- a/arch/arm/cpu/arm926ejs/davinci/Makefile
> >> > +++ b/arch/arm/cpu/arm926ejs/davinci/Makefile
> >> > @@ -38,8 +38,11 @@ COBJS-$(CONFIG_DRIVER_TI_EMAC)   += lxt972.o
> dp83848.o et1011c.o ksz8873.o
> >> >
> >> >  ifdef CONFIG_SPL_BUILD
> >> >  COBJS-y    += spl.o
> >> > -COBJS-$(CONFIG_SOC_DM365)  += dm365_lowlevel.o
> >> > -COBJS-$(CONFIG_SOC_DA8XX)  += da850_lowlevel.o
> >> > +COBJS-$(CONFIG_DM365_SPL)  += dm365_lowlevel.o
> >> > +COBJS-$(CONFIG_DM365_SPL)  += dm365_spl.o
> >> > +COBJS-$(CONFIG_DA850EVM_SPL)       += da850_lowlevel.o
> >> > +COBJS-$(CONFIG_DA850EVM_SPL)       += da850_spl.o
> >> > +COBJS-$(CONFIG_HAWKBOARD_SPL)      += hawkboard_nand_spl.o
> >> >  endif
> >>
> >> CONFIG_SPL_BUILD means we'll only do this on the SPL build, not the
> >> normal build, and we already have symbols for the board and the SoC so
> >> we shouldn't need any new CONFIG symbols here, I'm pretty sure.
> >
> >  The problem here is that both da850evm and hawkboard define the
> >  CONFIG_SOC_DA850, and CONFIG_SOC_DA8XX, as the hawkboard shares code
> >  like pinmux with the da850.
> >
> >  I see a CONFIG_MACH_DAVINCI_* like define in da850evm.h and
> >  hawkboard.h. Should i add a similar define for cam_enc_4xx, and use
> >  these instead.
> 
> Actually the problem is that now we have a board specific file
> (hawkboard_nand_spl.c) in the arch tree. Hawkboard has a DA850 SoC so if we
> have a da850_spl.c hawkboard should either use it as well, or we make the
> *spl.c files board specific and put them into the board tree.

  I'd vote for moving the *spl.c files to their corresponding board
  directories -- infact hawkboard_nand_spl.c was earlier under it's
  board directory. This i think keeps the implementation clean, avoids
  the risk of breakage, and also makes it simpler for any newer board
  in the same soc family migrating to spl, which i think might
  increase the ifdeffery.

  Maybe Tom and Heiko can comment on how it can be done, and i'll take
  the route of the majority :).

-sughosh