public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Leo Barnes <barnes.leo@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Flashing UBI-images with nandwrite
Date: Tue, 27 Jul 2010 16:43:14 +0300	[thread overview]
Message-ID: <1280238194.3021.5.camel@localhost.localdomain> (raw)
In-Reply-To: <AANLkTikBRe_bfGC+5c9z6GVNUgPYgEW=d0=x2gaM3X7Z@mail.gmail.com>

On Tue, 2010-07-27 at 14:31 +0200, Leo Barnes wrote:
> Hello!
> 
> I have a question about how ubifs handles completely empty blocks (or
> rather: is it possible to flash ubi images with nandwrite). This is
> the situation:
> 
> I have created a ubifs-image from a root directory using mkfs.ubifs
> and then created a ubi-image containing one dynamic volume based on
> this image with ubinize. The normal way to flash images to my device
> is through a bootloader which I suspect flashes the images with a tool
> similar to nandwrite. This means that if I use the bootloader to flash
> images, all blocks that are not filled with data will be completely
> empty, as opposed to when using ubiformat which flashes in the EC
> header in all blocks, even those containing no data. Should ubifs/ubi
> be able to spot these blocks and assign them to the volume with the
> autoresize flag set? If this should be possible, I might have stumbled
> upon a bug. This is what happens:
> 
> 1. Create an ubifs image with mkfs.ubifs.
> 2. Create an ubi image with ubinize, containing one dynamic volume
> with autoresize set.
> 3. Clear the mtd-partition with flash_eraseall.
> 4. Write image to flash using nandwrite.
> 5. Mount ubifs-volume
> 6. Unmount ubifs-volume. This fails with the following debug info in
> the kernel log:
> 
> <3>[  557.690704] UBI error: ubi_io_read: error -74 while reading
> 126976 bytes from PEB 10:4096, read 32768 bytes
> <7>[  557.690948] UBIFS DBG (pid 415): dbg_check_ltab_lnum: ubi_read
> failed, LEB 8, error -5
> <3>[  557.691131] UBIFS error (pid 415): dbg_check_ltab: failed at LEB 8
> <3>[  557.691253] UBIFS error (pid 415): do_commit: commit failed, error -5
> <4>[  557.691467] UBIFS warning (pid 415): ubifs_ro_mode: switched to
> read-only mode, error -5
> <4>[  557.691680] [<c0330630>] (dump_stack+0x0/0x14) from [<c014030c>]
> (ubifs_ro_mode+0x64/0x74)
> ........
> <4>[  557.708282] [<c00d1e14>] (sys_umount+0x0/0x33c) from
> [<c0023e80>] (ret_fast_syscall+0x0/0x2c)
> <5>[  557.709411] UBIFS: un-mount UBI device 1, volume 0
> <7>[  557.709625] UBIFS DBG (pid 413): ubifs_bg_thread: background
> thread "ubifs_bgt1_0" stops
> <7>[  557.710083] UBIFS DBG (pid 415): ubifs_umount: un-mounting UBI
> device 1, volume 0
> 
> When I flash the same image using ubiformat, everything works fine.
> Should it be possible to flash ubi-images using nandwrite?

I do not recommend nandwrite because it kills erase counters. And I do
not use it. But I think the issues you see are somehow related to ECC -
nandwrite may try to write ECC, or do something which causes ECC errors.
-74 is EBADMSG and indicates an ECC error.

ubiformat does not touch OOB. Try to play with nandwrite's OOB-related
options.
-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

      reply	other threads:[~2010-07-27 13:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-27 12:31 Flashing UBI-images with nandwrite Leo Barnes
2010-07-27 13:43 ` Artem Bityutskiy [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=1280238194.3021.5.camel@localhost.localdomain \
    --to=dedekind1@gmail.com \
    --cc=barnes.leo@gmail.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