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