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.
- 12 Oct 2008