[U-Boot] what are valid formats for initrd image downloaded and used by "bootm"
using yocto project to build artifacts to tftp down to a board for "bootm" command -- what are the valid formats for the "initrd" object that can be recognized by "bootm"? since YP can generate a *ton* of different image types. thanks.
rday
Dear Robert,
In message alpine.LFD.2.20.1607080356390.9216@localhost.localdomain you wrote:
using yocto project to build artifacts to tftp down to a board for "bootm" command -- what are the valid formats for the "initrd" object that can be recognized by "bootm"? since YP can generate a *ton* of different image types. thanks.
"bootm" understands botht he (deprecated) legacy uImage format, plus of course the (preferred) FIT images.
Best regards,
Wolfgang Denk
On Fri, 8 Jul 2016, Wolfgang Denk wrote:
Dear Robert,
In message alpine.LFD.2.20.1607080356390.9216@localhost.localdomain you wrote:
using yocto project to build artifacts to tftp down to a board for "bootm" command -- what are the valid formats for the "initrd" object that can be recognized by "bootm"? since YP can generate a *ton* of different image types. thanks.
"bootm" understands botht he (deprecated) legacy uImage format, plus of course the (preferred) FIT images.
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".
so more an openembedded question, but am i correct in assuming that any of those OE "u-boot" files are usable as initrds? thanks.
rday
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
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
Dear Robert,
In message alpine.LFD.2.20.1607080739350.7066@localhost.localdomain you wrote:
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 ...
For now this is OK, but you might consider switching to FIT images instead. These may look more complicated initially, but they are also much more flexible and allow for things like signed / encrypted images and such...
Best regards,
Wolfgang Denk
On Fri, 8 Jul 2016, Wolfgang Denk wrote:
Dear Robert,
In message alpine.LFD.2.20.1607080739350.7066@localhost.localdomain you wrote:
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 ...
For now this is OK, but you might consider switching to FIT images instead. These may look more complicated initially, but they are also much more flexible and allow for things like signed / encrypted images and such...
already on my list ... in my copious free time. :-(
rday
participants (2)
-
Robert P. J. Day -
Wolfgang Denk