[U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC

[Michal Simek]

Hi Albert,

On 02/04/2015 11:34 AM, Albert ARIBAUD wrote:
> Hello Michal,
> 
> On Wed, 4 Feb 2015 10:56:02 +0100, Michal Simek
> <michal.simek at xilinx.com> wrote:
>> On 02/04/2015 04:11 AM, Masahiro Yamada wrote:
>>> Hi Michal,
>>>
>>>
>>> On Tue, 3 Feb 2015 10:11:39 +0100
>>> Michal Simek <michal.simek at xilinx.com> wrote:
>>>
>>>> Hi Simon,
>>>>
>>>> On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
>>>>> Hi.
>>>>>
>>>>>
>>>>> On Mon, 2 Feb 2015 16:57:15 -0700
>>>>> Simon Glass <sjg at chromium.org> wrote:
>>>>>
>>>>>> Hi Michal,
>>>>>>
>>>>>> On 2 February 2015 at 08:31, Michal Simek <michal.simek at xilinx.com> wrote:
>>>>>>> Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA
>>>>>>> relocation (mostly only GOT) where functions aray are not
>>>>>>> updated. This patch is fixing function pointers for DM core
>>>>>>> and serial-uclass to ensure that relocated functions are called.
>>>>>>>
>>>>>>> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
>>>>>>> ---
>>>>>>>
>>>>>>>  drivers/core/root.c            | 64 ++++++++++++++++++++++++++++++++++++++++++
>>>>>>>  drivers/serial/serial-uclass.c | 16 +++++++++++
>>>>>>>  2 files changed, 80 insertions(+)
>>>>>>
>>>>>> How long will we have to carry this patch? It seems that if we add any
>>>>>> new driver we will have to add more code like this?
>>>>>
>>>>>
>>>>>
>>>>> This patch is unfortunate.
>>>>> Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
>>>>
>>>> This patch (or similar one) has to be alive when we have platform
>>>> which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot.
>>>> There is an option to move to REL/RELA but the question is if
>>>> all platforms have it/support it. Unfortunately I think that
>>>> it will be in the tree for a long time.
>>>>
>>>>>
>>>>> If we use SPL, we do not have to relocate code, I think.
>>>>
>>>> SPL doesn't have relocation that's why this code is not used there.
>>>>
>>>
>>> It is not what I meant.
>>>
>>>
>>> If SPL can directly load the main u-boot image
>>> to the DRAM address where it is linked,
>>> we do not relocate the code in the main image.
>>
>> Current behavior is that SPL is reading u-boot.img entry point which
>> can be in any location and jump to it and u-boot self relocate to the end of
>> memory.
>> If SPL adds u-boot directly to the location where it should run after relocation
>> then relocation is not needed.
>> To ensure this capability (based on my poor GOT/REL/RELA) experience it means
>> that SPL loads u-boot to that location and patch REL/RELA section based on this location
>> and internal relocation should be skipped.
> 
> IOW, that SPL perform the work of relocate_code() in U-Boot -- at least,
> on ARM, where REL/RELA is used.

Maybe we don't understand each other. SPL is not relocate self to any other location.
It just copies full u-boot to memory and jump to it and then full U-Boot relocate
self to the end of memory.

> 
>> This is definitely doable for REL/RELA case and it can also speedup boot process
> 
> Not sure about the speed-up, but never mind.

What I wanted to describe is that imagine case that SPL will does a little bit more
steps when full u-boot should be loaded. It loads full u-boot to the end of memory
and fix rel/rela section before passing control to it.
IMHO (and not expert) removes one u-boot copy which current full u-boot does.
(On the other hand if you want speedup boot you can boot OS directly).


> 
>> (I don't think there is easy way how to solve this with just GOT relocation because
>> of that MANUAL_RELOC code which is patching arrays with function pointers).
> 
> Even without importing SPL in the equation, switching from GOT to
> REL/RELA has enourmous advantages.

I believe you - I haven't finish this on Microblaze as we talked on IRC some time ago.
I have to do what arm64 is doing in tools/relocate-rela.c.

Thanks,
Michal