From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alessandro Rubini Date: Sun, 17 Apr 2011 21:30:39 +0200 Subject: [U-Boot] Question about relocation In-Reply-To: <4DAB301B.3030201@aribaud.net> References: <4DAB301B.3030201@aribaud.net> <4DAB1D92.3080907@aribaud.net> <20110417011939.GA18636@mail.gnudd.com> <20110417175705.GA28484@mail.gnudd.com> Message-ID: <20110417193039.GA29460@mail.gnudd.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de >> Ori, simply, end-to-beginning when moving up. Or always >> end-to-beginning since we are expected to always move up (upper than >> the target address it can't run). > Since the 'issue' is caused by the code assuming one direction, I'd > prefer it not to assume the other now; I prefer choosing > end-to-beginning if target is dest than source, beginning-to-end otherwise. but the calculation is done to move to end of ram, so dest is always higher than source. > Actually no, copying and fixing is not done in a single run. There is > the copying of the text+data+const area, then the fixing which runs > through the relocation table area; they are different. Yes, that's what I meant. It's not a memcpy, you also use the data after the copy so any overlap is an issue, indepentend of the order of copying. >> Or, easier: if we are already high enough to overlap, don't relocate >> at all. If it's acceptable, I'll patch for taht. > But then comes the question of how enough is "high enough". :) If there's no overlap, you can relocate. If the areas overal, you keep the current address which also is "high enough". If you ack (even offlist) I'll submit a patch tomorrow (monday) /alessandro