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

[Johan Jonker]

On 7/15/23 17:55, Miquel Raynal wrote:
> Hi Johan,
> 
> jbx6244@xxxxxxxxx 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@xxxxxxxxx/

> 
>> Signed-off-by: Johan Jonker <jbx6244@xxxxxxxxx>
>> ---
>>
>> 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@xxxxxx/
>> ---
>>  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