tree 1a0be5ad9c3dbb4c91648112752729f0b4b5627b
parent c183eea17c38d114a7a72aa0c938f8f3e7149a1d
author John Rigby <john.rigby@linaro.org> 1286999851 -0600
committer Wolfgang Denk <wd@denx.de> 1287434987 +0200

common/image.c fix length calculation in boot_relocate_fdt

boot_relocate_fdt is called on platforms with CONFIG_SYS_BOOTMAPSZ
defined to relocate the device tree blob to be inside the
boot map area between bootmap_base and bootmap_base+CONFIG_SYS_BOOTMAPSZ.

For the case where the blob needs to be relocated, space is
allocated inside the bootmap by calling lmb_alloc_base with
size passed in plus some padding:

    of_len = *of_size + CONFIG_SYS_FDT_PAD;

For the case where the blob is already inside the bounds of the boot map
area, lmb_reserve is called to reserve the the space where the blob is
already residing.  The calculation for this case is currently:

    of_len = (CONFIG_SYS_BOOTMAPSZ + bootmap_base) - (ulong)fdt_blob;

This is wrong because it reserves all the space in the boot map area
from the blob to the end ignoring completely the actual size. The
worst case is where the blob is at the beginning and the entire boot map
area get reserved. Fix this by changing the length calculation to this:

    of_len = *of_size + CONFIG_SYS_FDT_PAD;

This bug has likely never manifested itself because bootm has never
been called with the fdt blob already in the bootmap area.  In my
testing on an OMAP3 beagle board I initially worked around the bug
by simply moving the initial location of the fdt blob.  I have tested
with the new calculation with the fdt blob both inside and outside
the boot map area.

Signed-off-by: John Rigby <john.rigby@linaro.org>