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.si...@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.si...@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 <s...@chromium.org> wrote: >>>>> >>>>>> Hi Michal, >>>>>> >>>>>> On 2 February 2015 at 08:31, Michal Simek <michal.si...@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.si...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
