Jerry, thank you for your reply, please see below: On Wed, Jul 23, 2008 at 2:46 PM, Jerry Van Baren <[EMAIL PROTECTED]> 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). > <http://article.gmane.org/gmane.comp.boot-loaders.u-boot/36343/> > 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: > <http://search.gmane.org/?query=relocation&author=grant+likely&group=gmane.comp.boot-loaders.u-boot&sort=date&DEFAULTOP=and&xP=Zreloc%09Zchang%09Zgrant%09Zlike&xFILTERS=Gcomp.boot-loaders.u-boot---A> > 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 > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
