All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Gatliff <bgat@billgatliff.com>
To: Dan Post <djp.mtd@onemyth.net>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Intel flash and cfi_probe.c
Date: Tue, 20 Jan 2004 19:29:55 -0600	[thread overview]
Message-ID: <400DD613.80601@billgatliff.com> (raw)
In-Reply-To: <20040120215050.M62159@onemyth.net>

Dan:


I've seen similar behavior with the J flashes, see my posts from a 
couple of days ago.  My temporary workaround was to issue my own 0xff in 
my map driver functions.  :^(

I noticed the F0's, but didn't wade into the datasheet enough to spot 
that as an issue...


b.g.


Dan Post wrote:

>Hi,
>
>I was looking at the cfi_probe.c file, and noticed that there are numerous
>'0xF0' commands to flash (theoretically to put the flash back into read array
>mode).  This is incorrect in terms of Intel flash; according to the datasheets
>for L18/30 and K3/18, the "read array" command is 0xFF.
>
>Normally, it would work fine (by virtue of accident, the state machine is
>coherent enough not to break after the probe), except in cases of XIP (based
>on dwmw2's code, which I have been working on and will send out probably this
>week).  It breaks the system then because 0xF0 doesn't really put an Intel
>chip into read array, so when you enable intterupts, you schedule to a
>function running out of flash, which happens to be in status mode.... == big
>bad no-run, i.e. you freeze.
>
>(Specifically, it blows up on L*...  though it seemed to "work" on K*, that
>may just be an accident or compatibility mode that wasn't put into L*.  Or
>maybe I munged my code somehow and something magically changed.  It's not in
>the datasheets, so the behavior could change at any time.  When I changed the
>0xF0's to 0xFF's, it worked on L*.)
>
>I assume that the 0xF0 is for AMD flash (a datasheet I checked out confirms
>this).  For the cfi_probe.c file to be "proper", it needs to issue 0xFF to
>Intel flash, and 0xF0 for AMD.  (Any other chips using different commands??)
>
>What would happen if we issued an 0xF0;0xFF to an AMD chip?  Or 0xFF;0xF0? 
>Any AMD chip-heads care to answer?  It looks like it will "work" on Intel chips...
>
>At any rate, either there needs to be a clever hack like that, or the
>cfi_probe.c facilities need to be refactored so they know which command to
>issue to flash.
>
>Dan
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/
>  
>

-- 
Bill Gatliff
So what part of make clean all install do you not understand?
bgat@billgatliff.com

      parent reply	other threads:[~2004-01-21  1:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-20 21:50 Intel flash and cfi_probe.c Dan Post
2004-01-20 22:40 ` Thayne Harbaugh
2004-01-20 22:44 ` David Woodhouse
2004-01-21  1:32   ` Bill Gatliff
2004-01-21  1:29 ` Bill Gatliff [this message]

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=400DD613.80601@billgatliff.com \
    --to=bgat@billgatliff.com \
    --cc=djp.mtd@onemyth.net \
    --cc=linux-mtd@lists.infradead.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.