From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Date: Mon, 27 Jun 2005 10:26:31 -0600 Subject: [U-Boot-Users] Relocation of symbols? In-Reply-To: <20050627134030.85669CD555@atlas.denx.de> References: <3YJEA6HGSNLF3264765ZTQSQYSRNJI43.42bffa31@pc-block> <20050627134030.85669CD555@atlas.denx.de> Message-ID: <528646bc05062709261380120e@mail.gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 6/27/05, Wolfgang Denk wrote: > Dear Andreas, > > in message <3YJEA6HGSNLF3264765ZTQSQYSRNJI43.42bffa31@pc-block> you wrote: > > It's just that not many people really understand all the details how > the relocation works. > I guess you can probably tell GCC to add GOT entries for these > pointers, but I have to admit that I don't know off-hand what's the > most efficient way. > Just to satisfy my curiosity... What is the design decision behind u-boot building as a single relocatable binary (with all the complexities associated with relocation)? As opposed to a a two stage process with a small chunk of bootstrap code encapsulating the main u-boot image. The bootstrap code being linked seperatly from the main image so each image runs in the address space it is linked to. (like a Linux zImage; bootstrap code only responsible for initializing RAM, copying the main image and jumping to it). I can see that a two stage scheme would sidestep the relocation issues mentioned above and should make probing with a debugger simpler. What are the advantages of the single binary approach? Image size perhaps? Cheers, g.