2023-07-15 11:09:51

by Johan Jonker

[permalink] [raw]
Subject: [PATCH v1 2/2] mtd: rawnand: add nand-skip-bbtscan and nand-no-bbm-quirk DT options

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.

Signed-off-by: Johan Jonker <[email protected]>
---

Previous discussion:
[PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
https://lore.kernel.org/linux-mtd/[email protected]/
---
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



2023-07-15 16:19:53

by Miquel Raynal

[permalink] [raw]
Subject: Re: [PATCH v1 2/2] mtd: rawnand: add nand-skip-bbtscan and nand-no-bbm-quirk DT options

Hi Johan,

[email protected] 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?

> Signed-off-by: Johan Jonker <[email protected]>
> ---
>
> Previous discussion:
> [PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
> https://lore.kernel.org/linux-mtd/[email protected]/
> ---
> 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

2023-07-17 11:05:36

by Johan Jonker

[permalink] [raw]
Subject: Re: [PATCH v1 2/2] mtd: rawnand: add nand-skip-bbtscan and nand-no-bbm-quirk DT options



On 7/15/23 17:55, Miquel Raynal wrote:
> Hi Johan,
>
> [email protected] 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.

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/[email protected]/

>
>> Signed-off-by: Johan Jonker <[email protected]>
>> ---
>>
>> Previous discussion:
>> [PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
>> https://lore.kernel.org/linux-mtd/[email protected]/
>> ---
>> 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

2023-07-31 09:45:31

by Miquel Raynal

[permalink] [raw]
Subject: Re: [PATCH v1 2/2] mtd: rawnand: add nand-skip-bbtscan and nand-no-bbm-quirk DT options

Hi Richard,

[email protected] wrote on Mon, 17 Jul 2023 12:49:43 +0200:

> On 7/15/23 17:55, Miquel Raynal wrote:
> > Hi Johan,
> >
> > [email protected] 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/[email protected]/
>
> >
> >> Signed-off-by: Johan Jonker <[email protected]>
> >> ---
> >>
> >> Previous discussion:
> >> [PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add skipbbt option
> >> https://lore.kernel.org/linux-mtd/[email protected]/
> >> ---
> >> 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