Slow read performance of NAND flash on PPC 405EP

Slow read performance of NAND flash on PPC 405EP

[Andy Hawkins]

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

Hi,

We have a custom PPC-405EP based board, with a Samsumg 8Gbit flash
(K9W8G08U1M) attached via EBC bank 2. When we read from this flash, we are
only getting data rates of around 20 MBits/sec (this is using 'dd' to read
direct from the linux /dev/mtd/x device). Our estimates show that the device
should be capable of something like 100 MBits/sec.

The EBC bank is set up as follows:

#define CFG_EBC_PB2AP           0x8a015480
#define CFG_EBC_PB2CR           0xFF458000  /*
BAS=0xFF4,BS=4MB,BU=R/W,BW=8bit */

The EBC bus is running at 54 MHz. We were originally running this bus at 27
MHz, and this speed increase doesn't appear to have done an awful lot for
us. By looking at the timings of various signals on an oscilloscope, we
adjusted the PB2AP register to that shown above, in an attempt to remove as
many of the wait states as possible.

However, during a read, we are seeing that each byte read cycle takes around
220 nSec (this is taken between the times when the #PERCS2 line for the
device goes low). A significant portion (about 6 clock periods) of this
time, the device appears to be doing nothing (i.e. the chip select line is
inactive). The code in the linux kernel to read a page of data from the
flash is very simple:

static void nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
{
        int i;
        struct nand_chip *this = mtd->priv;

        for (i=0; i<len; i++)
                buf[i] = readb(this->IO_ADDR_R);
}

readb maps to a call to in_8(FLASH_BASE_ADDRESS). The in_8 function does
contain what appear to be un-necessary calls to twi and isync, but removing
these calls does not alter the cycle time significantly.

Is there some setup of the EBC (or other component in the processor) that we
have incorrect that could be affecting the throughput?

Any advice you can offer would be greatly appreciated.

Thanks

Andy

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2624 bytes --]

Re: Slow read performance of NAND flash on PPC 405EP

[Artem B. Bityutskiy]

Andy Hawkins wrote:
> Hi,
Hi Andy

> 
> We have a custom PPC-405EP based board, with a Samsumg 8Gbit flash
> (K9W8G08U1M) attached via EBC bank 2. When we read from this flash, we are
> only getting data rates of around 20 MBits/sec (this is using 'dd' to read
> direct from the linux /dev/mtd/x device). Our estimates show that the device
> should be capable of something like 100 MBits/sec.

Bah, 8Gbit! :-)

JFFS2 is not enough scalable to work with 8Gbit Flashes. The practical 
limit is about 1Gbit. I would suggest to forget about JFFS2 in your 
case. You will never feel comfortable with JFFS2 + 8Gbit flashes.

Try to make 500MB file and remount JFFS2, then open it. See how much 
time this will take. See how much memory will me used.

Also ypu may glance at the introduction chapters at 
http://www.linux-mtd.infradead.org/tech/JFFS3design.pdf

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: Slow read performance of NAND flash on PPC 405EP

[Artem B. Bityutskiy]

Andy Hawkins wrote:
> Hi,
> 
> We have a custom PPC-405EP based board, with a Samsumg 8Gbit flash
> (K9W8G08U1M) attached via EBC bank 2. When we read from this flash, we are
> only getting data rates of around 20 MBits/sec (this is using 'dd' to read
> direct from the linux /dev/mtd/x device). Our estimates show that the device
> should be capable of something like 100 MBits/sec.
> 
Ops, pardon, you are not going to use JFFS2 :-) Ignore that mail then :-)

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: Slow read performance of NAND flash on PPC 405EP

[Conn Clark]

Andy Hawkins wrote:
> Hi,
> 
> We have a custom PPC-405EP based board, with a Samsumg 8Gbit flash
> (K9W8G08U1M) attached via EBC bank 2. When we read from this flash, we are
> only getting data rates of around 20 MBits/sec (this is using 'dd' to read
> direct from the linux /dev/mtd/x device). Our estimates show that the device
> should be capable of something like 100 MBits/sec.
> 
> The EBC bank is set up as follows:
> 
> #define CFG_EBC_PB2AP           0x8a015480
> #define CFG_EBC_PB2CR           0xFF458000  /*
> BAS=0xFF4,BS=4MB,BU=R/W,BW=8bit */
> 
> The EBC bus is running at 54 MHz. We were originally running this bus at 27
> MHz, and this speed increase doesn't appear to have done an awful lot for
> us. By looking at the timings of various signals on an oscilloscope, we
> adjusted the PB2AP register to that shown above, in an attempt to remove as
> many of the wait states as possible.
> 

It would be nice if you would break out the fields in the PB2AP control 
word. This is what I came up with.

BME = 1, burst mode enabled
FWT = 2, 3 wait states
BWT = 4, 5 wait states
CSN = 0, 0 clock cycles before CS asserted
OEN = 1, 1 clock cycle before the PerOE is asserted
WBN = 1, 1 clock cycle delay until the first PerW line assertion after CS
WBF = 1, 1 clock cycle delay
TH  = 2, 2 clock cycles in between each burst
RE  = 0, PerREADY line disabled
SOR = 1, no effect
BME = 0


So you are reading things in burst mode. I have no experience doing 
things in burst mode so I'm not going to be much help. I would look at 
your timing diagrams again. Try changing the TH to 1 or 0 and see what 
happens.

> However, during a read, we are seeing that each byte read cycle takes around
> 220 nSec (this is taken between the times when the #PERCS2 line for the
> device goes low). A significant portion (about 6 clock periods) of this
> time, the device appears to be doing nothing (i.e. the chip select line is
> inactive). The code in the linux kernel to read a page of data from the
> flash is very simple:
> 
> static void nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
> {
>         int i;
>         struct nand_chip *this = mtd->priv;
> 
>         for (i=0; i<len; i++)
>                 buf[i] = readb(this->IO_ADDR_R);
> }
> 
> readb maps to a call to in_8(FLASH_BASE_ADDRESS). The in_8 function does
> contain what appear to be un-necessary calls to twi and isync, but removing
> these calls does not alter the cycle time significantly.
> 
> Is there some setup of the EBC (or other component in the processor) that we
> have incorrect that could be affecting the throughput?
> 
> Any advice you can offer would be greatly appreciated.
> 
> Thanks
> 
> Andy
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

Good Luck

-- Conn Clark

*****************************************************************
Blessed be the heretic, for he causes some to think and unites
the rest against him.
*****************************************************************

Conn Clark
Engineering Assistant                clark@esteem.com
Electronic Systems Technology Inc.        www.esteem.com

Stock Ticker Symbol                ELST

Re: Slow read performance of NAND flash on PPC 405EP

[Conn Clark]

Andy Hawkins wrote:
> Hi,
> 
> Thanks for the reply.
> 
> 
>>It would be nice if you would break out the fields in the
>>PB2AP control
>>word. This is what I came up with.
>>
>>BME = 1, burst mode enabled
>>FWT = 2, 3 wait states
>>BWT = 4, 5 wait states
>>CSN = 0, 0 clock cycles before CS asserted
>>OEN = 1, 1 clock cycle before the PerOE is asserted
>>WBN = 1, 1 clock cycle delay until the first PerW line
>>assertion after CS
>>WBF = 1, 1 clock cycle delay
>>TH  = 2, 2 clock cycles in between each burst
>>RE  = 0, PerREADY line disabled
>>SOR = 1, no effect
>>BME = 0
> 
> 
> That matches how we decoded it, yes.
> 
> 
>>So you are reading things in burst mode. I have no experience doing
>>things in burst mode so I'm not going to be much help. I
>>would look at
>>your timing diagrams again. Try changing the TH to 1 or 0 and
>>see what
>>happens.
> 
> 
> We did try switching away from burst mode. However, as the flash is a serial
> read device with only one address, then each 'burst' transaction is only for
> a single ready anyway. We did try configuring without burst mode enabled,
> and it made little difference.
> 
> Are the figures we're seeing particularly slow, or are our expectations
> unrealistic?
> 
> Any other ideas?
> 
> Thanks again
> 
> Andy
> 


Without looking at the data sheet for your flash device I find it a 
little strange that the first wait state is 3 and the subsequent read 
wait states are 5 (i.e. 3,5,5,5,5... ) . Usually burst sequential 
devices have a long first wait state period followed by shorter ones 
(i.e. 5,3,3,3,3..... ). Are you sure you have this correct?

Unfortunately I don't have time to calculate your actual data rate. 
Other than reducing the Transfer Hold setting down from 2 to 1 or 0 I 
don't have any other ideas. In the end you get what you can get and 
thats it. If you have everything correct thats about all your going to 
get unless you start pushing timing beyond what they are rated for. I'm 
sure you don't want to do that.

Good Luck

-- Conn

*****************************************************************
Blessed be the heretic, for he causes some to think and unites
the rest against him.
*****************************************************************

Conn Clark
Engineering Assistant                clark@esteem.com
Electronic Systems Technology Inc.        www.esteem.com

Stock Ticker Symbol                ELST