[U-Boot] [PATCH v5] SPL: Makefile: Build a separate autoconf.mk for SPL

[York Sun <yorksun@freescale.com>]

On 08/19/2013 03:04 PM, Tom Rini wrote:
> On Mon, Aug 19, 2013 at 02:20:25PM -0700, York Sun wrote:
>> On 08/19/2013 12:54 PM, Tom Rini wrote:
>>> On Mon, Aug 19, 2013 at 02:47:53PM -0500, Scott Wood wrote:
>>>> On Mon, 2013-08-19 at 16:14 +0800, ying.zhang at freescale.com wrote:
>>>>> From: Ying Zhang <b40530@freescale.com>
>>>>
>>>> No.  You added one line AFAICT.  Preserve the original author here.
>>>
>>> Indeed.
>>>
>>
>> Do we need Ying to send a new version? We can reset the author to Joe
>> when applying this patch.
>>
>>>>> SPL defines CONFIG_SPL_BUILD but this does not percolate to the autoconf.mk Makefile.
>>>>> As a result the build breaks when CONFIG_SPL_BUILD is used in the board-specific include
>>>>> header file. With this, there is a possibility of having a CONFIG option defined in the
>>>>> header file but not defined in the Makefile causing all kinds of build failure and problems.
>>>>>
>>>>> It also messes things for up, for example, when one might want to undefine options to
>>>>> keep the SPL small and doesn't want to be stuck with the CONFIG options used for U-boot.
>>>>> Lastly, this also avoids defining special CONFIG_SPL_ variables for cases where some
>>>>> options are required in U-boot but not in SPL.
>>>>>
>>>>> We add a spl-autoconf.mk rule that is generated for SPL with the CONFIG_SPL_BUILD flag
>>>>> and conditionally include it for SPL builds.
>>>>>
>>>>> Signed-off-by: Joel A Fernandes <joelagnel@ti.com>
>>>>> Signed-off-by: Ying Zhang <b40530@freescale.com>
>>>>> ---
>>>>> Change from v4:
>>>>> - No change.
>>>>> Change from v3:
>>>>> - No change.
>>>>
>>>> Surely there was *some* change or you wouldn't have reposted...
>>>
>>> v4 was adding Joel's S-o-b line back to the changelog.
>>>
>>
>>
>> I tried to run MAKEALL for arm and powerpc. Powerpc all passed but I am
>> having errors for arm, before applying this patch. I am using Linaro's
>> gcc 4.8.2 for arm. Should I use a different toolchain? I am not used to
>> work on arm platforms.
> 
> That's expected as the Linaro toolchain isn't good for all ARMs.  I'll
> pass this through some testing locally as well.

Any suggestion on cross toolchain for ARM. I want to extend my MAKEALL
coverage, but don't want to deal with too many varieties of toolchains.

York