MTD on a Motorola MPCN765 ?

MTD on a Motorola MPCN765 ?

[Jan Rovins]

Hi all,
We are working on a project that involves a MPCN765 host card, and we are
running a 2.2.17 Kernel.
I have Downloaded the MTD patches and have merged them into our kernel, and
every thing still boots...
I tried some guesses at AMD CFI configuration, but it looks like our board
has exotic flash chips & geometry
that are not currently supported in MTD. (Time to roll up my sleeves & start
hacking code)

The MPCN765 has a 16MB bank of flash that is 64 bits wide (Ugh!) and is
comprised of four 16 bit devices.
we are planning to use the bottom 2/3 of this for boot image and the top 1/3
for application data storage (via MTD).
The Motorola literature mentions the flash chips as AM29DL323C in one
document, and AM29LV323C in an other doc.
The chips them selves say D323CT90VI on them, and the only data sheet that
is on the AMD web site is for a AM29DL323D.
at this point I am hoping that these are all similar enough so that the
differences wont matter.
 Is any one out there familiar with these chips? 

Right now I am looking for some general guidance as to which direction to
proceed.
my gut feel is to do a board specific Mapping implementation, because of the
strange geometry.
The other alternative would be to expand the generic AMD/CFI stuff so that
it could accommodate our board's flash geometry.
at this point I am still familiarizing myself with the MTD code, and would
appreciate any opinions and/or advice.

Thanks in advance,

Jan Rovins 
Member Technical Staff 
S-Link Corp. 
jrovins@ss7-link.com 
856-642-9229 X-228 




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

Re: MTD on a Motorola MPCN765 ?

[David Woodhouse]

jrovins@ss7-link.com said:
> I tried some guesses at AMD CFI configuration, but it looks like our
> board has exotic flash chips & geometry that are not currently
> supported in MTD. (Time to roll up my sleeves & start hacking code)

> The MPCN765 has a 16MB bank of flash that is 64 bits wide (Ugh!) and
> is comprised of four 16 bit devices.

Hmmm. This isn't currently supported, but it should be on 64-bit platforms.

In a few places, we currently assume that __u32 is big enough to hold the 
largest word for accessing flash - when building commands, etc. 

If we change that to 'unsigned long' and put all the 64-bit stuff inside 
"#ifdef BITS_PER_LONG >= 64" we should be OK. 


jrovins@ss7-link.com said:
> Right now I am looking for some general guidance as to which direction
> to proceed. my gut feel is to do a board specific Mapping
> implementation, because of the strange geometry. The other alternative
> would be to expand the generic AMD/CFI stuff so that it could
> accommodate our board's flash geometry.

You need both - you'll need to provide a board-specific mapping driver, and 
you also need to extend the generic code a little so it can cope with 
64-bit busses.

Roughly:
 1. Provide cfi64_to_cpu and cpu_to_cfi64 in include/linux/mtd/cfi_endian.h
 2. Add the necessary 64-bit parts to the inline routines in cfi.h - 
	cfi_write(), cfi_read(), cfi_read_query(), cfi_build_cmd(), etc.,
	and make them use 'unsigned long' instead of __u32 for holding
	a bus word. 
	Also add the CFIDEV_BUSWIDTH_8 definitions. You can leave out 
	CFIDEV_INTERLEAVE_8 for now unless you're feeling virtuous.
 3. Fix up the CFI command set drivers to use unsigned long too, and add the
	64-bit cases where appropriate. 

Remember to surround all 64-bit stuff with #ifdef CFIDEV_BUSWIDTH_8 (which 
in turn is dependent on BITS_PER_LONG >= 64). 

--
dwmw2




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