[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