Problems with AMD CFI chips

Problems with AMD CFI chips

[mark.langsdorf]

I'm testing the MTD/JFFS combo using Kernel 2.2.16 and
the October 30, 2000 version of MTD on AMD CFI compliant
chips.

The Flash bank is found correctly, and loads, and I can
write to it.  However, when I boot from it, I can't seem
to get it to commit writes - either creating new files 
or altering old ones.  Once I reboot the device, my
changes are gone.

mtab shows the root device as being mounted read/write.
When I write a file, the debug info seems to indicate
that the version numbers are being updated properly.

What other information should I provide to help debug
this problem?

Mark Langsdorf
Advanced Micro Devices, Inc             Tel: 512.602.3756
5204 E. Ben White Blvd. M/S 590         Fax: 512.602.5051
Austin, TX 78741                        mark.langsdorf@amd.com


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

Re: Problems with AMD CFI chips

[David Woodhouse]

mark.langsdorf@amd.com said:
>  The Flash bank is found correctly, and loads, and I can write to it.
> However, when I boot from it, I can't seem to get it to commit writes
> - either creating new files  or altering old ones.  Once I reboot the
> device, my changes are gone.

Please check using the /dev/mtd0 device directly to see whether your writes 
are 'taking'. 

What 'map' driver are you using? I found that it didn't work for me on the 
iPAQ because I wasn't enabling the Vpp voltage during write cycles. Is this 
necessary on your targer?

Other than that, poke the author and/or look at the code yourself to see 
what's happening. What interleave/buswidth are you using?

Note to self: Must produce a proper bug report for Nico for the current
cfi_cmdset_0001 code, does doesn't work for me on 1x16 devices.

--
dwmw2




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

RE: Problems with AMD CFI chips

[mark.langsdorf]

> mark.langsdorf@amd.com said:
> >  The Flash bank is found correctly, and loads, and I can 
> > write to it.
> > However, when I boot from it, I can't seem to get it to 
> > commit writes- either creating new files or altering old
> > ones.  Once I reboot the device, my changes are gone.
> 
> Please check using the /dev/mtd0 device directly to see 
> whether your writes are 'taking'. 

	I can write to /dev/mtd0, the writes through the char
interface are definitely consistent over power-outs.  It's
only when I use jffs on /dev/mtdblock0 that I run into problems.

> What 'map' driver are you using?

	Modified version of physmap, since the flash banks are
physically mapped at 0x2000000 but I needed to partition them
because the BIOS and kernel image are also stored on the same
banks.

> for me on the iPAQ because I wasn't enabling the Vpp voltage
> during write cycles. Is this necessary on your targer?
> 
> Other than that, poke the author and/or look at the code 
> yourself to see what's happening. What interleave/buswidth
> are you using?

	Interleave 2, 4 byte buswidth, to support 2 16 bit chips.
Again, that all looks pretty consistent.

	I think it may be some kind of interaction with jffs,
because I've had limited success with creating directories 
and deleting files, but not consistently.  I'm not sure where
I should look in the jffs code to get more information, though,
and would appreciate some pointers.
	Also, when does jffs attempt to clean out the dirty
space?  thread_should_wake reports upwards of 2 megs of
dirty space, which is about 16 sectors and 14% of the available
memory.  I'd think that should get returned to the free list
much earlier, especially during the reboots.

-Mark Langsdorf
AMD, Inc.


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

Re: Problems with AMD CFI chips

[Gregory Schallert]

>    Also, when does jffs attempt to clean out the dirty
> space?

On an aside, how does jffs schedule the clean up and is this really CPU
intensive?



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

RE: Problems with AMD CFI chips

[David Woodhouse]

On Thu, 2 Nov 2000 mark.langsdorf@amd.com wrote:

> 	Interleave 2, 4 byte buswidth, to support 2 16 bit chips.
> Again, that all looks pretty consistent.

Should be fine. ISTR that's what the original author was using.

> 	I think it may be some kind of interaction with jffs,
> because I've had limited success with creating directories 
> and deleting files, but not consistently.  I'm not sure where
> I should look in the jffs code to get more information, though,
> and would appreciate some pointers.

Make sure you've got up-to-date JFFS code. Or the code in the 2.4 kernel
is known good.

Hack flash_safe_write() to read back the data afterwards and verify it.

> 	Also, when does jffs attempt to clean out the dirty
> space?  thread_should_wake reports upwards of 2 megs of
> dirty space, which is about 16 sectors and 14% of the available
> memory.  I'd think that should get returned to the free list
> much earlier, especially during the reboots.

When the free space goes below gc_minfree_threshold or the dirty space
goes above gc_maxdirty_threshold. These are defined as 5% and 33% of the
total size of the flash partition, respectively. 

It's inefficient to GC too much before it's needed. In an ideal world,
we'd always have just enough free space to handle the next write without
having to wait for GC to happen.

-- 
dwmw2




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

Re: Problems with AMD CFI chips

[David Woodhouse]

On Thu, 2 Nov 2000, Gregory Schallert wrote:

> On an aside, how does jffs schedule the clean up and is this really CPU
> intensive?

While the conditions I quoted before are met, the jffs_gcd kernel thread
wakes up and does it in the background.

If the GC thread is ever killed by the user, or for some reason it's
been really slow and we've actually run out of free space, GC can also be
done from the user's context, to make room for a write to happen.

-- 
dwmw2




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

Re: cfi_cmdset_0001

[Nicolas Pitre]

On Tue, 31 Oct 2000, David Woodhouse wrote:

> Note to self: Must produce a proper bug report for Nico for the current
> cfi_cmdset_0001 code, does doesn't work for me on 1x16 devices.

I'm interested in it.  I just tested the current code on a GraphicsClient
board with Intel parts.  There is apparently a problem withe the buffer
write code.  The word write method works well though.  Oddly enough, the
buffer write method in my (being deprecated) flash-mem driver has no
problem...

Could you test with the write buffer disabled?


Nicolas



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