| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <dd6cc84d-7dc3-af55-9177-7930544f0dcf@microchip.com>
Date: Thu, 18 Apr 2019 14:11:10 +0000
From: <Tudor.Ambarus@...rochip.com>
To: <nagasure@...inx.com>, <liu.xiang6@....com.cn>, <vigneshr@...com>
CC: <bbrezillon@...nel.org>, <broonie@...nel.org>, <richard@....at>,
<linux-kernel@...r.kernel.org>, <linux-spi@...r.kernel.org>,
<marek.vasut@...il.com>, <linux-mtd@...ts.infradead.org>,
<nagasuresh12@...il.com>, <dwmw2@...radead.org>,
<michals@...inx.com>
Subject: Re: 4-Byte addressing issue with IS25WP256D nor flash
Hi, Naga,
On 03/19/2019 03:57 PM, Naga Sureshkumar Relli wrote:
> *External E-Mail*
>
> *
> *
>
> Hi Tudor,
>
>
>
>> -----Original Message-----
>
>> From: Tudor.Ambarus@...rochip.com <Tudor.Ambarus@...rochip.com>
>
>> Sent: Monday, March 18, 2019 11:05 AM
>
>> To: Naga Sureshkumar Relli <nagasure@...inx.com>; bbrezillon@...nel.org;
>
>> broonie@...nel.org
>
>> Cc: richard@....at; linux-kernel@...r.kernel.org; linux-spi@...r.kernel.org;
>
>> marek.vasut@...il.com; linux-mtd@...ts.infradead.org; nagasuresh12@...il.com;
>
>> dwmw2@...radead.org; Michal Simek <michals@...inx.com>; liu.xiang6@....com.cn
>
>> Subject: Re: 4-Byte addressing issue with IS25WP256D nor flash
>
>>
>
>> 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?
>
> sfdp header:
>
> 0x53, 0x46, 0x44, 0x50,
SFDP Header: 1st DWORD
>0x6, 0x1,0x1, 0xff,
SFDP Header: 2nd DWORD
Number of Parameter Headers (NPH)=2
>0x0, 0x6, 0x1, 0x10,
JEDEC Flash Parameter Header: 1st DWORD
Parameter Table length: 0x10
>0x30, 0x0, 0x0, 0xff
JEDEC Flash Parameter Header: 2nd DWORD
Parameter Table Pointer
>
>
> Parameter table header
>
> 0x9d, 0x5, 0x1, 0x3, 0x80, 0x0, 0x0, 0x2
is this a vendor table?
> Parameter Table data:
>
dword[1]:
> 0xe5, 0x20, *0xf9*, 0xff,
indeed, A18:A17 is 00b, 3-byte only addressing. A18:A17 should have been of
value 01b.
dword[2]:
> 0xff, 0xff, 0xff, 0xf,
dword[3]:
> 0x44, 0xeb, 0x8, 0x6b,
dword[4]:
> 0x8, 0x3b, 0x80, 0xbb,
dword[5]:
> 0xfe, 0xff, 0xff, 0xff,
dword[6]:
> 0xff, 0xff, 0x0, 0xff,
dword[7]:
> 0xff, 0xff, 0x44, 0xeb,dword[8]:
> 0xc, 0x20, 0xf, 0x52,
^4KB erase ^32KB erase
dword[9]:
> 0x10, 0xd8, 0x0, 0xff,
^64KB erase
dword[10]:
> 0x23, 0x4a, 0xc9, 0x0,
dword[11]:
> 0x82, 0xd8, 0x11, 0xce,
dword[12]:
> 0xcc, 0xcd, 0x68, 0x46,
dword[13]:
> 0x7a, 0x75, 0x7a, 0x75,
dword[14]:
> 0xf7, 0xae, 0xd5, 0x5c,
dword[15]:
> 0x4a, 0x42, 0x2c, 0xff,
dword[16]:
> 0xf0, 0x30, 0xf2, 0xa9
^ xx1x_xxxxb is set, and confirms that the flash supports
dedicated 4-Byte address instruction set.
BFPT looks sane, with the exception of the 3-byte only addressing.
You have the same problem as Liu. Check Liu's patch at
https://patchwork.ozlabs.org/patch/1071453/. Ideally would be to know if these 2
parts are the only ones that have this bug or if there are more. Can you contact
ISSI and ask them which parts are affected? If ISSI will not respond in a
reasonable amount of time, we can update Liu's patch to have a single post_bfpt
function that checks if the flash id corresponds to IS25(WP/LP)256D before
setting addr_width to 4.
Cheers,
ta
>> > 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?
>
> No.
>
>>
>
>> >
>
>> > + 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.
>
> Ok
>
>>
>
>> >
>
>> > 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 :(
>
> No problem and thanks for asking more information.
>
>
>
> Thanks,
>
> Naga Sureshkumar Relli
>
>>
>
>> Cheers,
>
>> ta
>
Powered by blists - more mailing lists