Hello Wolfgang,
Wolfgang Denk wrote:
Dear Heiko Schocher,
In message 4CA57762.3000201@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