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@e000e000 {
| #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@e1000000 {
| 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?
Helmut
