[v1,2/2] mtd: rawnand: add nand-skip-bbtscan and nand-no-bbm-quirk DT options

Message ID 2b0dc481-562f-c8df-545e-dcf6548adb07@gmail.com
State New
Headers
Series [v1,1/2] dt-bindings: mtd: nand-controller: add nand-skip-bbtscan and nand-no-bbm-quirk DT options |

Commit Message

Johan Jonker July 15, 2023, 10:49 a.m. UTC
  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 <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(+)

--
2.30.2
  

Comments

Miquel Raynal July 15, 2023, 3:55 p.m. UTC | #1
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?

> 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
  
Johan Jonker July 17, 2023, 10:49 a.m. UTC | #2
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.
 
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
  
Miquel Raynal July 31, 2023, 9:08 a.m. UTC | #3
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
  

Patch

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;