From mboxrd@z Thu Jan 1 00:00:00 1970 From: vb Date: Wed, 23 Jul 2008 15:46:54 -0700 Subject: [U-Boot-Users] Changing u-boot relocation scheme In-Reply-To: <4887A6CF.9090404@ge.com> References: <4887A6CF.9090404@ge.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Jerry, thank you for your reply, please see below: On Wed, Jul 23, 2008 at 2:46 PM, Jerry Van Baren wrote: > vb wrote: >> One thing which (IMO anyway) slows down >> its acceptance is the way it handles relocating of itself into an >> arbitrary DRAM area. (Arbitrary meaning that it depends on many >> factors and the exact address can't be assigned ahead of time). > > One thing (IMO anyway) that allows u-boot to Just Work[tm] is that it > relocates itself to the best location available, automatically adjusting to > the probed memory configuration. > > There. Fixed that. ;-) > Sorry, I was not clear - it indeed is a great property of u-boot that it can run on any probed memory config. What I meant to say was that the way it relocates itself is not perfect, and this is why u-boot is not becoming more ubiquitous. >> While this relocation is seamless for u-boot in its released form, it >> becomes a pain each time a module needs to be added (not necessarily >> for following release to the Open Source community, for instance used >> for inhouse installations which include tens of thousand units for >> some companies). If these added modules were not written in position >> independent manner (namely, using structures with multiple stage >> indirect pointers interleaved with data), the effort to make these >> modules work in u-boot is very exhausting. > > You lost me here. > > What is a module? for the purposes of this discussion any .o file or any library of .o files. > How does a it relate to u-boot? I need to extend u-boot with certain functionality available from those modules. > Why does it need to be relocated? because the modules are now part of u-boot, they need to be relocated along with the rest of the image. > Why isn't it written in position independent manner? because they come from different sources, not concerned with u-boot, and just work and need to be ported as is. > How is your relocation methodology going to fixup a module's data > structures? The relocation will adjust only pointers to absolute addresses stored in text/data segments. > What pointers are in your data structures? Why do they need to be > relocated? > in some cases data structures include pointers to other data structures, etc. (This is called 'tree' btw, sorry couldn't resist :-) [snip] > > Gcc supports "proper" relocation, if only we knew how to make it work for > all "reasonable" versions of gcc (and Grant's conclusion is that many > versions of gcc in use today do *not* support the relocation). > > well, if there is a pointer to a data element or to a function stored in a data structure, the .bin image is built and fixed using actual addresses set by the linker. How can gcc help here? > Grant Likely created a patch that did this in the 1.3.0 timeframe, but ended > up reverting it due to toolset problems - it was a patch before its time. > > To read up on the history, follow this search: > > I will read up on this. [snip] >> I made some experiments, and this seems feasible, this could be done >> as a local customization, but I would much prefer to release it to the >> u-boot community and make it part of mainline - will you consider such >> a patch? >> >> Thank you for reading this far, please let me know what you think, > > On one hand, your proposal sounds fairly simple and independent of the gcc > version. The primary cost would be extra build steps > 1) Link at TEXT_BASE > 2) Link at address 0 > 3) Binary diff the two to find addresses that need relocation > 4) Rebuild with the diff table (compile the diff table and relink) > add here inserting code to process the table and modify pointers after relocation (which is already being done, but suing a different algorithm) > On the other hand, the skeptic in me says it ain't that easy. Go ahead, > prove me wrong. ;-) > I am sure it is doable, I am just trying to understand if this would be accepted in general, because it can be done differently depending if one needs to push it upstream or not. cheers, /vb >> Vadim > > Best regards, > gvb >