[OE-core] Generating UBIs containing multiple volumes
Anders Darander
anders at chargestorm.se
Mon Feb 11 06:47:45 UTC 2013
* Jon Szymaniak <jon.szymaniak at gmail.com> [130209 00:29]:
> I see that the image_types.bbclass's IMAGE_CMD_ubi() does the following:
> 1) Creates a single-volume ubinize.cfg on the fly
> 2) Runs mkfs.ubifs to create the UBIFS image
> 3) Run ubinize to create a UBI image
> However, I'm currently using a two-volume image: one volume for the
> rootfs, and one for "user config" as shown in the below ubinize.cfg.
> I'm considering making some changes to image_types.bbclass to support
> this and was hoping I could get some feedback and advice.
> [rootfs]
> mode=ubi
> image=rootfs.ubifs
> vol_id=0
> vol_size=200MiB
> vol_type=dynamic
> vol_flags=autoresize
> vol_name=rootfs
> [config]
> mode=ubi
> image=config.ubifs
> vol_id=1
> vol_size=8MiB
> vol_type=dynamic
> vol_name=config
Looks good sofar.
> I'd planned to stage my config.ubifs with some sane default files via
> a recipe (e.g., an ubinize invocation in a do_compile). It feels like
> it might be "bad practice" to have a recipe install config.ubifs
> (perhaps a name with a timestamp and then a shorthand symlink, as done
> with existing image files) into $(DEPLOY_DIR_IMAGE}. Any
> recommendations?
Not really concerning this. Though, if your recipe actually creates an
image, then I'd expect to find it it $(DEPLOY_DIR_IMAGE).
I'd probably make sure that the config.ubifs were generated by a special
image-recipe, thus, I'd be leveraging the standar image creation support
for doing this. This image would then have an IMAGE_INSTALL that
included config-$(MACIHINE).bb, or whatever that recipe is called.
> Where would be an appropriate place to keep a custom ubinize.cfg? In
> my case, it should always remain the same for my MACHINE. However, I'm
> not certain if this would be always be the case for other folks...
In my own use-case, where I'm creating a ubi-image that includes
ubi-volumes with a raw kernel in one place, as well as ubi-volumes with
squashfs-rootfs, etc... What I've done is to create my own
image_types_cs.bbclass in my own bsp-layer. This class creates by custom
ubisq-image (which is really an UBI-image more or less as described
above). This solves the issues nicely for my use-case.
Cheers,
Anders
--
Anders Darander
ChargeStorm AB / eStorm AB
More information about the Openembedded-core
mailing list