Generating UBIs containing multiple volumes

Generating UBIs containing multiple volumes

[Jon Szymaniak]

Hi all,

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

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?

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...

Thank you,
Jon

Re: Generating UBIs containing multiple volumes

[Anders Darander]

* Jon Szymaniak <jon.szymaniak@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