CFI Extended (Intel P30) problems on an ARM PXA255

CFI Extended (Intel P30) problems on an ARM PXA255

[Dan Merillat]

I originally sent this to the linux-arm list, but it's looking more
and more like either a MTD issue, or a hardware issue with our board.

We have a custom PXA255 board, based on the generic Intel reference
design.  Nothing very
complex at all.   RAM, Strataflash (P30), JTAG and a serial port is
all I have active at this point.

Everything works correctly, until I try to write to the filesystem. 
As soon as I do, I start getting JFFS corruption notices.  It's fairly
obvious what's wrong: All reads are returning 0x0080, the 'Ok' status
bit.   I can break in the jtag, write a reset to the flash, and
continue, and new reads work properly, until I write again (or the
original write retries).

I thought it might be a memory timing issue, but I pulled the timing
register (MSC0) and applied the faster timings to u-boot, and it can
still read and write the flash properly.    System speed and memory
speed are also the same (200mhz/100mhz) for both u-boot and linux.

I started from the gumstix.org tree, so I'm currently using their
static-partitions patch until I can patch something better in.  It
only touches the maps/ directory to create their MTD partition info.

trimmed dmesg:

Linux version 2.6.15gum (harik§taz) (gcc version 3.4.5) #5 Tue May 2
18:43:14 EDT 2006
CPU: XScale-PXA255 Ä69052d06Ü revision 6 (ARMv5TE)
Machine: The Gumstix Platform
Memory policy: ECC disabled, Data cache writeback
Memory clock: 99.53MHz (*27)
Run Mode clock: 199.07MHz (*2)
Turbo Mode clock: 199.07MHz (*1.0, inactive)
CPU0: D VIVT undefined 5 cache
CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
Built 1 zonelists
Kernel command line: console=ttyS0,115200n8 rootfstype=jffs2
reboot=cold,hard init=/bin/sh root=1f01
...
Probing Gumstix Flash ROM at physical address 0x00000000 (16-bit bankwidth)
Gumstix Flash ROM: Found 1 x16 devices at 0x0 in 16-bit bank
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
Using static partitions on Gumstix Flash ROM
Creating 2 MTD partitions on "Gumstix Flash ROM":
0x00000000-0x00040000 : "Bootloader"
0x00040000-0x02000000 : "RootFS"

....

Write error in obliterating obsoleted node at 0x00102318: -30
Node header CRC failed at 0030171c. But it must have been OK earlier.
Node was: ä 0080, 2080, 00800080, 00800080 ü
Node totlen on flash (0x00800080) != totlen from node ref (0x00000030)


What are the exit points from mtd erase/write operations?  I was
thinking of putting a test-read of phys 0x0 and comparing to 0x0080 to
see if I'm getting real data, and if not, to
re-send the CFI_RESET.  I just can't follow the internals well enough
to figure where that's happening.

I have not ruled out hardware, but I have tested it quite a bit with
the CFI driver of u-boot and I havn't seen this problem there.

Thanks in advance for any help.

--Dan

Re: CFI Extended (Intel P30) problems on an ARM PXA255

[Nicolas Pitre]

On Wed, 3 May 2006, Dan Merillat wrote:

> I originally sent this to the linux-arm list, but it's looking more
> and more like either a MTD issue, or a hardware issue with our board.
> 
> We have a custom PXA255 board, based on the generic Intel reference
> design.  Nothing very
> complex at all.   RAM, Strataflash (P30), JTAG and a serial port is
> all I have active at this point.
> 
> Everything works correctly, until I try to write to the filesystem. As soon as
> I do, I start getting JFFS corruption notices.  It's fairly
> obvious what's wrong: All reads are returning 0x0080, the 'Ok' status
> bit.   I can break in the jtag, write a reset to the flash, and
> continue, and new reads work properly, until I write again (or the
> original write retries).
> 
> I thought it might be a memory timing issue, but I pulled the timing
> register (MSC0) and applied the faster timings to u-boot, and it can
> still read and write the flash properly.    System speed and memory
> speed are also the same (200mhz/100mhz) for both u-boot and linux.
> 
> I started from the gumstix.org tree, so I'm currently using their
> static-partitions patch until I can patch something better in.  It
> only touches the maps/ directory to create their MTD partition info.
> 
> trimmed dmesg:
> 
> ....
> 
> Write error in obliterating obsoleted node at 0x00102318: -30

-30 is -EROFS.

Did you unlock the flash sectors before mounting JFFS2?


Nicolas

Re: CFI Extended (Intel P30) problems on an ARM PXA255

[Dan Merillat]

On 5/4/06, Nicolas Pitre <nico@cam.org> wrote:
> On Thu, 4 May 2006, Dan Merillat wrote:
>
> > > > Write error in obliterating obsoleted node at 0x00102318: -30
> > >
> > > -30 is -EROFS.
> > >
> > > Did you unlock the flash sectors before mounting JFFS2?
> >
> > I wish it were that simple.
>
> Still, did you unlock the flash sectors?

YES, I unlocked the flash sectors.  Both partiions, all regions.  And
if the WP# line is being dropped/raised it would re-protect all the
sectors, which it's not.  I can run the commandline flash_unlock and
flash_erase (which, of course, trash everything and I have to re-flash
afterwards.)

Also, if the sectors are locked, then it's still a bug to stay in
status register mode.  A read-only flash is a valid configuration, and
should result in a read-only filesystem, not an unusable filesystem.

I verified again and again, I don't know why I got a EROFS and I wish
to god I hadn't pasted it.  No other run has gotten me this result
unless I deliberatly lock the sectors before starting linux.  I just
verified with a very slow erase all, re-upload jffs2 filesystem over
115200 serial, re-flash, crc32 verify the contents, and fill the
remaining flash with 0x0.   U-boot has no problems performing any of
this, so the flash is indeed unlocked.  Then I started linux and ended
up with the same deal, after a write whatever the first read happens
to be returns 0x0080 and gets all sorts of wacky corruption errors.

RE: CFI Extended (Intel P30) problems on an ARM PXA255

[ext-manjunath.govindashetty]

Hi ,

I am getting the kernel panic while mounting the partition using jffs2 for amd29lV256MH flash.Hence if u have some pointer for this problem please suggest. There are two chips on IXP23xx based board

Best Regards


Given below is the log of the error

 erase /dev/mtdblock/4
mtdblock_open
ok
Erase Total 1 Units
mtdblock_release
Unable to handle kernel paging request at virtual address fffffffc
mm = 40149380 pgd = 40004000
*pgd = 00002041, *pmd = 00002041, *pte = 00000000, *ppte = 00000000
Internal error: Oops: 0

Regards

-----Original Message-----
From: linux-mtd-bounces@lists.infradead.org
[mailto:linux-mtd-bounces@lists.infradead.org]On Behalf Of ext Dan
Merillat
Sent: Thursday, 04. May 2006 20:38
To: linux-mtd@lists.infradead.org
Subject: Re: CFI Extended (Intel P30) problems on an ARM PXA255


On 5/4/06, Nicolas Pitre <nico@cam.org> wrote:
> On Thu, 4 May 2006, Dan Merillat wrote:
>
> > > > Write error in obliterating obsoleted node at 0x00102318: -30
> > >
> > > -30 is -EROFS.
> > >
> > > Did you unlock the flash sectors before mounting JFFS2?
> >
> > I wish it were that simple.
>
> Still, did you unlock the flash sectors?

YES, I unlocked the flash sectors.  Both partiions, all regions.  And
if the WP# line is being dropped/raised it would re-protect all the
sectors, which it's not.  I can run the commandline flash_unlock and
flash_erase (which, of course, trash everything and I have to re-flash
afterwards.)

Also, if the sectors are locked, then it's still a bug to stay in
status register mode.  A read-only flash is a valid configuration, and
should result in a read-only filesystem, not an unusable filesystem.

I verified again and again, I don't know why I got a EROFS and I wish
to god I hadn't pasted it.  No other run has gotten me this result
unless I deliberatly lock the sectors before starting linux.  I just
verified with a very slow erase all, re-upload jffs2 filesystem over
115200 serial, re-flash, crc32 verify the contents, and fill the
remaining flash with 0x0.   U-boot has no problems performing any of
this, so the flash is indeed unlocked.  Then I started linux and ended
up with the same deal, after a write whatever the first read happens
to be returns 0x0080 and gets all sorts of wacky corruption errors.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: CFI Extended (Intel P30) problems on an ARM PXA255

[Jared Hulbert]

> Then I started linux and ended
> up with the same deal, after a write whatever the first read happens
> to be returns 0x0080 and gets all sorts of wacky corruption errors.

Okay.  Instead of mounting jffs2...
start with an erased volume.
'dd if=/dev/mtdX of=/original_data bs=32 count=1'
try 'flash_eraseall' then
'dd if=/dev/mtdX of=/erased_data bs=32 count=1'
try 'echo "jared is cool" >> /dev/mtdX'
'dd if=/dev/mtdX of=/written_data bs=32 count=1'

Now what do each *_data contain?

Re: CFI Extended (Intel P30) problems on an ARM PXA255

[David Vrabel]

Dan Merillat wrote:
> I originally sent this to the linux-arm list, but it's looking more
> and more like either a MTD issue, or a hardware issue with our board.
> 
> We have a custom PXA255 board, based on the generic Intel reference
> design.  Nothing very
> complex at all.   RAM, Strataflash (P30), JTAG and a serial port is
> all I have active at this point.
> 
> Everything works correctly, until I try to write to the filesystem. As
> soon as I do, I start getting JFFS corruption notices.  It's fairly
> obvious what's wrong: All reads are returning 0x0080, the 'Ok' status
> bit.   I can break in the jtag, write a reset to the flash, and
> continue, and new reads work properly, until I write again (or the
> original write retries).

Perhaps the cache invalidating operation in the MTD map driver you're
using is wrong?

> I thought it might be a memory timing issue, but I pulled the timing
> register (MSC0) and applied the faster timings to u-boot, and it can
> still read and write the flash properly.    System speed and memory
> speed are also the same (200mhz/100mhz) for both u-boot and linux.

If you suspect memory timings may be an issue I would advise slowing the
timings under Linux to the lowest possible.  The experiment you describe
here changes two variables (the software and the timings) which is not
good practice.

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

Re: CFI Extended (Intel P30) problems on an ARM PXA255

[Dan Merillat]

On 5/5/06, David Vrabel <dvrabel@arcom.com> wrote:
>
> Perhaps the cache invalidating operation in the MTD map driver you're
> using is wrong?

Ouch, it doesn't appear to have a map->inval_cache member.  I'm going
to copy the one from pxa25x-flash.c and see if that fixes it, however,
how could this work with an intel J3 part, but not an intel P30 part?
Same kernel exactly, booting back and forth.  It should either work
for both, or fail for both.

> If you suspect memory timings may be an issue I would advise slowing the
> timings under Linux to the lowest possible.  The experiment you describe
> here changes two variables (the software and the timings) which is not
> good practice.

I changed one variable.   I changed u-boot to use linux's memory
timings, and the problem did not manifest.  I would then conclude that
memory timing in and of itself is not the problem.

Re: CFI Extended (Intel P30) problems on an ARM PXA255

[Dan Merillat]

> On 5/5/06, David Vrabel <dvrabel@arcom.com> wrote:
> >
> > Perhaps the cache invalidating operation in the MTD map driver you're
> > using is wrong?

And no such luck there, either.

static void pxa25x_map_inval_cache(struct map_info *map, unsigned long from,
                ssize_t len)
{
        consistent_sync((char *)map->cached + from, len, DMA_FROM_DEVICE);
}

map_info.inval_cache=pxa25x_map_inval_cache;

Is that wrong? It is getting called after writes to flash.


>
> > If you suspect memory timings may be an issue I would advise slowing the
> > timings under Linux to the lowest possible.  The experiment you describe
> > here changes two variables (the software and the timings) which is not
> > good practice.

Tried it the other way around as well, set msc0 to boot-up paranoid
mode: 0x7ff07ff8 or longest waits on all reads/writes and no
burst-mode read.  No go, same deal.

# mount / -o remount,rw
# touch /tmp/test
# ls
JFFS2 notice: (1) read_unknown: node header CRC failed at 0x048f70.
But it must have been OK earlier.
Node totlen on flash (0x00800080) != totlen from node ref (0x0000004c)
JFFS2 warning: (1) jffs2_do_read_inode_internal: no data nodes found for ino #47
/bin/sh: ls: Input/output error

(xscale-gdb) monitor long 0xff000000
Read long at 0xff000000 : 0x00800080
(xscale-gdb) monitor short 0xff0000aa = 0xff
Wrote short to 0xff0000aa : 0xff
(xscale-gdb) monitor long 0xff000000
Read long at 0xff000000 : 0xea000212

same deal, I can remount RO and use the filesystem (aside from /bin/ls
which is marked invalid until I reboot)

Trying vanilla 2.6.16.14 now.