linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: J Barlow <jbarlow@ivl.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: What if the UBI flasher can't skip all-FF pages?
Date: Tue, 11 Jan 2011 11:35:28 +0200	[thread overview]
Message-ID: <1294738528.2266.12.camel@koala> (raw)
In-Reply-To: <loom.20110110T205414-506@post.gmane.org>

Hi,

On Mon, 2011-01-10 at 22:47 +0000, J Barlow wrote:
> Hi everyone,
> 
> I am developing an embedded system with a NAND flash.  We're intending to 
> program all of the NAND flashes in a factory programmer.  I've read "how the UBI 
> flash should work" and I suspect that the UBI flasher doesn't work that way.  
> Specifically, I'm pretty sure it doesn't know how to skip pages containing only 
> FFs.  Unfortunately, the flasher's software is proprietary, not to mention only 
> available in Chinese.  It might well work as expected, but testing this would 
> also be difficult and expensive since the flasher is in a factory in China.

First of all, is this a problem for your flash? If yes, why is it a
problem and why you cannot test this?

The original reason for writing this article was that some flashes have
write non-0xFF ECC to the OOB area when programmed with all 0xFFs. But
this case is easily testable.

> Is there any reasonable way to let UBIFS know all pages have been programmed 
> initially? For example, maybe I could deliberate replace all-FF pages with all-
> 00 pages in the flashed image.  Or will that just cause UBI/UBIFS to find 
> corrupt empty space and fail?  Or perhaps someone could direct me how to make a 
> patch that would help with UBIFS/UBI/ubinize with this specific situation.  It 
> does seem like other people have run into problems with poorly written flashers 
> problem, and in some cases like mine changing the flasher is not an option.

The easiest way is to introduce a bit to UBI EC headers which would mean
"I'm an LEB flashed in production, and empty pages were programmed with
0xFFs, do something". Then for each of such LEBs UBI would do full
re-write and would clean the flag. It is very easy to implement, but
would mean that the first boot basically needs full re-write of the
flashed data, which may be very slow.

With more work and thought it is also possible to invent better
solution, though. But I do not have time to think about this and
describe this right now (vacation) :-)

> Also, if I use a read-only UBIFS in a dynamic UBI volume, will UBIFS ever 
> attempt to double-program an all-FF page?

Depends. But yes, for some of them, not all.

>   I would imagine if I used a read-only 
> UBIFS in a static UBI volume I won't have trouble -- except that I also need to 
> update the firmware.

Yes, in case of R/O usage I do not see issues.

>   Is it possible to ubiupdatevol a static UBI volume, or do 
> I need something more aggressive to modify a static UBI volume?

You can use ubiupdatevol

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

  reply	other threads:[~2011-01-11  9:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-10 22:47 What if the UBI flasher can't skip all-FF pages? J Barlow
2011-01-11  9:35 ` Artem Bityutskiy [this message]
2011-01-13 22:23   ` J Barlow
2011-01-14  5:45     ` Jon Povey
2011-01-18  8:56       ` Artem Bityutskiy
2011-01-18  8:56 ` 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=1294738528.2266.12.camel@koala \
    --to=dedekind1@gmail.com \
    --cc=jbarlow@ivl.com \
    --cc=linux-mtd@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).