Re: 4-Byte addressing issue with IS25WP256D nor flash

[<Tudor.Ambarus@microchip.com>]

Hi, Naga,

On 03/13/2019 12:30 PM, Naga Sureshkumar Relli wrote:
> Hi,
> 
>  
> 
> Currently I am facing an issue with is25wp256d part.
> 
>  1. With u-boot the data integrity is working(erase, write, read and verify)
>     with out any issues
>  2. Don’t probe the qspi at u-boot, and boot Linux and do data integrity
>     (erase, write, read and verify)  and verification done successfully.
>  3. At u-boot, do sf probe and after booting Linux, check for data integrity
> 
>       (erase, write, read and verify) and verify is failing.
> 
> And here are my observations.
> 
> When we do sf probe at u-boot, as per the device size, u-boot is changing
> 
> The flash device addressing mode from 3 byte to 4 byte
> 
>  
> 
> But Linux spi-nor frame work is using 3 byte commands with 3 Byte addressing(because
> 
> Of wrong sfdp information from the is25wp256d part). Hence data verification is failing.
> 
> i.e. sfdp information is saying that it supports only 3-Byte addressing.
> 
> that means, sfdp table for is25wp256d is wrong.
> 

I couldn't find the sfdp table described in the datasheet. I would like to check
if bfpt is not entirely wrong. Can you please hexdump the entire sfdp table?

>  
> 
> Here are the steps that I am running.
> 
> Write data using u-boot  like below
> 
> 1. sf probe 0 0 0
> 
> 2. mw.b 0x100000 11 0x100
> 
> 3. sf write 0x100000 0x0 0x100
> 
> 4. sf read 0x200000 0x0 0x100
> 
> 5. md.b 0x200000 0x100
> 
> 00200000: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 00200010: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 00200020: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 00200030: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 00200040: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 00200050: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 00200060: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 00200070: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 00200080: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 00200090: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 002000a0: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 002000b0: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 002000c0: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 002000d0: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 002000e0: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> 002000f0: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11    ................
> 
> And in Linux just try reading the data,
> 
> root# mtd_debug read /dev/mtd0 0x0 0x100 test.bin
> 
> root#hexdump -C -n 50 test.bin
> 
> 0000000 ffff ffff  1111 1111 1111 1111 1111 1111
> 
> 0000010 1111 1111 1111 1111 1111 1111 1111
> 
> *
> 
> 0000100
> 
>  
> 
> I did the below change in spi-nor.c
> 
> iff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> 
> index 4216ce0..f8603ff 100644
> 
> --- a/drivers/mtd/spi-nor/spi-nor.c
> 
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> 
> @@ -2890,6 +2890,11 @@ static int spi_nor_init_params(struct spi_nor *nor,
> 
>                         nor->addr_width = 0;
> 
>                         nor->mtd.erasesize = 0;
> 
>                 } else {
> 
> +                       if ((JEDEC_MFR(info) == SNOR_MFR_ISSI) &&
Does all issi flashes have this problem?

> 
> +                           params->size >  OFFSET_16_MB) {
> 
> +                               nor->addr_width = 4;
> 
> +                               set_4byte(nor, info, 1);
> 
> +                       }
> 
>                         memcpy(params, &sfdp_params, sizeof(*params));
> 
>                 }
> 
>         }
> 
> Any further suggestions?

We should implement this as a post_bfpt fixup hook.

> 
> I have gone through https://lkml.org/lkml/2018/11/14/599.
> 
> But I didn’t see any further mails after that.

Sorry, I forgot about it :(

Cheers,
ta

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/