All of lore.kernel.org
 help / color / mirror / Atom feed
From: Holger Brunck <holger.brunck@keymile.com>
To: dedekind1@gmail.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: Thu, 03 Feb 2011 10:01:57 +0100	[thread overview]
Message-ID: <4D4A6F05.30401@keymile.com> (raw)
In-Reply-To: <1296666971.30461.8.camel@localhost>

Hi,

On 02/02/2011 06:16 PM, Artem Bityutskiy wrote:
> 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
> 

ah ok. This was exactly what I figure out from the UBI/UBIFS documentation, but
due to the discussions and patches for the min I/O sizes adaptions I was a
little bit unsure what to do. Thanks for the clarification.

Regards
Holger

      reply	other threads:[~2011-02-03  9:02 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
2011-02-03  9:01     ` Holger Brunck [this message]

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=4D4A6F05.30401@keymile.com \
    --to=holger.brunck@keymile.com \
    --cc=agust@denx.de \
    --cc=dedekind1@gmail.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.