ARM: kirkwood: Increase NAND chip-delay for DNS-320
PATCH 1/1 ARM: kirkwood: Increase NAND chip-delay for DNS-320
The default chip-delay of 25ns is a bit too tight for some DNS-320's, increase to 35ns.
---
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(+)
arch/arm/boot/dts/kirkwood-dns320.dts +4 -0
@@ -50,5 +50,9 @@ clock-frequency = <166666667>; status = "okay"; }; + + nand at 3000000 { + chip-delay = <35>; + }; }; };
Signature · 1 line
1.7.10.4
PATCH 1/1 ARM: kirkwood: Increase NAND chip-delay for DNS-320
Quoted 11 lines · 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 <[email protected]>---
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).
Quoted 4 lines
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 1/1 ARM: kirkwood: Increase NAND chip-delay for DNS-320
Quoted 12 lines · Andrew Lunn
Quoted 11 lines · 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 <[email protected]>---
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).
Quoted 7 lines
Quoted 4 lines
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.
Quoted 2 lines
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...
Quoted 3 lines
Andrew
Signature · 1 line
Jamie Lentin
PATCH 1/1 ARM: kirkwood: Increase NAND chip-delay for DNS-320
Quoted 6 lines
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:
Quoted 6 lines
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 1/1 ARM: kirkwood: Increase NAND chip-delay for DNS-320
Quoted 13 lines · Andrew Lunn
Quoted 6 lines
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:
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
Andrew
Signature · 1 line
Jamie Lentin
PATCH 1/1 ARM: kirkwood: Increase NAND chip-delay for DNS-320
Quoted 18 lines
Quoted 3 lines
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.
Quoted 3 lines
This
chip_delayvalue seems to be there in both the DNS320 and DNS325 GPL source. Maybe increasingchip_delayfor 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 1/1 ARM: kirkwood: Increase NAND chip-delay for DNS-32[05]
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.
--- arch/arm/boot/dts/kirkwood-dnskw.dtsi | 1 + 1 file changed, 1 insertion(+)
arch/arm/boot/dts/kirkwood-dnskw.dtsi +1 -0
@@ -48,6 +48,7 @@ nand at 3000000 { status = "okay"; + chip-delay = <35>; partition at 0 { label = "u-boot";
Signature · 1 line
1.7.10.4
PATCH v2 1/1 ARM: kirkwood: Increase NAND chip-delay for DNS-32[05]
Quoted 24 lines · 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 <[email protected]>--- arch/arm/boot/dts/kirkwood-dnskw.dtsi | 1 + 1 file changed, 1 insertion(+)arch/arm/boot/dts/kirkwood-dnskw.dtsi +1
-0@@ -48,6 +48,7 @@ nand at 3000000 { status = "okay"; + chip-delay = <35>; partition at 0 { label = "u-boot";Signature · 1 line
1.7.10.4
Andrew
PATCH 1/1 ARM: kirkwood: Increase NAND chip-delay for DNS-320
In reply to Andrew LunnQuoted 22 lines · Andrew Lunn
Quoted 18 lines
Quoted 3 lines
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.
Quoted 3 lines
This
chip_delayvalue seems to be there in both the DNS320 and DNS325 GPL source. Maybe increasingchip_delayfor both would be safest.
Quoted 8 lines
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?
Quoted 3 lines
Andrew
Signature · 1 line
Jamie Lentin