linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Yegor Yefremov <yegorslists@googlemail.com>
To: Roger Quadros <rogerq@kernel.org>
Cc: linux-mtd@lists.infradead.org,
	Linux-OMAP <linux-omap@vger.kernel.org>,
	 miquel.raynal@bootlin.com
Subject: Re: raw/omap2: erasing issue
Date: Mon, 11 Jul 2022 06:54:33 +0200	[thread overview]
Message-ID: <CAGm1_ksO92fvs8Wsq0oJzqDkGtROh=Be7gDW9NUJtRF3PP9RCw@mail.gmail.com> (raw)
In-Reply-To: <3f04c503-7f48-3c39-083a-aec076706deb@kernel.org>

Hi Roger,

On Sun, Jul 10, 2022 at 8:52 AM Roger Quadros <rogerq@kernel.org> wrote:
>
> Hello Yegor,
>
> On 05/07/2022 17:46, Yegor Yefremov wrote:
> > Hi Roger,
> >
> > On Mon, Jul 4, 2022 at 12:31 PM Yegor Yefremov
> > <yegorslists@googlemail.com> wrote:
> >>
> >> Hi Roger,
> >>
> >> On Mon, Jul 4, 2022 at 12:28 PM Roger Quadros <rogerq@kernel.org> wrote:
> >>>
> >>> Hello Yegor,
> >>>
> >>> On 04/07/2022 14:28, Yegor Yefremov wrote:
> >>>> Hi Roger,
> >>>>
> >>>> On Thu, Jun 30, 2022 at 1:22 PM Roger Quadros <rogerq@kernel.org> wrote:
> >>>>>
> >>>>> Hi Yegor,
> >>>>>llo
> >>>>> On 29/06/2022 17:23, Yegor Yefremov wrote:
> >>>>>> Hi Roger,
> >>>>>>
> >>>>>> On Wed, Jun 29, 2022 at 3:44 PM Roger Quadros <rogerq@kernel.org> wrote:
> >>>>>>>
> >>>>>>> Hi Yegor,
> >>>>>>>
> >>>>>>> On 29/06/2022 14:33, Roger Quadros wrote:
> >>>>>>>> Hi Yegor,
> >>>>>>>>
> >>>>>>>> On 28/06/2022 14:59, Yegor Yefremov wrote:
> >>>>>>>>> On Tue, Jun 28, 2022 at 1:57 PM Yegor Yefremov
> >>>>>>>>> <yegorslists@googlemail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi Roger,
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Jun 28, 2022 at 1:44 PM Roger Quadros <rogerq@kernel.org> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Yegor,
> >>>>>>>>>>>
> >>>>>>>>>>> On 28/06/2022 13:48, Yegor Yefremov wrote:
> >>>>>>>>>>>> Since linux 5.17 I get the following issue when doing ubiformat:
> >>>>>>>>>>>>
> >>>>>>>>>>>> # ubiformat -y /dev/mtd5
> >>>>>>>>>>>> ubiformat: mtd5 (nand), size 265945088 bytes (253.6 MiB), 2029
> >>>>>>>>>>>> eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
> >>>>>>>>>>>> libscan: scanning eraseblock 1097 -- 54 % complete  eth1 timed out to bring up
> >>>>>>>>>>>> libscan: scanning eraseblock 2028 -- 100 % complete
> >>>>>>>>>>>> ubiformat: 2001 eraseblocks have valid erase counter, mean value is 9
> >>>>>>>>>>>> ubiformat: 2 eraseblocks are supposedly empty
> >>>>>>>>>>>> ubiformat: 26 bad eraseblocks found, numbers: 3, 4, 5, 6, 8, 9, 10,
> >>>>>>>>>>>> 11, 13, 14, 15, 16, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30,
> >>>>>>>>>>>> 31, 32
> >>>>>>>>>>>
> >>>>>>>>>>> I'm guessing these bad blocks recently added due to the offending patch?
> >>>>>>>>>>
> >>>>>>>>>> Yes.
> >>>>>>>>>>
> >>>>>>>>>>>> ubiformat: formatting eras[   33.644323] nand: nand_erase_nand:
> >>>>>>>>>>>> attempt to erase a bad block at page 0x00000d40
> >>>>>>>>>>>> ubiformat: formatting eraseblock 28[   33.658809] nand:
> >>>>>>>>>>>> nand_erase_nand: attempt to erase a bad block at page 0x00000d80
> >>>>>>>>>>>> ubiformat: formatting eraseblock 29 --  1 % [   33.674531] nand:
> >>>>>>>>>>>> nand_erase_nand: attempt to erase a bad block at page 0x00000dc0
> >>>>>>>>>>>> ubiformat: formatting eraseblock 30 --  1 % complete [   33.684508]
> >>>>>>>>>>>> nand: nand_erase_nand: attempt to erase a bad block at page 0x00000e00
> >>>>>>>>>>>> ubiformat: formatting eraseblock 34 --  1 % complete  libmtd: error!:
> >>>>>>>>>>>> MEMERASE64 ioctl failed for eraseblock 34 (mtd5)
> >>>>>>>>>>>>         error 5 (Input/output error)
> >>>>>>>>>>>>
> >>>>>>>>>>>> ubiformat: error!: failed to erase eraseblock 34
> >>>>>>>>>>>>            error 5 (Input/output error)
> >>>>>>>>>>>> ubiformat: marking block 34 bad
> >>>>>>>>>>>> ubiformat: formatting eraseblock 35 --  1 % complete  libmtd: error!:
> >>>>>>>>>>>> MEMERASE64 ioctl failed for eraseblock 35 (mtd5)
> >>>>>>>>>>>>         error 5 (Input/output error)
> >>>>>>>>>>>>
> >>>>>>>>>>>> ubiformat: error!: failed to erase eraseblock 35
> >>>>>>>>>>>>            error 5 (Input/output error)
> >>>>>>>>>>>> ubiformat: marking block 35 bad
> >>>>>>>>>>>> ubiformat: formatting eraseblock 36 --  1 % complete  libmtd: error!:
> >>>>>>>>>>>> MEMERASE64 ioctl failed for eraseblock 36 (mtd5)
> >>>>>>>>>>>>         error 5 (Input/output error)
> >>>>>>>>>>>>
> >>>>>>>>>>>> ubiformat: error!: failed to erase eraseblock 36
> >>>>>>>>>>>>            error 5 (Input/output error)
> >>>>>>>>>>>> ubiformat: marking block 36 bad
> >>>>>>>>>>>> ubiformat: formatting eraseblock 37 --  1 % complete  libmtd: error!:
> >>>>>>>>>>>> MEMERASE64 ioctl failed for eraseblock 37 (mtd5)
> >>>>>>>>>>>>         error 5 (Input/output error)
> >>>>>>>>>>>>
> >>>>>>>>>>>> ubiformat: error!: failed to erase eraseblock 37
> >>>>>>>>>>>>            error 5 (Input/output error)
> >>>>>>>>>>>> ubiformat: marking block 37 bad
> >>>>>>>>>>>>
> >>>>>>>>>>>> ubiformat: error!: consecutive bad blocks exceed limit: 4, bad flash?
> >>>>>>>>>>>> # [   36.322563] vwl1271: disabling
> >>>>>>>>>>>>
> >>>>>>>>>>>> git bisect pointed to the following commit:
> >>>>>>>>>>>>
> >>>>>>>>>>>> a9e849efca4f9c7732ea4a81f13ec96208994b22 is the first bad commit
> >>>>>>>>>>>> commit a9e849efca4f9c7732ea4a81f13ec96208994b22
> >>>>>>>>>>>> Author: Roger Quadros <rogerq@kernel.org>
> >>>>>>>>>>>> Date:   Thu Dec 9 11:04:55 2021 +0200
> >>>>>>>>>>>>
> >>>>>>>>>>>>     mtd: rawnand: omap2: move to exec_op interface
> >>>>>>>>>>>>
> >>>>>>>>>>>>     Stop using legacy interface and move to the exec_op interface.
> >>>>>>>>>>>>
> >>>>>>>>>>>>     Signed-off-by: Roger Quadros <rogerq@kernel.org>
> >>>>>>>>>>>>     Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> >>>>>>>>>>>>     Link: https://lore.kernel.org/linux-mtd/20211209090458.24830-4-rogerq@kernel.org
> >>>>>>>>>>>>
> >>>>>>>>>>>> :040000 040000 2341051b8aa8e6b554b8a44d2934f76d1aa460c4
> >>>>>>>>>>>> c1727080ff16c403f4ad5ed840acc90127b632f8 M      drivers
> >>>>>>>>>>>>
> >>>>>>>>>>>> Info to my NAND flash:
> >>>>>>>>>>>>
> >>>>>>>>>>>> [    5.695760] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >>>>>>>>>>>> [    5.702193] nand: Micron MT29F2G08ABAEAWP
> >>>>>>>>>>>> [    5.706356] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> >>>>>>>>>>>> 2048, OOB size: 64
> >>>>>>>>>>>> [    5.714204] nand: using OMAP_ECC_BCH8_CODE_HW ECC scheme
> >>>>>>>>>>>> [    5.719673] 6 cmdlinepart partitions found on MTD device omap2-nand.0
> >>>>>>>>>>>> [    5.726232] Creating 6 MTD partitions on "omap2-nand.0":
> >>>>>>>>>>>> [    5.731594] 0x000000000000-0x000000020000 : "SPL"
> >>>>>>>>>>>> [    5.737788] mtdblock: MTD device 'SPL' is NAND, please consider
> >>>>>>>>>>>> using UBI block devices instead.
> >>>>>>>>>>>> [    5.750113] 0x000000020000-0x000000040000 : "SPL.backup1"
> >>>>>>>>>>>> [    5.756916] mtdblock: MTD device 'SPL.backup1' is NAND, please
> >>>>>>>>>>>> consider using UBI block devices instead.
> >>>>>>>>>>>> [    5.769870] 0x000000040000-0x000000060000 : "SPL.backup2"
> >>>>>>>>>>>> [    5.776695] mtdblock: MTD device 'SPL.backup2' is NAND, please
> >>>>>>>>>>>> consider using UBI block devices instead.
> >>>>>>>>>>>> [    5.789559] 0x000000060000-0x000000080000 : "SPL.backup3"
> >>>>>>>>>>>> [    5.796423] mtdblock: MTD device 'SPL.backup3' is NAND, please
> >>>>>>>>>>>> consider using UBI block devices instead.
> >>>>>>>>>>>> [    5.809341] 0x000000080000-0x000000260000 : "u-boot"
> >>>>>>>>>>>> [    5.816652] mtdblock: MTD device 'u-boot' is NAND, please consider
> >>>>>>>>>>>> using UBI block devices instead.
> >>>>>>>>>>>> [    5.829189] 0x000000260000-0x000010000000 : "UBI"
> >>>>>>>>>>>> [    5.971508] mtdblock: MTD device 'UBI' is NAND, please consider
> >>>>>>>>>>>> using UBI block devices instead.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> What platform are you on?
> >>>>>>>>>>> I do remember testing this on omap3-beagle but it does not use BCH8 ECC scheme.
> >>>>>>>>>>
> >>>>>>>>>> I am on am335x [1]
> >>>>>>>>>>
> >>>>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am335x-baltos-ir5221.dts?h=v5.19-rc4
> >>>>>>>>>
> >>>>>>>>> NAND node definition [1]:
> >>>>>>>>>
> >>>>>>>>> &gpmc {
> >>>>>>>>> pinctrl-names = "default";
> >>>>>>>>> pinctrl-0 = <&nandflash_pins_s0>;
> >>>>>>>>> ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
> >>>>>>>>> status = "okay";
> >>>>>>>>>
> >>>>>>>>> nand@0,0 {
> >>>>>>>>> compatible = "ti,omap2-nand";
> >>>>>>>>> reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
> >>>>>>>>> interrupt-parent = <&gpmc>;
> >>>>>>>>> interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
> >>>>>>>>>     <1 IRQ_TYPE_NONE>; /* termcount */
> >>>>>>>>> rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
> >>>>>>>>> nand-bus-width = <8>;
> >>>>>>>>> ti,nand-ecc-opt = "bch8";
> >>>>>>>>> ti,nand-xfer-type = "polled";
> >>>>>>>>
> >>>>>>>> Could you please change this to "prefetch-polled" and see if it fixes the issue?
> >>>>>>>>
> >>>>>>>
> >>>>>>> I tried to set ti,nand-xfer-type to "polled" on beagle-c4 board and could not reproduce the issue
> >>>>>>> I will need your help please to debug this issue.
> >>>>>>>
> >>>>>>> Could you please apply the below patch on top of commit a9e849efca4f9c7732ea4a81f13ec96208994b22
> >>>>>>> and send me the full kernel log and output of ubiformat command?
> >>>>>>
> >>>>>> I'll post the data later.
> >>>>>>
> >>>>>> The test with the "prefetch-polled" setting looks promising:
> >>>>>>
> >>>>>> 1. ubiformat runs without issues
> >>>>>> 2. I can boot from NAND after "cat MLO > /dev/mtdblock0", etc.
> >>>>>> 3. the kernel can mount UBIFS as rootfs
> >>>>>>
> >>>>>> The only issue I have for now, is that barebox fails to correctly
> >>>>>> mount the first partition (the second with UBIFS rootfs - no problem).
> >>>>>> This is how I write to NAND:
> >>>>>>
> >>>>>> ubiformat -y /dev/mtd5
> >>>>>> ubiattach -p /dev/mtd5
> >>>>>> ubimkvol /dev/ubi0 -N kernel -s 56MiB
> >>>>>> mount -t ubifs ubi0:kernel /mnt
> >>>>>> cp kernel-fit.itb /mnt
> >>>>>> umount /mnt
> >>>>>> ubimkvol /dev/ubi0 -N rootfs -s 180MiB
> >>>>>> ubiupdatevol /dev/ubi0_1 rootfs.ubifs
> >>>>>>
> >>>>>> barebox log:
> >>>>>>
> >>>>>> Booting from NAND
> >>>>>> ubi0: scanning is finished
> >>>>>> ubi0: registering /dev/nand0.UBI.ubi
> >>>>>> ubi0: registering kernel as /dev/nand0.UBI.ubi.kernel
> >>>>>> ubi0: registering rootfs as /dev/nand0.UBI.ubi.rootfs
> >>>>>> ubi0: attached mtd0 (name "nand0.UBI", size 253 MiB) to ubi0
> >>>>>> ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
> >>>>>> ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
> >>>>>> ubi0: VID header offset: 512 (aligned 512), data offset: 2048
> >>>>>> ubi0: good PEBs: 1999, bad PEBs: 30, corrupted PEBs: 0
> >>>>>
> >>>>> Note that we now have 30 bad PEBs. I suppose these are not
> >>>>> really bad and we need to somehow clear bad block status for these.
> >>>>
> >>>> Do you mean using u-boot's "nand scrab"? So far, I didn't found any
> >>>> other option. There are numerous threads both mtd and barebox mailing
> >>>> lists but no implementation.
> >>>>
> >>>> Unfortunately, I don't have the initial BBT info. So let's hope the
> >>>> system can handle this.
> >>>
> >>>
> >>> "nand scrub" will mark all sectors not-bad so doesn't look like the best option.
> >>> I was wondering if there is a better way to selectively mark individual sectors not bad.
> >>
> >> Haven't found anything suitable so far.
> >>
> >>>>
> >>>> Btw, I have applied your debug patch and executed a ubiformat command
> >>>> but the debug messages weren't triggered.
> >>>
> >>> That is because you no longer see errors during nand erase. Did you try
> >>> going back to ti,nand-xfer-type = "polled" ?
> >>
> >> I have applied the patch to a9e849efca4f9c7732ea4a81f13ec96208994b22
> >> and at that time our DTS still has xfer type as "polled" and ubiformat
> >> command failed as expected.
> >
> > I think the issue is solved. The bootloader was actually complaining
> > about the missing zstd support. I could see this with the latest
> > barebox version (2022.06).
> >
> > I've also switched to "ti,nand-xfer-type = "prefetch-dma";" as other DTS do.
>
> Just to conclude,
> 1) Barebox issue was barebox configuration related.
> 2) NAND erase issue was fixed by switching to "prefetch-dma" or "prefetch-polled"

This is correct.

> Does the issue still happen with "polled"? If yes it might be due to too less
> GPMC timing value for Read/Busy signalling.

What particular setting do you mean?

                gpmc,sync-clk-ps = <0>;
                gpmc,cs-on-ns = <0>;
                gpmc,cs-rd-off-ns = <44>;
                gpmc,cs-wr-off-ns = <44>;
                gpmc,adv-on-ns = <6>;
                gpmc,adv-rd-off-ns = <34>;
                gpmc,adv-wr-off-ns = <44>;
                gpmc,we-on-ns = <0>;
                gpmc,we-off-ns = <40>;
                gpmc,oe-on-ns = <0>;
                gpmc,oe-off-ns = <54>;
                gpmc,access-ns = <64>;
                gpmc,rd-cycle-ns = <82>;
                gpmc,wr-cycle-ns = <82>;
                gpmc,bus-turnaround-ns = <0>;
                gpmc,cycle2cycle-delay-ns = <0>;
                gpmc,clk-activation-ns = <0>;
                gpmc,wr-access-ns = <40>;
                gpmc,wr-data-mux-bus-ns = <0>;

I just copied the settings from am335x-evm.dts.

Yegor

> Can you please send a patch with the fix? Thanks!
>
> >
> > Thanks for your help.
> >
> > Yegor
>
> cheers,
> -roger

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2022-07-11  4:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-28 10:48 raw/omap2: erasing issue Yegor Yefremov
2022-06-28 11:44 ` Roger Quadros
2022-06-28 11:57   ` Yegor Yefremov
2022-06-28 11:59     ` Yegor Yefremov
2022-06-28 12:42       ` Roger Quadros
2022-06-29 11:33       ` Roger Quadros
2022-06-29 13:44         ` Roger Quadros
2022-06-29 14:23           ` Yegor Yefremov
2022-06-30 11:22             ` Roger Quadros
2022-07-04  8:58               ` Yegor Yefremov
2022-07-04 10:28                 ` Roger Quadros
2022-07-04 10:31                   ` Yegor Yefremov
2022-07-05 12:16                     ` Yegor Yefremov
2022-07-10  6:52                       ` Roger Quadros
2022-07-11  4:54                         ` Yegor Yefremov [this message]
2022-07-22 11:49                           ` Roger Quadros

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='CAGm1_ksO92fvs8Wsq0oJzqDkGtROh=Be7gDW9NUJtRF3PP9RCw@mail.gmail.com' \
    --to=yegorslists@googlemail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=rogerq@kernel.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).