* P30 flash left in read status mode after a write
@ 2007-02-14 18:52 Jon Ringle
2007-02-14 19:14 ` Josh Boyer
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Jon Ringle @ 2007-02-14 18:52 UTC (permalink / raw)
To: linux-mtd
Hi,
We have a hardware architecture with a IXP455 processor that allows read
access to a P30 flash attached to the IXP's expansion bus from a Pentium
M that does it's access via the PCI bus. The flash has 4 partitions:
Redboot, jffs2, fconfig, fis. I am running Linux 2.6.16.29 and I've
found that whenever a write is done to the jffs2 filesystem that flash
is left in read status mode and anything trying to do a read of flash
directly reads only 0x0080. Reading from an mtd device seems to fix the
problem. I modified the mapper utility from LDD3 so I could read flash
directly from linux which illustrates the problem:
[root@rsc4 ~]# mapper /dev/mem 0x51fa0000 0x100 1|hexdump -C
mapped "/dev/mem" from 1375338496 (0x51fa0000) to 1375338752 (0x51fa0100)
00000000 00 00 10 00 0b ad fa ce 01 0c 01 00 62 6f 6f 74
|............boot|
00000010 5f 73 63 72 69 70 74 00 00 00 00 01 04 11 01 0c
|_script.........|
00000020 62 6f 6f 74 5f 73 63 72 69 70 74 5f 64 61 74 61
|boot_script_data|
00000030 00 62 6f 6f 74 5f 73 63 72 69 70 74 00 25 7b 73
|.boot_script.%{s|
00000040 6e 69 66 66 7d 0a 25 7b 67 6f 7d 0a 25 7b 66 69
|niff}.%{go}.%{fi|
00000050 78 5f 7a 49 6d 61 67 65 7d 0a 00 00 00 00 00 00
|x_zImage}.......|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
00000100
[root@rsc4 ~]# touch xyz
[root@rsc4 ~]# mapper /dev/mem 0x51fa0000 0x100 1|hexdump -C
mapped "/dev/mem" from 1375338496 (0x51fa0000) to 1375338752 (0x51fa0100)
00000000 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80
|................|
*
00000100
[root@rsc4 ~]# cat /dev/mtd2 > /dev/null
[root@rsc4 ~]# mapper /dev/mem 0x51fa0000 0x100 1|hexdump -C
mapped "/dev/mem" from 1375338496 (0x51fa0000) to 1375338752 (0x51fa0100)
00000000 00 00 10 00 0b ad fa ce 01 0c 01 00 62 6f 6f 74
|............boot|
00000010 5f 73 63 72 69 70 74 00 00 00 00 01 04 11 01 0c
|_script.........|
00000020 62 6f 6f 74 5f 73 63 72 69 70 74 5f 64 61 74 61
|boot_script_data|
00000030 00 62 6f 6f 74 5f 73 63 72 69 70 74 00 25 7b 73
|.boot_script.%{s|
00000040 6e 69 66 66 7d 0a 25 7b 67 6f 7d 0a 25 7b 66 69
|niff}.%{go}.%{fi|
00000050 78 5f 7a 49 6d 61 67 65 7d 0a 00 00 00 00 00 00
|x_zImage}.......|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
00000100
It appears that the MTD_XIP code has what I need to get flash out of
read status mode after a write, however, since I'm not actually doing
execute in place, it's overkill for my purposes. It seems that writing a
xip_enable() function that puts flash in ready mode and leaving the
other xip_* functions defined as nothing was a quick way to fix the
problem in my case:
static void __xipram xip_enable(struct map_info *map, struct flchip *chip,
unsigned long adr)
{
struct cfi_private *cfi = map->fldrv_priv;
if (chip->state != FL_POINT && chip->state != FL_READY) {
map_write(map, CMD(0xff), adr);
chip->state = FL_READY;
}
(void) map_read(map, adr);
}
This did indeed seem to fix the problem, but I'm not sure if I might
inadvertently be causing some side effect. I believe that I might be
taking a slight performance hit to consecutive jffs2 write operations
because now each write operation will need to spend more cycles putting
the flash in to a write mode.
Any advice would be appreciated.
Thanks,
Jon
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: P30 flash left in read status mode after a write
2007-02-14 18:52 P30 flash left in read status mode after a write Jon Ringle
@ 2007-02-14 19:14 ` Josh Boyer
2007-02-14 19:47 ` Nicolas Pitre
2007-02-14 20:56 ` Jörn Engel
2 siblings, 0 replies; 11+ messages in thread
From: Josh Boyer @ 2007-02-14 19:14 UTC (permalink / raw)
To: Jon Ringle; +Cc: linux-mtd
On Wed, 2007-02-14 at 13:52 -0500, Jon Ringle wrote:
> Hi,
>
> We have a hardware architecture with a IXP455 processor that allows read
> access to a P30 flash attached to the IXP's expansion bus from a Pentium
> M that does it's access via the PCI bus. The flash has 4 partitions:
> Redboot, jffs2, fconfig, fis. I am running Linux 2.6.16.29 and I've
> found that whenever a write is done to the jffs2 filesystem that flash
> is left in read status mode and anything trying to do a read of flash
> directly reads only 0x0080. Reading from an mtd device seems to fix the
Yes.
> This did indeed seem to fix the problem, but I'm not sure if I might
> inadvertently be causing some side effect. I believe that I might be
> taking a slight performance hit to consecutive jffs2 write operations
> because now each write operation will need to spend more cycles putting
> the flash in to a write mode.
You're probably better off changing the driver to put the chip back in
read mode after directly from the write function. You will, as you
correctly pointed out, incur a performance hit to consecutive JFFS2
writes.
Of course, I don't really see a problem here to being with though.
Doing the reads and writes through the MTD layer (which JFFS2 does)
should all work just fine. Unless you're trying to access the flash via
something other than MTD. If so, that is likely going to be racy.
josh
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: P30 flash left in read status mode after a write
2007-02-14 18:52 P30 flash left in read status mode after a write Jon Ringle
2007-02-14 19:14 ` Josh Boyer
@ 2007-02-14 19:47 ` Nicolas Pitre
2007-02-14 20:09 ` [SPAM] " Jon Ringle
2007-02-14 20:56 ` Jörn Engel
2 siblings, 1 reply; 11+ messages in thread
From: Nicolas Pitre @ 2007-02-14 19:47 UTC (permalink / raw)
To: Jon Ringle; +Cc: linux-mtd
On Wed, 14 Feb 2007, Jon Ringle wrote:
> I am running Linux 2.6.16.29 and I've
> found that whenever a write is done to the jffs2 filesystem that flash
> is left in read status mode and anything trying to do a read of flash
> directly reads only 0x0080. Reading from an mtd device seems to fix the
> problem.
This is done on purpose. And as you deduced yourself this is so to
avoid ...
> taking a slight performance hit to consecutive jffs2 write operations
> because now each write operation will need to spend more cycles putting
> the flash in to a write mode.
>
> Any advice would be appreciated.
First, why is this a problem for you?
Nicolas
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [SPAM] Re: P30 flash left in read status mode after a write
2007-02-14 19:47 ` Nicolas Pitre
@ 2007-02-14 20:09 ` Jon Ringle
2007-02-14 20:33 ` Nicolas Pitre
0 siblings, 1 reply; 11+ messages in thread
From: Jon Ringle @ 2007-02-14 20:09 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: linux-mtd
Nicolas Pitre wrote:
> On Wed, 14 Feb 2007, Jon Ringle wrote:
>
>
>> I am running Linux 2.6.16.29 and I've
>> found that whenever a write is done to the jffs2 filesystem that flash
>> is left in read status mode and anything trying to do a read of flash
>> directly reads only 0x0080. Reading from an mtd device seems to fix the
>> problem.
>>
>
> This is done on purpose. And as you deduced yourself this is so to
> avoid ...
>
>
>> taking a slight performance hit to consecutive jffs2 write operations
>> because now each write operation will need to spend more cycles putting
>> the flash in to a write mode.
>>
>> Any advice would be appreciated.
>>
>
> First, why is this a problem for you?
>
>
This is a problem on our (unusual) hardware because we have a Pentium M
processor (not running Linux) that reads fconfig partition outside the
context of the IXP processor that is running Linux. It does so via data
path: Pentium -> PCI -> IXP Expansion bus -> Flash. This data path
allows the Pentium to directly access the fconfig partition without
needing any active code on the IXP's arm core processor to do anything
to facilitate such access by the Pentium. However, when the mtd driver
leaves the flash in read status mode, the Pentium just reads 0x0080 when
trying to read the fconfig partition. With a change to have the mtd
driver put the flash back into ready mode after a write, then I think
that the Pentium only needs to deal with a temporary read failure if it
happens to do a read at the same time that a write is occurring on the
jffs2. In which case, the Pentium code simply spins retrying to do the
read until it is successful.
Jon
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [SPAM] Re: P30 flash left in read status mode after a write
2007-02-14 20:09 ` [SPAM] " Jon Ringle
@ 2007-02-14 20:33 ` Nicolas Pitre
2007-02-14 20:41 ` Jon Ringle
0 siblings, 1 reply; 11+ messages in thread
From: Nicolas Pitre @ 2007-02-14 20:33 UTC (permalink / raw)
To: Jon Ringle; +Cc: linux-mtd
On Wed, 14 Feb 2007, Jon Ringle wrote:
> Nicolas Pitre wrote:
> > First, why is this a problem for you?
> >
> >
> This is a problem on our (unusual) hardware because we have a Pentium M
> processor (not running Linux) that reads fconfig partition outside the context
> of the IXP processor that is running Linux. It does so via data path: Pentium
> -> PCI -> IXP Expansion bus -> Flash. This data path allows the Pentium to
> directly access the fconfig partition without needing any active code on the
> IXP's arm core processor to do anything to facilitate such access by the
> Pentium. However, when the mtd driver leaves the flash in read status mode,
> the Pentium just reads 0x0080 when trying to read the fconfig partition. With
> a change to have the mtd driver put the flash back into ready mode after a
> write, then I think that the Pentium only needs to deal with a temporary read
> failure if it happens to do a read at the same time that a write is occurring
> on the jffs2. In which case, the Pentium code simply spins retrying to do the
> read until it is successful.
And how do you determine that you have a read failure?
Because the flash doesn't necessarily always have 0x00800080 to show
when outside of the read mode.
Of course, since you have an unusual setup you can have an unusual patch
in your own kernel tree for this issue. But this isn't entirely safe
since the Pentium code might be fooled by some other flash status output
that doesn,t look like a read failure.
Nicolas
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [SPAM] Re: P30 flash left in read status mode after a write
2007-02-14 20:33 ` Nicolas Pitre
@ 2007-02-14 20:41 ` Jon Ringle
2007-02-14 20:57 ` Nicolas Pitre
0 siblings, 1 reply; 11+ messages in thread
From: Jon Ringle @ 2007-02-14 20:41 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: linux-mtd
Nicolas Pitre wrote:
> On Wed, 14 Feb 2007, Jon Ringle wrote:
>
>
>> Nicolas Pitre wrote:
>>
>>> First, why is this a problem for you?
>>>
>>>
>>>
>> This is a problem on our (unusual) hardware because we have a Pentium M
>> processor (not running Linux) that reads fconfig partition outside the context
>> of the IXP processor that is running Linux. It does so via data path: Pentium
>> -> PCI -> IXP Expansion bus -> Flash. This data path allows the Pentium to
>> directly access the fconfig partition without needing any active code on the
>> IXP's arm core processor to do anything to facilitate such access by the
>> Pentium. However, when the mtd driver leaves the flash in read status mode,
>> the Pentium just reads 0x0080 when trying to read the fconfig partition. With
>> a change to have the mtd driver put the flash back into ready mode after a
>> write, then I think that the Pentium only needs to deal with a temporary read
>> failure if it happens to do a read at the same time that a write is occurring
>> on the jffs2. In which case, the Pentium code simply spins retrying to do the
>> read until it is successful.
>>
>
> And how do you determine that you have a read failure?
>
> Because the flash doesn't necessarily always have 0x00800080 to show
> when outside of the read mode.
>
True. However, the data that is being read has magic values and a
checksum for validity, so the likelihood of a false positive on passing
these tests is extremely unlikely.
> Of course, since you have an unusual setup you can have an unusual patch
> in your own kernel tree for this issue. But this isn't entirely safe
> since the Pentium code might be fooled by some other flash status output
> that doesn,t look like a read failure.
>
I was intending for just patching my own kernel tree for this issue,
since this issue is unlikely to be of wider audience appeal. I just
wanted to present my problem to people that are more knowledgeable with
the mtd code as a sanity check for my solution.
Jon
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: P30 flash left in read status mode after a write
2007-02-14 18:52 P30 flash left in read status mode after a write Jon Ringle
2007-02-14 19:14 ` Josh Boyer
2007-02-14 19:47 ` Nicolas Pitre
@ 2007-02-14 20:56 ` Jörn Engel
2007-02-14 21:22 ` [SPAM] " Jon Ringle
2 siblings, 1 reply; 11+ messages in thread
From: Jörn Engel @ 2007-02-14 20:56 UTC (permalink / raw)
To: Jon Ringle; +Cc: linux-mtd
On Wed, 14 February 2007 13:52:31 -0500, Jon Ringle wrote:
>
> This did indeed seem to fix the problem, but I'm not sure if I might
> inadvertently be causing some side effect. I believe that I might be
> taking a slight performance hit to consecutive jffs2 write operations
> because now each write operation will need to spend more cycles putting
> the flash in to a write mode.
If the performance hit concerns you, you could set a timer instead of
changing the chip state. Only if the timer expires - which means that
consecutive writes are a non-issue - do you change the chip state.
Jörn
--
"Error protection by error detection and correction."
-- from a university class
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [SPAM] Re: P30 flash left in read status mode after a write
2007-02-14 20:41 ` Jon Ringle
@ 2007-02-14 20:57 ` Nicolas Pitre
0 siblings, 0 replies; 11+ messages in thread
From: Nicolas Pitre @ 2007-02-14 20:57 UTC (permalink / raw)
To: Jon Ringle; +Cc: linux-mtd
On Wed, 14 Feb 2007, Jon Ringle wrote:
> > And how do you determine that you have a read failure?
> >
> > Because the flash doesn't necessarily always have 0x00800080 to show
> > when outside of the read mode.
> >
> True. However, the data that is being read has magic values and a
> checksum for validity, so the likelihood of a false positive on passing
> these tests is extremely unlikely.
> > Of course, since you have an unusual setup you can have an unusual patch
> > in your own kernel tree for this issue. But this isn't entirely safe
> > since the Pentium code might be fooled by some other flash status output
> > that doesn,t look like a read failure.
> >
> I was intending for just patching my own kernel tree for this issue,
> since this issue is unlikely to be of wider audience appeal. I just
> wanted to present my problem to people that are more knowledgeable with
> the mtd code as a sanity check for my solution.
Your solution looked sane.
Nicolas
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [SPAM] Re: P30 flash left in read status mode after a write
2007-02-14 20:56 ` Jörn Engel
@ 2007-02-14 21:22 ` Jon Ringle
2007-02-14 21:34 ` Nicolas Pitre
0 siblings, 1 reply; 11+ messages in thread
From: Jon Ringle @ 2007-02-14 21:22 UTC (permalink / raw)
To: Jörn Engel; +Cc: linux-mtd
Jörn Engel wrote:
> On Wed, 14 February 2007 13:52:31 -0500, Jon Ringle wrote:
>
>> This did indeed seem to fix the problem, but I'm not sure if I might
>> inadvertently be causing some side effect. I believe that I might be
>> taking a slight performance hit to consecutive jffs2 write operations
>> because now each write operation will need to spend more cycles putting
>> the flash in to a write mode.
>>
>
> If the performance hit concerns you, you could set a timer instead of
> changing the chip state. Only if the timer expires - which means that
> consecutive writes are a non-issue - do you change the chip state.
>
>
Using a timer sounds like a good idea. I'll keep it in mind. I'm not
sure yet whether I'm concerned about the performance hit as I haven't
profiled the impact yet. Has anyone got any data that shows what kind of
improvement jffs2 write operations get with this optimization in place
to leave flash in read status mode?
Jon
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [SPAM] Re: P30 flash left in read status mode after a write
2007-02-14 21:22 ` [SPAM] " Jon Ringle
@ 2007-02-14 21:34 ` Nicolas Pitre
2007-02-20 19:11 ` Alexey Korolev
0 siblings, 1 reply; 11+ messages in thread
From: Nicolas Pitre @ 2007-02-14 21:34 UTC (permalink / raw)
To: Jon Ringle; +Cc: linux-mtd, Jörn Engel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1123 bytes --]
On Wed, 14 Feb 2007, Jon Ringle wrote:
> Jörn Engel wrote:
> > On Wed, 14 February 2007 13:52:31 -0500, Jon Ringle wrote:
> >
> >> This did indeed seem to fix the problem, but I'm not sure if I might
> >> inadvertently be causing some side effect. I believe that I might be
> >> taking a slight performance hit to consecutive jffs2 write operations
> >> because now each write operation will need to spend more cycles putting
> >> the flash in to a write mode.
> >>
> >
> > If the performance hit concerns you, you could set a timer instead of
> > changing the chip state. Only if the timer expires - which means that
> > consecutive writes are a non-issue - do you change the chip state.
> >
> >
> Using a timer sounds like a good idea. I'll keep it in mind. I'm not
> sure yet whether I'm concerned about the performance hit as I haven't
> profiled the impact yet. Has anyone got any data that shows what kind of
> improvement jffs2 write operations get with this optimization in place
> to leave flash in read status mode?
It should be fairly minimal. Probably less than 5% difference.
Nicolas
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [SPAM] Re: P30 flash left in read status mode after a write
2007-02-14 21:34 ` Nicolas Pitre
@ 2007-02-20 19:11 ` Alexey Korolev
0 siblings, 0 replies; 11+ messages in thread
From: Alexey Korolev @ 2007-02-20 19:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jörn Engel, linux-mtd
HI ALL.
I'm not sure if it could help but it remind me one bug I faced over a year ago. Could you please try this fixup. It fixes improper CFI parsing in CFI drivers.
--- trunk/drivers/mtd/chips/cfi_cmdset_0001.c (revision 8)
+++ trunk/drivers/mtd/chips/cfi_cmdset_0001.c (revision 10)
@@ -285,7 +285,7 @@
sizeof(struct cfi_intelext_otpinfo);
/* Burst Read info */
- extra_size += (extp->MinorVersion < '4') ? 6 : 5;
+ extra_size += (unsigned int)extp->extra[extra_size+1]+2;
/* Number of hardware-partitions */
extra_size += 1;
@@ -519,7 +519,7 @@
sizeof(struct cfi_intelext_otpinfo);
/* Burst Read info */
- offs += (extp->MinorVersion < '4') ? 6 : 5;
+ offs += (int)extp->extra[offs+1]+2;
-------------------------------------
Original fix message is here:http://lists.infradead.org/pipermail/linux-mtd/2005-October/014144.html
Thanks
Alexey
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2007-02-20 19:11 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-14 18:52 P30 flash left in read status mode after a write Jon Ringle
2007-02-14 19:14 ` Josh Boyer
2007-02-14 19:47 ` Nicolas Pitre
2007-02-14 20:09 ` [SPAM] " Jon Ringle
2007-02-14 20:33 ` Nicolas Pitre
2007-02-14 20:41 ` Jon Ringle
2007-02-14 20:57 ` Nicolas Pitre
2007-02-14 20:56 ` Jörn Engel
2007-02-14 21:22 ` [SPAM] " Jon Ringle
2007-02-14 21:34 ` Nicolas Pitre
2007-02-20 19:11 ` Alexey Korolev
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.