From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Wed, 4 Feb 2015 11:34:07 +0100 Subject: [U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC In-Reply-To: <47a1090bf93248349575eba1fc1e3315@BN1AFFO11FD015.protection.gbl> References: <20150203110242.452E.AA925319@jp.panasonic.com> <20150204121153.6F85.AA925319@jp.panasonic.com> <47a1090bf93248349575eba1fc1e3315@BN1AFFO11FD015.protection.gbl> Message-ID: <20150204113407.764554dc@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Michal, On Wed, 4 Feb 2015 10:56:02 +0100, Michal Simek wrote: > On 02/04/2015 04:11 AM, Masahiro Yamada wrote: > > Hi Michal, > > > > > > On Tue, 3 Feb 2015 10:11:39 +0100 > > Michal Simek 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 wrote: > >>> > >>>> Hi Michal, > >>>> > >>>> On 2 February 2015 at 08:31, Michal Simek 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 > >>>>> --- > >>>>> > >>>>> 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. > This is definitely doable for REL/RELA case and it can also speedup boot process Not sure about the speed-up, but never mind. > (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. > Thanks, > Michal Amicalement, -- Albert.