linux-kernel - RE: [LINUX PATCH v13] rawnand: pl353: Add basic driver for arm pl353 smc nand interface

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <MWHPR02MB2623540BA389042E7795E071AF5A0@MWHPR02MB2623.namprd02.prod.outlook.com>
Date:   Fri, 29 Mar 2019 05:21:29 +0000
From:   Naga Sureshkumar Relli <nagasure@...inx.com>
To:     Helmut Grohne <helmut.grohne@...enta.de>
CC:     "bbrezillon@...nel.org" <bbrezillon@...nel.org>,
        "miquel.raynal@...tlin.com" <miquel.raynal@...tlin.com>,
        "richard@....at" <richard@....at>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "computersforpeace@...il.com" <computersforpeace@...il.com>,
        "marek.vasut@...il.com" <marek.vasut@...il.com>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Michal Simek <michals@...inx.com>,
        "nagasureshkumarrelli@...il.com" <nagasureshkumarrelli@...il.com>
Subject: RE: [LINUX PATCH v13] rawnand: pl353: Add basic driver for arm pl353
 smc nand interface

Hi Helmut,

> -----Original Message-----
> From: Helmut Grohne <helmut.grohne@...enta.de>
> Sent: Thursday, March 28, 2019 5:21 PM
> To: Naga Sureshkumar Relli <nagasure@...inx.com>
> Cc: bbrezillon@...nel.org; miquel.raynal@...tlin.com; richard@....at;
> dwmw2@...radead.org; computersforpeace@...il.com; marek.vasut@...il.com; linux-
> mtd@...ts.infradead.org; linux-kernel@...r.kernel.org; Michal Simek <michals@...inx.com>;
> nagasureshkumarrelli@...il.com
> Subject: Re: [LINUX PATCH v13] rawnand: pl353: Add basic driver for arm pl353 smc nand
> interface
> 
> Hi Naga,
> 
> On Wed, Mar 27, 2019 at 09:13:59AM +0000, Naga Sureshkumar Relli wrote:
> > It's a on-die ECC capable device. Did u mentioned nand-ecc-mode = "on-die" in dts.
> > The same part I tested by mentioning "on-die" property in dts and it worked for me.
> > Please share the dts entries for NAND.
> > Also if it is x8 bus then please mention nand-bus-width = <8>; If it
> > is x16 mention nand-bus-width = <16>;
> 
> Thank you for pointing at the relevant properties. Indeed, these were missing in my previous
> tests. I am now using the following dt (generated from multiple fragments, giving the
> decompiled dt here):
> 
> | memory-controller@...0e000 {
> | 	#address-cells = <0x2>;
> | 	#size-cells = <0x1>;
> | 	status = "okay";
> | 	clock-names = "memclk", "apb_pclk";
> | 	clocks = <0x1 0xb 0x1 0x2c>;
> | 	compatible = "arm,pl353-smc-r2p1", "arm,primecell";
> | 	interrupt-parent = <0x4>;
> | 	interrupts = <0x0 0x12 0x4>;
> | 	ranges = <0x0 0x0 0xe1000000 0x1000000>;
> | 	reg = <0xe000e000 0x1000>;
> |
> | 	flash@...00000 {
> | 		status = "okay";
> | 		compatible = "arm,pl353-nand-r2p1";
> | 		reg = <0x0 0x0 0x1000000>;
> | 		#address-cells = <0x1>;
> | 		#size-cells = <0x1>;
> | 		nand-ecc-mode = "on-die";
> | 		nand-ecc-algo = "hamming";
> | 		nand-bus-width = <0x8>;
> | 	};
> | };
> 
> With this dt, the device is successfully initialized and the data read is mostly intact. When
> using it with jffs2, I get loads of ECC errors though (offsets and lengths vary):
> 
> | jffs2: mtd->read(0x800 bytes from 0xb60000) returned ECC error
> 
> Reverting back to the out-of-tree driver (4.14), it works normally, so a hardware defect seems
> unlikely. I compared a register dump of the smc between those drivers and the only difference I
> could find was NAND timings (at 0xE000E180), which are much lower with the new drivers
> as it does not consume the arm,nand-cycle-* properties that the old driver consumed. I tried
> hard coding the previous timings, but the ECC errors persist. This leads me to conclude that
> timings are not the cause for what I am seeing.
> 
> Is there anything else I can try to diagnose it?
Thanks for trying with new dts.
Previously we will pass the nand-cycle-* through dts.
But now framework is giving all the timing information of SDR. So we will just configure those
Timings. I will recheck the driver about the timings.

Till now I tried mtd-utils(mtd-debug) and ubifs.
I haven't tried jffs2. Let me give a try and will let you know.

Thanks,
Naga Sureshkumar Relli.
> 
> Helmut