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

Cédric Le Goater clg at kaod.org
Thu Nov 10 22:55:08 AEDT 2016


On 11/10/2016 01:00 AM, Rick Altherr wrote:
> 
> 
> On Tue, Nov 1, 2016 at 11:31 PM, Joel Stanley <joel at jms.id.au <mailto:joel at jms.id.au>> wrote:
> 
>     Hi Rick,
> 
>     On Wed, Nov 2, 2016 at 3:56 PM, Rick Altherr <raltherr at google.com <mailto:raltherr at google.com>> wrote:
>     > FIT is the modern u-boot native image format for kernels, device trees,
>     > and ramdisks.  Enabling FIT only compiles in support for the image
>     > format.  For these devices, the kernel+dtb and ramdisk are loaded from
>     > separate locations in flash and can be any mix of legacy or FIT images.
>     > When using FIT images, the dtb is stored as a separate entry that
>     > requires CONFIG_OF_LIBFDT to load it into RAM and pass it to the kernel.
>     >
>     > Tested under qemu with both legacy and FIT kernel+dtb images for
>     > palmetto and witherspoon.
> 
>     The changes look good to me.
> 
>     Is the FIT support in v2016.07 new enough for us? Is there any reason
>     to move to a v2016.09 base?
> 
> 
> AFAIK, v2016.07 is new enough.  It certainly includes FIT, FDT loading, and FIT signature checking.
>  
> 
>     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.

C.


More information about the openbmc mailing list