On Fri, 8 Jul 2016, Wolfgang Denk wrote:
> Dear Robert,
>
> In message <alpine.LFD.2.20.1607080453210.5437@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
