[U-Boot] what are valid formats for initrd image downloaded and used by "bootm"

[Robert P. J. Day]

On Fri, 8 Jul 2016, Wolfgang Denk wrote:

> Dear Robert,
>
> In message <alpine.LFD.2.20.1607080453210.5437 at localhost.localdomain> you wrote:
> >
> >   ok, and one last (admittedly a bit off-topic) followup ...
> > openembedded supplies a class, image_types_uboot.bbclass, that can
> > generate a pile of u-boot related images:
> >
> > IMAGE_TYPES += "ext2.u-boot ext2.gz.u-boot ext2.bz2.u-boot
> >    ext2.lzma.u-boot ext3.gz.u-boot ext4.gz.u-boot cpio.gz.u-boot"
> >
> > if i want an immediately usable initrd i can download and pass off to
> > bootm, i'm assuming i can use any of those "u-boot" suffixed image
> > types, like, say, "cpio.gz.u-boot," which will generate a file with a
> > name like "blahblah...20160708082958.rootfs.cpio.gz.u-boot".
>
> What is your assumption based on?  Just on the suffix ".u-boot"?
>
> >   so more an openembedded question, but am i correct in assuming that
> > any of those OE "u-boot" files are usable as initrds? thanks.
>
> You need to look into the actual recipes to be sure what the ".u-boot"
> means, and how these images are built.
>
> "openembedded-core/meta/classes/image_types_uboot.bbclass" defines
> something like this:
>
> oe_mkimage () {
>     mkimage -A ${UBOOT_ARCH} -O linux -T ramdisk -C $2 -n ${IMAGE_NAME} \
>         -d ${DEPLOY_DIR_IMAGE}/$1 ${DEPLOY_DIR_IMAGE}/$1.u-boot
>     if [ x$3 = x"clean" ]; then
>         rm $1
>     fi
> }
>
> This would indeed mean that ".u-boot" is, from U-Boot's point of
> view, a ramdisk image wrapped with the legacy image header, and as
> such usable with "bootm".

  yup, i just went through most of the above, and built a
*cpio.gz.u-boot format ramdisk, and it works just fine, so i'm happy.
onward ...

rday