From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stoexhubfe02.domain01.net ([83.145.59.141]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1U4nQW-0006nF-7o for openembedded-core@lists.openembedded.org; Mon, 11 Feb 2013 08:03:45 +0100 Received: from localhost (193.41.119.134) by stoexhubfe02.domain01.net (10.12.10.7) with Microsoft SMTP Server id 8.3.279.1; Mon, 11 Feb 2013 07:47:45 +0100 Date: Mon, 11 Feb 2013 07:47:45 +0100 From: Anders Darander To: Message-ID: <20130211064745.GC2424@ad.chargestorm.se> Mail-Followup-To: openembedded-core@lists.openembedded.org References: MIME-Version: 1.0 In-Reply-To: X-Accept-Language: sv, en, de X-GPG-Fingerprint: 5AF0 B2E9 78FE 9D75 D110 6F8F 3E31 84D7 920E 938C X-GPG-Key-Id: 0x920E938C X-GPG-Keyserver: hkp://keys.gnupg.net Organization: ChargeStorm AB User-Agent: Mutt/1.5.20 (2009-12-10) X-GFI-SMTP-Submission: 1 Subject: Re: Generating UBIs containing multiple volumes X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 07:03:46 -0000 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline * Jon Szymaniak [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