>> 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
