Problem writing to NOR flash

Problem writing to NOR flash

[Andy Hawkins]

Hi,

We're trying to write to NOR flash on our custom board. We can
successfully read without problem, but when we try to write we get the
following (apologies about the wrapping):

Unlocking flash.Oops: kernel access of bad area, sig: 11
NIP: C00CE4B8 XER: 00000000 LR: C00CE438 SP: C7769E10 REGS: c7769d60
TRAP: 0800d
MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DEAR: C8C0E002, ESR: 00800000
TASK = c7768000[170] 'fw_setenv' Last syscall: 54
last math 00000000 last altivec 00000000
PLB0: bear= 0x00000000 acr=   0x00000000 besr=  0x00000000
PLB0 to OPB: bear= 0x00000000 besr0= 0x00000000 besr1= 0x00000000

GPR00: 00000000 C7769E10 C7768000 00000000 C016657C 00000001 0000000E
00000000
GPR08: 00000020 C900E000 00001FFF 00000000 00000000 1001B8EC 00000000
00000000
GPR16: 00000000 00000000 00000000 00000000 00009032 C00CE380 00000000
C7769E88
GPR24: C0190000 C03BB740 C7769E88 C03BB778 C016657C 00000000 C018B440
FFC00002
Call backtrace:
C00CE3D4 C00CDDAC C00CE550 C00C3CEC C00C4DD4 C004C33C C000457C
7FFFFC30 100016A8 10001448 10002B7C 0FEB6D84 00000000

The backtrace information points to the crash being in
do_xxlock_oneblock (if I'm reading the System.map correctly).

The relevant bits of System.map are below

c00c3c80 t part_unlock
c00c3cf0 t part_sync
c00c4c2c t mtd_ioctl
c00c55d0 t mtd_notify_add
c00cdbdc t cfi_amdstd_varsize_frob
c00cde3c t cfi_amdstd_erase_varsize
c00ce380 t do_xxlock_oneblock
c00ce4d8 t cfi_amdstd_lock_varsize
c00ce51c t cfi_amdstd_unlock_varsize
c00ce560 t cfi_amdstd_destroy

The flash is a M29W320DB.

I'm using a relatively old snapshot, but comparing with the current
snapshot shows that function hasn't changed.

Can anyone offer any advice? I have access to a BDI-2000 if any low
level debugging is required.

Many thanks.

Andy

Problem writing to NOR flash

[Andy Hawkins]

Hi all,

We're using a 2.4.20 derived kernel, and a while back updated to a
recent MTD snapshot to get support for the Samsung NAND 128MiB on our
hardware).

However, we found that with this snapshot, we could no longer write to
the NOR flash on our board (I posted a message about this on 19th July,
but had no responses).

To see if this problem has now been fixed, I have just downloaded the
latest snapshot to try. However, I can no longer get this to compile.
After changing some Makefiles, I have now found that the new code uses
'kvec' in place of 'iovec'. Is this a 2.6 feature?

If so, are there any plans to make the current MTD code work with 2.4?

What would people recommend we do in order to get working MTD support
for the chips on our board for a 2.4 kernel?

Many thanks.

Andy

Re: Problem writing to NOR flash

[Dmitry A. Fedorov]

On 26 Jul 2004, Andy Hawkins wrote:

> We're using a 2.4.20 derived kernel, and a while back updated to a
> recent MTD snapshot

The same for 2.4.26.

> To see if this problem has now been fixed, I have just downloaded the
> latest snapshot to try. However, I can no longer get this to compile.
> After changing some Makefiles, I have now found that the new code uses
> 'kvec' in place of 'iovec'. Is this a 2.6 feature?
> 
> If so, are there any plans to make the current MTD code work with 2.4?

Porting of current MTD snapshot that oriented to 2.6 kernel is not
simple task. I did it for my hardware and have some patch set.

> What would people recommend we do in order to get working MTD support
> for the chips on our board for a 2.4 kernel?

Ask me for these patches, extend it for your hardware set and try to
push it back to MTD source.

Re: Problem writing to NOR flash

[Andy Hawkins]

Hi,

> Porting of current MTD snapshot that oriented to 2.6 kernel is not
> simple task. I did it for my hardware and have some patch set.
> 
> > What would people recommend we do in order to get working MTD support
> > for the chips on our board for a 2.4 kernel?
> 
> Ask me for these patches, extend it for your hardware set and try to
> push it back to MTD source.

Can I have a copy of these patches then? Have you had any problems
writing to NOR?

Thanks.

Andy

Re: Problem writing to NOR flash

[Dmitry A. Fedorov]

On 26 Jul 2004, Andy Hawkins wrote:

> > Porting of current MTD snapshot that oriented to 2.6 kernel is not
> > simple task. I did it for my hardware and have some patch set.
> > 
> > > What would people recommend we do in order to get working MTD support
> > > for the chips on our board for a 2.4 kernel?
> > 
> > Ask me for these patches, extend it for your hardware set and try to
> > push it back to MTD source.
> 
> Can I have a copy of these patches then?

Some time later (a few days).

> Have you had any problems writing to NOR?

No, after upgrade from the MTD snapshot.
There were problems with erase (ioctl call did not wait of
completion of erase operation) and jffs2 did not allowed to
write. Now it works properly.

Re: Problem writing to NOR flash

[Andy Hawkins]

Hi,

On Mon, 2004-07-26 at 15:35, Dmitry A. Fedorov wrote:
> > Can I have a copy of these patches then?
> 
> Some time later (a few days).

Thanks for that.

> 
> > Have you had any problems writing to NOR?
> 
> No, after upgrade from the MTD snapshot.
> There were problems with erase (ioctl call did not wait of
> completion of erase operation) and jffs2 did not allowed to
> write. Now it works properly.

Ah, should have been more clear. This is a 'raw' write to the NOR
device. It appears that it's crashing inside do_xxlock_oneblock in
cfi_cmdset_0002.c (where it does the 'cfi_write').

There's a comment at the top of the code saying that it's very chip
specific, and hasn't been tested on an interleaved device (which I think
mine is).

Anyone help?

Thanks.

Andy

Re: Problem writing to NOR flash

[Dmitry A. Fedorov]

On 26 Jul 2004, Andy Hawkins wrote:

> > > Have you had any problems writing to NOR?
> > 
> > No, after upgrade from the MTD snapshot.
> > There were problems with erase (ioctl call did not wait of
> > completion of erase operation) and jffs2 did not allowed to
> > write. Now it works properly.
> 
> Ah, should have been more clear. This is a 'raw' write to the NOR
> device. It appears that it's crashing inside do_xxlock_oneblock in
> cfi_cmdset_0002.c (where it does the 'cfi_write').
> There's a comment at the top of the code saying that it's very chip
> specific, and hasn't been tested on an interleaved device (which I think
> mine is).

I have use the same cmdset (exactly) but single (interleave 1) 16 bit
wide chip Am29LV640. No problems yet with backported code.

Re: Problem writing to NOR flash

[Andy Hawkins]

Hi,

On Mon, 2004-07-26 at 16:00, Dmitry A. Fedorov wrote:
> I have use the same cmdset (exactly) but single (interleave 1) 16 bit
> wide chip Am29LV640. No problems yet with backported code.

I've been doing a bit of digging now. The chip in question is an ST
M29W320DB (32MBit)

do_xxlock_oneblock is called, with an address of 0. However, this is
translated in the function to an address of ffc00002. This address is
then (eventually) passed into map_write16, which adds the virtual
address of the flash onto this address...

This to me appears to be invalid, but I'm not entirely sure what
*should* be happening here. The chip's start address is added on to the
address inside do_xxlock_oneblock (although this is zero), and then the
virtual address is added on again. However, the translation doesn't
appear correct to me:

adr = ((adr & ~0xffff) | 0x2) + ~0x3fffff;

As you can probably tell, I don't fully understand how the code is
*supposed* to work, so it's difficult to know exactly what is going
wrong here.

Thanks.

Andy

Re: Problem writing to NOR flash

[Andy Hawkins]

Hi all,

After a bit more digging and reading of the data sheet, it appears the
the chip I'm using doesn't need locking and unlocking. I then went back
to the version of the code where we had this working (whatever came with
the 2.4.20 kernel) and found that none of this locking / unlocking
mechanism was present.

So, to test I commented out the contents of cfi_amdstd_lock_varsize and
cfi_amdstd_unlock_varsize, and I can now successfully write to the NOR!

Are these functions only required for some very specific chips? If so,
what is the *correct* way for this code to determine whether or not they
are needed (this code is in a 'generic' file, so I'm surprised that
there's chip specific information in there).

Thanks for any advice you can offer.

Andy

Re: Problem writing to NOR flash

[David Woodhouse]

On Mon, 2004-07-26 at 14:32 +0100, Andy Hawkins wrote:
> To see if this problem has now been fixed, I have just downloaded the
> latest snapshot to try. However, I can no longer get this to compile.
> After changing some Makefiles, I have now found that the new code uses
> 'kvec' in place of 'iovec'. Is this a 2.6 feature?

Yes.

> If so, are there any plans to make the current MTD code work with 2.4?

No.

> What would people recommend we do in order to get working MTD support
> for the chips on our board for a 2.4 kernel?

Use 2.6.

-- 
dwmw2

Re: Problem writing to NOR flash

[Eric W. Biederman]

Andy Hawkins <a.hawkins@cabletime.com> writes:

> Hi all,
> 
> After a bit more digging and reading of the data sheet, it appears the
> the chip I'm using doesn't need locking and unlocking. I then went back
> to the version of the code where we had this working (whatever came with
> the 2.4.20 kernel) and found that none of this locking / unlocking
> mechanism was present.
> 
> So, to test I commented out the contents of cfi_amdstd_lock_varsize and
> cfi_amdstd_unlock_varsize, and I can now successfully write to the NOR!
> 
> Are these functions only required for some very specific chips? 

Yes.

> If so,
> what is the *correct* way for this code to determine whether or not they
> are needed (this code is in a 'generic' file, so I'm surprised that
> there's chip specific information in there).

When Thayne wrote the code he was assuming that since there were no
lock/unlock functions the lock/unlock entry points were simply
not called.  And he figured if it actually broken something someone
would scream.  And then he thought someone had removed the code
when cfi_cmdset_0002 was scrubbed a while ago.

In addition that code really is generic, it applies to firmware
hub parts and there are chips that use both cfi_cmdset_0001 and
cfi_cmdset_0002 that can use it.

When I get a chance it is my intention to refactor the probing
routines to make handling of chips with special capabilities
simpler.

As a first step I am putting a few conditionals in cfi_amdstd_setup
so that chips that we won't use those methods on chips that
don't support them.  Then we can look at better ways to organize
the probe code so the probe/setup code is not such a mess.

I have the first chunk done but I'm not ready to check it
in until I have a chance to test it.  And I am swamped right now...

Eric

Re: Problem writing to NOR flash

[Eric W. Biederman]

ebiederman@lnxi.com (Eric W. Biederman) writes:

> Andy Hawkins <a.hawkins@cabletime.com> writes:
> 

> > If so,
> > what is the *correct* way for this code to determine whether or not they
> > are needed (this code is in a 'generic' file, so I'm surprised that
> > there's chip specific information in there).
> 
> 
> I have the first chunk done but I'm not ready to check it
> in until I have a chance to test it.  And I am swamped right now..

Well the changes wound up being a little more extensive than
I described them.  But the code in cfi_cmdset_0001 and cfi_cmdset_0002 should
now be free of incorrect assumptions about what a flash chip can do.

As for the correct way to do this it probably still needs a little more
code review but there are fixup functions that are called when command sets
are initialized that allow for weird cases to be special cased.

Eric