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

[Simon Glass]

Hi Albert,

On Wed, Dec 7, 2011 at 12:15 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Le 30/11/2011 00:40, Simon Glass a écrit :
>
>> Hi Mike,
>>
>> On Tue, Nov 29, 2011 at 3:19 PM, Mike Frysinger<vapier at 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. :)

OK it sounds like SPL won't cause problems with this series, good.

Regards,
Simon

>
>> Regards,
>> Simon
>
>
> Amicalement,
> --
> Albert.