From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Johan Jonker <jbx6244@gmail.com>
Cc: richard@nod.at, vigneshr@ti.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v1 2/2] mtd: rawnand: add nand-skip-bbtscan and nand-no-bbm-quirk DT options
Date: Mon, 31 Jul 2023 11:08:45 +0200 [thread overview]
Message-ID: <20230731110845.7b6e52ea@xps-13> (raw)
In-Reply-To: <7448d35b-ce62-7e80-6467-ed929ad6838b@gmail.com>
Hi Richard,
jbx6244@gmail.com wrote on Mon, 17 Jul 2023 12:49:43 +0200:
> On 7/15/23 17:55, Miquel Raynal wrote:
> > Hi Johan,
> >
> > jbx6244@gmail.com wrote on Sat, 15 Jul 2023 12:49:18 +0200:
> >
> >> A NAND chip can contain a different data format then the MTD framework
> >> expects in the erase blocks for the Bad Block Table(BBT).
> >> Result is a failed probe, while nothing wrong with the hardware.
> >> Some MTD flags need to be set to gain access again.
> >>
> >> Skip the automatic BBT scan with the NAND_SKIP_BBTSCAN option
> >> so that the original content is unchanged during the driver probe.
> >> The NAND_NO_BBM_QUIRK option allows us to erase bad blocks with
> >> the nand_erase_nand() function and the flash_erase command.
> >>
> >> Add nand-skip-bbtscan and nand-no-bbm-quirk Device Tree options,
> >> so the user has the "freedom of choice" by neutral
> >> access mode to read and write in whatever format is needed.
> >
>
> > This sounds like a partial solution. How do you handle bad blocks?
>
> Hi Miquel,
>
> See below some Rockchip related links:
>
> The file rk_ftl_arm_v7.S is marked GPL2, so I can freely refer/decode/hack to/in that.
> For rk3066 a closed source piece called usbplug is still needed to program initial U-boot.
> This usbplug contains similar code as in the S file and formats the NAND for FTL.
> U-boot is not small enough yet (WIP if I have the time) to replace that.
> Long story short is that on Rockchip NAND's we can expect pages with various ECC and scrambled/randomized all over the place.
>
> One effect is that when the MTD framework driver is probed a first time the BBT pages don't look what was expected.
> For this first probe to be successful I must be able to turn of the MTD internal BBT scan and then erase/format all blocks except boot blocks of course.
> During this first run bad blocks are handled by/tested/kept track of/set BBM in user space.
> This is not meant as permanent mode.(except maybe if this S file is converted as open source FTL (WIP))
>
> Richard doesn't like module parameters, so I can't simply do modprobe for example in a script.
> After that the whole kernel/MTD must rebooted without these DT options.
Richard, do you think we should support such use case? Any direction
would help.
>
> This patch does make parameters/flags available for all.
> If that is too much freedom to handle I can parse them in the Rockchip driver, let me know.
>
> Linux always gets away with the "it must be generic functionality" excuse.
> In U-boot there is the same driver with little or no interaction with the user, so we must deal with that.
> Please advise how we can solve this in a simple nice automated way.
>
>
> Johan
>
> ===
>
> function FlashSetRandomizer()
> https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/rk_nand/rk_ftl_arm_v7.S#L120
> https://github.com/rockchip-linux/u-boot/blob/next-dev/drivers/rknand/rk_ftl_arm_v7.S#L199
>
> Proof of concept for U-boot:
> [v2,06/11] rockchip: idb: add randomizer option
> http://patchwork.ozlabs.org/project/uboot/patch/0b295d0e-53d6-b35a-3058-861e203b4d83@gmail.com/
>
> >
> >> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> >> ---
> >>
> >> Previous discussion:
> >> [PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
> >> https://lore.kernel.org/linux-mtd/1618382560.2326931.1689261435022.JavaMail.zimbra@nod.at/
> >> ---
> >> drivers/mtd/nand/raw/nand_base.c | 6 ++++++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> >> index a6af521832aa..f0fa5c3519b1 100644
> >> --- a/drivers/mtd/nand/raw/nand_base.c
> >> +++ b/drivers/mtd/nand/raw/nand_base.c
> >> @@ -5521,6 +5521,12 @@ static int rawnand_dt_init(struct nand_chip *chip)
> >> if (of_property_read_bool(dn, "nand-is-boot-medium"))
> >> chip->options |= NAND_IS_BOOT_MEDIUM;
> >>
> >> + if (of_property_read_bool(dn, "nand-no-bbm-quirk"))
> >> + chip->options |= NAND_NO_BBM_QUIRK;
> >> +
> >> + if (of_property_read_bool(dn, "nand-skip-bbtscan"))
> >> + chip->options |= NAND_SKIP_BBTSCAN;
> >> +
> >> if (of_property_read_bool(dn, "nand-on-flash-bbt"))
> >> chip->bbt_options |= NAND_BBT_USE_FLASH;
> >>
> >> --
> >> 2.30.2
> >>
> >
> >
> > Thanks,
> > Miquèl
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Johan Jonker <jbx6244@gmail.com>
Cc: richard@nod.at, vigneshr@ti.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v1 2/2] mtd: rawnand: add nand-skip-bbtscan and nand-no-bbm-quirk DT options
Date: Mon, 31 Jul 2023 11:08:45 +0200 [thread overview]
Message-ID: <20230731110845.7b6e52ea@xps-13> (raw)
In-Reply-To: <7448d35b-ce62-7e80-6467-ed929ad6838b@gmail.com>
Hi Richard,
jbx6244@gmail.com wrote on Mon, 17 Jul 2023 12:49:43 +0200:
> On 7/15/23 17:55, Miquel Raynal wrote:
> > Hi Johan,
> >
> > jbx6244@gmail.com wrote on Sat, 15 Jul 2023 12:49:18 +0200:
> >
> >> A NAND chip can contain a different data format then the MTD framework
> >> expects in the erase blocks for the Bad Block Table(BBT).
> >> Result is a failed probe, while nothing wrong with the hardware.
> >> Some MTD flags need to be set to gain access again.
> >>
> >> Skip the automatic BBT scan with the NAND_SKIP_BBTSCAN option
> >> so that the original content is unchanged during the driver probe.
> >> The NAND_NO_BBM_QUIRK option allows us to erase bad blocks with
> >> the nand_erase_nand() function and the flash_erase command.
> >>
> >> Add nand-skip-bbtscan and nand-no-bbm-quirk Device Tree options,
> >> so the user has the "freedom of choice" by neutral
> >> access mode to read and write in whatever format is needed.
> >
>
> > This sounds like a partial solution. How do you handle bad blocks?
>
> Hi Miquel,
>
> See below some Rockchip related links:
>
> The file rk_ftl_arm_v7.S is marked GPL2, so I can freely refer/decode/hack to/in that.
> For rk3066 a closed source piece called usbplug is still needed to program initial U-boot.
> This usbplug contains similar code as in the S file and formats the NAND for FTL.
> U-boot is not small enough yet (WIP if I have the time) to replace that.
> Long story short is that on Rockchip NAND's we can expect pages with various ECC and scrambled/randomized all over the place.
>
> One effect is that when the MTD framework driver is probed a first time the BBT pages don't look what was expected.
> For this first probe to be successful I must be able to turn of the MTD internal BBT scan and then erase/format all blocks except boot blocks of course.
> During this first run bad blocks are handled by/tested/kept track of/set BBM in user space.
> This is not meant as permanent mode.(except maybe if this S file is converted as open source FTL (WIP))
>
> Richard doesn't like module parameters, so I can't simply do modprobe for example in a script.
> After that the whole kernel/MTD must rebooted without these DT options.
Richard, do you think we should support such use case? Any direction
would help.
>
> This patch does make parameters/flags available for all.
> If that is too much freedom to handle I can parse them in the Rockchip driver, let me know.
>
> Linux always gets away with the "it must be generic functionality" excuse.
> In U-boot there is the same driver with little or no interaction with the user, so we must deal with that.
> Please advise how we can solve this in a simple nice automated way.
>
>
> Johan
>
> ===
>
> function FlashSetRandomizer()
> https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/rk_nand/rk_ftl_arm_v7.S#L120
> https://github.com/rockchip-linux/u-boot/blob/next-dev/drivers/rknand/rk_ftl_arm_v7.S#L199
>
> Proof of concept for U-boot:
> [v2,06/11] rockchip: idb: add randomizer option
> http://patchwork.ozlabs.org/project/uboot/patch/0b295d0e-53d6-b35a-3058-861e203b4d83@gmail.com/
>
> >
> >> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> >> ---
> >>
> >> Previous discussion:
> >> [PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
> >> https://lore.kernel.org/linux-mtd/1618382560.2326931.1689261435022.JavaMail.zimbra@nod.at/
> >> ---
> >> drivers/mtd/nand/raw/nand_base.c | 6 ++++++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> >> index a6af521832aa..f0fa5c3519b1 100644
> >> --- a/drivers/mtd/nand/raw/nand_base.c
> >> +++ b/drivers/mtd/nand/raw/nand_base.c
> >> @@ -5521,6 +5521,12 @@ static int rawnand_dt_init(struct nand_chip *chip)
> >> if (of_property_read_bool(dn, "nand-is-boot-medium"))
> >> chip->options |= NAND_IS_BOOT_MEDIUM;
> >>
> >> + if (of_property_read_bool(dn, "nand-no-bbm-quirk"))
> >> + chip->options |= NAND_NO_BBM_QUIRK;
> >> +
> >> + if (of_property_read_bool(dn, "nand-skip-bbtscan"))
> >> + chip->options |= NAND_SKIP_BBTSCAN;
> >> +
> >> if (of_property_read_bool(dn, "nand-on-flash-bbt"))
> >> chip->bbt_options |= NAND_BBT_USE_FLASH;
> >>
> >> --
> >> 2.30.2
> >>
> >
> >
> > Thanks,
> > Miquèl
Thanks,
Miquèl
next prev parent reply other threads:[~2023-07-31 9:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-15 10:48 [PATCH v1 1/2] dt-bindings: mtd: nand-controller: add nand-skip-bbtscan and nand-no-bbm-quirk DT options Johan Jonker
2023-07-15 10:48 ` Johan Jonker
2023-07-15 10:49 ` [PATCH v1 2/2] mtd: rawnand: " Johan Jonker
2023-07-15 10:49 ` Johan Jonker
2023-07-15 15:55 ` Miquel Raynal
2023-07-15 15:55 ` Miquel Raynal
2023-07-17 10:49 ` Johan Jonker
2023-07-17 10:49 ` Johan Jonker
2023-07-31 9:08 ` Miquel Raynal [this message]
2023-07-31 9:08 ` Miquel Raynal
2023-07-18 15:46 ` [PATCH v1 1/2] dt-bindings: mtd: nand-controller: " Conor Dooley
2023-07-18 15:46 ` Conor Dooley
2023-07-19 19:39 ` Johan Jonker
2023-07-19 19:39 ` Johan Jonker
2023-07-31 9:04 ` Miquel Raynal
2023-07-31 9:04 ` Miquel Raynal
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=20230731110845.7b6e52ea@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jbx6244@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=vigneshr@ti.com \
/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.