* Jon Szymaniak <[email protected]> [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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
