All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] UBI Fastmap seems to be broken
Date: Wed, 23 Mar 2016 06:48:45 +0100	[thread overview]
Message-ID: <56F22E3D.7020609@denx.de> (raw)
In-Reply-To: <061AB0A2D7D38B4F9DAEA70B2D72EFD51E60DF@DENBGAT9EJ5MSX.ww902.siemens.net>

Hello Tony,

please add me to Cc, I am little bit under water, and it was just
luck, that I found this EMail ;-)

Am 22.03.2016 um 13:39 schrieb Benzig, Tony:
> Hello together,
>
> I've been working on an AM335x based board with a NAND Flash attached on the GPMI Interface.
> I've been using U-boot v2015.01 with the latest ubi patches. Please don't ask why I'm not using the latest U-Boot Version, it's due to some company conventions.

That was my first thought ;-)

> So my ubi and ubifs drivers are the same as the drivers on the current U-Boot master.

You should also look, that mtd and your nand driver is the same as in
mainline.

> I also added this patch from Heiko Schocher [U-Boot] [PATCH] mtd,  ubi: set free_count to zero before walking through erase list: (http://lists.denx.de/pipermail/u-boot/2016-February/244472.html)
> Without using this patch, ubi is trying to write on pages which are not empty and this will directly lead to unrecoverable ecc errors.

Yes, but I think, this patch needs more investigation why this happens ..

> Nevertheless, ubi is working so far but once I attach my ubi the second time (this will normally happen via fastmap), I can't mount my UBIFS anymore.
> Please see the log below.

Hmm.. I have such tests running for current mainline, they show no
errors ...

> It looks like there is something wrong with the fastmap anchors, because if I disable "CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT" and let Linux do the conversion, everything is fine until
> U-Boot is updating the anchors.

What Linux version do you use. I did the UBI/UBIFS sync with Linux 4.2,
as UBI Fastmap is broken/buggy in Linux version before!

> So, could you help me to analyse this strange behaviour or is it already known?

I am not aware of it ...

> U-Boot# nand erase.part System
> device 0 offset 0xa00000, size 0x1f600000
> Erasing at 0x1ffe0000 -- 100% complete.
> OK
>
> U-Boot# usb start
> (Re)start USB...
> USB0:   scanning bus 0 for devices... 1 USB Device(s) found
>         scanning usb for storage devices... 1 Storage Device(s) found
>
> U-Boot# fatload usb 0:1 0x82000000 update/rootfs.ubi
> 2097152 bytes read in 1300 ms (1.5 MiB/s)
>
> U-Boot# nand write 0x82000000 0xA00000 0x200000
> NAND write: device 0 offset 0xa00000, size 0x200000
> 2097152 bytes written: OK
>
> U-Boot# ubi part System
> ubi0: default fastmap pool size: 200
> ubi0: default fastmap WL pool size: 100
> ubi0: attaching mtd1
> ubi0: scanning is finished
> ubi0: attached mtd1 (name "mtd=2", size 502 MiB)
> ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
> ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
> ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
> ubi0: good PEBs: 4016, bad PEBs: 0, corrupted PEBs: 0
> ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
> ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 2042447318
> ubi0: available PEBs: 3896, total reserved PEBs: 120, PEBs reserved for bad PEB handling: 80
>
> U-Boot# ubifsmount ubi:hwi
> UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "hwi", R/O mode
> UBIFS (ubi0:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
> UBIFS (ubi0:0): FS size: 3047424 bytes (2 MiB, 24 LEBs), journal size 1142785 bytes (1 MiB, 8 LEBs)
> UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
> UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 8db76d20, small LPT model
>
> U-Boot# ubi part System
> Unmounting UBIFS volume hwi!
> ubi0 error: ubi_detach_mtd_dev: ubi0 reference count 1, destroy anyway
> ubi0: detaching mtd1
> ubi0: mtd1 is detached
> ubi0: default fastmap pool size: 200
> ubi0: default fastmap WL pool size: 100
> ubi0: attaching mtd1
> ubi0: attached by fastmap

Here a fastmap is found ... looks good.

> ubi0: fastmap pool size: 200
> ubi0: fastmap WL pool size: 100
> ubi0: attached mtd1 (name "mtd=2", size 502 MiB)
> ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
> ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
> ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
> ubi0: good PEBs: 4016, bad PEBs: 0, corrupted PEBs: 0
> ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
> ubi0: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 2042447318
> ubi0: available PEBs: 3896, total reserved PEBs: 120, PEBs reserved for bad PEB handling: 80

Looks good ...

> U-Boot# ubifsmount ubi:hwi
> UBIFS error (ubi0:0 pid 0): mount_ubifs: can't format empty UBI volume: read-only mount
> Error reading superblock on volume 'ubi:hwi' errno=-30!
> ubifsmount - mount UBIFS volume
>
> Usage:
> ubifsmount <volume-name>
>      - mount 'volume-name' volume

No real idea, whats happen here ... you have to debug into it,
sorry.

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

  reply	other threads:[~2016-03-23  5:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-22 12:39 [U-Boot] UBI Fastmap seems to be broken Benzig, Tony
2016-03-23  5:48 ` Heiko Schocher [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-03-21 16:35 Benzig, Tony

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=56F22E3D.7020609@denx.de \
    --to=hs@denx.de \
    --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.