| Message ID | 1351457262-11506-1-git-send-email-jm@lentin.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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 >
> 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
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 >
> >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
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 >
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@3000000 { + chip-delay = <35>; + }; }; };
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(+)