[PATCH u-boot v2] Enable FIT image support and FDT loading for AST2400/AST2500

[Cédric Le Goater]

>>     It does introduce a warning in a hack we carry for loading the
>>     initramfs, which I think points to a legitimate issue:
>>
>>     common/image.c: In function ‘boot_get_ramdisk’:
>>     common/image.c:1078:4: warning: ‘rd_load’ may be used uninitialized in
>>     this function [-Wmaybe-uninitialized]
>>         memmove ((void *)rd_load, (uchar *)rd_data, rd_len);
>>         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>     This code an Aspeed hack we carry. It is required to copy the
>>     initramfs from flash. Cedric was doing some investigation into why we
>>     need the hack, and it appears to be an upstream bug.
>>
>>     If I read the code correctly, prior to enabling FIT we only accepted
>>     IMAGE_FORMAT_LEGACY. If we move the hack to be part of that case we
>>     should be ok, as we don't need to do the hack when loading from FIT.
>>
>>     Can you try that and add a second patch to your series that moves the hack?
>>
>> Looks like Cedric has a patch that just removes the hack.  I'll look into this more and add it to my series.
> 
> Thanks. tell us how it goes. I think we should be able to remove the hack
> for the ramdisk if we use fdt.

Talking of hacks, I think I have killed this ugly one :

	https://github.com/legoater/u-boot/commit/c17a8847ca6c1fa8b00c16bd78a70a61cc1f0569

Here is my branch based on a v2016.11-rc3+

	https://github.com/legoater/u-boot/commits/v2016.11-aspeed-openbmc

in which I removed the mmu disablement hack. I only tested it on
a AST2500 evb. Could some one (with a flash programmer) confirm
on a board with the same SoC ? 



I think that device tree support will remove the need of ramdisk
hacks. From there, the only (major) problem left is the DRAM 
calibration algo which needs to be rewritten in C. 

Did a wiki update :

	https://github.com/openbmc/u-boot/wiki


Cheers,

C.