[U-Boot] [PATCH v2 09/22] omap4: add spl support for OMAP4 SDP

Aneesh V aneesh at ti.com
Thu May 26 15:25:57 CEST 2011


Hi Wolfgang,

On Tuesday 17 May 2011 06:23 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4DD26B36.4050102 at ti.com>  you wrote:
>>
>> And how do you distinguish between the two cases at the top level
>> Makefile? Using a CONFIG flag or on a per platform basis?
>
> The decision should not be make in the top level makefile, but in
> spl/Makefile.  And this can simply check if a board directory exists
> in the first place.

1. How about the case where there is some board dependent code but also
code shared by the boards(SoC based code). Will we have different
'Makefile's then - one for board and one for SoC. Will we then build
different libraries at each leavel and link them together etc?

2. I think one key thing that you are perhaps missing is that in SPL
the board level Makefile is not just meant for board level files.
Instead it is used to pull together files from all the layers and make
a custom image. IMHO, we will get into un-necessary complexities if we
lose this property of SPL. We may rather spend efforts on making the
regular U-Boot more configurable.

>
>> Why not just invoke the board level Makefile from the top-level
>> Makefile and let it decide about the code-reuse by doing something like
>> I did?
>
> Because then we need board specific directories and board specific
> Makefiles even for those boards where no board specific code exists,
> and all these Makefiles will be semi-identical copies of each other.
>

Considering point 2 above I think this is logical.

The board level Makefile needs to have all the files. For the SoC level
selection of files and the SoC level rules, include the respective *.mk
files. Because in this case there are no board specific files there is
nothing more in the Makefile. Please note that this may not be the case
in general. Most boards, I suspect, may have some board specific files
too.

I wouldn't really consider the include statements as duplication of
code. Instead, that was a way of avoiding duplication of code "given
the constraints of the SPL model".

best regards,
Aneesh

>>> Then we should adapt the directory and Makefile structure and allow
>>> for such common code without need for separate spl/board/
>>> directories.
>>
>> Do you have any specific proposals? I have a feeling that this may get
>> un-necessarily complicated.
>
> Having to maintain multiple copies of identical Makefiles is more
> complicated and error prone in the long run. Let's rather spoend a few
> thoughts initially and solve this problem before it spreads.
>
> Best regards,
>
> Wolfgang Denk
>


More information about the U-Boot mailing list