Wacky JEDEC probes

[Stefan Roese]

Hi!

I am trying to use "jedec_probe.c" on our ppc based board to support two
different flash types (AMD AM29VL160xT and SSTI SST39LF160). Both are used
in 16bit mode. Since the SST flash is not really CFI compliant, I have to
use jedec_probe, right?

Two problems:
1) 16bit support for the AM29LV160 device.
The simple solution is to add the 16bit part as new device. Works here fine.

2) Support for the ST39LF160 device.
The ID-check in every block doesn't work on this device, since it's block
size is smaller that it's unlock addresses. Therefore the ID-check in every
block has to disabled for SST devices.

Please find attached a patch for these two problems (against the current cvs
version). Any comments? Could this be commited?

Best regards,
Stefan.

> -----Ursprüngliche Nachricht-----
> Von: linux-mtd-admin at lists.infradead.org
> [mailto:linux-mtd-admin at lists.infradead.org]Im Auftrag von Thayne
> Harbaugh
> Gesendet: Montag, 3. März 2003 21:42
> An: David Woodhouse
> Cc: linux-mtd at lists.infradead.org
> Betreff: Re: Wacky JEDEC probes
>
>
> I never committed my previous patch that improved jedec probes: I wasn't
> sure if Dave did not like it or if he just wanted more checks.  I have
> revised my previous patch and added the extra checks Dave suggested and
> I intend to commit this patch if there are not any concerns.
>
> On Thu, 2003-02-20 at 09:32, David Woodhouse wrote:
> > On Wed, 2003-02-19 at 16:26, Thayne Harbaugh wrote:
>
> <snip>
>
> > > The obvious problem is that there is no way to challenge a device and
> > > discover if it truly is in ID mode.  Because of this one must assume
> > > that sending the unlock sequence was correct and really worked.
> >
> > Some devices don't _have_ an unlock sequence though.
>
> Devices that don't have an unlock sequence are marked with
> MTD_UADDR_UNNECESSARY.
>
> >  I'm more inclined
> > to follow the route of taking the chip _out_ of ident mode and checking
> > the contents change. Bear in mind that (IIRC) we should get the correct
> > ident from offset 0 and 1 in _every_ erase block, shouldn't we?
> >
> > After finding an ident, we put the chip back in read mode and check for
> > the ident again. If it hasn't changed (i.e. the data matches the ident
> > we think we saw) then go back to ident mode and check for the ids in the
> > _next_ eraseblock instead. Or something like that ;)
>
> I added a jedec_match() function that is responsible for this now.
> jedec_match() has the following sequence:
>
> 1) checks that the ID's match
>
> 2) checks if the device has an unlock sequence and that the unlock
> addresses match
>
> 3) checks for the ID in every block
>
> 4) takes the chip out of ID mode and checks for the ID in the first
> block
>
> If and only if all of the above checks succeed then the match is
> successful.
>
> I don't feel that it is necessary to check for a change in any but the
> first block.  This is ultra conservative.  The intention is that if the
> probe does not have obvious success then it might be dangerous to
> proceed.
>
> For the case where the probe fails, but there really is a device then
> there should be a module that can be loaded that takes all the device
> parameters from the command line.  That way the user can deal with
> bizarre behavior.
>
> > > - Some devices have 8 bit and 16 bit modes and have unique unlock
> > > addresses for each.  I'm not sure which ones should be used -
> that's why
> > > these cases are labeled as "FIXME."
> >
> > The one you use depends on the mode the chip is in -- you'd probably end
> > up wanting two separate entries for these chips, or depending on which
> > mode we're in.
>
> Will add this later if the current patch is acceptable.
>
> > > - It appears that some CFI devices are in the jedec_table[] - I'm not
> > > sure if this is desirable.
> >
> > Possibly not. Who added them and when? (cvs annotate :)
>
> Have not followed through on this - yet.
>
> > > - The unlock_addrs[] array enumerates the known unlock addresses.  I
> > > have noticed that these address pairs can be x555/x2aa, x555/xaaa,
> > > x5555/x2aaa, x5555/xaaaa, x0/x0.  Some of these pairs are not
> currently
> > > listed because they are used for 8 bit mode on 16 bit
> devices.  Now that
> > > these addresses are enumerated it might be better to iterate over the
> > > list instead of keep state while shifting and or'ing.
> >
> > That's a sane idea and entirely orthogonal to the original change, I
> > suppose.
>
> Have not follewed through on this either.
>
>
> --
> Thayne Harbaugh
> Linux Networx
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jedec_probe.patch
Type: application/octet-stream
Size: 3535 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20030401/d5fb8141/attachment.obj