All of lore.kernel.org
 help / color / mirror / Atom feed
* Problem with eLBC?
@ 2011-12-05 14:02 Alexander Lyasin
  2011-12-05 21:08 ` Scott Wood
  0 siblings, 1 reply; 3+ messages in thread
From: Alexander Lyasin @ 2011-12-05 14:02 UTC (permalink / raw)
  To: galak, linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 5705 bytes --]

Dear Kumar Gala!

Our company is a client Freescale company, we use mpc8308, mpc8321 and other 
microprocessors. 
I have a board on the mpc8308 chip. This board runs the Linux kernel.
On this board there is NAND flash and DSP proc. on the Local Bus.
Chunk from DTS-file is below:

        localbus@e0005000 {
                #address-cells = <2>;
                #size-cells = <1>;
                compatible = "fsl,mpc8315-elbc", "fsl,elbc", "simple-bus";
                reg = <0xe0005000 0x1000>;
                interrupts = <77 0x8>;
                interrupt-parent = <&ipic>;

                // CS0 and CS1 are swapped when
                // booting from nand, but the
                // addresses are the same.
                ranges = <0x0 0x0 0xfe000000 0x00800000
                          0x1 0x0 0xe0600000 0x00002000
                          0x2 0x0 0xf0000000 0x00020000
                          0x3 0x0 0xfa000000 0x00008000>;

                nand@1,0 {
                        #address-cells = <1>;
                        #size-cells = <1>;
                        compatible = "fsl,mpc8315-fcm-nand",
                                     "fsl,elbc-fcm-nand";
                        reg = <0x1 0x0 0x2000>;

                        u-boot@0 {
                                reg = <0x0 0x100000>;
                                read-only;
                                label = "U-Boot-NAND";
                        };
                        dtb@100000 {
                                reg = <0x100000 0x40000>;
                                read-only;
                                label = "DTB-NAND";
                        };
                        kernel@140000 {
                                reg = <0x140000 0x200000>;
                                read-only;
                                label = "Kernel-NAND";
                        };
                        jffs2@340000 {
                                reg = <0x00340000 0x01c00000>;
                                label = "JFFS2-NAND";
                        };
                        reserve@1f40000 {
                                reg = <0x01f40000 0x000c0000>;
                                label = "Reserve";
                        };
                };

                dsp0@D0020000 {
                        reg = <0xD0020000 0x10000>;
                        interrupts = <18 0x8>;
                        interrupt-parent = <&ipic>;
                        dsp0;
                };

                dsp1@D0030000 {
                        reg = <0xD0030000 0x10000>;
                        interrupts = <19 0x8>;
                        interrupt-parent = <&ipic>;
                        dsp1;
                };

User-level application periodically reads data from the DSP and writes the 
data to the DSP via a character device. When the application is reading from 
DSP or writing to the DSP, file system calls to cause errors:

[root@mpc8308-kd-124 /root]# ls -l                                                                                                                           
mtd->read(0xdc bytes from 0x8af524) returned ECC error                                                                                                       
mtd->read(0x1fc bytes from 0x8aee04) returned ECC error                                                                                                      
mtd->read(0xac bytes from 0x8ae554) returned ECC error                                                                                                       
mtd->read(0x200 bytes from 0x8adc00) returned ECC error
..............
..............
...............
when writing to flash errors occur following items:

Write of 1662 bytes at 0x01935244 failed. returned -5, retlen 0                                                                                              
Not marking the space at 0x01935244 as dirty because the flash driver returned 
retlen zero                                                                   
Write of 1662 bytes at 0x01930000 failed. returned -5, retlen 0                                                                                              
Not marking the space at 0x01930000 as dirty because the flash driver returned 
retlen zero                                                                   
nand_erase: start = 0x000001c70000, len = 16384                                                                                                              
nand_isbad_bbt(): bbt info for offs 0x01c70000: (block 1820) 0x00                                                                                            
nand_write_oob: to = 0x01c70000, len = 8                                                                                                                     
cannot write OOB for EB at 01930000, requested 8 bytes, read 0 bytes, error -5

I write to support this problem and I was told the following:

	In reply to your Service Request SR 1-807899446: 

	Yes, due to several design peculiarities in local bus nand controller, 		
	simultaneous accesses to nand flash and to other local bus memory 		
	controller may cause nand flash controller access failure. Our linux team 	
	suggested to use "software lock" method to avoid this problem - please do 
	not use other local bus controllers, when nand flash is accessed. 

	Thank you for your interest in Freescale Semiconductor products and for 		
	the opportunity to serve you.
	Best regards.

Do you think, Kumar, how can solve this problem? Perhaps this problem is not 
in eLBS?

Alexander V. Lyasin <alexander.lyasin@gmail.com>
Linux system developer
TAKT Inc

[-- Attachment #2: Type: text/html, Size: 20689 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Problem with eLBC?
  2011-12-05 14:02 Problem with eLBC? Alexander Lyasin
@ 2011-12-05 21:08 ` Scott Wood
  2011-12-06  9:30   ` Joakim Tjernlund
  0 siblings, 1 reply; 3+ messages in thread
From: Scott Wood @ 2011-12-05 21:08 UTC (permalink / raw)
  To: Alexander Lyasin; +Cc: linuxppc-dev

On 12/05/2011 08:02 AM, Alexander Lyasin wrote:
> In reply to your Service Request SR 1-807899446:
> 
> Yes, due to several design peculiarities in local bus nand controller,
> simultaneous accesses to nand flash and to other local bus memory
> controller may cause nand flash controller access failure. Our linux
> team suggested to use "software lock" method to avoid this problem -
> please do not use other local bus controllers, when nand flash is accessed.

What kernel version are you using?  The latest mainline kernel should
not have this issue.

Make sure you have these patches:

commit d08e44570ed611c527a1062eb4f8c6ac61832e6e
Author: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Date:   Thu May 19 18:48:01 2011 +0800

    powerpc/fsl_lbc: Add workaround for ELBC-A001 erratum

    Simultaneous FCM and GPCM or UPM operation may erroneously trigger
    bus monitor timeout.

    Set the local bus monitor timeout value to the maximum by setting
    LBCR[BMT] = 0 and LBCR[BMTPS] = 0xF.

    Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

and

commit 476459a6cf46d20ec73d9b211f3894ced5f9871e
Author: Scott Wood <scottwood@freescale.com>
Date:   Fri Nov 13 14:13:01 2009 -0600

    mtd: eLBC NAND: use recommended command sequences

    Currently, the program and erase sequences do not wait for completion,
    instead relying on a subsequent waitfunc() callback.  However, this
causes
    the chipselect to be deasserted while the NAND chip is still
asserting the
    busy pin, which can corrupt activity on other chipselects.

    This patch switches to using the sequences recommended by the manual,
    in which a wait is performed within the initial command sequence.
We can
    now re-use the status byte from the initial command sequence, rather
than
    having to do another status read in the waitfunc.

    Since we're already touching the command sequences, it also cleans
up some
    cruft in SEQIN that isn't needed since we cannot program partial pages
    outside of OOB.

    Signed-off-by: Scott Wood <scottwood@freescale.com>
    Reported-by: Suchit Lepcha <suchit.lepcha@freescale.com>
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>

-Scott

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Problem with eLBC?
  2011-12-05 21:08 ` Scott Wood
@ 2011-12-06  9:30   ` Joakim Tjernlund
  0 siblings, 0 replies; 3+ messages in thread
From: Joakim Tjernlund @ 2011-12-06  9:30 UTC (permalink / raw)
  To: Scott Wood; +Cc: Alexander Lyasin, linuxppc-dev

>
> On 12/05/2011 08:02 AM, Alexander Lyasin wrote:
> > In reply to your Service Request SR 1-807899446:
> >
> > Yes, due to several design peculiarities in local bus nand controller,
> > simultaneous accesses to nand flash and to other local bus memory
> > controller may cause nand flash controller access failure. Our linux
> > team suggested to use "software lock" method to avoid this problem -
> > please do not use other local bus controllers, when nand flash is accessed.
>
> What kernel version are you using?  The latest mainline kernel should
> not have this issue.
>
> Make sure you have these patches:
>
> commit d08e44570ed611c527a1062eb4f8c6ac61832e6e
> Author: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> Date:   Thu May 19 18:48:01 2011 +0800
>
>     powerpc/fsl_lbc: Add workaround for ELBC-A001 erratum
>
>     Simultaneous FCM and GPCM or UPM operation may erroneously trigger
>     bus monitor timeout.
>
>     Set the local bus monitor timeout value to the maximum by setting
>     LBCR[BMT] = 0 and LBCR[BMTPS] = 0xF.
>
>     Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
>     Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> and
>
> commit 476459a6cf46d20ec73d9b211f3894ced5f9871e
> Author: Scott Wood <scottwood@freescale.com>
> Date:   Fri Nov 13 14:13:01 2009 -0600
>
>     mtd: eLBC NAND: use recommended command sequences
>
>     Currently, the program and erase sequences do not wait for completion,
>     instead relying on a subsequent waitfunc() callback.  However, this
> causes
>     the chipselect to be deasserted while the NAND chip is still
> asserting the
>     busy pin, which can corrupt activity on other chipselects.
>
>     This patch switches to using the sequences recommended by the manual,
>     in which a wait is performed within the initial command sequence.
> We can
>     now re-use the status byte from the initial command sequence, rather
> than
>     having to do another status read in the waitfunc.
>
>     Since we're already touching the command sequences, it also cleans
> up some
>     cruft in SEQIN that isn't needed since we cannot program partial pages
>     outside of OOB.
>
>     Signed-off-by: Scott Wood <scottwood@freescale.com>
>     Reported-by: Suchit Lepcha <suchit.lepcha@freescale.com>
>     Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
>     Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>
> -Scott

Scott, you seem know something about eLBC and NAND. I have been told
that using NAND and other memory mapped devices on the same LB may
stall accesses to the other devices as the FCM may hold the bus for
long periods(a whole write or erase op.), is this so?

If still true, I guess the whole CPU "freezes" until the NAND op.
is complete?

 Jocke

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-12-06  9:30 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-05 14:02 Problem with eLBC? Alexander Lyasin
2011-12-05 21:08 ` Scott Wood
2011-12-06  9:30   ` Joakim Tjernlund

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.