From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Wed, 04 Feb 2015 23:08:43 +1100 Subject: [U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC In-Reply-To: <20150204113407.764554dc@lilith> References: <20150203110242.452E.AA925319@jp.panasonic.com> <20150204121153.6F85.AA925319@jp.panasonic.com> <47a1090bf93248349575eba1fc1e3315@BN1AFFO11FD015.protection.gbl> <20150204113407.764554dc@lilith> Message-ID: <54D20BCB.2050805@tss-engineering.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Albert, >>>> >>>>> >>>>> 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. I've always thought the logical approach would be for SPL to calculate where U-Boot would end up in RAM, copy it from wherever (NAND, NOR, MMC, whatever) to the final location, perform the relocation fixups, then jump straight into U-Boot. It's pretty much what the Dynamic Loader does (particularly with address space layout randomization) > > 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. It will save a RAM to RAM copy of u-boot's text and data sections. However, running the relocation code in SPL may be even slower (depending on configuration of caches). >> (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 must admit, I'm really rusty with GOT vs REL/RELA - anyone care to give me a refresher? But yes, only having to deal with REL/RELA sections will make the relocation procedures much simpler Regards, Graeme