CFI command set 0002 (AMD/Fujitsu) work.

CFI command set 0002 (AMD/Fujitsu) work.

[David Vrabel]

Hi,

I'm currently working on cfi_cmdset_0002.c to get erase-suspend-program 
working.  So far I've taken all the chip status checking code and 
refactored it into a single function -- it was all a bit of a mess.

A couple of questions:

1. There's a fair amount of crap related to very broken SST chips (all 
the stuff for retrying commands).  a) This is mess and appears only 
applicable to a very few number of chips; b) I'm not sure it would even 
work if talking to the chip is broken then retrying a few times won't 
guarantee it will work.  I'd suggest removing this stuff from 
cfi_cmdset_0002.c.  Clearly the SST chips aren't compliant even though 
they claim to be.  Thoughts?

2. The "fast programming" feature (unlock bypass) which is currently 
always disabled (due to "code brokeness"). I don't believe this will 
ever work with erase-suspends.  Should the "fast programming" stuff be 
removed?

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

Re: CFI command set 0002 (AMD/Fujitsu) work.

[David Woodhouse]

On Mon, 2004-02-16 at 14:24 +0000, David Vrabel wrote:
> I'm currently working on cfi_cmdset_0002.c to get erase-suspend-program 
> working.  So far I've taken all the chip status checking code and 
> refactored it into a single function -- it was all a bit of a mess.

Thanks for doing this.


> 1. There's a fair amount of crap related to very broken SST chips (all 
> the stuff for retrying commands).  a) This is mess and appears only 
> applicable to a very few number of chips; b) I'm not sure it would even 
> work if talking to the chip is broken then retrying a few times won't 
> guarantee it will work.  I'd suggest removing this stuff from 
> cfi_cmdset_0002.c.  Clearly the SST chips aren't compliant even though 
> they claim to be.  Thoughts?

That seems reasonable to me. It's horrid. I wonder if we could do it in
a wrapper around the 'real' chip driver, only for the broken chips?

> 2. The "fast programming" feature (unlock bypass) which is currently 
> always disabled (due to "code brokeness"). I don't believe this will 
> ever work with erase-suspends.  Should the "fast programming" stuff be 
> removed?

Yes, drop it until/unless someone wants to make it work.

-- 
dwmw2

Re: CFI command set 0002 (AMD/Fujitsu) work.

[David Vrabel]

David Vrabel wrote:
> 
> I'm currently working on cfi_cmdset_0002.c to get erase-suspend-program 
> working.

Erase-suspend-program is still disabled...

> So far I've taken all the chip status checking code and 
> refactored it into a single function -- it was all a bit of a mess.

This has been done and checked into CVS.  I believe I haven't broken 
anything.  Users of interleaved AMD chips may wish to check I didn't 
miss anything.

> 1. There's a fair amount of crap related to very broken SST chips (all 
> the stuff for retrying commands). I'd suggest removing this stuff from 
> cfi_cmdset_0002.c.

This has now been removed from CVS.

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

Re: CFI command set 0002 (AMD/Fujitsu) work.

[Thayne Harbaugh]

On Mon, 2004-02-16 at 07:24, David Vrabel wrote:

> I'm currently working on cfi_cmdset_0002.c to get erase-suspend-program 
> working.  So far I've taken all the chip status checking code and 
> refactored it into a single function -- it was all a bit of a mess.

Very nice.

> 1. There's a fair amount of crap related to very broken SST chips (all 
> the stuff for retrying commands).

There's really not that much code.

>   a) This is mess and appears only 
> applicable to a very few number of chips;

Yes - it's only for a small number.

> b) I'm not sure it would even 
> work if talking to the chip is broken then retrying a few times won't 
> guarantee it will work.

Yes, it's so horribly broken that there is *never* a guarantee that it
will work.  I can't think of a reliable way to go about it other than
give it a reasonable number of tries.

> I'd suggest removing this stuff from 
> cfi_cmdset_0002.c.  Clearly the SST chips aren't compliant even though 
> they claim to be.  Thoughts?

Sure.  It is clutter and is only for a small number of chips that should
be replaced with chips that work.  I'll see what I can do on my own to
fix the problems I have to deal with.

> 2. The "fast programming" feature (unlock bypass) which is currently 
> always disabled (due to "code brokeness"). I don't believe this will 
> ever work with erase-suspends.  Should the "fast programming" stuff be 
> removed?

I don't see a reason to keep it.

-- 
Thayne Harbaugh
Linux Networx