From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?QW5kcmVhcyBCaWXDn21hbm4=?= Date: Thu, 22 Sep 2011 09:10:20 +0200 Subject: [U-Boot] [RFC PATCH] arm: provide a CONFIG flag for disabling relocation In-Reply-To: <4E79F37C.3070402@aribaud.net> References: <20110920180959.8008F1208F1E@gemini.denx.de> <4E78E5DE.60300@aribaud.net> <4E79C1B5.7040101@aribaud.net> <4E79C887.6010906@gmail.com> <4E79D27D.30409@aribaud.net> <4E79D91C.8070008@gmail.com> <4E79F37C.3070402@aribaud.net> Message-ID: <4E7ADF5C.2040006@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 Dear Albert, Am Mi 21 Sep 2011 16:23:56 CEST schrieb Albert ARIBAUD: > Le 21/09/2011 14:31, Andreas Bie?mann a ?crit : >> Dear Albert, >> >> Am Mi 21 Sep 2011 14:03:09 CEST schrieb Albert ARIBAUD: >>> Le 21/09/2011 13:20, Andreas Bie?mann a ?crit : >>>> Dear "GROYER, Anthony", >>>> Dear Albert, >>>> >>>> Am Mi 21 Sep 2011 12:51:33 CEST schrieb Albert ARIBAUD: >>>>> Le 21/09/2011 11:29, GROYER, Anthony a ?crit : > Apart from your question (how are the number of registers in ldmia and > stmia speed related to the speed of the copy loop?) there is another > one: how do we handle the fact that the length to copy may not be a > multiple of the ldmia/stmia 'width'? Even in arm926ejs/start.S, two > registers are used, but the alignment for text+data is 4 bytes, not 8. Good point. Well, we could implement some 'rewind' apart from .bss zeroing, if we care about it. I guess this could be done without any impact to copy time, if we really save time by using more regs for ldmia/stmia. But how about reading beyond the _end symbol from flash crossing some border e.g. end of address space, end of flash space ... ? > This did not bite us so far, and should not, since we're going to copy > into the space after .text, which *should* be .bss, which we'll zero > right after. But Murphy's law could hit... > >>> As for r8, it should be preserved as it points to gd, but that is >>> ensured by the C code already IIRC. >> >> We use -ffixed-r8 therefore the compiler takes care for the C part, but >> we need to respect this in asm. > > in arm926ejs/start.S we do. If there are other start.S files where r8 > is trashed, they should be fixed indeed. There should no one else left, my last changeset fixed it globally: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/90010/focus=90013 best regards Andreas Bie?mann