Hi Alessandro,
Le 17/04/2011 03:19, Alessandro Rubini a écrit :
Hello. I'm trying to make at91sam9261ek working again, but relocation overlaps the destinatin address.
In this board, u-boot runs already in RAM. This is exactly like the nhk8815 that I ported a few hours ago, but while there the IPL loaded our code at the beginning of RAM, in this case the IPL loaded us already at end of RAM.
Now, this is the printout of the situation:
U-Boot code: 23F00000 -> 23F36EFC BSS: -> 23F78570 monitor len: 00078570 ramsize: 04000000 TLB table at: 23ff0000 Top of RAM usable for U-Boot at: 23ff0000 Reserving 481k for U-Boot at: 23f64000 Reserving 180k for malloc() at: 23f37000 Reserving 24 Bytes for Board Info at: 23f36fe8 Reserving 144 Bytes for Global Data at: 23f36f58 New Stack Pointer is: 23f36f50 RAM Configuration: Bank #0: 20000000 64 MiB relocation Offset is: 00064000Since "tor len: 00078570" and "relocation Offset is: 00064000" the system data-aborts during relocation, as code overwrites relocation tables.
What is the suggested solution? Changing the IPL is not acceptable for me, because it is an external tool used by everyone: everybody knows it loads and runs code at 23f0.0000.
Thanks /alessandro
IIUC, the issue is with the moving of the image. One solution I see, and which is not 100% perfect, would be that the copy code perform either a beginning-to-end copy or an end-to-beginning copy depending on the source and destination addresses and size.
So, when copying say 256K from 0x01000000 to 0x03FC0000, the code could do the copy either way, beginning-to end (0x01000000 to 0x0103FFFF) or end-to-beginning (0x0103FFFF to 0x01000000); but when copying from 0x03FB0000 to 0x03FC0000, only the end-to-beginning copy would be possible.
This still leaves holes in that copying U-Boot from RAM to RAM where the source is *really* near the end might actually trash the copy code itself. Maybe the instruction cache will help, but I won't bet on this without heavy testing.
Amicalement,