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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Le 30/11/2011 00:40, Simon Glass a ?crit :
> Hi Mike,
>
> On Tue, Nov 29, 2011 at 3:19 PM, Mike Frysinger<vapier@gentoo.org>  wrote:
>> On Tuesday 29 November 2011 17:09:19 Simon Glass wrote:
>>> On Tue, Nov 29, 2011 at 1:40 PM, Mike Frysinger 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 ?
>>>
>>> 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.
>>
>> not sure why this matters ?
>> -mike
>>
>
> Because if they require linking with reloc.o then we will get link
> failures some boards. There is some ugly stuff in SPL which pulls in
> particular files from around U-Boot. Any time I split something out of
> start.S I may break something.

IIRC, SPL never relocates itself -- the goal of SPL is to get some code 
in memory that will just enable RAM, move the rest of U-Boot in, and 
jump to it.

What SPL pulls in is drivers/ functions for console output and access to 
the RAM and main U-Boot image.

Besides, sometimes making boards all fail until they are fixed is a good 
way to manage a change. :)

> Regards,
> Simon

Amicalement,
-- 
Albert.