All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Holger Brunck <holger.brunck@keymile.com>
Cc: Anatolij Gustschin <agust@denx.de>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
Subject: Re: [PATCH 0/7] UBIFS: fix recovery on CFI NOR
Date: Wed, 02 Feb 2011 19:16:11 +0200	[thread overview]
Message-ID: <1296666971.30461.8.camel@localhost> (raw)
In-Reply-To: <4D497663.3070806@keymile.com>

Hi,

On Wed, 2011-02-02 at 16:21 +0100, Holger Brunck wrote:
> I have tested this patches on an ppc82xx and ppc83xx boards with different NOR
> flashes with different writebuffers (64 and 1024 bytes) and check wether I am
> able to mount previous created UBIFS partitions and this works without any
> problems. So the incompatbility seems to be solved. Additionaly I tried it on a
> NAND based system and this runs also without problems.

OK, thanks!

> Another question related to the writebuffer adaptions for UBI. What should be
> done during creation of ubi images on a host system with ubinize if your patches
> find their way in the "standard" UBI/UBIFS code. 

Nothing, when creating images you specify min. I/O size, which is 1 in
case of NOR.

> In the past we had "only" NOR
> flashes with a writebuffer of 64 bytes and we create our ubi images without the
> -m parameter during executing ubinize for the esw image.

No, you always specify 1. Your flash still allows writing 1 byte at a
time, and this is the minimum, so you set -m 1.

64 is the internal detail, the "optimal" write size. UBIFS will
automatically pick it up and will try to write in 64-byte chunks at a
time, but not always, only when it is possible.

>  Now we got a new flash
> with writebuffer = 1024. Whats the way forward in the future? Is it ok to omit
> the "-m" parameter or do we have to create the images with "-m 64" or "-m 1024"?

Similarly, just use -m 1

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

  reply	other threads:[~2011-02-02 17:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-02  8:21 [PATCH 0/7] UBIFS: fix recovery on CFI NOR Artem Bityutskiy
2011-02-02  8:21 ` [PATCH 1/7] UBI: incorporate maximum write size Artem Bityutskiy
2011-02-02  8:21 ` [PATCH 2/7] UBIFS: " Artem Bityutskiy
2011-02-02  8:21 ` [PATCH 3/7] UBIFS: introduce write-buffer size field Artem Bityutskiy
2011-02-02  8:21 ` [PATCH 4/7] UBIFS: use max_write_size for write-buffers Artem Bityutskiy
2011-02-02  8:21 ` [PATCH 6/7] UBIFS: amend commentaries in io.c to match new situation Artem Bityutskiy
2011-02-02  8:21 ` [PATCH 7/7] UBIFS: use max_write_size during recovery Artem Bityutskiy
2011-02-02 12:48 ` [PATCH 0/7] UBIFS: fix recovery on CFI NOR Anatolij Gustschin
2011-02-02 15:21 ` Holger Brunck
2011-02-02 17:16   ` Artem Bityutskiy [this message]
2011-02-03  9:01     ` Holger Brunck

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=1296666971.30461.8.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=agust@denx.de \
    --cc=holger.brunck@keymile.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nvbolhuis@aimvalley.nl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.