[U-Boot] [PATCH v2 1/6] fdt_relocate: fix fdt size and endian bugs

[John Rigby]

On Tue, Oct 12, 2010 at 3:20 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear John Rigby,
>
> In message <1285775292-15060-2-git-send-email-john.rigby at linaro.org> you wrote:
>> Fix two problems in fdt_relocate.
Sorry this should be boot_relocate_fdt
>>
>> First, for the non relocation case current code calculates
>> fdt blob size by subtracting the fdt address from the end
>
> Please consider the non relocation case obsoleted. This is nothing
> that needs to or should have FDT support added.
>
>> of bootmap.  This wrong because it assumes that the fdt_blob
>> is located at the top (high) of the bootmap.  Use the current
>> size plus padding instead.  For example if the blob is at
>> the beginning of bootmap then the calculated size will be
>> the size of the entire bootmapped area.
>>
>> Second, fdt_relocate returns bad size info on little endian
>> platforms because it calls be32_to_cpu on the value returned
>> by fdt_totalsize.  This is wrong because the value returned
>> by fdt_totalsize is already cpu endian.

After changing fdt_relocate to boot_relocate_fdt the commit
message is correct.

>> index 3a2f25e..4aec9d6 100644
>> --- a/common/image.c
>> +++ b/common/image.c
>> @@ -1252,7 +1252,7 @@ int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
>>               *of_size = of_len;
>>       } else {
>>               *of_flat_tree = fdt_blob;
>> -             of_len = (CONFIG_SYS_BOOTMAPSZ + bootmap_base) - (ulong)fdt_blob;
>> +             of_len = *of_size + (unsigned)CONFIG_SYS_FDT_PAD;
>
> Um... what are the implications of this on other architectures?

I believe this bug has never caused anyone problems because
the else has never been reached.