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

[Heiko Schocher <hs@denx.de>]

Hello Sughosh, Christian, Tom,

Sughosh Ganu wrote:
> 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@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.

Hmm.. I vote against creating board specific files. I am here in line
with Christians proposal, posted here:

http://lists.denx.de/pipermail/u-boot/2012-January/115166.html

Did this work for the hawkboard? If you do not need some inits, maybe
we add here defines or better make this functions weak, and you can write
board specific functions for this parts. The code in board_init_r()
is only a "selection" from where to load u-boot, which I think in the
long term could be made more common for other SoCs too ... so I want
to prevent to split this in board specific files.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany