From: Roy Spliet <seven@nimrod-online.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] ARM: sunxi: Experiences NAND flash
Date: Mon, 17 Aug 2015 09:30:38 +0100 [thread overview]
Message-ID: <55D19BAE.5000204@nimrod-online.com> (raw)
In-Reply-To: <20150817093411.4ff853c4@bbrezillon>
Hello,
Reply in-line
Op 17-08-15 om 08:34 schreef Boris Brezillon:
> Hi Oliver,
>
> Sorry for the late reply (I was in vacation for the last 2 weeks)
>
> On Tue, 11 Aug 2015 14:16:52 +0200
> Olliver Schinagl <oliver+list@schinagl.nl> wrote:
>
>> Hello everybody,
>>
>> We are working with Boris and Roy's patch series on getting the NAND
>> flash chip working on Olimex OLinuXino Lime2 boards. Initially,
>> everything looks fine, but we noticed that occasionally (after
>> power/cycle or power cut) ubi fails to mount the partition. It is not
>> something easily enough to reproduce, but it has failed on 5 boards out
>> of 30 we have.
> I remember warning you about that problem before: MLC NANDs are not as
> reliable as SLC ones (please read my presentation about MLC support in
> Linux [1]). I also remember recommending using an SLC chip if you were
> tight on time to avoid dealing with all these MLC related problems, but
> you decided to go for the MLC solution.
>
> Back to your problem now, what you're seeing here is probably caused by
> interrupted PROGRAM operations on paired pages (page 17, 18 and 26 to 32
> of my presentation for more information).
In his defence; we looked at it, and from what we could tell it is not
possible to find an affordable SLC chip that the Allwinner A10/A20
BootROM would even boot from. In general, chips below 8K page size
require 64-bit EEC strength to operate, which in turn required more OOB
area than any chip would provide. This limitation is in my opinion a
design fault from AllWinners side and I hope that their future SoCs can
boot with more relaxed EEC settings to facilitate for cheap SLC chips,
but right now there is nothing we can do to change that situation.
>> U-boot reports the following:
>> UBI: default fastmap pool size: 100
>> UBI: default fastmap WL pool size: 25
>> UBI: attaching mtd1 to ubi0
>> UBI: scanning is finished
>> UBI init error 22
>> Error reading superblock on volume 'ubi:boot' errno=-19!
>> ubifsmount - mount UBIFS volume
>>
>> whereas the linux kernel booted from sd card gives:
>> ubiattach /dev/ubi_ctrl -m 0
>> [ 100.560704] ubi0: default fastmap pool size: 8
>> [ 100.565186] ubi0: default fastmap WL pool size: 4
>> [ 100.570100] ubi0: attaching mtd0
>> [ 100.590469] ubi0: scanning is finished
>> [ 100.594732] ubi0 error: ubi_read_volume_table: the layout volume was
>> not found
>> [ 100.602675] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd0,
>> error -22
>> ubiattach: error!: cannot attach mtd0
>> error 22 (Invalid argument)
>>
>> The u-boot version we are using is a few months out of date
>> U-Boot 2015.07-rc2-g2540c39 (Aug 04 2015 - 16:09:02 +0200) Allwinner
>> Technology
>> arm-none-eabi-gcc (4.8.4-1+11-1) 4.8.4 20141219 (release)
>> GNU ld (2.25-5+5+b1) 2.25
>>
>> but the kernel is fairly up to date:
>> 4.2.0-rc4-opinicus-g8ec3671
>>
>>
>> Now I know that the mtd stuff is all very new and all very untested,
>> what I am curious about is a) have other people actually tried the mtd
>> stuff on Allwinner hardware, and b) has anybody encountered this issue
>> as well?
> Yes we did. So far we're using the NAND in SLC mode to address this
> problem. It seems to work, but you also loose half the NAND capacity.
So as requested by someone else: how exactly does that work? Can we just
give your NAND driver a mapping between shared pages and instruct it to
ignore half, or does the driver require some serious patchery?
Cheers,
Roy
>
>> It's not something very easily reproducible (toggling a machine on/off
>> repeatedly did not trigger it yet) but it does happen.
> I managed to reproduce it by faking a power cut directly in the NAND
> core code (by sending a RESET command to the NAND chip in the middle of
> a program operation), and I can confirm SLC mode address the problem.
>
> Anyway, remember that MLC NANDs have other sources of unreliability
> (e.g the unstable bits problem).
>
> Best Regards,
>
> Boris
>
>
> [1]http://events.linuxfoundation.org/sites/events/files/slides/brezillon-mlc-nand_0.pdf
>
next prev parent reply other threads:[~2015-08-17 8:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-11 12:16 [U-Boot] ARM: sunxi: Experiences NAND flash Olliver Schinagl
2015-08-12 13:31 ` [U-Boot] [linux-sunxi] " Olliver Schinagl
2015-08-17 7:48 ` Boris Brezillon
2015-08-17 7:34 ` [U-Boot] " Boris Brezillon
2015-08-17 7:51 ` [U-Boot] [linux-sunxi] " Michal Suchanek
2015-08-17 8:30 ` Roy Spliet [this message]
2015-08-17 9:03 ` [U-Boot] " Boris Brezillon
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=55D19BAE.5000204@nimrod-online.com \
--to=seven@nimrod-online.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox