RE: The archives [looking for info on AM29LV640 flash]

RE: The archives [looking for info on AM29LV640 flash]

[mark.langsdorf]

>  I've been browsing the archive to see if anyone's used MTD on
> AM29LV640 (64Mb, NAND I believe) parts.

	The spec sheet for the Am29LV640 indicates they are CFI
parts.  You should be able to use the cfi_cmdset_0002 module
with them, though admittedly I haven't tested this myself.

-Mark Langsdorf
AMD, Inc.


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Anyone using mtd on NAND flash? (Was: The archives [looking for info on AM29LV640 flash])

[Björn Eriksson]

> >  I've been browsing the archive to see if anyone's used MTD on
> > AM29LV640 (64Mb, NAND I believe) parts.
>
> 	The spec sheet for the Am29LV640 indicates they are CFI
> parts.  You should be able to use the cfi_cmdset_0002 module
> with them, though admittedly I haven't tested this myself.

 I've just been across the hall to strangle our hardware engineer (who
happens to also be my boss). He /intended/ to use the AM29LV640 part but had
problems finding a reliable source for them so we're using Samsungs KM29U128
part instead.

 There's no mention of CFI in the .pdf file I've got but I've detected the
KM29U128 chip using:

read_ID() /*pseudo_code*/ {
	const ReadID_cmd = 0x90;

	ready_chip();
	chip_enable();
	cmd_latch_enable();
	outportb(DATA, ReadID_cmd);	/*Read ID command */
	cmd_latch_disable();
	addr_latch_enable();
	outportb(DATA, 0x00);		/*1st address cycle */
	addr_latch_disable();

	m_code = inportb(DATA);		/* Reading 2 byte data */
	d_code = inportb(DATA);

	return (m_code << 8) | d_code;
}

 Which doesn't have much similarity to the cfi_probe.c:cfi_probe_new_chip()
function so I guess they're not CFI compliant chips; Why is that?


//Björnen.



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Anyone using mtd on NAND flash? (Was: The archives [looking for info on AM29LV640 flash])

[David Woodhouse]

bjorn@brannstrom.se said:
>  I've just been across the hall to strangle our hardware engineer (who
> happens to also be my boss). He /intended/ to use the AM29LV640 part
> but had problems finding a reliable source for them so we're using
> Samsungs KM29U128 part instead.

Don't strangle him. Have him hung, drawn and quartered.

The KM29U128 is an _entirely_ different beast. NAND flash is quite 
different to NOR flash.

With NOR flash, you can keep clearing bits individually until they're all
zero. With NAND flash you can only do 10 write cycles in each 512-byte page
before it becomes unreliable and you have to erase it again. JFFS currently
exceeds that number.

Also, NAND flash is permitted to ship with bad blocks and you're expected to
work round them. JFFS doesn't, and JFFS-on-NAND should probably use an error
correcting checksum rather than the simple checksum it currently uses.

He's just replaced something you could use with the current code with 
something we're not going to support for some time, unless you care to do 
the necessary work yourself.

You can't use NFTL, as we do on the DiskOnChip, because it's patented, and
even if you were only going to distribute within the Free World, the NFTL
code requires the built-in ECC support provided by the DiskOnChip ASIC.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Anyone using mtd on NAND flash?

[Stéphane Laroche]

On the subject of NAND flash, could some JFFS expert point me on where I should
look for those multiple writes to the same page?

I am currently working on a NAND driver for MTD that takes care of bad blocks
and virtual mapping.  It does ECC, keeps a bad block table and does the virtual
mapping of blocks so that MTD sees a linear block device with 100% good
blocks.  I'm using AMD which actually claims they'll have no bad blocks for the
specified amount of writes (100,000).  For Samsung or Toshiba parts (and AMD,
just to be safe), the driver reserves a certain number of blocks (35) to be
able to remap bad blocks dynamically.

So I think that JFFS should work with such a driver, if we make sure than no
more than 1 write occurs on the same 512-byte page.  [ AMD recommends writing
only once to a page, while Samsung/Toshiba talk of 10 writes ].

Is this a big task (JFFS design affected)?

Thanks,

-Stephane

David Woodhouse wrote:

> bjorn@brannstrom.se said:
> >  I've just been across the hall to strangle our hardware engineer (who
> > happens to also be my boss). He /intended/ to use the AM29LV640 part
> > but had problems finding a reliable source for them so we're using
> > Samsungs KM29U128 part instead.
>
> Don't strangle him. Have him hung, drawn and quartered.
>
> The KM29U128 is an _entirely_ different beast. NAND flash is quite
> different to NOR flash.
>
> With NOR flash, you can keep clearing bits individually until they're all
> zero. With NAND flash you can only do 10 write cycles in each 512-byte page
> before it becomes unreliable and you have to erase it again. JFFS currently
> exceeds that number.
>
> Also, NAND flash is permitted to ship with bad blocks and you're expected to
> work round them. JFFS doesn't, and JFFS-on-NAND should probably use an error
> correcting checksum rather than the simple checksum it currently uses.
>
> He's just replaced something you could use with the current code with
> something we're not going to support for some time, unless you care to do
> the necessary work yourself.
>
> You can't use NFTL, as we do on the DiskOnChip, because it's patented, and
> even if you were only going to distribute within the Free World, the NFTL
> code requires the built-in ECC support provided by the DiskOnChip ASIC.
>
> --
> dwmw2
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Anyone using mtd on NAND flash?

[David Woodhouse]

stephane.laroche@colubris.com said:
> On the subject of NAND flash, could some JFFS expert point me 

You're posting in the wrong place if you want JFFS experts. Join the JFFS
development list - see http://developer.axis.com/software/jffs/ for
subscription instructions.

> on where I should look for those multiple writes to the same page?

The JFFS code writes out a node header, then writes the data separately. In 
some cases, it even goes back after writing the data and puts the correct 
checksum into the node header. 

Look for calls to flash_safe_write() in intrep.c

> I am currently working on a NAND driver for MTD that takes care of bad
> blocks and virtual mapping.  It does ECC, keeps a bad block table and
> does the virtual mapping of blocks so that MTD sees a linear block
> device with 100% good blocks. 

Nice. One question - why do you want to do it in the MTD driver rather than 
in the next layer up? This kind of functionality will be needed for a 
number of devices, so it's probably worth putting it in JFFS.

We're already intending to stop JFFS from treating the flash as a single 
linear device, and start keeping a list of erase blocks in various 
conditions (full,dirty,empty,etc.). It wouldn't be difficult to handle bad 
blocks once that's done.

Also, the write caching to ensure we only perform one write per page is 
going to make it extremely easy for JFFS to do its own ECC too, where 
appropriate.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org