Le 19/11/2010 12:48, Wolfgang Denk a écrit : > Dear Albert ARIBAUD, > > In message<4ce66215.2030...@free.fr> you wrote: >> >> There is a variant of this problem with many ARM boards, those based on >> Marvell SoCs for instance, which have a start address at 0xFFFF0000 -- >> that's a 64K block the usage of which we want to maximize. > > Yes, that's basicly a simialr problem. > >> I had a general solution to this by, in summary, building a linear >> u-boot, then splitting the binary when flashing, and have the copy loop >> in the startup stitch back the parts. However, this solution did not >> work well with relocation, and may not necessarily be applicable to >> non-ARM archs. However, now that we have a (mostly) stabilized >> relocation mechanism, I'll dig again into this solution. > > The problem is that we're now linked for running in flash, so the > linker should be the tool that performs the location of code into the > output image.
Indeed. But then, there's where your code was linked for, where it will relocate to... and where it actually runs. After all, ELF relocation would work equally well whatever the link location. Yes, I know that running code somewhere else than where it was linked for may be difficult. But not necessarily impossible, and I *think* I can find a way. > Best regards, > > Wolfgang Denk Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
