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".
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Save yourself! Reboot in 5 seconds!
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
