[PATCH] [RFC] tools: fitmount: fuse mount fit images

[Tom Rini]

On Wed, Jun 24, 2020 at 08:20:38AM +0530, selvamuthukumar v wrote:
> On Tue, Jun 23, 2020 at 11:47 PM Tom Rini <trini at konsulko.com> wrote:
> >
> > On Tue, Jun 23, 2020 at 06:01:38PM +0530, selvamuthukumar v wrote:
> > > On Mon, Jun 15, 2020 at 11:15 PM Selva Muthukumar
> > > <v.selvamuthukumar at gmail.com> wrote:
> > > >
> > > > Allow mounting of FIT images. If FIT images are used for firmware upgrade
> > > > from linux, mouting can save space in comparison to using dumpimage.
> > > >
> > >
> > > Any comments on this? Is there any other way to get FIT image
> > > contents, without extracting it?
> >
> > Sorry for the delay.  For your program, there's a few things such as
> > missing license header and being able to opt-in as otherwise we add a
> > new build dependency for everyone.
> >
> > For getting FIT image contents, the existing dumpimage tool handles
> > this.
> >
> dumpimage extracts image contents into new files. Current firmware
> upgrade process in our product is:
> 
> 1. FIT image has kernel and rootfs. Get new FIT image in tmpfs.
> 2. dumpimage to extract the FIT image in tmpfs.
> 3. Write kernel and rootfs in partitions.
> 
> many times step2 fails because there is not enough space in tmpfs. FIT
> image and individual components need to be present in tmpfs. When we
> mount the FIT image, it does not take extra space tmpfs.

Ah, so that's your use-case.  But in this case, couldn't you use a named
pipe instead to stream from the image after step one?  Or add a -q
option to dumpimage (so it doesn't print anything) and use -o
/dev/stdout and pipe that directly to whatever is writing to flash?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200624/73404aa5/attachment.sig>