All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Ringle <jon@ringle.org>
To: Nicolas Pitre <nico@cam.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [SPAM]  Re: P30 flash left in read status mode after a write
Date: Wed, 14 Feb 2007 15:41:34 -0500	[thread overview]
Message-ID: <45D373FE.7080900@ringle.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0702141526130.1757@xanadu.home>

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

  reply	other threads:[~2007-02-14 20:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45D373FE.7080900@ringle.org \
    --to=jon@ringle.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nico@cam.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.