jedec_probe.c

Joshua Wise joshua at joshuawise.com
Sat Jul 5 21:57:04 EDT 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 05 July 2003 7:19 pm, Eric W. Biederman wrote:
> > But IMHO it does a bad job of doing it. It needs to go through each chip
> > in order, and try each chip's unlock addresses in order, as opposed to
> > guessing at unlock addresses based on interleave and chip type.

Bah, I was just pissed off :), I meant go through each chip in the array.

> I would hate to get to the point where the order of the table entries
> matters.  Magic table orders are very hard to maintain properly, and
> very easy for one inattentive update to break.  jedec_probe does get
> a manufacturer id and a device id which makes it good enough that with
> a few refinements it should be able to handle this.  A better
> algorithm for selecting the unlock addresses is certainly desirable,
> and now we have a test case, where it actually matters.

Right. This is what I mean - jedec_probe cannot use the generic probing 
functions that assume that we can query chips by doing something like Q/R/Y, 
it instead should loop.

> cfi_private in this case is more badly named then anything.  It holds
> generic parameters that describe NOR flash devices.   The history
> is that the cfi code was written first with a generic infrastructure.

Right, right - I was just confused to hell and back :)

> And then it was realized that chips that implemented the older probe
> had the same set of requirements and the same set of commands, just
> a less convenient probe method, that does not provide all of the
> information needed to use a random flash chip.  Instead that
> information needs to be looked up in a table.

goto part_where_joshua_whines_about_using_generic_probing; // :)

> To clarify I meant things like the command set/chip drivers and the
> like.  In particular I meant a driver for sufficiently strange
> hardware can fill in a mtd_info structure with a fully custom set
> of methods and all of the upper layers will work.

Oh, interesting.

> Hmm.  I am surprised that this has problems as it looks like a pretty
> standard part.  But looking at the table of commands on page 19 it
> does appear that the standard guesses we make don't seem to line up.

Indeed, I got it working over JTAG with relatively little trouble (the main 
issue being that to program, it must be used in word mode.)

> Does it work if you just hard code the address in jedec_probe_chip?
> Just to confirm which piece needs to get fixed.

I'd assume that it would. Is jedec_probe_chip used anywhere other than 
jedec_probe?

> Eric
~joshua

- -- 
Joshua Wise | www.joshuawise.com
GPG Key     | 0xEA80E0B3
Quote       | <lilo> I akilled *@* by mistake
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/B4HwPn9tWOqA4LMRAvoRAJ0RQ4mXtk+FGIZIAfR1WsuBx2gYnwCfYTs3
xwZ1xpcJsyoyjO6HTFZnHIw=
=koC6
-----END PGP SIGNATURE-----




More information about the linux-mtd mailing list