headers
Pete Skelly | 2 Mar 2001 01:58

DOC2000 - 96MB on a 650Mhz PIII - cannot doc_read_ecc


I've been having trouble getting my 96MB DOC device to run on my system,
and have noticed a few others having similar problems in the archive.  

I'm using the mtd drivers from the 2.4.1 kernel (no mods)

I threw a kernel debugger on the system, and set a breakpoint where the ECC
status
is read, and it returned 0x8a, 0x8e, 0x8a during the 3 reads of  the ECC
status, 
hence a failure.

Next, I stepped through the entire doc_read_ecc process, and reading the 
ecc status returned 0x8a, 0x8e, 0x0a, a success.

This implies that there are some timing issues with either the larger DOC
chips
that are not addressed in the code, or there are timing issues caused by the
fact
that I'm running a PIII -650 system, which is a bit faster than most
embedded systems.

Anyone else come across anything like this.  I'm going to do some more
sniffing around,
to see if I can determine exactly which 'Delay' is not long enough, but if
anyone has any
technical info on what timing issues might be suspect, your help would be
appreciated.

p
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pete Skelly | 2 Mar 2001 09:38

RE: DOC2000 - 96MB on a 650Mhz PIII - cannot doc_read_ecc


Looks like timing is in fact the problem.  I multiplied the delay
in the routine DoC_Delay by 3, making this call last as long
as if my machine were a 200Mhz machine (which is probably closer to
what the Doc2000 drivers we're developed on), and was able to
successfully use nflt on the drive.

Although it looks like M-Systems doesn't publish the actual delays required,
they did indicate that there were in fact delays that had to be taken into
account.  

Any idea on the real numbers for the delays.  If one knew that, one could
write
proc-speed independent delay code (err, not sure whether I'm volunteering or
not)

Also, could this be related to some of the problems people are seeing with
larger
modules?  Do the larger modules have greater delays for sending commands to
the chip,
or are they simply found in faster systems?

p

-----Original Message-----
From: Pete Skelly [mailto:pete.skelly <at> astanetworks.com]
Sent: Thursday, March 01, 2001 4:59 PM
To: 'mtd <at> infradead.org'
Subject: DOC2000 - 96MB on a 650Mhz PIII - cannot doc_read_ecc
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Woodhouse | 2 Mar 2001 09:57
Favicon

Re: DOC2000 - 96MB on a 650Mhz PIII - cannot doc_read_ecc


pete.skelly <at> astanetworks.com said:
>  Also, could this be related to some of the problems people are seeing
> with larger modules?  Do the larger modules have greater delays for
> sending commands to the chip, or are they simply found in faster
> systems? 

Or the newer DiskOnChip devices are less tolerant w.r.t timing than the 
older ones? I think this is probably the cause of most of the problems that 
people have been seeing.

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org
Permalink | Reply | 0 comments |
headers
Ollie Lho | 2 Mar 2001 12:06
Picon

Re: DOC2000 - 96MB on a 650Mhz PIII - cannot doc_read_ecc

Pete Skelly wrote:
> 
> Looks like timing is in fact the problem.  I multiplied the delay
> in the routine DoC_Delay by 3, making this call last as long
> as if my machine were a 200Mhz machine (which is probably closer to
> what the Doc2000 drivers we're developed on), and was able to
> successfully use nflt on the drive.
> 
> Although it looks like M-Systems doesn't publish the actual delays required,
> they did indicate that there were in fact delays that had to be taken into
> account.
> 
> Any idea on the real numbers for the delays.  If one knew that, one could
> write
> proc-speed independent delay code (err, not sure whether I'm volunteering or
> not)
> 
> Also, could this be related to some of the problems people are seeing with
> larger
> modules?  Do the larger modules have greater delays for sending commands to
> the chip,
> or are they simply found in faster systems?
> 

M-System does "publish" the timming requirement in their documents. But they
does not made it very clearly, and it seems that the timming varies with
the age of the flash and/or different lot.

Ollie
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Schirmer / TayTron | 2 Mar 2001 21:44

Some bugs

Hi!

Thanks a lot for this great piece of software!

While playing with it i noticed some bugs:

1. CFI-Intel P_ID 3 not supported

We have 2 interlaced Intel TE28F320 chips. They report P_ID = 3 which isnt
handled by mtd. After forcing this value to 1 by hand everything works very
well.

Workaround: cfi_probe.c ~ line 562:

/* Do any necessary byteswapping */
cfi.cfiq->P_ID = le16_to_cpu(cfi.cfiq->P_ID);

if (cfi.cfiq->P_ID == 3)
  cfi.cfiq->P_ID = 1;

cfi.cfiq->P_ADR = le16_to_cpu(cfi.cfiq->P_ADR);

2. CFI-Intel 16 Bit mode broken

Intel 16 bit wide access is broken because the extended query table is read
via read8() calls. Using cfi_read_query instead solves this issue.

Workaround: cfi_cmd_set_0001.c ~ line 105:

/* Read in the Extended Query Table */
(Continue reading)

Permalink | Reply | 9 comments |
headers
David Woodhouse | 3 Mar 2001 17:39
Favicon

Re: Some bugs

On Fri, 2 Mar 2001, Florian Schirmer / TayTron wrote:

> 1. CFI-Intel P_ID 3 not supported
> 
> We have 2 interlaced Intel TE28F320 chips. They report P_ID = 3 which isnt
> handled by mtd. After forcing this value to 1 by hand everything works very
> well.

Sensible workaround for now. We need to make sure the cfi_cmdset_0001
code doesn't try to use any commands from the extended command set, but I 
don't think it supports any yet, so it's not an issue.

We need to rework the loading of submodules anyway, so we can fix this 
properly at that time.

> 2. CFI-Intel 16 Bit mode broken
> 
> Intel 16 bit wide access is broken because the extended query table is read
> via read8() calls. Using cfi_read_query instead solves this issue.

OK, applied. Thanks.

> 3. Write support is broken on ppc because of endianess problem
> 
> cat bla.img > /dev/mtd/0
> cat /dev/mtd/0 > bla2.img
> 
> Results in a swapped file. I can only _guess_ where the problem is exactly.
> Reading is done via read_fromio() while writing is done by using writew()
> calls. One of these funtions seem to swapp the bytes. Maybe it isnt really a
(Continue reading)

Permalink | Reply | 8 comments |
headers
Florian Schirmer / TayTron | 3 Mar 2001 18:41

AW: Some bugs

Hi!

>> 3. Write support is broken on ppc because of endianess problem
>>
>> cat bla.img > /dev/mtd/0
>> cat /dev/mtd/0 > bla2.img
>>
>> Results in a swapped file. I can only _guess_ where the problem is
exactly.
>> Reading is done via read_fromio() while writing is done by using writew()
>> calls. One of these funtions seem to swapp the bytes. Maybe it isnt
really a
>> mtd isse. Maybe it's my fault. I've read something in one of the include
>> files about the endianess issue but did not find the information again.

[...]

>That's not a generic solution. There should be no byteswapping of data
>anywhere. What map driver are you using? It sounds like it's byteswapping
>on write8(), which is wrong. Make it stop doing that and define
>CFI_HOST_ENDIAN or CFI_BIG_ENDIAN in include/linux/mtd/cfi_endian.h

physmap.c. It isn't doing any byteswapping. Thats the point. Yes this was
the include file i was looking for. But it doesnt solve the problem. Since
physmap ist unsing it at all changing the mode to big_endian breaks the
whole thing. The chips wont be detected since their bytes are flipped :)

So the problem must be either in the mtd cfi_cmd_set module (not swapping
while writing data) or somethere in the kernel stuff. Any ideas? This is the
only true problem at the moment i dont know a good workaround for.
(Continue reading)

Permalink | Reply | 7 comments |
headers
David Woodhouse | 3 Mar 2001 19:18
Favicon

Re: AW: Some bugs

On Sat, 3 Mar 2001, Florian Schirmer / TayTron wrote:

> So the problem must be either in the mtd cfi_cmd_set module (not swapping
> while writing data) or somethere in the kernel stuff. Any ideas? This is the
> only true problem at the moment i dont know a good workaround for.

Aha - writew is defined as little-endian. We should be using __raw_writew() 
in physmap.c, and possibly mb() after it.

I've committed that change - please test.

> Okay found the problem: EraseRegionInfo[0] is equal at both positions. And
> it's already in correct byteorder in BOTH positions. Swapping the order
> again in cfi_cmd_set_0001 causes the trouble. This results in erase size
> 0x200 instead of 0x20000. So please remove it.

OK, that's applied too, thanks.

> So please can you commit the 3 solved issues to cvs?

The first was already there. The above two just joined it. Please confirm 
that the writew change is working.

Thanks.

--

-- 
dwmw2

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org
(Continue reading)

Permalink | Reply | 6 comments |
headers
Subodh Nijsure | 4 Mar 2001 22:09
Picon
Favicon

What should value of CONFIG_MTD_CFIB* be?


[I am very much a novice when it comes flash..] 

In the latest MTD code ( from infradead CVS ) there are few #defines 
are introduced CONFIG_MTD_CFI_B1, B2,B3 and CONFIG_MTD_CFI_I1. 

What should my values be for above variables 
if my hardware is two Intel 28F160S3
(sector size 64K) flash devices, configured to operate in 
16-bit mode giving me 4Mb, 32-bit wide memory? 

This is how my MTD config looks like and cfi_probe is not able to  
detect these intel chips.

#
# Linearly Mapped Flash Device Drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_CFI_GEOMETRY is not set
# CONFIG_MTD_CFI_INTELEXT is not set
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_SHARP is not set
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=28000000
CONFIG_MTD_PHYSMAP_LEN=400000
CONFIG_MTD_PHYSMAP_BUSWIDTH=4
# CONFIG_MTD_NORA is not set
# CONFIG_MTD_PNC2000 is not set
# CONFIG_MTD_RPXLITE is not set
# CONFIG_MTD_SBC_MEDIAGX is not set
(Continue reading)

Permalink | Reply | 1 comment |
headers
Florian Schirmer / TayTron | 5 Mar 2001 08:05

Re: What should value of CONFIG_MTD_CFIB* be?

Hi ...

> What should my values be for above variables
> if my hardware is two Intel 28F160S3
> (sector size 64K) flash devices, configured to operate in
> 16-bit mode giving me 4Mb, 32-bit wide memory?
>
>
> This is how my MTD config looks like and cfi_probe is not able to
> detect these intel chips.

CFI probe needs CONFIG_MTD_CFI_INTELEXT=y to find the chips. I dont know
about the JEDEC code, wether it is working already or work in progress.
Maybe you want to disable CONFIG_MTD_CSTM_CFI_JEDEC and CONFIG_MTD_JEDEC.
You dont need it for CFI chips.

If it still doesn't work check out the latest code from cvs. (But there is a
small bug which prevents in cfi_cmdset_0001 from compiling - look at my next
message).

Hope that helps,
   Florian Schirmer

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org
Permalink | Reply | 0 comments |

Gmane