Dear Wolfgang, On Friday 25 March 2011 07:42 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<1301058732-30898-1-git-send-email-ane...@ti.com> you wrote: >> Relocation may not be needed and desirable in many cases: >> * For many boards the amount of SDRAM is fixed. >> So relocation is not needed. > > This is plain wrong. This has been explained a couple of times > before. Please read the archives. >
I read this one: http://tree.celinuxforum.org/pipermail/celinux-dev/2009-December/001916.html I also read again this discussion I had started sometime back: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88067/focus=88262 I don't think any of these features will suffer due to my change. Please note that the memory for pRAM, frame buffer etc would still be allocated at the end of available memory. I am preventing only code relocation. My strategy is to leave enough space before and after the U-boot in the non-relocation case. Before the U-Boot for Linux, after U-boot for stack, heap and all other dynamic needs. Wouldn't that work? Am I missing something? >> * Relocation adds un-necessary additional overhead when >> it's not needed. This delay is singificant on slower >> platforms such as FPGA > > Do you have numbers? How much delay do you see caused by the > relocation of U-Boot? No, I don't have any numbers. In fact, if I enable relocation I get into some issues on the FPGA platform I am working on currently. But that seems to be a problem with the platform (For some reason, it doesn't work well when some code is copied to a new area and executed from there - maybe some issue with the memory model). But the platform is so slow that booting U-boot itself takes couple of minutes. The overhead due to relocation will surely get magnified in such cases. Another problem I have with relocation is that it makes debugging with JTAG debugers more difficult. The addresses of symbols in the ELF target are no longer valid. Of course, you can load the symbols at an offset from the original location. But one has to first enable debug prints, find the relocation offset, use it while loading the symbols before you can do source level debugging. > >> * Many boards have ample memory. So reserving enough memory >> for Linux in the first half is not a challenge even without >> relocation > > You appear not to understand what relocation is needed for. > > > I tend to reject your patch, unless you can come up with really > convincing arguments. Also, your patch should then work for all > boards - not only ARM, but also PowerPC (one of the arguments for > relocation was that we want to unify the code). I am afraid I will not be able to do that for all the archs primarily because I will not be able to test anything other than armv7 and also I do not understand their assembly languages. Sometimes, fixes in relocate_code() will be needed to make sure the special case of relocation offset = 0 works well. I had to do that for armv7(It's part of the SPL series). However, the same principles as in this patch should apply everywhere it shouldn't be very difficult to make it work for any architecture when there is a need. best regards, Aneesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
