All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Longchamp <valentin.longchamp@keymile.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [NAND] fsl_elbc_nand and subpage access
Date: Tue, 19 Nov 2013 17:01:50 +0100	[thread overview]
Message-ID: <528B8B6E.2070506@keymile.com> (raw)

Hello Scott,

For the kmp204x boards, UBI is used to take care of the volumes created and
deleted on our NAND Flash. I am currently using a 3.10 kernel and when UBI
attaches mtd0, this works fine:

> UBI: attaching mtd0 to ubi0
> UBI: scanning is finished
> UBI: attached mtd0 (name "ubi0", size 128 MiB) to ubi0
> UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
> UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
> UBI: VID header offset: 512 (aligned 512), data offset: 2048
> UBI: good PEBs: 1024, bad PEBs: 0, corrupted PEBs: 0
> UBI: user volume: 0, internal volumes: 1, max. volumes count: 128
> UBI: max/mean erase counter: 2/2, WL threshold: 4096, image sequence number: 598317289
> UBI: available PEBs: 980, total reserved PEBs: 44, PEBs reserved for bad PEB handling: 40

It is interesting to notice that with the kernel's MTD subsystem, subpage access
is supported (we don't use HW ECC but SOFT_BCH) and thus the VID header offset
is going to be 512 thanks to this subpage support.

Now, when I try to access the same NAND flash ubi partition in u-boot 2013.10,
this fails:

> => ubi part ubi0
> UBI: attaching mtd1 to ubi0
> UBI: physical eraseblock size:   131072 bytes (128 KiB)
> UBI: logical eraseblock size:    126976 bytes
> UBI: smallest flash I/O unit:    2048
> UBI: VID header offset:          2048 (aligned 2048)
> UBI: data offset:                4096
> UBI error: validate_ec_hdr: bad VID header offset 512, expected 2048
> UBI error: validate_ec_hdr: bad EC header
> UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0
> UBI error: ubi_init: cannot attach mtd1
> UBI error: ubi_init: UBI error: cannot initialize UBI, error -22
> UBI init error 22
> => 

Since u-boot does not support subpage access with the fsl_elbc_nand driver, it
choses a VID offset that is as big as a page and here we have an incompatibility...

I know that I could give an argument to the kernel (ubi.mtd=0,2048) so that it
also ignores the subpages, but that feels like a not optimal workaround (that I
am currently using but I would like to get rid of if), and our other systems
(kirkwood and 83xx based) support NAND subpage access in u-boot nicely.

Is there a reason why fsl_elbc_nand does not allow subpage access in the case of
SOFT_(BCH_)ECC ?

Best Regards

Valentin

             reply	other threads:[~2013-11-19 16:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-19 16:01 Valentin Longchamp [this message]
2013-11-19 23:39 ` [U-Boot] [NAND] fsl_elbc_nand and subpage access Scott Wood

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=528B8B6E.2070506@keymile.com \
    --to=valentin.longchamp@keymile.com \
    --cc=u-boot@lists.denx.de \
    /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.