public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Nancy <nancydreaming@gmail.com>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: ubifs image file confusion!
Date: Wed, 14 May 2008 16:20:00 +0300	[thread overview]
Message-ID: <1210771200.5708.50.camel@sauron> (raw)
In-Reply-To: <bae050c10805130541w132a1757paea415f5564b23ec@mail.gmail.com>

On Tue, 2008-05-13 at 20:41 +0800, Nancy wrote:
>    Cause I was writing ubi-util, sure I show this issue at UBI standpoint.
If you want me to understand you and properly answer, you should try to
formulate things better. I understand language difficulties and this is
all right. I just ask you to try better, may be re-reading what you have
composed and trying imagine me reading your mail and imagine which part
could be not very clear for me.

>    OK, what mkfs.ubifs for? generate image file used by ubiupdatevol.
OK.

> It should contain the necessary data. What is necessary data? at least
> the data should be writen down on the Nand flash. On the standpoint of
> UBI, those data should be mapped.  It does not make sense to contain
> data(LEBs which contents are all 0xFF).
OK.

>  ubiupdatevol have to play a
> trick to avoid writing those 0xFF to Nand.
OK.

>    As I fool understand which I have plase after that mail:
Cannot parse this sentence, sorry.

> > >        #ubiupdatevol /dev/ubi0_0 ubifs.img   also write the unmapped
> > > LEBs to Nand flash.
> > It does not write them, but it creates them if the image size is less
> > then amount of space on the volume. What else do you expect?
>    I do not mean that part of 0xFF.  I mean the unmapped part in the image file.
Cannot understand what we are talking about here. What
'ubiupdatevol /dev/ubi0_0 ubifs.img' doing is:
1. Wipes out whole volume ubi0_0 which technically means unmapping all
LEBs.
2. Puts date from ubifs.img to the volume, starting from LEB 0.
3. If the ubifs.img file is less than the ubi0_0 volume, some amount of
LEBs at the end will be unmapped.


> pls:
>       1. ubinize tool do not check whether vol_id or vol_name's
> uniqueness which may cause unexpected error.

OK, will be fixed but a bit later.

>       2. ubinize tool's volume size check do not aligned to LEB size.
Cannot parse this.

> I can't use an image file which taken up of its all volume space.
> eg. LEB size =258048  , .cfg defined vol size = 100MiB ,
> vfat.img(407LEBs)     fail
> it say something like the image file size exceed the volume size. I'm
> home now, can't plase the original error message here. sorry.
Sorry, do not understand this.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

  reply	other threads:[~2008-05-14 13:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-08  9:17 ubifs image file confusion! Nancy
2008-05-08  9:56 ` Nancy
2008-05-14 13:23   ` Artem Bityutskiy
2008-05-08 10:48 ` Artem Bityutskiy
2008-05-09  7:05   ` Nancy
2008-05-10  4:20     ` Nancy
2008-05-10  7:31       ` Nancy
2008-05-13  9:48         ` Artem Bityutskiy
2008-05-13 12:52           ` Nancy
2008-05-14 13:45             ` Artem Bityutskiy
2008-05-15  4:06               ` Nancy
2008-05-13  9:44       ` Artem Bityutskiy
2008-05-13 12:41         ` Nancy
2008-05-14 13:20           ` Artem Bityutskiy [this message]
2008-05-15  3:18             ` Nancy
2008-07-08 10:45             ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1210771200.5708.50.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nancydreaming@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox