Problem with cfi_probe.c and Intel chip

Problem with cfi_probe.c and Intel chip

[Alice Hennessy]

Hello,

I just tried the latest code  and discovered that the command used
before the query command  and also to
return to read mode  in cfi_probe.c  has been changed to 0xF0 - it used
to be 0xFF .  The board I'm testing
on has an Intel strata chip and is not responding to the query.  If I
use 0xFF, then everything is fine.  AMD chips
seems to be happy with either command (I think because the
AMD automatically returns to read mode after
a command anyway).   It looks like this was changed with the jedec-probe

additions so maybe this is necessary
for older jedec chips (which I haven't tested).

Alice

Re: Problem with cfi_probe.c and Intel chip

[David Woodhouse]

ahennessy@mvista.com said:
> I just tried the latest code  and discovered that the command used
> before the query command  and also to return to read mode  in
> cfi_probe.c  has been changed to 0xF0 - it used to be 0xFF .  The
> board I'm testing on has an Intel strata chip and is not responding to
> the query.  If I use 0xFF, then everything is fine.  AMD chips seems
> to be happy with either command (

I seem to recall someone complaining before, and having to change it. But 
if so, I don't see why it only came in with the jedec-probe stuff. 

Three options:
1. Change it to 0xFF and see if anyone screams.
2. Make it send both 0xFF and 0xF0.
3. Make it work out what type of chip it's talking to and send the _right_ 
	command.



--
dwmw2

Re: Problem with cfi_probe.c and Intel chip

[Eric W. Biederman]

Alice Hennessy <ahennessy@mvista.com> writes:

> Hello,
> 
> I just tried the latest code  and discovered that the command used
> before the query command  and also to
> return to read mode  in cfi_probe.c  has been changed to 0xF0 - it used
> to be 0xFF .  The board I'm testing
> on has an Intel strata chip and is not responding to the query.  If I
> use 0xFF, then everything is fine.  AMD chips
> seems to be happy with either command (I think because the
> AMD automatically returns to read mode after
> a command anyway).   It looks like this was changed with the jedec-probe
> 
> additions so maybe this is necessary
> for older jedec chips (which I haven't tested).

In this case it works for all of intel chips I have, so I thought the extra
0xFF in the reset, was put in by someone being extra careful, and not someone
having problems...

I'll reenable it in just a minute.

Eric

Re: Problem with cfi_probe.c and Intel chip

[Eric W. Biederman]

David Woodhouse <dwmw2@infradead.org> writes:

> ahennessy@mvista.com said:
> > I just tried the latest code  and discovered that the command used
> > before the query command  and also to return to read mode  in
> > cfi_probe.c  has been changed to 0xF0 - it used to be 0xFF .  The
> > board I'm testing on has an Intel strata chip and is not responding to
> > the query.  If I use 0xFF, then everything is fine.  AMD chips seems
> > to be happy with either command (
> 
> I seem to recall someone complaining before, and having to change it. But 
> if so, I don't see why it only came in with the jedec-probe stuff. 

O.k. I just did a skim through the JEDEC 21c section 3.5 assuming most
of the time flash designers would follow a variant of the standard.
And at various points both 0xF0 and 0xFF are mentioned as a reset,
with perhaps a little preference towards 0xFF.

The probe algorithm is pretty much reset the chip, and then read it's
id.  So there isn't a lot that can be simplified there.

We are pretty much probing for the jedec 1 byte command set
(intel) or the jedec multibyte command set (amd).  With respect to the
single byte command set, we are already sending the nonsense byte
multibyte prefix and expecting it to ignore it.  So expecting the
multibyte command set to ignore the reset for the single byte command
set is reasonable.  

If we run into further problems we can detangle the single byte and
the multibyte command set probes.
 
> Three options:
> 1. Change it to 0xFF and see if anyone screams.
Well I just did remove 0xFF and see if anyone screams, I should have
looked closer but I thought it was an intel specific then, and nothing
I have required it.  Though I admit 0xFF was not there originally.

> 2. Make it send both 0xFF and 0xF0.
So far I haven't heard of any breakage with this combination.  And now
that I have double checked and discovered in some weird fashion that
they are both equally valid, it is probably safe to leave them both
in.  At least until we hear of further breakage.

> 3. Make it work out what type of chip it's talking to and send the _right_ 
> 	command.
This suffers from extreme catch22.



Eric

Re: Problem with cfi_probe.c and Intel chip

[Alice Hennessy]

"Eric W. Biederman" wrote:

> David Woodhouse <dwmw2@infradead.org> writes:
>
> > ahennessy@mvista.com said:
> > > I just tried the latest code  and discovered that the command used
> > > before the query command  and also to return to read mode  in
> > > cfi_probe.c  has been changed to 0xF0 - it used to be 0xFF .  The
> > > board I'm testing on has an Intel strata chip and is not responding to
> > > the query.  If I use 0xFF, then everything is fine.  AMD chips seems
> > > to be happy with either command (
> >
> > I seem to recall someone complaining before, and having to change it. But
> > if so, I don't see why it only came in with the jedec-probe stuff.
>
> O.k. I just did a skim through the JEDEC 21c section 3.5 assuming most
> of the time flash designers would follow a variant of the standard.
> And at various points both 0xF0 and 0xFF are mentioned as a reset,
> with perhaps a little preference towards 0xFF.
>
> The probe algorithm is pretty much reset the chip, and then read it's
> id.  So there isn't a lot that can be simplified there.
>
> We are pretty much probing for the jedec 1 byte command set
> (intel) or the jedec multibyte command set (amd).  With respect to the
> single byte command set, we are already sending the nonsense byte
> multibyte prefix and expecting it to ignore it.  So expecting the
> multibyte command set to ignore the reset for the single byte command
> set is reasonable.
>
> If we run into further problems we can detangle the single byte and
> the multibyte command set probes.
>
> > Three options:
> > 1. Change it to 0xFF and see if anyone screams.
> Well I just did remove 0xFF and see if anyone screams, I should have
> looked closer but I thought it was an intel specific then, and nothing
> I have required it.  Though I admit 0xFF was not there originally.
>
> > 2. Make it send both 0xFF and 0xF0.
> So far I haven't heard of any breakage with this combination.  And now
> that I have double checked and discovered in some weird fashion that
> they are both equally valid, it is probably safe to leave them both
> in.  At least until we hear of further breakage.
>
> > 3. Make it work out what type of chip it's talking to and send the _right_
> >       command.
> This suffers from extreme catch22.
>
> Eric
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

>From reading the Intel spec,  I don't see any reason putting the chip into read
array
mode (0xff) would be necessary before the query command so I'm not sure why
my board is having problems.  Even if the bios has issued a command to the
flash
between power up and cfi_probe,  I don't think read array command is necessary
between commands.
If my board is the only Intel with a problem, then I need to investigate it
further.

Alice

Re: Problem with cfi_probe.c and Intel chip

[Jonas Holmberg]

On Thu, 2002-01-10 at 23:47, David Woodhouse wrote:
> 
> ahennessy@mvista.com said:
> > I just tried the latest code  and discovered that the command used
> > before the query command  and also to return to read mode  in
> > cfi_probe.c  has been changed to 0xF0 - it used to be 0xFF .  The
> > board I'm testing on has an Intel strata chip and is not responding to
> > the query.  If I use 0xFF, then everything is fine.  AMD chips seems
> > to be happy with either command (
> 
> I seem to recall someone complaining before, and having to change it. But 
> if so, I don't see why it only came in with the jedec-probe stuff. 
> 
> Three options:
> 1. Change it to 0xFF and see if anyone screams.

I will! Toshiba 8MiB (TC58FVT641FT) won't leave autoselect mode if you
change that. Then amd_flash_probe (and jedec_probe I suppose) will not
be able to detect "mirrors" of previously found chips.

/Jonas

> 2. Make it send both 0xFF and 0xF0.
> 3. Make it work out what type of chip it's talking to and send the _right_ 
> 	command.
> 
> 
> 
> --
> dwmw2
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Problem with cfi_probe.c and Intel chip

[Jonas Holmberg]

> > 1. Change it to 0xFF and see if anyone screams.
> I will!

Scream, that is.

> Toshiba 8MiB (TC58FVT641FT) won't leave autoselect mode if you
> change that. Then amd_flash_probe (and jedec_probe I suppose) will not
> be able to detect "mirrors" of previously found chips. /Jonas

Forget the part about amd_flash_probe and jedec_probe. What I meant was
cfi_probe (TC58FVT641FT is a CFI-chip, and I shouldn't write emails
while programming).

/Jonas

Re: Problem with cfi_probe.c and Intel chip

[Eric W. Biederman]

Alice Hennessy <ahennessy@mvista.com> writes:

> array
> mode (0xff) would be necessary before the query command so I'm not sure why
> my board is having problems.  Even if the bios has issued a command to the
> flash
> between power up and cfi_probe,  I don't think read array command is necessary
> between commands.
> If my board is the only Intel with a problem, then I need to investigate it
> further.

That would certainly be useful.  My real suspicion is that this code hasn't
been utilized all that much, and we are entering it's first real
stabalization phase.  Since all I did was comment out what looked like
redundant code, I actually think you are the second person to notice
this.   Personally I have deal with boot block type flash memory,
which may have different characteristics than other intel product lines.

Having a couple of people get a firm grasp on what things cause
problems, is probably needed right now.  So if you come up with
anything interesting I'd be glad to hear it.

Eric

Re: Problem with cfi_probe.c and Intel chip

[Alice Hennessy]

"Eric W. Biederman" wrote:

> Alice Hennessy <ahennessy@mvista.com> writes:
>
> > array
> > mode (0xff) would be necessary before the query command so I'm not sure why
> > my board is having problems.  Even if the bios has issued a command to the
> > flash
> > between power up and cfi_probe,  I don't think read array command is necessary
> > between commands.
> > If my board is the only Intel with a problem, then I need to investigate it
> > further.
>
> That would certainly be useful.  My real suspicion is that this code hasn't
> been utilized all that much, and we are entering it's first real
> stabalization phase.  Since all I did was comment out what looked like
> redundant code, I actually think you are the second person to notice
> this.   Personally I have deal with boot block type flash memory,
> which may have different characteristics than other intel product lines.
>
> Having a couple of people get a firm grasp on what things cause
> problems, is probably needed right now.  So if you come up with
> anything interesting I'd be glad to hear it.
>
> Eric

I will do that.

Alice