[PATCH] ARM: kirkwood: Increase NAND chip-delay for DNS-320

[PATCH] ARM: kirkwood: Increase NAND chip-delay for DNS-320

[Jamie Lentin]

The default chip-delay of 25ns is a bit too tight for some DNS-320's,
increase to 35ns.

Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
---
I now own 2 DNS-320's, the first of which is happy with a mainline
kernel, the second fills the console with "Bad eraseblock xxx at
0x00000xxxxxxx" for every eraseblock and refuses to access the NAND.
Beyond this they appear identical, and report the same NAND chip
(I haven't physically checked that it's the same, however).

The patch below fixes it, however:-
* Is there something else I should be trying, rather than potentially
masking the problem?
* Is chip-delay too low for kirkwood generally?

Cheers,

 arch/arm/boot/dts/kirkwood-dns320.dts |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-dns320.dts b/arch/arm/boot/dts/kirkwood-dns320.dts
index 5bb0bf3..abe17a4 100644
--- a/arch/arm/boot/dts/kirkwood-dns320.dts
+++ b/arch/arm/boot/dts/kirkwood-dns320.dts
@@ -50,5 +50,9 @@
 			clock-frequency = <166666667>;
 			status = "okay";
 		};
+
+		nand at 3000000 {
+			chip-delay = <35>;
+		};
 	};
 };
-- 
1.7.10.4

[PATCH] ARM: kirkwood: Increase NAND chip-delay for DNS-320

[Andrew Lunn]

On Sun, Oct 28, 2012 at 08:47:42PM +0000, Jamie Lentin wrote:
> The default chip-delay of 25ns is a bit too tight for some DNS-320's,
> increase to 35ns.
> 
> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
> ---
> I now own 2 DNS-320's, the first of which is happy with a mainline
> kernel, the second fills the console with "Bad eraseblock xxx at
> 0x00000xxxxxxx" for every eraseblock and refuses to access the NAND.
> Beyond this they appear identical, and report the same NAND chip
> (I haven't physically checked that it's the same, however).
> 
> The patch below fixes it, however:-
> * Is there something else I should be trying, rather than potentially
> masking the problem?
> * Is chip-delay too low for kirkwood generally?

Do you know what NAND chip it is? We can check the datasheet and see
what is specified.

All kirkwood's use 25ns and i don't think there have been any problems
reported. But that does not mean Dlink have mounted a slower device.

	  Andrew

[PATCH] ARM: kirkwood: Increase NAND chip-delay for DNS-320

[Jamie Lentin]

On Sun, 28 Oct 2012, Andrew Lunn wrote:

> On Sun, Oct 28, 2012 at 08:47:42PM +0000, Jamie Lentin wrote:
>> The default chip-delay of 25ns is a bit too tight for some DNS-320's,
>> increase to 35ns.
>>
>> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
>> ---
>> I now own 2 DNS-320's, the first of which is happy with a mainline
>> kernel, the second fills the console with "Bad eraseblock xxx at
>> 0x00000xxxxxxx" for every eraseblock and refuses to access the NAND.
>> Beyond this they appear identical, and report the same NAND chip
>> (I haven't physically checked that it's the same, however).
>>
>> The patch below fixes it, however:-
>> * Is there something else I should be trying, rather than potentially
>> masking the problem?
>> * Is chip-delay too low for kirkwood generally?
>
> Do you know what NAND chip it is? We can check the datasheet and see
> what is specified.

The chip markings are: SAMSUNG 146 K9F1G08U0D SCB0 (FKJ554PWN)

Unfortunately the other NAS is too far away to get at, but D-link haven't 
stuck to exactly the same chip. This DNS-320 review shows a different 
Samsung part:

http://diit.cz/data/images/thumb/67491_2b9e5e4fbd.jpg?1307884464

The datasheet for the K9F1G08U0D says max 35usecs "Data Transfer from Cell 
to Register", whereas K9F1G08U0C (what the DNS-320 review shows) says 
25usecs. If this is the value in the datasheet to check, then this would 
explain the problems.

> All kirkwood's use 25ns and i don't think there have been any problems
> reported. But that does not mean Dlink have mounted a slower device.

I've not had anyone with this NAS report similar problems. It could just 
be I've been particuarly lucky...

>
> 	  Andrew
>

-- 
Jamie Lentin

[PATCH] ARM: kirkwood: Increase NAND chip-delay for DNS-320

[Andrew Lunn]

> The chip markings are: SAMSUNG 146 K9F1G08U0D SCB0 (FKJ554PWN)
> 
> Unfortunately the other NAS is too far away to get at, but D-link
> haven't stuck to exactly the same chip. This DNS-320 review shows a
> different Samsung part:
> 
> http://diit.cz/data/images/thumb/67491_2b9e5e4fbd.jpg?1307884464
> 
> The datasheet for the K9F1G08U0D says max 35usecs "Data Transfer
> from Cell to Register", whereas K9F1G08U0C (what the DNS-320 review
> shows) says 25usecs. If this is the value in the datasheet to check,
> then this would explain the problems.

Seems sensible.

I'm currently downloading the GPL sources from dlink. If the kernel
sources are included, we can see how dlink sets this. If its also 35,
then there is no argument.

The only thing you could think about is probing the nand device, and
if it is not K9F1G08U0D put the delay back to 25.

   Andrew

[PATCH] ARM: kirkwood: Increase NAND chip-delay for DNS-320

[Jamie Lentin]

On Mon, 29 Oct 2012, Andrew Lunn wrote:

>> The chip markings are: SAMSUNG 146 K9F1G08U0D SCB0 (FKJ554PWN)
>>
>> Unfortunately the other NAS is too far away to get at, but D-link
>> haven't stuck to exactly the same chip. This DNS-320 review shows a
>> different Samsung part:
>>
>> http://diit.cz/data/images/thumb/67491_2b9e5e4fbd.jpg?1307884464
>>
>> The datasheet for the K9F1G08U0D says max 35usecs "Data Transfer
>> from Cell to Register", whereas K9F1G08U0C (what the DNS-320 review
>> shows) says 25usecs. If this is the value in the datasheet to check,
>> then this would explain the problems.
>
> Seems sensible.
>
> I'm currently downloading the GPL sources from dlink. If the kernel
> sources are included, we can see how dlink sets this. If its also 35,
> then there is no argument.

Rummaging myself, my best guess is:

linux-2.6.22.18/arch/arm/mach-feroceon-kw/nand.c
173:    this->chip_delay = 30;

u-boot-1.1.4/board/mv_feroceon/USP/mv_nand.c
68: nand->chip_delay = 30;

However, this is too fast for my NAS when using a mainline kernel. 31usecs 
seems to work though. It's probably worth noting that the original 
firmware wasn't without it's problems on this particular board---I 
couldn't get it to reflash the NAND with a new firmware image. It could 
certainly read the NAND though.

This chip_delay value seems to be there in both the DNS320 and DNS325 GPL 
source. Maybe increasing chip_delay for both would be safest.

> The only thing you could think about is probing the nand device, and
> if it is not K9F1G08U0D put the delay back to 25.

That would be good, although the challenge will be a neat place to hang 
the code.

>
>   Andrew
>

-- 
Jamie Lentin

[PATCH] ARM: kirkwood: Increase NAND chip-delay for DNS-320

[Andrew Lunn]

> >I'm currently downloading the GPL sources from dlink. If the kernel
> >sources are included, we can see how dlink sets this. If its also 35,
> >then there is no argument.
> 
> Rummaging myself, my best guess is:
> 
> linux-2.6.22.18/arch/arm/mach-feroceon-kw/nand.c
> 173:    this->chip_delay = 30;
> 
> u-boot-1.1.4/board/mv_feroceon/USP/mv_nand.c
> 68: nand->chip_delay = 30;
> 
> However, this is too fast for my NAS when using a mainline kernel.
> 31usecs seems to work though. It's probably worth noting that the
> original firmware wasn't without it's problems on this particular
> board---I couldn't get it to reflash the NAND with a new firmware
> image. It could certainly read the NAND though.
> 
> This chip_delay value seems to be there in both the DNS320 and
> DNS325 GPL source. Maybe increasing chip_delay for both would be
> safest.

Yep. Please could you submit a new patch for dnskw.dtsi.

I guess you are not the only person with problems with 30, so 35 seems
sensible.

Do you have any idea how much this affects performance? It might not
be worth the effort to probe the chip and set the timing, if its only
a couple of % difference.

  Andrew

[PATCH V2] ARM: kirkwood: Increase NAND chip-delay for DNS-32[05]

[Jamie Lentin]

The default chip-delay of 25us is a bit too tight for some DNS-320's,
and D-Link seem to specify 30us in their kernels for both devices.
Increase to 35us to make sure the NAND is stable.

Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
---
 arch/arm/boot/dts/kirkwood-dnskw.dtsi |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index e0e4397..0360361 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -48,6 +48,7 @@
 
 		nand at 3000000 {
 			status = "okay";
+			chip-delay = <35>;
 
 			partition at 0 {
 				label = "u-boot";
-- 
1.7.10.4

[PATCH] ARM: kirkwood: Increase NAND chip-delay for DNS-320

[Jamie Lentin]

On Tue, 30 Oct 2012, Andrew Lunn wrote:

>>> I'm currently downloading the GPL sources from dlink. If the kernel
>>> sources are included, we can see how dlink sets this. If its also 35,
>>> then there is no argument.
>>
>> Rummaging myself, my best guess is:
>>
>> linux-2.6.22.18/arch/arm/mach-feroceon-kw/nand.c
>> 173:    this->chip_delay = 30;
>>
>> u-boot-1.1.4/board/mv_feroceon/USP/mv_nand.c
>> 68: nand->chip_delay = 30;
>>
>> However, this is too fast for my NAS when using a mainline kernel.
>> 31usecs seems to work though. It's probably worth noting that the
>> original firmware wasn't without it's problems on this particular
>> board---I couldn't get it to reflash the NAND with a new firmware
>> image. It could certainly read the NAND though.
>>
>> This chip_delay value seems to be there in both the DNS320 and
>> DNS325 GPL source. Maybe increasing chip_delay for both would be
>> safest.
>
> Yep. Please could you submit a new patch for dnskw.dtsi.
>
> I guess you are not the only person with problems with 30, so 35 seems
> sensible.
>
> Do you have any idea how much this affects performance? It might not
> be worth the effort to probe the chip and set the timing, if its only
> a couple of % difference.

Highly unscientific tests show that it's not making a vast difference. 
Even if it did, collecting chip to speed mappings is going to be a 
headache.

Given a range of chip_delay values, would it make sense for the NAND
driver to find the lowest chip_delay that results in a stable NAND. 
Possibly during the bad block scan?

>
>  Andrew
>

-- 
Jamie Lentin

[PATCH V2] ARM: kirkwood: Increase NAND chip-delay for DNS-32[05]

[Andrew Lunn]

On Thu, Nov 01, 2012 at 09:57:01PM +0000, Jamie Lentin wrote:
> The default chip-delay of 25us is a bit too tight for some DNS-320's,
> and D-Link seem to specify 30us in their kernels for both devices.
> Increase to 35us to make sure the NAND is stable.
> 
> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
> ---
>  arch/arm/boot/dts/kirkwood-dnskw.dtsi |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
> index e0e4397..0360361 100644
> --- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
> +++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
> @@ -48,6 +48,7 @@
>  
>  		nand at 3000000 {
>  			status = "okay";
> +			chip-delay = <35>;
>  
>  			partition at 0 {
>  				label = "u-boot";
> -- 
> 1.7.10.4
> 

Acked-by: Andrew Lunn <andrew@lunn.ch>

	  Andrew