[meta-freescale] Improving SD-Card images

Maciek Borzecki maciej.borzecki at open-rnd.pl
Tue Jul 22 00:37:27 PDT 2014


On wto, 2014-07-22 at 09:09 +0200, Jens Rehsack wrote:
> Am 22.07.2014 um 08:37 schrieb Maciek Borzecki <maciej.borzecki at open-rnd.pl>:
> 
> > On wto, 2014-07-22 at 07:16 +0200, Jens Rehsack wrote:
> >> Am 21.07.2014 um 16:50 schrieb Otavio Salvador <otavio at ossystems.com.br>:
> >> 
> >>> Hello,
> >>> 
> >>> On Sun, Jul 20, 2014 at 8:13 AM, maciej.borzecki at open-rnd.pl
> >>> <maciej.borzecki at open-rnd.pl> wrote:
> >>>>> Dnia 19 lipiec 2014 o 16:50 Jens Rehsack <rehsack at gmail.com> napisał(a):
> >>>>> the options of meta-fsl-arm/classes/image_types_fsl.bbclass to generate
> >>>>> sdcards are somehow limited :)
> >>>>> 
> >>>>> For the final release we'd like to have following partitions:
> >>>>> 1) boot (ext2, fat?)
> >>>>> 2) prod-root (squashfs)
> >>>>> 3) recovery-root (squashfs)
> >>>>> 4) volatile (ext[34]?)
> >>>>> 5) changes (unionfs over 2)
> >>>>> 
> >>>>> Looks as if image_types_fsl.bbclass would need rework to support >2
> >>>>> partition, but that's just coding.
> >>>> 
> >>>> Have you considered wic? I've posted a patch that adds building of SD card
> >>>> image for BBB:
> >>>> http://article.gmane.org/gmane.linux.embedded.yocto.meta-ti/4171 also
> >>>> meta-ti have already dumped their
> >>>> sdimg bbclass in favor of wic. Not saying that meta-fsl should do the same,
> >>>> just pointing out that there may
> >>>> be some room for unification.
> >>> ...
> >>> 
> >>> This is the long-term goal for sure.
> >>> 
> >>> I have worked with Tom in extending 'wic' to have the plugin system
> >>> you used to enable BBB to generate the image. I also want to try to
> >>> leverage the U-Boot support backend so we can avoid a lot of
> >>> custom-made recipes and duplication.
> >>> 
> >>> I wasn't aware of your patch (thanks), I will look at it next week ...
> >> 
> >> But beside of unifying image creation - which is of course a great step
> >> for both, anyone who can give me a hint where to look for 2 independent
> >> filesystems being created in one target (foo-image)?.
> > 
> > This should help:
> > http://article.gmane.org/gmane.linux.embedded.yocto.meta-ti/4185
> > 
> > You'll also need these patches:
> > http://article.gmane.org/gmane.comp.handhelds.openembedded.core/53449
> > http://article.gmane.org/gmane.comp.handhelds.openembedded.core/53422
> 
> That's regarding how to put more partitions/filesystems in one image, not
> how to built a recovery-rootfs, isn't it?
That's right.

> 
> > Then, the kickstart file is as follows:
> > # vfat boot partition
> > part --source beaglebonebootimg --ondisk mmcblk0p --fstype=vfat --label boot --active --align 1024 --size 10
> > # root filesystem
> > part / --source rootfs --ondisk mmcblk0p --fstype=ext3 --label root --align 1024
> > # data partition
> > part /media/data --ondisk mmcblk0p --fstype=vfat --label data --align 1024 --size 100 --fsoptions sync
> > 
> > 3 partitions are defined in the file:
> > - vfat, built by beaglebonebootimg source plugin (see first patch for
> >  reference on what the plugin does)
> > - 2nd partition (ext3), built by rootfs plugin (contents of
> >  IMAGE_ROOTFS)
> > - 3rd partition (vfat, 100MB, mounted with sync), empty partition,
> >  automatically added to fstab
> > 
> > Hope this clears things up a bit.
> 
> Not really - I'd like to know how to get 
Having spent roughly 3 days with wic code, I'll try to point out what's
missing.

> # vfat boot partition
> part --source uboot-imx-img --ondisk mmcblk0 --fstype=vfat --active --align 1024 --size 10
Source pluging for building parition with uboot-imx. My original though
was that it would be nice to have a general plugin that covers this, at
least partially and only for u-boot. Now, I'm not sure if it's right
approach. The beaglebone code that I posted has only one BBB specific
step, which is copying over MLO. 

> # root-fs
> part / --source rootfs --ondisk mmcblk0 --fstype=squashfs --label root --align 1024
squashfs is not supported, needs adding
> # recovery-root-fs
> part /recovery --source recoverfs --ondisk mmcblk0 --fstype=squashfs --label root --align 1024
> # data/tmp partition
> part /var/tmp --ondisk mmcblk0p --fstype=ext3 --label data --align 1024 --size 1024 --fsoptions sync
> # union-fs for root-fs changes - howto will come later
> part / --ondisk mmcblk0p --fstype=unionfs --label change --align 1024 --size 1536 --fsoptions sync
Current code assumes that any entry listed in kickstart corresponds to a
physical partition. In this case, there is no physical partition right?
I'd say that unionfs entry should not be listed here. Maybe Otavio can
comment on this this.

> 
> And the crucial question is: where does the recoverfs filesystem image comes from, when rootfs is generated magically by image.bbclass?
I'd say another class, perhaps extending image. You'd basically want a
subset of packages/files that end up in rootfs.



-- 
Maciej Borzęcki
Senior Software Developer at Open-RnD Sp. z o.o., Poland
www.open-rnd.pl
mobile: +48 889 117 365, fax: +48 42 657 9079

Niniejsza wiadomość wraz z załącznikami może zawierać chronione prawem
lub poufne informacje i została wysłana wyłącznie do wiadomości i
użytku osób, do których została zaadresowana. Jeśli wiadomość została
otrzymana przypadkowo zabrania się jej kopiowania lub rozsyłania do
osób trzecich. W takim przypadku uprasza się o natychmiastowe
zniszczenie wiadomości oraz poinformowanie nadawcy o zaistniałej
sytuacji za pomocą wiadomości zwrotnej. Dziękujemy.

This message, including any attachments hereto, may contain privileged
or confidential information and is sent solely for the attention and
use of the intended addressee(s). If you are not an intended addressee,
you may neither use this message nor copy or deliver it to anyone. In
such case, you should immediately destroy this message and kindly notify
the sender by reply email. Thank you.




More information about the meta-freescale mailing list