[U-Boot] [PATCH v2 06/22] Add generic spl infrastructure

[Aneesh V <aneesh@ti.com>]

Hi Wolfgang,

On Monday 16 May 2011 01:18 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1305472900-4004-7-git-send-email-aneesh@ti.com>  you wrote:
>> Define a new type of SPL that is not tied to any particular media.
>> - Create a top level directory 'spl' that has a structure similar
>>    to the existing 'nand_spl'
>> - Make necessary changes to top-level Makefile to build such an spl
>>
>> Rationale for this approach:
>> - There may be SPLs(like the OMAP x-loader) that support booting from
>>    multiple media.
>> - Also, there is no harm in keeping SPLs specific to a particular media
>>    also under this directory. In fact it makes sense to merge all the
>>    different spl directories into this one.
>
> Thanks a lot for addressing this. This is an area that has long been
> on my mind, and I'm really happy to see someone starting to work on
> this.

>
> In addition to booting from different types of media, I see at least
> two more topics that scould and should addressed by this work:
>
> - Get rid of xloader. I cannot see any good reasons why we need it,
>    i. e. which functions if performs that cannot be as well (and
>    eventually even more efficiently) be performed in the U-Boot SPL
>    code.

Indeed, SPL is seen as a replacement for x-loader.

>
> - Become more flexible regarding the kind of second stage payload.
>    It is definitely very powerful and convenient during development to
>    be able to load U-Boot with all it's capabilities as payload of the
>    SPL, but then, except for image size and parameter passing, there is
>    little or no difference to loading a Linux kernel directly instead
>    (and actually this is what most of the super-fast booting approaches
>    do).  If done right, we may even have the flexibility to do both,
>    just by providing different images as payload.
>

How do we handle the differences you just mentioned, namely the size,
parameter passing etc. Maybe, we should have special handling for each
and define config flags like CONFIG_SPL_PAYLOAD_UBOOT,
CONFIG_SPL_PAYLOAD_LINUX_KERNEL etc?

>
>> Signed-off-by: Aneesh V<aneesh@ti.com>
>> ---
>> This patch generates 1 checkpatch warning due to declaration
>> of DECLARE_GLOBAL_DATA_PTR. This is un-avoidable
>> ---
>>   Makefile                           |   24 ++++++++++++++++++++++++
>>   arch/arm/include/asm/global_data.h |    5 +++++
>>   2 files changed, 29 insertions(+), 0 deletions(-)
>
> Here the commit message and the implementation do not agree.  You
> wrote "Create a top level directory 'spl'" - but I don't see any of
> that here?

In this patch, I just created the makefile infrastructure that expects
this directory structure. The files are created later in an OMAP
specific patch.

I think I should have used something like "define a directory
structure" instead of "create".

>
> I think this should be split into a separate patch series, and care
> should be taken that commit messages and implementaiton match.

Ok.

>
> Best regards,
>
> Wolfgang Denk
>