Hello Albert, Albert ARIBAUD wrote: > Le 01/10/2010 07:25, Heiko Schocher a écrit : >> Hello Wolfgang, >> >> Wolfgang Denk wrote: >>> Dear Heiko Schocher, >>> >>> In message<4ca4aeff.3050...@denx.de> you wrote: >>>>> 1. should CONFIG_SKIP_RELOCATE_UBOOT be not defined anymore? >>>> If TEXT_BASE == relocation address it could be defined, >>>> never tested. >>> >>> We should point out that this is only intended (and allowed) for >>> boards where U-Boot gets loaded into RAM by some other means (like a >>> first stage boot loader, say when booting from NAND or SDCard). >>> >>> When booting from NOR or some other persistent memory TEXT_BASE will >>> point to that address range, and then it is obviously impossible to >>> use the same value as relocation address. >> >> Yes, you are right, that just work on boards, which use a preloader ... >> >> bye, >> Heiko > > Actually CONFIG_SKIP_RELICATE_UBOOT should become unneeded once all > boards which use it are made to support relocation, as the code will > always check if it runs at its intended location and relocate only if > needed.
Yes, maybe we come to this solution. > Of course, code which is loaded in RAM at a location different from its > intended one (e.g., during a debugging session) will relocate -- which > raises the interesting question of overlapping source and destination > areas. That might of course be completely solved, if there is room > enough in IRAM (or cache memory) by putting the relocating code there > alongside initial stack, jumping to it from FLASH, and having it jump > back to the RAM location of the rest of the code. But is it worth it? When starting from Flash, this is no problem, because relocation code runs from Flash, and copies u-boot to the relocation address in ram and jumps to it. So no need to copy relocation code. If u-boot starts in RAM, then it is the task from the preloader where it copies u-boot code, and if there is somewhere in IRAM enough room for it, this would be an option. Otherwise it is a problem if relocation results in overlapping source and destination areas ... but you will fast detect this problem, when you see, that u-boot no longer works ;-) bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
