[U-Boot] [PATCH v2 2/6] reboard: define CONFIG_SYS_SKIP_RELOC for all archs

Simon Glass sjg at chromium.org
Mon Dec 12 06:06:13 CET 2011


Hi Albert,

On Sun, Dec 11, 2011 at 6:57 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Le 10/12/2011 20:16, Simon Glass a écrit :
>
>> We are introducing a new generic relocation features and we want this to
>> be the default. So we need to opt all architectures out first. Some may
>> never have relocation, but those that do will eventually move over to
>> this generic relocation framework.
>>
>> This is part of the unified board effort, but since we are only dealing
>> with relocation in this series, CONFIG_SYS_SKIP_RELOC is more appropriate
>> than CONFIG_SYS_LEGACY_BOARD.
>
>
> I'm afraid I haven't made myself clear on CONFIG_SYS_SKIP_RELOC. I did not
> mean it to be an 'old vs new reloc' choice mechanism; I mean it to be the
> controlling option for whether relocation happens at all or not.
>
> I want a relocation skip option, because it is useful for boards which, for
> any reason, know that they are already residing at the Right Address(tm).
>
> As far as an option to switch from old to new relocation... If there is a
> consensus from all custodians that all arches should move to generic
> relocation, then I think we should avoid allowing the older mechanism to
> persist at all.

OK I see. That is a different thing to this patch. So what should I
call CONFIG_SYS_SKIP_RELOC? Should it be renamed to
CONFIG_SYS_LEGACY_RELOC?

With what you are looking for, there was a patch on the list some time
ago which disables relocation under CONFIG control. From memory it
received a cool reception. IMO there is value in it, but this again is
a separate patch. There are three parts to relocate_code():

- copy the code
- relocate the code
- zero the BSS

While the first two can be skipped if the code doesn't need to move,
the last must always be done.

Regards,
Simon

>
> Amicalement,
> --
> Albert.

Regards,
Simon


More information about the U-Boot mailing list