Hello Wolfgang, Wolfgang Denk wrote: > Dear Heiko Schocher, > > In message <4ca57762.3000...@denx.de> you wrote: >> 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 ;-) > > I think we have to be careful here. > > Please keep in mind that the with the new setup the relocation address > is not a constant, not even for systems that come with a fixed memroy > configuration. > > If you enable for example the protected RAM feature, the relocation > address will be shifted down by the amount needed for the reserved > PRAM area - which is variable, as it can be set through an > environment variable. > > So assume you have a system with a preloader, and you optimize your > configuration to load U-Bot to the "final" position close to the end > of the RAM. Not the user defines "setenv pram 128" and reboots. > Now U-Boot will try to relocate itself 128 kB down, which pretty > reliably causes an overlap.
Good point ... > Eventually we have to detect such situations and relocate twice then? Hmm.. just an idea: We calculate the relocation address in arch/arm/lib/board.c board_init_f() So, it should be possible to add a check if relocation_address + u-boot_len < TEXT_BASE If this is not the case, we can try to relocate twice ... but this will result in one more copy of u-boot ... ... easier would be, not to use such a setting (relocate address == TEXT_BASE) on a board which uses such features ... 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
