From: Miquel Raynal <miquel.raynal@bootlin.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] cmd: mtd: solve bad block support in erase command
Date: Thu, 26 Sep 2019 11:42:31 +0200 [thread overview]
Message-ID: <20190926114231.4b3f0a7b@xps13> (raw)
In-Reply-To: <fa7563df3038453da3bda06da03fb51d@SFHDAG6NODE3.st.com>
Hi Patrick,
Patrick DELAUNAY <patrick.delaunay@st.com> wrote on Thu, 26 Sep 2019
09:31:46 +0000:
> Hi Stefan,
>
> > From: Stefan Roese <sr@denx.de>
> > Sent: vendredi 20 septembre 2019 11:20
> >
> > Hi Patrick,
> >
> > On 20.09.19 09:20, Patrick Delaunay wrote:
> > > This patch modify the loop in mtd erase command to erase one by one
> > > the blocks in the requested area.
> > >
> > > It solves issue on "mtd erase" command on nand with existing bad
> > > block, the command is interrupted on the first bad block with the trace:
> > > "Skipping bad block at 0xffffffffffffffff"
> > >
> > > In MTD driver (nand/raw), when a bad block is present on the MTD
> > > device, the erase_op.fail_addr is not updated and we have the initial
> > > value MTD_FAIL_ADDR_UNKNOWN = (ULL)-1.
> >
> > So here is the difference? I remember testing this on a board with SPI NAND and
> > here it worked correctly. But your test case is with RAW NAND?
>
> Yes with RAW nand.
>
> it is the difference the U-Boot code, for SPI nan use:
> int nanddev_mtd_erase()
>
> the fail address is always updated
> => einfo->fail_addr = nanddev_pos_to_offs(nand, &pos);
>
>
> > Do you have a change to also test this on a board with SPI NAND?
>
> I do the test a SPI-NAND today.
>
> The mtd erase command was functional on SPI-ANND before my patch :
> I create 2 bad block manually and they are correctly skipped.
>
> STM32MP> mtd list
> List of MTD devices:
> * spi-nand0
> - device: spi-nand at 0
> - parent: qspi at 58003000
> - driver: spi_nand
> - type: NAND flash
> - block size: 0x20000 bytes
> - min I/O: 0x800 bytes
> - OOB size: 128 bytes
> - OOB available: 62 bytes
> - 0x000000000000-0x000010000000 : "spi-nand0"
> - 0x000000000000-0x000000200000 : "fsbl"
> - 0x000000200000-0x000000400000 : "ssbl1"
> - 0x000000400000-0x000000600000 : "ssbl2"
> - 0x000000600000-0x000010000000 : "UBI"
>
> STM32MP> mtd erase spi-nand0 0x00000000 0x10000000
> Erasing 0x00000000 ... 0x0fffffff (2048 eraseblock(s))
> 0x0fd00000: bad block
> 0x0fd20000: bad block
> attempt to erase a bad/reserved block @fd00000
> Skipping bad block at 0x0fd00000
> attempt to erase a bad/reserved block @fd20000
> Skipping bad block at 0x0fd20000
> 0x0fd00000: bad block
> 0x0fd20000: bad block
>
>
> > Thanks,
> > Stefan
> >
>
> What it is the better solution for you ?
>
> update the MTD command (my patch) or allign the behavior of the 2 MTD devices
> - MTD RAW NAND (nand_base.c:: nand_erase_nand)
> - MTD SPI NAND (core.c:: nanddev_mtd_erase)
Do you think it is easy to make use of nanddev_mtd_erase() from the raw
NAND core? It is probably a little bit more elegant (and efficient)
to do all in one go than iterating over each block (while there is a
helper in the core to do that).
Thanks,
Miquèl
next prev parent reply other threads:[~2019-09-26 9:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-20 7:20 [U-Boot] [PATCH] cmd: mtd: solve bad block support in erase command Patrick Delaunay
2019-09-20 9:20 ` Stefan Roese
2019-09-26 9:31 ` Patrick DELAUNAY
2019-09-26 9:42 ` Miquel Raynal [this message]
2019-09-27 11:23 ` Patrick DELAUNAY
2019-09-29 19:46 ` Miquel Raynal
2019-09-20 9:55 ` Miquel Raynal
2020-01-25 17:08 ` Tom Rini
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=20190926114231.4b3f0a7b@xps13 \
--to=miquel.raynal@bootlin.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.