public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
* jedec_probe.c bug: AMD AM29LV800 in byte mode
@ 2005-02-18 16:48 Steve Wahl
  0 siblings, 0 replies; 2+ messages in thread
From: Steve Wahl @ 2005-02-18 16:48 UTC (permalink / raw)
  To: linux-mtd

Hello, list.

I'm newly returning to this list; I used to be on it, went through a
change in employment, and now, surprise, I'm doing some related work
again.

I emailed David (dwmw2) directly to ask how I should aproach this, but
he either didn't get it or correctly blew me off :-).  I'm assuming
the former, but hold nothing against him if it's the latter.

I did see one other post in the archives that refered to the *400, not
*800 version of this chip, but I didn't see any real solution.

The meat of the problem is: when this chip is in byte mode, the id
should be read from location 2, and when the chip is in word mode, the
id should be read from location 1.  The jedec_read_id() code does the
exact opposite.

I'd be more than willing to develop and offer a patch, but I don't
have a clue as to the range of chips this code applies to, and how to
know which ones need to change.  The best I can suggest at the moment
is reading both locations and indicating in the jedec_table[] which
location should be compared with. (Does anybody think that's the right
way to go?  I'll see if I can work such a patch up if so...)

I have a current patch which just changes the location where ID is
read from.  It makes this chip work, but of course breaks all the
others.  

Background:

    System is based on a PPC chip, is currently running Linux 2.4 with
    the old amd_flash.c driver (with a similar patch).  I'm porting
    Linux 2.6 to this system.  Previous 2.4 port person just did the
    patch on his own for this company and as far as I can tell didn't
    inform the world that a change had to be made.  I'd rather get the
    mainline MTD code working so that (A) future ports (Linux 2.8?)
    won't run into the problem, and (B) I have a set of code that will
    still work when my hardware guys decide to change to a flash chip
    that my current kludge breaks.

    If anyone cares, we're not running a filesystem on this chip, just
    need to re-write the boot code with it.  We have another chip
    that's NAND, on which we're using YAFFS.

Thanks for listening,

--> Steve Wahl, Qlogic Corporation.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* jedec_probe.c bug: AMD AM29LV800 in byte mode
@ 2005-03-08 19:08 Steve Wahl
  0 siblings, 0 replies; 2+ messages in thread
From: Steve Wahl @ 2005-03-08 19:08 UTC (permalink / raw)
  To: linux-mtd

[Trying again, maybe I was overbose last time. :-) If I missed a
response, feel free to bash me with a clue-by-4.]

When this chip (AM29LV800) is in byte mode, the id should be read from
location 2, and when in word mode, the id should be read from location
1.

jedec_read_id() (jedec_probe.c, near line 1675) seems to do the exact
opposite (read from 2 in word mode, and 1 in byte mode).  Because of
this, it is not finding this chip for me.  

I hacked it to always read from 2 rather than 1.

I'm willing to develop a patch for this, but I'm sure some chips
actually work with the current code, and I don't want to break them.
So I need some guidance on how to proceed.

Should I be reading both location 1 and location 2, and add a field to
jedec_table[] that indicates which location(s) to compare with?

--> Steve Wahl, Qlogic Corporation

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-03-08 19:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-08 19:08 jedec_probe.c bug: AMD AM29LV800 in byte mode Steve Wahl
  -- strict thread matches above, loose matches on Subject: below --
2005-02-18 16:48 Steve Wahl

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox