Problems with cfi_cmdset_0001

Problems with cfi_cmdset_0001

[Shane Nay]

Okay, I've been reading the PDF for Strataflash, by Intel.  And I've traced
my problems with the write routines in MTD down to two problems, the Block
address, and the word write problem.  The command address isn't properly
interpretted for this chip.  I'm not sure what the CFI spec is, but I
think:
cmd_adr=adr & ~(wbufsize-1);
is wrong.  (Well, maybe it's different chip to chip, but I know it's wrong
for this chip)

It should compute the top of the block via the erasesize and size.
cmd_adr=mtd->erasesize*((int)(adr/mtd->erasesize));

Now, this fixes the Block address.  The other problem though is
significantly nastier.

Okay, MTD seems to think that it can write twice as much data as it can to
a device at a time in write_buffer mode, which is all together wrong.  My
configuration is two x8 chips interleaved on a 16 bit bus.  Basically...,
its thinking we have two x16 chips on a 32 bit bus before streaming, but
then streams the data the right way, but twice as much as it said it would.
 (It says, I'm sending 16 words, then sends 32 of them instead, which as
you could imagine, is quite confusing to the poor flash chips)

In any event.  I've got the block address problem fixed up in the code with
the afore mentioned code.  The other problem I'm still working on. 
However, my code is so removed at this point from MTD base since I had too
many other things at play with MTD code to properly trace my problem, and
now I have a cleaner version of the code for XIP.  So I'm not sure I'm
going to roll all my changes into cfi_cmdset_0001.  Who is the maintainer
of this file BTW?  I'll try to make patches for him/her to fix these
problems.

Thanks,
Shane.

(Or maybe my extremely tired brain is mis-interpretting..., if I'm wrong,
tell me so :)



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

Re: Problems with cfi_cmdset_0001 && XIP kernel w/MTD working

[Shane Nay]

Problem solved, and MTD write, read, and erase is now functioning with an
XIP kernel.  Now come my questions..., I realized that it was trying to
fill the write buffer, but wasn't signaling the right size to the flash
chip now.  I traced where it was doing that, and have come to a conclusion
about a particular line of code.  But it might be a special case, and if so
we'll need some logic to deal with it, but I think it might just be a
mistake.  Okay, here it is:

In cfi_cmdset_001.c, in the do_write_buffer code, when it is sending the
size to the cmd_adr after putting the flash chip in write mode.  The
calculation for size there seems to be wrong for interleaved chips.  The
old code reads:
cfi_write(map,CMD((len/(cfi->device_type + CFIDEV_INTERLEAVE))-1),cmd_adr);

However, in my case, when it used this calculation, it undershot the number
of "words" it was going to write.  I think this is really confusing,
because the flash chip I'm working with percieves the number you send there
as "The number of times you will fill the bus".  But in the PDF it says
that that is the number of "words" that you will send it.  I suppose their
definition of word in this case is the present used buswidth of the chip. 
In any event, the correct code in my situation is:
cfi_write(map,CMD((len/(cfi->device_type)-1),cmd_adr);

The interleave should not factor into the division of the number of "words"
you are going to send.  I don't know if this is "generally true", but I
imagine it to be.  Anyone else out there with interleaved intel flashchips?

Thanks,
Shane.

(Ugh, replied to my own thread, bad juju)




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

Re: Problems with cfi_cmdset_0001

[Nicolas Pitre]

On Sat, 2 Dec 2000, Shane Nay wrote:

> Okay, I've been reading the PDF for Strataflash, by Intel.  And I've traced
> my problems with the write routines in MTD down to two problems, the Block
> address, and the word write problem.  The command address isn't properly
> interpretted for this chip.  I'm not sure what the CFI spec is, but I
> think:
> cmd_adr=adr & ~(wbufsize-1);
> is wrong.  (Well, maybe it's different chip to chip, but I know it's wrong
> for this chip)
>
> It should compute the top of the block via the erasesize and size.
> cmd_adr=mtd->erasesize*((int)(adr/mtd->erasesize));

Please consider using the following for better efficiency instead:

	cmd_adr = addr & ~(mtd->erasesize-1);

This produces the same result but omits the division which is best to avoid
on some CPUs which don't have a native instruction for it.

> Now, this fixes the Block address.  The other problem though is
> significantly nastier.
>
> Okay, MTD seems to think that it can write twice as much data as it can to
> a device at a time in write_buffer mode, which is all together wrong.  My
> configuration is two x8 chips interleaved on a 16 bit bus.  Basically...,
> its thinking we have two x16 chips on a 32 bit bus before streaming, but
> then streams the data the right way, but twice as much as it said it would.

What kind of arrangement do the probe function find?  Does it actually tell
you: "Found 2 x8 CFI devices at location 0 in 8 bit mode"?  If not, you'll
have to look at the probe code in cfi-probe.c.  Carefully reordering the
probe sequence might be required (I had to do it for the 32-bit buswidth
case).

> However, my code is so removed at this point from MTD base since I had too
> many other things at play with MTD code to properly trace my problem, and
> now I have a cleaner version of the code for XIP.  So I'm not sure I'm
> going to roll all my changes into cfi_cmdset_0001.

My impression is that it had better advantages to be separate just to keep
things as simple as possible.

> Who is the maintainer
> of this file BTW?  I'll try to make patches for him/her to fix these
> problems.

Well... I don't know who is the official maintainer, but I think I
contributed the largest mods recently.


Nicolas



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

Re: Problems with cfi_cmdset_0001

[Shane Nay]

Nicholas,
> Please consider using the following for better efficiency instead:
> 
> 	cmd_adr = addr & ~(mtd->erasesize-1);

Will do.  I was trying to think of the bit wise way to do it, but I was/am
kind of tired.

> 
> This produces the same result but omits the division which is best to
> avoid
> on some CPUs which don't have a native instruction for it.

Tell me about it..., working on FPU less MIPS processor.  So division in
general makes the hair on my neck stand out on end.

> 
> What kind of arrangement do the probe function find?  Does it actually
> tell
> you: "Found 2 x8 CFI devices at location 0 in 8 bit mode"?  If not,
> you'll
> have to look at the probe code in cfi-probe.c.  Carefully reordering the
> probe sequence might be required (I had to do it for the 32-bit buswidth
> case).

Ah, ic.  No, I think it found it correctly, here's the output:  (Paste
isn't working right now, have to turn on Emulate3Buttons again)
supports x8 and x16 via BYTE# with asynchronous interface


> 
> My impression is that it had better advantages to be separate just to
> keep
> things as simple as possible.

I happen to agree with your position now :-).  After a couple days of
drudging through stuff, I think simple is much better :).  I don't know
whether to contribut this stuff, and use a macro to re-probe for the
commandset_xip, and then write a commandset_xip.c file and contribute that
or what precisely.  It's pretty special purpose, so maybe just a patch
floating around for people to try out.  In any case, I have to maintain the
patch against linux-vr cvs repository for our device after we ship, so
it'll be floating around on the agenda computing pages starting Real Soon
Now, aka, as soon as I suck it into a kernel release for our device, which
is likely to be Monday or Tuesday.

> Well... I don't know who is the official maintainer, but I think I
> contributed the largest mods recently.

Cool, then I'll make the patch, post it on one of our pages and drop a link
here.  You guys can choose to include it in your stuff or not.  I
understand Daves philsophical issue on this..., RAM is cheaper than flash
:-).

Thanks,
Shane.



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

including doc2001 and docprobe into the kernel

[Adam Agnew]

when I try to include the millenium code right into the kernel along with
the ntfl layer, etc i get errors 
drivers/mtd/mtdlink.o: In function `DoC_Probe':
drivers/mtd/mtdlink.o(.text+0x26da): undefined reference to
`inter_module_get_request'
drivers/mtd/mtdlink.o(.text+0x26f9): undefined reference to
`inter_module_put'
drivers/mtd/mtdlink.o: In function `init_doc2001':
drivers/mtd/mtdlink.o(.text.init+0x75): undefined reference to
`inter_module_register'
make: *** [vmlinux] Error 1

I included all the module support etc... any ideas? The error goes away
when i compile the millenium driver as a module of course.
- adam agnew



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

Re: including doc2001 and docprobe into the kernel

[Levi Khatskevitch]

Adam,

You can add inter_module_xxx support by applying
patches/inter-module-2.2.17.patch on 2.2.17 kernel source. But if you didn't
apply patches/mtd-patch-2.2.17-20001130 please do so *before* adding any mtd
code to kernel tree. If you do everything correctly you shouldn't need
inter-module-xxx-2.2.17.patch. And don't forget to drivers/mtd/*.[ch],
include/linux/jffs.h and include/linux/mtd/*.h with the fresh ones from mtd cvs
tree *after* you've applied mtd-patch-2.2.17-20001130.

- Levi

On Sat, 02 Dec 2000, Adam Agnew wrote:
> when I try to include the millenium code right into the kernel along with
> the ntfl layer, etc i get errors 
> drivers/mtd/mtdlink.o: In function `DoC_Probe':
> drivers/mtd/mtdlink.o(.text+0x26da): undefined reference to
> `inter_module_get_request'
> drivers/mtd/mtdlink.o(.text+0x26f9): undefined reference to
> `inter_module_put'
> drivers/mtd/mtdlink.o: In function `init_doc2001':
> drivers/mtd/mtdlink.o(.text.init+0x75): undefined reference to
> `inter_module_register'
> make: *** [vmlinux] Error 1
> 
> I included all the module support etc... any ideas? The error goes away
> when i compile the millenium driver as a module of course.
> - adam agnew
> 
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
-- 
Levi Khatskevitch
CTO
Cachier, Corp
575 Grand St., Suite E306
New York, NY 10002


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

Re: including doc2001 and docprobe into the kernel

[David Woodhouse]

On Sun, 3 Dec 2000, Levi Khatskevitch wrote:

> Adam,
>
> You can add inter_module_xxx support by applying
> patches/inter-module-2.2.17.patch on 2.2.17 kernel source. But if you
> didn't apply patches/mtd-patch-2.2.17-20001130 please do so *before*
> adding any mtd code to kernel tree.

The patch is gone from CVS. It's now on the FTP site.

Also note that the latest CVS version of docprobe uses the doc2000.c
driver for _both_ 2000 and Millennium devices. So either build doc2000 and
docprobe into the kernel, not 'doc2001 and docprobe' as you say in
$subject, or comment out the #define DOC_SINGLE_DRIVER near the top of
docprobe.c.

The latter is probably the best option, given that the author of doc2001.c
thinks there are still bugs remaining in the Millennium support which is
merged into doc2000.c

-- 
dwmw2




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

Re: including doc2001 and docprobe into the kernel

[Levi Khatskevitch]

On Sun, 03 Dec 2000, David Woodhouse wrote:
> The patch is gone from CVS. It's now on the FTP site.

Hi,

If mtd-patch-* are gone from cvs what is the right procedure to bring the
latest mtd code into the kernel tree? Is is to apply a partial patch
mtd-*.infra.patch and then use patchin.sh? If that's so we need to have new
mtd-2.2.17.infra.patch and probably update or remove mtd-2.2.14.infra.patch and
mtd-2.2.16.infra.patch, they are way outdated.

BTW mtd-patch-2.2.17-20001130-1700GMT from ftp site still inserts
put_module_symbol even though it's not used anywhere in the source.

- Levi

-- 
Levi Khatskevitch
CTO
Cachier, Corp.
575 Grand St., Suite E306
New York, NY 10002


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

Re: including doc2001 and docprobe into the kernel

[David Woodhouse]

On Sun, 3 Dec 2000, Levi Khatskevitch wrote:

> If mtd-patch-* are gone from cvs what is the right procedure to bring
> the latest mtd code into the kernel tree? Is is to apply a partial
> patch mtd-*.infra.patch and then use patchin.sh? If that's so we need
> to have new mtd-2.2.17.infra.patch and probably update or remove
> mtd-2.2.14.infra.patch and mtd-2.2.16.infra.patch, they are way
> outdated.

The patch still exists, and the procedure for applying it is just the same
- except that now you download it from the FTP site, rather than clogging
up the CVS tree with it.

I've removed all the extra files from the CVS tree, too.

> BTW mtd-patch-2.2.17-20001130-1700GMT from ftp site still inserts
> put_module_symbol even though it's not used anywhere in the source.

Thanks. I'll try to remember to remove that part next time I make a patch.

-- 
dwmw2




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