[U-Boot] [RFC PATCH 1/7] reboard: define CONFIG_SYS_LEGACY_BOARD everywhere

[Aneesh V <aneesh@ti.com>]

Simon,

On Wednesday 30 November 2011 03:39 AM, Simon Glass wrote:
> +omap, samsung, imx maintainers
>
> Hi Mike,
>
> On Tue, Nov 29, 2011 at 1:40 PM, Mike Frysinger<vapier@gentoo.org>  wrote:
>> On Tuesday 29 November 2011 15:08:09 Simon Glass wrote:
>>> On Mon, Nov 28, 2011 at 7:11 PM, Mike Frysinger wrote:
>>>> On Monday 21 November 2011 18:57:54 Simon Glass wrote:
>>>>> We are introducing a new unified board setup and we want this to
>>>>> be the default. So we need to opt all architectures out first.
>>>>
>>>> the define says "BOARD", so shouldn't it be in board configs ?  we can do
>>>> that easily: add it to include/config_defaults.h.  then boards that opt
>>>> into it will #undef it in their own configs.
>>>
>>> Thanks for looking at this.
>>>
>>> I see this as an architecture feature - perhaps a rename to something
>>> like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving
>>> boards over one at a time, or having boards for a particular
>>> architecture that still do things the old way - it just increases
>>> maintenance and means that my eventual patch to remove
>>> arch/xxx/lib/board.c cannot be applied.
>>>
>>> My idea for this CONFIG is purely as a temporary measure before boards
>>> more over to the generic approach.
>>
>> how about we have the reloc code live in lib/reloc/ and be controlled by
>> CONFIG_LEGACY_ARCH_RELOC ?
>> -mike
>>
>
> Yes I can do that.
>
> My only concern is that if something like SPL needs to keep all the
> early code at the start of the image. I personally don't like the
> current method for doing that (would prefer a distinctive .text.early
> section name) and I don't believe that any SPL implementation actually
> relocates itself.

OMAP SPL doesn't relocate itself. Neither does it have any restriction
on the position of early code in the image.

best regards,
Aneesh