Add Relocation for ARM Systems

The fundamental problem with the ARM port is that on ARM, U-Boot gets linked to a fixed address in RAM.

We inherited this deficiency from the ARMBoot port - when the old PPCBoot (PowerPC only) got ported to ARM, the developers thought that the whole relocation as implemented in PPCBoot was too complicated and just not worth the effort, so they did what they did. BTW: later, the MIPS port copied the ARM implementation, unfortunately.

The advantage of the PowerPC implementation with relocation is that we can measure the actual size of memory present on the board, and then relocate U-Boot to the very end of the RAM, leaving nearly th whole RAM usable as one big contiguous area for "applications" like loading Linux kernel, ramdisk, etc.

The problem with the ARM implementation is that the link address is fixed, i. e. it cannot be adjusted to varying RAM sizes. If you have a board which can be fit with either 32 or with 64 MB of RAM, you have to link U-Boot so that it sits at the end of the 32 MB area. Which means that on a 64 MB system it will sit right in the middle of the RAM, splitting the RAM in two small chunks. Try to explain to a customer why he has some 60+ MB of free RAM on the system but he still cannot load a 33 MB ramdisk image...

There are more consequences from this design - on PowerPC we can implement "protected RAM", frame buffer memory we can share with Linux, log buffer memory we can share with Linux, etc. - all these need to sit at the end of the available physical RAM. On PowerPC, it goes without saying that all this works perfectly fine with variable RAM sizes (so we can have one U-Boot image working for example with different DIMM modules). On ARM, you have to configure U-Boot for a fixed memory size.

One day, real relocation should be added to ARM,so all these deficiencies can be removed.

-- WolfgangDenk - 12 Oct 2008