[Help] SST39VF6401B Support

[Help] SST39VF6401B Support

[Flávio Silveira]

Hi,

  I'm new to this list, so I'm not sure if I'm doing it correctly.

  I'm trying to get this chip supported by the 3rd party router firmware I 
use. The developer from this firmware applied latest patches from git but 
console log still says "pflash: cfi_probe failed" and then kernel panic.

  I tried to enable some debug without success.

  Any help appreciated

Flavio 

Re: [Help] SST39VF6401B Support

[Yegor Yefremov]

>  I'm new to this list, so I'm not sure if I'm doing it correctly.
>
>  I'm trying to get this chip supported by the 3rd party router firmware I
> use. The developer from this firmware applied latest patches from git but
> console log still says "pflash: cfi_probe failed" and then kernel panic.
>
>  I tried to enable some debug without success.
>
>  Any help appreciated

Some time ago I've got this flash chip working with this patch
https://patchwork.kernel.org/patch/32333/. Try enabling JEDEC_PROBE in
your kernel. Unfortunately I don't have such a system now to try this
patch with a newer kernel.

Regards,
Yegor

Re: [Help] SST39VF6401B Support

[Flávio Silveira]

Hi Yegor,

  Thanks for your response. Does this mean this chip isn't CFI compliant? 
Like, datasheet says it is, but not really.
 Sorry if I sound confused, I've never messed with flashchips before so 
names and terms are still complicated.

Regards,
  Flavio

----- Original Message ----- 
From: "Yegor Yefremov" <yegorslists@googlemail.com>
To: "Flávio Silveira" <fggs@terra.com.br>
Cc: <linux-mtd@lists.infradead.org>
Sent: Thursday, September 23, 2010 4:28 AM
Subject: Re: [Help] SST39VF6401B Support


>> I'm new to this list, so I'm not sure if I'm doing it correctly.
>>
>> I'm trying to get this chip supported by the 3rd party router firmware I
>> use. The developer from this firmware applied latest patches from git but
>> console log still says "pflash: cfi_probe failed" and then kernel panic.
>>
>> I tried to enable some debug without success.
>>
>> Any help appreciated
>
> Some time ago I've got this flash chip working with this patch
> https://patchwork.kernel.org/patch/32333/. Try enabling JEDEC_PROBE in
> your kernel. Unfortunately I don't have such a system now to try this
> patch with a newer kernel.
>
> Regards,
> Yegor
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

Re: [Help] SST39VF6401B Support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 394 bytes --]


>  Thanks for your response. Does this mean this chip isn't CFI
> compliant? Like, datasheet says it is, but not really.

SST? Broken CFI happened to me, too :(
http://patchwork.ozlabs.org/patch/51027/

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Help] SST39VF6401B Support

[Flávio Silveira]

Hi Wofram,

  Thanks for your response. What do you mean by broken CFI?
  Also, as you seem with way more experience than me, do you know if 
cfi_probe do 3 cycle command for SST CFI Query Entry?
  If you could check: http://www.sst.com/dotAsset/40483.pdf
  Give me your thoughts about it

Regards,
  Flavio

----- Original Message ----- 
From: "Wolfram Sang" <w.sang@pengutronix.de>
To: "Flávio Silveira" <fggs@terra.com.br>
Cc: "Yegor Yefremov" <yegorslists@googlemail.com>; 
<linux-mtd@lists.infradead.org>
Sent: Thursday, September 23, 2010 9:05 AM
Subject: Re: [Help] SST39VF6401B Support

Re: [Help] SST39VF6401B Support

[Yegor Yefremov]

>  Thanks for your response. Does this mean this chip isn't CFI compliant?
> Like, datasheet says it is, but not really.
> Sorry if I sound confused, I've never messed with flashchips before so names
> and terms are still complicated.

Just to apply the patch and see what happens. The most important part
of this patch is:

Please refer to the data sheets Table 6:
39VF6401B data sheet http://www.sst.com/downloads/datasheet/S71288.pdf
39VF6401 data sheet http://www.sst.com/downloads/datasheet/S71223-03.pdf

The difference in the 6th bus write cycle. 39VF6401B uses 0x50 and
39VF6401 uses 0x30.

Without this even if the chip gets detected you cannot write to it.

I haven't look at this since my try to submit this patch, so I don't
know how to fix the stuff for cfi_probe.

Regards,
Yegor

Re: [Help] SST39VF6401B Support

[Guillaume LECERF]

2010/9/23 Wolfram Sang <w.sang@pengutronix.de>:
>
>>  Thanks for your response. Does this mean this chip isn't CFI
>> compliant? Like, datasheet says it is, but not really.
>
> SST? Broken CFI happened to me, too :(
> http://patchwork.ozlabs.org/patch/51027/

This patch [1] (tried to) add support for your chip.
According to the datasheet [2], it uses addr_unlock1 = 0x555 and
addr_unlock2 = 0x2AA, and has no extended query table.
So this chip must be handled by the fixup_sst39vf_rev_b() fixup function.

Could you provide us with a more detailed log, i.e. with
DEBUG_CFI_FEATURES enabled in cfi_cmdset_0002.c and DEBUG_CFI in
cfi_probe.c ?


[1] http://patchwork.ozlabs.org/patch/50906/
[2] http://www.sst.com/dotAsset/40661.pdf
-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org

Re: [Help] SST39VF6401B Support

[Flávio Silveira]

Ok, I'll see if I can build a firmware with jedec enabled and your patch. 
Thanks!

Regards,
  Flavio

----- Original Message ----- 
From: "Yegor Yefremov" <yegorslists@googlemail.com>
To: "Flávio Silveira" <fggs@terra.com.br>
Cc: <linux-mtd@lists.infradead.org>
Sent: Thursday, September 23, 2010 9:18 AM
Subject: Re: [Help] SST39VF6401B Support


> Thanks for your response. Does this mean this chip isn't CFI compliant?
> Like, datasheet says it is, but not really.
> Sorry if I sound confused, I've never messed with flashchips before so 
> names
> and terms are still complicated.

Just to apply the patch and see what happens. The most important part
of this patch is:

Please refer to the data sheets Table 6:
39VF6401B data sheet http://www.sst.com/downloads/datasheet/S71288.pdf
39VF6401 data sheet http://www.sst.com/downloads/datasheet/S71223-03.pdf

The difference in the 6th bus write cycle. 39VF6401B uses 0x50 and
39VF6401 uses 0x30.

Without this even if the chip gets detected you cannot write to it.

I haven't look at this since my try to submit this patch, so I don't
know how to fix the stuff for cfi_probe.

Regards,
Yegor

Re: [Help] SST39VF6401B Support

[Yegor Yefremov]

> Ok, I'll see if I can build a firmware with jedec enabled and your patch.

By the way, what's your kernel version?

Yegor

Re: [Help] SST39VF6401B Support

[Flávio Silveira]

Hi Guillaume,

  I know you asked for Wolfram logs but just for you to know, I tried 
enabling DEBUG_CFI but no new output than before.
  Never tried DEBUG_CFI_FEATURES though.
  What output should I expect from both? The only thing I see is "pflash: 
cfi_probe failed"

Regards,
  Flavio

----- Original Message ----- 
From: "Guillaume LECERF" <glecerf@gmail.com>
To: "Wolfram Sang" <w.sang@pengutronix.de>
Cc: "Flávio Silveira" <fggs@terra.com.br>; <linux-mtd@lists.infradead.org>; 
"Yegor Yefremov" <yegorslists@googlemail.com>
Sent: Thursday, September 23, 2010 9:23 AM
Subject: Re: [Help] SST39VF6401B Support


2010/9/23 Wolfram Sang <w.sang@pengutronix.de>:
>
>> Thanks for your response. Does this mean this chip isn't CFI
>> compliant? Like, datasheet says it is, but not really.
>
> SST? Broken CFI happened to me, too :(
> http://patchwork.ozlabs.org/patch/51027/

This patch [1] (tried to) add support for your chip.
According to the datasheet [2], it uses addr_unlock1 = 0x555 and
addr_unlock2 = 0x2AA, and has no extended query table.
So this chip must be handled by the fixup_sst39vf_rev_b() fixup function.

Could you provide us with a more detailed log, i.e. with
DEBUG_CFI_FEATURES enabled in cfi_cmdset_0002.c and DEBUG_CFI in
cfi_probe.c ?


[1] http://patchwork.ozlabs.org/patch/50906/
[2] http://www.sst.com/dotAsset/40661.pdf
-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org

Re: [Help] SST39VF6401B Support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]


>  Thanks for your response. What do you mean by broken CFI?

Well, ehrm, it is broken :) It simply doesn't work the way it is
expected, due to the custom unlock address.

>  Also, as you seem with way more experience than me, do you know if
> cfi_probe do 3 cycle command for SST CFI Query Entry?
>  If you could check: http://www.sst.com/dotAsset/40483.pdf
>  Give me your thoughts about it

Sorry, besides my initial pointer, I have too many other things going on
today. But it seems Guillaume had a look and will guide you.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Help] SST39VF6401B Support

[Flávio Silveira]

It's kernel 2.6.23 with some patches, they call it 2.6.24.111

Flavio

----- Original Message ----- 
From: "Yegor Yefremov" <yegorslists@googlemail.com>
To: "Flávio Silveira" <fggs@terra.com.br>
Cc: <linux-mtd@lists.infradead.org>
Sent: Thursday, September 23, 2010 9:33 AM
Subject: Re: [Help] SST39VF6401B Support


>> Ok, I'll see if I can build a firmware with jedec enabled and your patch.
>
> By the way, what's your kernel version?
>
> Yegor
> 

Re: [Help] SST39VF6401B Support

[Yegor Yefremov]

> It's kernel 2.6.23 with some patches, they call it 2.6.24.111

It is really old! This is a gap of more than 10 kernel versions! Any
chance to get something newer? 2.6.35?

I could imagine, that the patches mentioned in this thread could fail
due to old kernel. Many things like JEDEC and CFI probes were greatly
improved since then. I tested my patch for 2.6.29. .27 and .28 may
also work.

Yegor

Re: [Help] SST39VF6401B Support

[Flávio Silveira]

Well, I never tried the patch for JEDEC as firmware doesn't use it yet.
 I'm still trying to build then test other things, thanks for your help!

Flavio

----- Original Message ----- 
From: "Yegor Yefremov" <yegorslists@googlemail.com>
To: "Flávio Silveira" <fggs@terra.com.br>
Cc: <linux-mtd@lists.infradead.org>
Sent: Thursday, September 23, 2010 10:45 AM
Subject: Re: [Help] SST39VF6401B Support


>> It's kernel 2.6.23 with some patches, they call it 2.6.24.111
>
> It is really old! This is a gap of more than 10 kernel versions! Any
> chance to get something newer? 2.6.35?
>
> I could imagine, that the patches mentioned in this thread could fail
> due to old kernel. Many things like JEDEC and CFI probes were greatly
> improved since then. I tested my patch for 2.6.29. .27 and .28 may
> also work.
>
> Yegor
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

Re: [Help] SST39VF6401B Support

[Flávio Silveira]

Hi Yegor,

I think I might found something:

In cfi_probe.c, starting at line 222, there are these lines:

cfi_send_gen_cmd(0xaa, addr_unlock1, base, map, cfi, cfi->device_type, 
NULL);
cfi_send_gen_cmd(0x55, addr_unlock2, base, map, cfi, cfi->device_type, 
NULL);
cfi_send_gen_cmd(0x90, addr_unlock1, base, map, cfi, cfi->device_type, 
NULL);

Which seems the correct way to CFI query the chip, but the last line is 
0x90.
Datasheet states that 0x90 is Software ID and CFI Query Entry is 0x98

Could that be the problem?

Regards,

Flavio

----- Original Message ----- 
From: "Yegor Yefremov" <yegorslists@googlemail.com>
To: "Flávio Silveira" <fggs@terra.com.br>
Cc: <linux-mtd@lists.infradead.org>
Sent: Thursday, September 23, 2010 10:45 AM
Subject: Re: [Help] SST39VF6401B Support


>> It's kernel 2.6.23 with some patches, they call it 2.6.24.111
>
> It is really old! This is a gap of more than 10 kernel versions! Any
> chance to get something newer? 2.6.35?
>
> I could imagine, that the patches mentioned in this thread could fail
> due to old kernel. Many things like JEDEC and CFI probes were greatly
> improved since then. I tested my patch for 2.6.29. .27 and .28 may
> also work.
>
> Yegor
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

Re: [Help] SST39VF6401B Support

[Yegor Yefremov]

Hi Flávio,

> I think I might found something:
>
> In cfi_probe.c, starting at line 222, there are these lines:
>
> cfi_send_gen_cmd(0xaa, addr_unlock1, base, map, cfi, cfi->device_type,
> NULL);
> cfi_send_gen_cmd(0x55, addr_unlock2, base, map, cfi, cfi->device_type,
> NULL);
> cfi_send_gen_cmd(0x90, addr_unlock1, base, map, cfi, cfi->device_type,
> NULL);
>
> Which seems the correct way to CFI query the chip, but the last line is
> 0x90.
> Datasheet states that 0x90 is Software ID and CFI Query Entry is 0x98
>
> Could that be the problem?

I'm not sure it is. Because if you compare both SST39VF6401B and
SST39VF3201, they both have the same sequences for Software ID and CFI
Query Entry. The SST39VF3201 will be detected without JEDEC probe in
2.6.35, so only by cfi_probe() means.

Try to apply this patch http://patchwork.ozlabs.org/patch/50906/, that
was mentioned by Guillaume.

Regards,
Yegor

Re: [Help] SST39VF6401B Support

[Fabio Giovagnini]

I solved with Gullielme suggestment on SST39VF6402B.

Cheers

Is the problem solved now?

In data giovedì 23 settembre 2010 14:23:27, Guillaume LECERF ha scritto:
: > 2010/9/23 Wolfram Sang <w.sang@pengutronix.de>:
> >>  Thanks for your response. Does this mean this chip isn't CFI
> >> compliant? Like, datasheet says it is, but not really.
> > 
> > SST? Broken CFI happened to me, too :(
> > http://patchwork.ozlabs.org/patch/51027/
> 
> This patch [1] (tried to) add support for your chip.
> According to the datasheet [2], it uses addr_unlock1 = 0x555 and
> addr_unlock2 = 0x2AA, and has no extended query table.
> So this chip must be handled by the fixup_sst39vf_rev_b() fixup function.
> 
> Could you provide us with a more detailed log, i.e. with
> DEBUG_CFI_FEATURES enabled in cfi_cmdset_0002.c and DEBUG_CFI in
> cfi_probe.c ?
> 
> 
> [1] http://patchwork.ozlabs.org/patch/50906/
> [2] http://www.sst.com/dotAsset/40661.pdf

-- 
Ing. Fabio Giovagnini

Aurion s.r.l.
P.I e C.F.
00885711200
skype: aurion.giovagnini
Tel. +39.051.594.78.24
Cell. +39.335.83.50.919
www.aurion-tech.com

Re: [Help] SST39VF6401B Support

[Guillaume LECERF]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

2010/9/23 Flávio Silveira <fggs@terra.com.br>:
> I think I might found something:
>
> In cfi_probe.c, starting at line 222, there are these lines:
>
> cfi_send_gen_cmd(0xaa, addr_unlock1, base, map, cfi, cfi->device_type,
> NULL);
> cfi_send_gen_cmd(0x55, addr_unlock2, base, map, cfi, cfi->device_type,
> NULL);
> cfi_send_gen_cmd(0x90, addr_unlock1, base, map, cfi, cfi->device_type,
> NULL);
>
> Which seems the correct way to CFI query the chip, but the last line is
> 0x90.
> Datasheet states that 0x90 is Software ID and CFI Query Entry is 0x98
>
> Could that be the problem?

No. This snippet comes from the function in charge of identifying the
chip and its capacities.

CFI Query Entry (0x98) is handled by cfi_qry_mode_on() in cfi_util.c.
Humm...
Could you try the attached patch ?

-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org

[-- Attachment #2: cfi_util-add-support-for-switc.patch --]
[-- Type: application/octet-stream, Size: 1046 bytes --]

cfi_util: add support for switching SST 39VF6401B chips into QRY mode

From: Guillaume LECERF <glecerf@gmail.com>

Signed-off-by: Guillaume LECERF <glecerf@gmail.com>
---
 drivers/mtd/chips/cfi_util.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/chips/cfi_util.c b/drivers/mtd/chips/cfi_util.c
index e503b2c..e41561e 100644
--- a/drivers/mtd/chips/cfi_util.c
+++ b/drivers/mtd/chips/cfi_util.c
@@ -77,6 +77,13 @@ int __xipram cfi_qry_mode_on(uint32_t base, struct map_info *map,
 	cfi_send_gen_cmd(0x98, 0x5555, base, map, cfi, cfi->device_type, NULL);
 	if (cfi_qry_present(map, base, cfi))
 		return 1;
+	/* 39VF6401B */
+	cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
+	cfi_send_gen_cmd(0xAA, 0x555, base, map, cfi, cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x55, 0x2AA, base, map, cfi, cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x98, 0x555, base, map, cfi, cfi->device_type, NULL);
+	if (cfi_qry_present(map, base, cfi))
+		return 1;
 	/* QRY not found */
 	return 0;
 }

Re: [Help] SST39VF6401B Support

[Flávio Silveira]

Hi Guillaume,

  I tried another router firmware with kernel 2.6.34.5, downloaded 
mtd-2.6.git and pasted chips folder and "linux/mtd" headers, applied your 
last patch and kernel compiled fine.
  I've also enabled debug in kernel and cfi. Should I paste console log in 
message body or should I attach a file with the log?
  I had an error but I don't know if it's related to mtd or the firmware, 
because my router is not officialy supported.

Regards,
  Flavio

----- Original Message ----- 
From: "Guillaume LECERF" <glecerf@gmail.com>
To: "Flávio Silveira" <fggs@terra.com.br>
Cc: <linux-mtd@lists.infradead.org>; "Yegor Yefremov" 
<yegorslists@googlemail.com>
Sent: Thursday, September 23, 2010 12:33 PM
Subject: Re: [Help] SST39VF6401B Support


2010/9/23 Flávio Silveira <fggs@terra.com.br>:
> I think I might found something:
>
> In cfi_probe.c, starting at line 222, there are these lines:
>
> cfi_send_gen_cmd(0xaa, addr_unlock1, base, map, cfi, cfi->device_type,
> NULL);
> cfi_send_gen_cmd(0x55, addr_unlock2, base, map, cfi, cfi->device_type,
> NULL);
> cfi_send_gen_cmd(0x90, addr_unlock1, base, map, cfi, cfi->device_type,
> NULL);
>
> Which seems the correct way to CFI query the chip, but the last line is
> 0x90.
> Datasheet states that 0x90 is Software ID and CFI Query Entry is 0x98
>
> Could that be the problem?

No. This snippet comes from the function in charge of identifying the
chip and its capacities.

CFI Query Entry (0x98) is handled by cfi_qry_mode_on() in cfi_util.c.
Humm...
Could you try the attached patch ?

-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org



--------------------------------------------------------------------------------


> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

Re: [Help] SST39VF6401B Support

[Guillaume LECERF]

2010/9/24 Flávio Silveira <fggs@terra.com.br>:
> Hi Guillaume,
>
>  I tried another router firmware with kernel 2.6.34.5, downloaded
> mtd-2.6.git and pasted chips folder and "linux/mtd" headers, applied your
> last patch and kernel compiled fine.
>  I've also enabled debug in kernel and cfi. Should I paste console log in
> message body or should I attach a file with the log?
>  I had an error but I don't know if it's related to mtd or the firmware,
> because my router is not officialy supported.

Any news on this one ?

-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org

Re: [Help] SST39VF6401B Support

[Flávio Silveira]

Actually yes, I applied your patch to kernel 2.6.35.4 and it detects the 
chip.
I just need to test without your patch to see the difference.

My problem is that dd-wrt an old kernel (2.6.24) and I couldn't port all 
fixes
and openwrt doesn't support my router's lan switch, but I can send you the 
logs if you want.

Thanks for your feedback on this


----- Original Message ----- 
From: "Guillaume LECERF" <glecerf@gmail.com>
To: "Flávio Silveira" <fggs@terra.com.br>
Cc: <linux-mtd@lists.infradead.org>
Sent: Tuesday, October 05, 2010 6:38 AM
Subject: Re: [Help] SST39VF6401B Support


2010/9/24 Flávio Silveira <fggs@terra.com.br>:
> Hi Guillaume,
>
> I tried another router firmware with kernel 2.6.34.5, downloaded
> mtd-2.6.git and pasted chips folder and "linux/mtd" headers, applied your
> last patch and kernel compiled fine.
> I've also enabled debug in kernel and cfi. Should I paste console log in
> message body or should I attach a file with the log?
> I had an error but I don't know if it's related to mtd or the firmware,
> because my router is not officialy supported.

Any news on this one ?

-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org

Re: [Help] SST39VF6401B Support

[Guillaume LECERF]

2010/10/5 Flávio Silveira <fggs@terra.com.br>:
> Actually yes, I applied your patch to kernel 2.6.35.4 and it detects the
> chip.
> I just need to test without your patch to see the difference.

As soon as you confirm me that the patch is indeed needed, I'll send
it for inclusion.

> My problem is that dd-wrt an old kernel (2.6.24) and I couldn't port all
> fixes
> and openwrt doesn't support my router's lan switch, but I can send you the
> logs if you want.

What is the exact reference of your router ?
Did you tried to ask on the OpenWRT mailing list ?

> Thanks for your feedback on this

No problem ;)

-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org

Re: [Help] SST39VF6401B Support

[Guillaume LECERF]

2010/10/5 Flávio Silveira <fggs@terra.com.br>:
> Actually yes, I applied your patch to kernel 2.6.35.4 and it detects the
> chip.
> I just need to test without your patch to see the difference.

Up.

Did you had time to test without the patch to see if it's actually needed ?

-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org

Re :Re: [Help] SST39VF6401B Support

[yidong zhang]

hi

>Just to apply the patch and see what happens. The most important part
>of this patch is:
>
>Please refer to the data sheets Table 6:
>39VF6401B data sheet http://www.sst.com/downloads/datasheet/S71288.pdf
>39VF6401 data sheet http://www.sst.com/downloads/datasheet/S71223-03.pdf
>
>The difference in the 6th bus write cycle. 39VF6401B uses 0x50 and
>39VF6401 uses 0x30.
>
>Without this even if the chip gets detected you cannot write to it.
>
>I haven't look at this since my try to submit this patch, so I don't
>know how to fix the stuff for cfi_probe.

 Recently, i use the 39VF6401B flash, and i apply your patch. The chip
can be get detected. But when i erase one sector, it use 0x30 to erase
one block. The size of a block is much bigger than a sector as we
know.So i use the JEDEC probe to detect the flash. And i make the
erase size to one block-erase size. And it works fine. So i think
the  chip(39VF6401B)  should not be CFI compliant, maybe the  JEDEC
mode is better.

Regards,
zhang

Re: Re :Re: [Help] SST39VF6401B Support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

Hi,

On Sat, Oct 16, 2010 at 03:08:46PM +0800, yidong zhang wrote:
> hi
> 
> >Just to apply the patch and see what happens. The most important part
> >of this patch is:
> >
> >Please refer to the data sheets Table 6:
> >39VF6401B data sheet http://www.sst.com/downloads/datasheet/S71288.pdf
> >39VF6401 data sheet http://www.sst.com/downloads/datasheet/S71223-03.pdf
> >
> >The difference in the 6th bus write cycle. 39VF6401B uses 0x50 and
> >39VF6401 uses 0x30.
> >
> >Without this even if the chip gets detected you cannot write to it.
> >
> >I haven't look at this since my try to submit this patch, so I don't
> >know how to fix the stuff for cfi_probe.
> 
>  Recently, i use the 39VF6401B flash, and i apply your patch. The chip
> can be get detected. But when i erase one sector, it use 0x30 to erase
> one block. The size of a block is much bigger than a sector as we
> know.So i use the JEDEC probe to detect the flash. And i make the
> erase size to one block-erase size. And it works fine. So i think
> the  chip(39VF6401B)  should not be CFI compliant, maybe the  JEDEC
> mode is better.

Please have a look at cfi_cmdset_0002.c, especially the table
cfi_nopri_fixup_table. Without verifying the details, I assume you just have to
add the IDs there and then you can have CFI.

Kind regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Re :Re: [Help] SST39VF6401B Support

[yidong zhang]

Hi
  Thanks for your reply. In the cfi_nopri_fixup_table, i added the
below code as you did.
{ CFI_MFR_SST, 0x236D, fixup_sst39vf_rev_b, NULL, }, // SST39VF6401B
And the flash can get detected. But i still have one confusion.
According to the  data sheets Table 6, in the 6th bus write cycle.
39VF6401B uses 0x50 and 39VF6401 uses 0x30. If 39VF6401B uses 0x30 in
the 6th bus write cycle, it will erase a block-size(64KByte). When you
want to erase one sector-size(4KByte), the driver actually erases one
block-size(64KByte).

On Sat, Oct 16, 2010 at 6:07 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> Hi,
>
> On Sat, Oct 16, 2010 at 03:08:46PM +0800, yidong zhang wrote:
>> hi
>>
>> >Just to apply the patch and see what happens. The most important part
>> >of this patch is:
>> >
>> >Please refer to the data sheets Table 6:
>> >39VF6401B data sheet http://www.sst.com/downloads/datasheet/S71288.pdf
>> >39VF6401 data sheet http://www.sst.com/downloads/datasheet/S71223-03.pdf
>> >
>> >The difference in the 6th bus write cycle. 39VF6401B uses 0x50 and
>> >39VF6401 uses 0x30.
>> >
>> >Without this even if the chip gets detected you cannot write to it.
>> >
>> >I haven't look at this since my try to submit this patch, so I don't
>> >know how to fix the stuff for cfi_probe.
>>
>>  Recently, i use the 39VF6401B flash, and i apply your patch. The chip
>> can be get detected. But when i erase one sector, it use 0x30 to erase
>> one block. The size of a block is much bigger than a sector as we
>> know.So i use the JEDEC probe to detect the flash. And i make the
>> erase size to one block-erase size. And it works fine. So i think
>> the  chip(39VF6401B)  should not be CFI compliant, maybe the  JEDEC
>> mode is better.
>
> Please have a look at cfi_cmdset_0002.c, especially the table
> cfi_nopri_fixup_table. Without verifying the details, I assume you just have to
> add the IDs there and then you can have CFI.
>
> Kind regards,
>
>   Wolfram
>
> --
> Pengutronix e.K.                           | Wolfram Sang                |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAky5eXAACgkQD27XaX1/VRs0SwCfe5vFN1rR5mJ+c6agYoJPRYw2
> OksAoJy1j0EZTRN0FYHyfWRONIbaOSZj
> =Mipu
> -----END PGP SIGNATURE-----
>
>

Re: Re :Re: [Help] SST39VF6401B Support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

On Sat, Oct 16, 2010 at 08:25:44PM +0800, yidong zhang wrote:
> Hi
>   Thanks for your reply. In the cfi_nopri_fixup_table, i added the
> below code as you did.
> { CFI_MFR_SST, 0x236D, fixup_sst39vf_rev_b, NULL, }, // SST39VF6401B

OK, please just use C-style comments (I just sent another patch
converting the others). Also, would be nice if you could check the
datasheet for other IDs mentioned there and add them, too.

> And the flash can get detected. But i still have one confusion.
> According to the  data sheets Table 6, in the 6th bus write cycle.
> 39VF6401B uses 0x50 and 39VF6401 uses 0x30. If 39VF6401B uses 0x30 in

Ouch! Is this true for the other 39VF*-non-B and B-versions, too?

Adding Guillaume to CC...

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Re :Re: [Help] SST39VF6401B Support

[yidong zhang]

On Sat, Oct 16, 2010 at 9:17 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Sat, Oct 16, 2010 at 08:25:44PM +0800, yidong zhang wrote:
>> Hi
>>   Thanks for your reply. In the cfi_nopri_fixup_table, i added the
>> below code as you did.
>> { CFI_MFR_SST, 0x236D, fixup_sst39vf_rev_b, NULL, }, // SST39VF6401B
>
> OK, please just use C-style comments (I just sent another patch
> converting the others). Also, would be nice if you could check the
> datasheet for other IDs mentioned there and add them, too.
>
>> And the flash can get detected. But i still have one confusion.
>> According to the  data sheets Table 6, in the 6th bus write cycle.
>> 39VF6401B uses 0x50 and 39VF6401 uses 0x30. If 39VF6401B uses 0x30 in
>
> Ouch! Is this true for the other 39VF*-non-B and B-versions, too?

Yeah,  it is true for the other  39vf*-no-B and B-versions listed on
the cfi_nopri_fixup_table. And many other chips look like the
39VF*-B-versions.



>
> Adding Guillaume to CC...
>
> Regards,
>
>   Wolfram
>
> --
> Pengutronix e.K.                           | Wolfram Sang                |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAky5pgAACgkQD27XaX1/VRuEjQCeNCz+zi5WcYZkPqs2e5qPHn2C
> 4dYAn20dlxN5m+SdRDqtaspFiEFR0KAY
> =q/e2
> -----END PGP SIGNATURE-----
>
>

Re: [Help] SST39VF6401B Support

[Flávio Silveira]

Sorry for the delay, I was travelling.

Not yet, I couldn't build a firmware without your patch to test it, perhaps 
in the middle of this week, but I'm guessing it is needed.

Flavio

----- Original Message ----- 
From: "Guillaume LECERF" <glecerf@gmail.com>
To: "Flávio Silveira" <fggs@terra.com.br>
Cc: <linux-mtd@lists.infradead.org>
Sent: Tuesday, October 12, 2010 8:48 AM
Subject: Re: [Help] SST39VF6401B Support


> 2010/10/5 Flávio Silveira <fggs@terra.com.br>:
>> Actually yes, I applied your patch to kernel 2.6.35.4 and it detects the
>> chip.
>> I just need to test without your patch to see the difference.
>
> Up.
>
> Did you had time to test without the patch to see if it's actually needed 
> ?
>
> -- 
> Guillaume LECERF
> GeeXboX developer - www.geexbox.org
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

Re: Re :Re: [Help] SST39VF6401B Support

[yidong zhang]

hi
   The 39VF*-B-Version flashes in the cfi_nopri_fixup_table don't work
well in the current code.  Because of the mistaken use of
command(0x30) in the 6th bus cycle, which should be 0x50. I think the
39VF*-B-Version flashes should be removed form the CFI probe mode. Or
maybe the erase operation should be changed for the Compatibility.

On Sat, Oct 16, 2010 at 9:17 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Sat, Oct 16, 2010 at 08:25:44PM +0800, yidong zhang wrote:
>> Hi
>>   Thanks for your reply. In the cfi_nopri_fixup_table, i added the
>> below code as you did.
>> { CFI_MFR_SST, 0x236D, fixup_sst39vf_rev_b, NULL, }, // SST39VF6401B
>
> OK, please just use C-style comments (I just sent another patch
> converting the others). Also, would be nice if you could check the
> datasheet for other IDs mentioned there and add them, too.
>
>> And the flash can get detected. But i still have one confusion.
>> According to the  data sheets Table 6, in the 6th bus write cycle.
>> 39VF6401B uses 0x50 and 39VF6401 uses 0x30. If 39VF6401B uses 0x30 in
>
> Ouch! Is this true for the other 39VF*-non-B and B-versions, too?
>
> Adding Guillaume to CC...
>
> Regards,
>
>   Wolfram
>
> --
> Pengutronix e.K.                           | Wolfram Sang                |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAky5pgAACgkQD27XaX1/VRuEjQCeNCz+zi5WcYZkPqs2e5qPHn2C
> 4dYAn20dlxN5m+SdRDqtaspFiEFR0KAY
> =q/e2
> -----END PGP SIGNATURE-----
>
>

Re: Re :Re: [Help] SST39VF6401B Support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

On Mon, Oct 18, 2010 at 12:00:46PM +0800, yidong zhang wrote:
> hi
>    The 39VF*-B-Version flashes in the cfi_nopri_fixup_table don't work
> well in the current code.  Because of the mistaken use of
> command(0x30) in the 6th bus cycle, which should be 0x50. I think the
> 39VF*-B-Version flashes should be removed form the CFI probe mode. Or
> maybe the erase operation should be changed for the Compatibility.

Or we put in a variable like the unlock-address?

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Re :Re: [Help] SST39VF6401B Support

[yidong zhang]

On Mon, Oct 18, 2010 at 7:41 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Mon, Oct 18, 2010 at 12:00:46PM +0800, yidong zhang wrote:
>> hi
>>    The 39VF*-B-Version flashes in the cfi_nopri_fixup_table don't work
>> well in the current code.  Because of the mistaken use of
>> command(0x30) in the 6th bus cycle, which should be 0x50. I think the
>> 39VF*-B-Version flashes should be removed form the CFI probe mode. Or
>> maybe the erase operation should be changed for the Compatibility.
>
> Or we put in a variable like the unlock-address?

Maybe that's a better solution. I have no other methods.


>
> --
> Pengutronix e.K.                           | Wolfram Sang                |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAky8Mk8ACgkQD27XaX1/VRtD1QCgvhKREHwzceC1STdpZXJ2qrum
> Wg4An0JXJSQTkr5eShXUdykOn6lhlvbt
> =3BkZ
> -----END PGP SIGNATURE-----
>
>

Re: Re :Re: [Help] SST39VF6401B Support

[Guillaume LECERF]

2010/10/18 Wolfram Sang <w.sang@pengutronix.de>:
>>    The 39VF*-B-Version flashes in the cfi_nopri_fixup_table don't work
>> well in the current code.  Because of the mistaken use of
>> command(0x30) in the 6th bus cycle, which should be 0x50. I think the
>> 39VF*-B-Version flashes should be removed form the CFI probe mode. Or
>> maybe the erase operation should be changed for the Compatibility.
>
> Or we put in a variable like the unlock-address?

I'm OK with solution, that's what I try to implement atm, but I'm
still looking for the right place to put this variable.


-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org

Re: Re :Re: [Help] SST39VF6401B Support

[Guillaume LECERF]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

2010/10/18 Guillaume LECERF <glecerf@gmail.com>:
> 2010/10/18 Wolfram Sang <w.sang@pengutronix.de>:
>>>    The 39VF*-B-Version flashes in the cfi_nopri_fixup_table don't work
>>> well in the current code.  Because of the mistaken use of
>>> command(0x30) in the 6th bus cycle, which should be 0x50. I think the
>>> 39VF*-B-Version flashes should be removed form the CFI probe mode. Or
>>> maybe the erase operation should be changed for the Compatibility.
>>
>> Or we put in a variable like the unlock-address?
>
> I'm OK with solution, that's what I try to implement atm, but I'm
> still looking for the right place to put this variable.

Hi.
Could you try the attached patches ?
Note: it's totally untested.

-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org

[-- Attachment #2: erase-command.patch --]
[-- Type: application/octet-stream, Size: 2778 bytes --]

mtd: cfi_cmdset_0002: make sector erase command variable

From: Guillaume LECERF <glecerf@gmail.com>

SST39VFxxxxB chips use 0x50 as sector erase command, instead of 0x30.
Make this value variable to handle such chips.

Signed-off-by: Guillaume LECERF <glecerf@gmail.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 3e6c47b..a359967 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -78,6 +78,7 @@ static struct mtd_chip_driver cfi_amdstd_chipdrv = {
 	.module		= THIS_MODULE
 };
 
+static map_word sector_erase_cmd = CMD(0x30);
 
 /* #define DEBUG_CFI_FEATURES */
 
@@ -291,6 +292,8 @@ static void fixup_sst39vf_rev_b(struct mtd_info *mtd, void *param)
 
 	cfi->addr_unlock1 = 0x555;
 	cfi->addr_unlock2 = 0x2AA;
+
+	sector_erase_cmd = CMD(0x50);
 }
 
 static void fixup_s29gl064n_sectors(struct mtd_info *mtd, void *param)
@@ -674,7 +677,7 @@ static int get_chip(struct map_info *map, struct flchip *chip, unsigned long adr
 				 * there was an error (so leave the erase
 				 * routine to recover from it) or we trying to
 				 * use the erase-in-progress sector. */
-				map_write(map, CMD(0x30), chip->in_progress_block_addr);
+				map_write(map, sector_erase_cmd, chip->in_progress_block_addr);
 				chip->state = FL_ERASING;
 				chip->oldstate = FL_READY;
 				printk(KERN_ERR "MTD %s(): chip not ready after erase suspend\n", __func__);
@@ -727,7 +730,7 @@ static void put_chip(struct map_info *map, struct flchip *chip, unsigned long ad
 	switch(chip->oldstate) {
 	case FL_ERASING:
 		chip->state = chip->oldstate;
-		map_write(map, CMD(0x30), chip->in_progress_block_addr);
+		map_write(map, sector_erase_cmd, chip->in_progress_block_addr);
 		chip->oldstate = FL_READY;
 		chip->state = FL_ERASING;
 		break;
@@ -870,7 +873,7 @@ static void __xipram xip_udelay(struct map_info *map, struct flchip *chip,
 			local_irq_disable();
 
 			/* Resume the write or erase operation */
-			map_write(map, CMD(0x30), adr);
+			map_write(map, sector_erase_cmd, adr);
 			chip->state = oldstate;
 			start = xip_currtime();
 		} else if (usec >= 1000000/HZ) {
@@ -1675,7 +1678,7 @@ static int __xipram do_erase_oneblock(struct map_info *map, struct flchip *chip,
 	cfi_send_gen_cmd(0x80, cfi->addr_unlock1, chip->start, map, cfi, cfi->device_type, NULL);
 	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi, cfi->device_type, NULL);
 	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi, cfi->device_type, NULL);
-	map_write(map, CMD(0x30), adr);
+	map_write(map, sector_erase_cmd, adr);
 
 	chip->state = FL_ERASING;
 	chip->erase_suspended = 0;

[-- Attachment #3: sst38vf640x.patch --]
[-- Type: application/octet-stream, Size: 970 bytes --]

SST38VF640x

From: Guillaume LECERF <glecerf@gmail.com>


---
 drivers/mtd/chips/cfi_cmdset_0002.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index a359967..32b0402 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -328,6 +328,10 @@ static struct cfi_fixup cfi_nopri_fixup_table[] = {
 	{ CFI_MFR_SST, 0x235D, fixup_sst39vf_rev_b, NULL, }, // SST39VF3201B
 	{ CFI_MFR_SST, 0x236C, fixup_sst39vf_rev_b, NULL, }, // SST39VF6402B
 	{ CFI_MFR_SST, 0x236D, fixup_sst39vf_rev_b, NULL, }, // SST39VF6401B
+	{ CFI_MFR_SST, 0x536A, fixup_sst39vf_rev_b, NULL, }, /* SST38VF6402 */
+	{ CFI_MFR_SST, 0x536B, fixup_sst39vf_rev_b, NULL, }, /* SST38VF6401 */
+	{ CFI_MFR_SST, 0x536C, fixup_sst39vf_rev_b, NULL, }, /* SST38VF6404 */
+	{ CFI_MFR_SST, 0x536D, fixup_sst39vf_rev_b, NULL, }, /* SST38VF6403 */
 	{ 0, 0, NULL, NULL }
 };
 

Re: Re :Re: [Help] SST39VF6401B Support

[Guillaume LECERF]

2010/10/21 yidong zhang <zhangyd6@gmail.com>:
>> Hi.
>> The patch use the fixup_sst39vf_rev_b() function which calls
>> fixup_old_sst_eraseregion().
>> It sets the NumEraseRegions to 1, thus CFI reports only the 1st erase
>> region, i.e. the one calculated with the sector information (8KByte).
>>
>> Did you actually tested it with a real chip ?
>
> Yes, i did test both SST39VF6401B and SST38VF6401 a moment ago; The
> SST39VF6401B works fine. But the SST38VF6401 couldn't work because of
> the sector-size.It was 64KByte when i displayed the erase size.

Could you send me your log with SST38VF6401 please ?
I need to investigate on this.

-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org

Re: Re :Re: [Help] SST39VF6401B Support

[yidong zhang]

On Thu, Oct 21, 2010 at 11:24 PM, Guillaume LECERF <glecerf@gmail.com> wrote:
> 2010/10/21 yidong zhang <zhangyd6@gmail.com>:
>>> Hi.
>>> The patch use the fixup_sst39vf_rev_b() function which calls
>>> fixup_old_sst_eraseregion().
>>> It sets the NumEraseRegions to 1, thus CFI reports only the 1st erase
>>> region, i.e. the one calculated with the sector information (8KByte).
>>>
>>> Did you actually tested it with a real chip ?
>>
>> Yes, i did test both SST39VF6401B and SST38VF6401 a moment ago; The
>> SST39VF6401B works fine. But the SST38VF6401 couldn't work because of
>> the sector-size.It was 64KByte when i displayed the erase size.
>
> Could you send me your log with SST38VF6401 please ?
> I need to investigate on this.


Typical byte/word write timeout: 8 µs
Maximum byte/word write timeout: 16 µs
Typical full buffer write timeout: 8 µs
Maximum full buffer write timeout: 64 µs
Typical block erase timeout: 16 ms
Maximum block erase timeout: 32 ms
Typical chip erase timeout: 32 ms
Maximum chip erase timeout: 64 ms
Device size: 0x800000 bytes (8 MiB)
Flash Device Interface description: 0x0001
  - x16-only asynchronous interface
Max. bytes in buffer write: 0x20
Number of Erase Block Regions: 2
  Erase Region #0: BlockSize 0x10000 bytes, 1024 blocks
cif->cfiq->EraseRegionInfo[i] = 10003ff
  Erase Region #1: BlockSize 0x10000 bytes, 128 blocks
cif->cfiq->EraseRegionInfo[i] = 100007f
mb86hxx_pflash: Found 1 x16 devices at 0x0 in 16-bit bank
number of CFI chips: 1
ersize is 10000, ernum is 400
Sum of regions (4000000) != total size of set of interleaved chips (800000)



>
> --
> Guillaume LECERF
> GeeXboX developer - www.geexbox.org
>

Re: Re :Re: [Help] SST39VF6401B Support

[Guillaume LECERF]

2010/10/22 yidong zhang <zhangyd6@gmail.com>:
>>> Yes, i did test both SST39VF6401B and SST38VF6401 a moment ago; The
>>> SST39VF6401B works fine. But the SST38VF6401 couldn't work because of
>>> the sector-size.It was 64KByte when i displayed the erase size.
>>
>> Could you send me your log with SST38VF6401 please ?
>> I need to investigate on this.
>
> Typical byte/word write timeout: 8 µs
> Maximum byte/word write timeout: 16 µs
> Typical full buffer write timeout: 8 µs
> Maximum full buffer write timeout: 64 µs
> Typical block erase timeout: 16 ms
> Maximum block erase timeout: 32 ms
> Typical chip erase timeout: 32 ms
> Maximum chip erase timeout: 64 ms
> Device size: 0x800000 bytes (8 MiB)
> Flash Device Interface description: 0x0001
>  - x16-only asynchronous interface
> Max. bytes in buffer write: 0x20
> Number of Erase Block Regions: 2

You didn't applied my latest patch, you would have only 1 erase region
if you did.

>  Erase Region #0: BlockSize 0x10000 bytes, 1024 blocks
> cif->cfiq->EraseRegionInfo[i] = 10003ff
>  Erase Region #1: BlockSize 0x10000 bytes, 128 blocks
> cif->cfiq->EraseRegionInfo[i] = 100007f
> mb86hxx_pflash: Found 1 x16 devices at 0x0 in 16-bit bank
> number of CFI chips: 1
> ersize is 10000, ernum is 400
> Sum of regions (4000000) != total size of set of interleaved chips (800000)

This is the typical error with SST chips when the
fixup_sst39vf_rev_b() fixup function isn't called.

Could you try and report me which patches you applied and what results
you have with SST38VF6401 ?

-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org

Re: Re :Re: [Help] SST39VF6401B Support

[yidong zhang]

On Fri, Oct 22, 2010 at 3:52 PM, Guillaume LECERF <glecerf@gmail.com> wrote:
> 2010/10/22 yidong zhang <zhangyd6@gmail.com>:
>>>> Yes, i did test both SST39VF6401B and SST38VF6401 a moment ago; The
>>>> SST39VF6401B works fine. But the SST38VF6401 couldn't work because of
>>>> the sector-size.It was 64KByte when i displayed the erase size.
>>>
>>> Could you send me your log with SST38VF6401 please ?
>>> I need to investigate on this.
>>
>> Typical byte/word write timeout: 8 µs
>> Maximum byte/word write timeout: 16 µs
>> Typical full buffer write timeout: 8 µs
>> Maximum full buffer write timeout: 64 µs
>> Typical block erase timeout: 16 ms
>> Maximum block erase timeout: 32 ms
>> Typical chip erase timeout: 32 ms
>> Maximum chip erase timeout: 64 ms
>> Device size: 0x800000 bytes (8 MiB)
>> Flash Device Interface description: 0x0001
>>  - x16-only asynchronous interface
>> Max. bytes in buffer write: 0x20
>> Number of Erase Block Regions: 2
>
> You didn't applied my latest patch, you would have only 1 erase region
> if you did.
  It was printed by the print_cfi_ident function. And the region
number is readed from the flash. So there was 2 erase region

>>  Erase Region #0: BlockSize 0x10000 bytes, 1024 blocks
>> cif->cfiq->EraseRegionInfo[i] = 10003ff
>>  Erase Region #1: BlockSize 0x10000 bytes, 128 blocks
>> cif->cfiq->EraseRegionInfo[i] = 100007f
>> mb86hxx_pflash: Found 1 x16 devices at 0x0 in 16-bit bank
>> number of CFI chips: 1
>> ersize is 10000, ernum is 400
>> Sum of regions (4000000) != total size of set of interleaved chips (800000)
>
> This is the typical error with SST chips when the
> fixup_sst39vf_rev_b() fixup function isn't called.

   It did call the fixup_sst39vf_recv_b() function, so you can see
 >>number of CFI chips: 1
When we take the 1st erase region, we will get the wrong flash size
because of the wrong information(ersize is 10000, ernum is 400).

>
> Could you try and report me which patches you applied and what results
> you have with SST38VF6401 ?

Sorry, my current kernel version is not the latest one. My kernel
version is 2.6.31. I changed the code as your patch.  But i can
confirm that the flash(SST39VF6401B) works fine. But the SST38VF6401
flash couldn't pass the probe. Please see the log below

>>  Erase Region #0: BlockSize 0x10000 bytes, 1024 blocks
>> cif->cfiq->EraseRegionInfo[i] = 10003ff
>>  Erase Region #1: BlockSize 0x10000 bytes, 128 blocks
>> cif->cfiq->EraseRegionInfo[i] = 100007f

I think the information we get from the flash is wrong. So we
shuoldn't take the 1st Erase Region. We can not  get the right
description of the flash in the CFI mode. Maybe they should be moved
to JEDEC mode.

> --
> Guillaume LECERF
> GeeXboX developer - www.geexbox.org
>

Re: Re :Re: [Help] SST39VF6401B Support

[Guillaume LECERF]

2010/10/22 yidong zhang <zhangyd6@gmail.com>:
>> You didn't applied my latest patch, you would have only 1 erase region
>> if you did.
>  It was printed by the print_cfi_ident function. And the region
> number is readed from the flash. So there was 2 erase region

OK, my bad :(

The datasheet is really f***ed up.

"Sector Information (y + 1 = Number of sectors; z x 256B = sector size)
y = 2047 + 1 = 2048 sectors (03FFH = 1023)
z = 32 x 256 Bytes = 8 KBytes/sector (0100H = 32)"

03FFH = 1023, so y = 1023 + 1 = 1024 sectors
0100H = 256 (not 32), so z = 256 x 256 = 64 KBytes/sector

I think we should modify the sector size on the fly, i.e. changing
0100h to 0020h (32).

Could you try setting cif->cfiq->EraseRegionInfo[0] to 0x02003FF in
fixup_sst39vf_rev_b() ?

-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org

Re: Re :Re: [Help] SST39VF6401B Support

[yidong zhang]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

On Fri, Oct 22, 2010 at 6:41 PM, Guillaume LECERF <glecerf@gmail.com> wrote:
> 2010/10/22 yidong zhang <zhangyd6@gmail.com>:
>>> You didn't applied my latest patch, you would have only 1 erase region
>>> if you did.
>>  It was printed by the print_cfi_ident function. And the region
>> number is readed from the flash. So there was 2 erase region
>
> OK, my bad :(
>
> The datasheet is really f***ed up.
>
> "Sector Information (y + 1 = Number of sectors; z x 256B = sector size)
> y = 2047 + 1 = 2048 sectors (03FFH = 1023)
> z = 32 x 256 Bytes = 8 KBytes/sector (0100H = 32)"
>
> 03FFH = 1023, so y = 1023 + 1 = 1024 sectors
> 0100H = 256 (not 32), so z = 256 x 256 = 64 KBytes/sector
>
> I think we should modify the sector size on the fly, i.e. changing
> 0100h to 0020h (32).
>
> Could you try setting cif->cfiq->EraseRegionInfo[0] to 0x02003FF in
> fixup_sst39vf_rev_b() ?
>
Hi
  how about this attached patch.

> --
> Guillaume LECERF
> GeeXboX developer - www.geexbox.org
>

[-- Attachment #2: 0001-mtd-cfi_cmdset_0002-add-CFI-detection-for-SST-38VF64.patch --]
[-- Type: application/octet-stream, Size: 1713 bytes --]

From d40e6584546314437bb34cc2e36ada49eb51413a Mon Sep 17 00:00:00 2001
From: zhangyd <zhangyd6@gmail.com>
Date: Fri, 22 Oct 2010 22:59:42 -0400
Subject: [PATCH] mtd: cfi_cmdset_0002: add CFI detection for SST 38VF640x chips

Add support for SST38VF640x chips in CFI mode.

Signed-off-by: yidong zhang <zhangyd6@gmail.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 3e6c47b..7ce8db6 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -291,6 +291,12 @@ static void fixup_sst39vf_rev_b(struct mtd_info *mtd, void *param)
 
 	cfi->addr_unlock1 = 0x555;
 	cfi->addr_unlock2 = 0x2AA;
+	
+	if (((cfi->cfiq->EraseRegionInfo[0] >> 8) & ~0xff) == 0x10000) {
+		cfi->cfiq->EraseRegionInfo[0] = 0x02003ff;
+		pr_warning("%s: Bad SST38VF640X CFI data, adjust one sector	\
+			size  from 64KBytes to 8KBytes", mtd->name);
+	}
 }
 
 static void fixup_s29gl064n_sectors(struct mtd_info *mtd, void *param)
@@ -325,6 +331,10 @@ static struct cfi_fixup cfi_nopri_fixup_table[] = {
 	{ CFI_MFR_SST, 0x235D, fixup_sst39vf_rev_b, NULL, }, // SST39VF3201B
 	{ CFI_MFR_SST, 0x236C, fixup_sst39vf_rev_b, NULL, }, // SST39VF6402B
 	{ CFI_MFR_SST, 0x236D, fixup_sst39vf_rev_b, NULL, }, // SST39VF6401B
+	{ CFI_MFR_SST, 0x536A, fixup_sst39vf_rev_b, NULL, }, /* SST38VF6402 */
+	{ CFI_MFR_SST, 0x536B, fixup_sst39vf_rev_b, NULL, }, /* SST38VF6401 */
+	{ CFI_MFR_SST, 0x536C, fixup_sst39vf_rev_b, NULL, }, /* SST38VF6404 */
+	{ CFI_MFR_SST, 0x536D, fixup_sst39vf_rev_b, NULL, }, /* SST38VF6403 */
 	{ 0, 0, NULL, NULL }
 };
 
-- 
1.7.2.3

Re: Re :Re: [Help] SST39VF6401B Support

[Guillaume LECERF]

2010/10/22 yidong zhang <zhangyd6@gmail.com>:
>> Could you try setting cif->cfiq->EraseRegionInfo[0] to 0x02003FF in
>> fixup_sst39vf_rev_b() ?
>>
> Hi
>  how about this attached patch.

If it works for you, I'll send a patch series for SST 39VF640xB and
38VF640x, because both chips needs 0x50 as erase command.

-- 
Guillaume LECERF
GeeXboX developer - www.geexbox.org

Re: Re :Re: [Help] SST39VF6401B Support

[yidong zhang]

On Fri, Oct 22, 2010 at 11:36 PM, Guillaume LECERF <glecerf@gmail.com> wrote:
> 2010/10/22 yidong zhang <zhangyd6@gmail.com>:
>>> Could you try setting cif->cfiq->EraseRegionInfo[0] to 0x02003FF in
>>> fixup_sst39vf_rev_b() ?
>>>
>> Hi
>>  how about this attached patch.
>
> If it works for you, I'll send a patch series for SST 39VF640xB and
> 38VF640x, because both chips needs 0x50 as erase command.

Sorry, i cannot test it right now.  I will sent the result as soon as i can.
>
> --
> Guillaume LECERF
> GeeXboX developer - www.geexbox.org
>

Re: [Help] SST39VF6401B Support

[Fabio Giovagnini]

Hi Guys,
As Gullelm remeber for sure, I used the jedec probe for such a flash in a very 
old 2.6 kernel.

Now I'm migrating to the newets one kernel.
Do you tell me how the kernel will be updated with the last mtd stuff 
developed; or in place of it how to patch a standard kernel?

Thanks a  lot and sorry for my question if it is improper


In data venerdì 22 ottobre 2010 17:42:39, yidong zhang ha scritto:
: > On Fri, Oct 22, 2010 at 11:36 PM, Guillaume LECERF <glecerf@gmail.com> 
wrote:
> > 2010/10/22 yidong zhang <zhangyd6@gmail.com>:
> >>> Could you try setting cif->cfiq->EraseRegionInfo[0] to 0x02003FF in
> >>> fixup_sst39vf_rev_b() ?
> >> 
> >> Hi
> >>  how about this attached patch.
> > 
> > If it works for you, I'll send a patch series for SST 39VF640xB and
> > 38VF640x, because both chips needs 0x50 as erase command.
> 
> Sorry, i cannot test it right now.  I will sent the result as soon as i
> can.
> 
> > --
> > Guillaume LECERF
> > GeeXboX developer - www.geexbox.org
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 
Ing. Fabio Giovagnini

Aurion s.r.l.
P.I e C.F.
00885711200
skype: aurion.giovagnini
Tel. +39.051.594.78.24
Cell. +39.335.83.50.919
www.aurion-tech.com

Re: [Help] SST39VF6401B Support

[Flávio Silveira]

Hi guys,

  I've tested this patch on kernel 2.6.23 (actually it's called 2.6.24.111) 
and didn't work.

  Below are my diffs and I can post original files as well, please help me 
make it work!

Thanks in advance!

cfi_util.c

29a30,107
> int __xipram cfi_qry_present(struct map_info *map, __u32 base,
>         struct cfi_private *cfi)
> {
>  int osf = cfi->interleave * cfi->device_type; /* scale factor */
>  map_word val[3];
>  map_word qry[3];
>
>  qry[0] = cfi_build_cmd('Q', map, cfi);
>  qry[1] = cfi_build_cmd('R', map, cfi);
>  qry[2] = cfi_build_cmd('Y', map, cfi);
>
>  val[0] = map_read(map, base + osf*0x10);
>  val[1] = map_read(map, base + osf*0x11);
>  val[2] = map_read(map, base + osf*0x12);
>
>  if (!map_word_equal(map, qry[0], val[0]))
>   return 0;
>
>  if (!map_word_equal(map, qry[1], val[1]))
>   return 0;
>
>  if (!map_word_equal(map, qry[2], val[2]))
>   return 0;
>
>  return 1;  /* "QRY" found */
> }
> EXPORT_SYMBOL_GPL(cfi_qry_present);
>
> int __xipram cfi_qry_mode_on(uint32_t base, struct map_info *map,
>         struct cfi_private *cfi)
> {
>  cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x98, 0x55, base, map, cfi, cfi->device_type, NULL);
>  if (cfi_qry_present(map, base, cfi))
>   return 1;
>  /* QRY not found probably we deal with some odd CFI chips */
>  /* Some revisions of some old Intel chips? */
>  cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0xFF, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x98, 0x55, base, map, cfi, cfi->device_type, NULL);
>  if (cfi_qry_present(map, base, cfi))
>   return 1;
>  /* ST M29DW chips */
>  cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x98, 0x555, base, map, cfi, cfi->device_type, NULL);
>  if (cfi_qry_present(map, base, cfi))
>   return 1;
>  /* some old SST chips, e.g. 39VF160x/39VF320x */
>  cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0xAA, 0x5555, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x55, 0x2AAA, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x98, 0x5555, base, map, cfi, cfi->device_type, NULL);
>  if (cfi_qry_present(map, base, cfi))
>   return 1;
>  /* SST 39VF640xB */
>  cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0xAA, 0x555, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x55, 0x2AA, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x98, 0x555, base, map, cfi, cfi->device_type, NULL);
>  if (cfi_qry_present(map, base, cfi))
>   return 1;
>  /* QRY not found */
>  return 0;
> }
> EXPORT_SYMBOL_GPL(cfi_qry_mode_on);
>
> void __xipram cfi_qry_mode_off(uint32_t base, struct map_info *map,
>           struct cfi_private *cfi)
> {
>  cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0xFF, 0, base, map, cfi, cfi->device_type, NULL);
>  /* M29W128G flashes require an additional reset command
>     when exit qry mode */
>  if ((cfi->mfr == CFI_MFR_ST) && (cfi->id == 0x227E || cfi->id == 0x7E))
>   cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
> }
> EXPORT_SYMBOL_GPL(cfi_qry_mode_off);
>

cfi_cmdset_0002.c

219a220,253
> static void fixup_old_sst_eraseregion(struct mtd_info *mtd)
> {
>    struct map_info *map = mtd->priv;
>    struct cfi_private *cfi = map->fldrv_priv;
>
>    /*
>     * These flashes report two seperate eraseblock regions based on the
>     * sector_erase-size and block_erase-size, although they both operate 
> on the
>     * same memory. This is not allowed according to CFI, so we just pick 
> the
>     * sector_erase-size.
>     */
>    cfi->cfiq->NumEraseRegions = 1;
> }
>
> static void fixup_sst39vf_rev_b(struct mtd_info *mtd, void *param)
> {
>    struct map_info *map = mtd->priv;
>    struct cfi_private *cfi = map->fldrv_priv;
>
>    fixup_old_sst_eraseregion(mtd);
>
>    cfi->addr_unlock1 = 0x555;
>    cfi->addr_unlock2 = 0x2AA;
> }
>
> /* Used to fix CFI-Tables of chips without Extended Query Tables */
> static struct cfi_fixup cfi_nopri_fixup_table[] = {
>    { CFI_MFR_SST, 0x235C, fixup_sst39vf_rev_b, NULL, }, // SST39VF3202B
>    { CFI_MFR_SST, 0x235D, fixup_sst39vf_rev_b, NULL, }, // SST39VF3201B
>    { CFI_MFR_SST, 0x236C, fixup_sst39vf_rev_b, NULL, }, // SST39VF6402B
>    { CFI_MFR_SST, 0x236D, fixup_sst39vf_rev_b, NULL, }, // SST39VF6401B
>    { 0, 0, NULL, NULL }
> };
>


----- Original Message ----- 
From: "Fabio Giovagnini" <fabio.giovagnini@aurion-tech.com>
To: <linux-mtd@lists.infradead.org>
Cc: "yidong zhang" <zhangyd6@gmail.com>; <David.Woodhouse@intel.com>; 
"Wolfram Sang" <w.sang@pengutronix.de>; <yegorslists@googlemail.com>; 
"Guillaume LECERF" <glecerf@gmail.com>; <taliaferro62@gmail.com>
Sent: Friday, October 22, 2010 2:50 PM
Subject: Re: [Help] SST39VF6401B Support


Hi Guys,
As Gullelm remeber for sure, I used the jedec probe for such a flash in a 
very
old 2.6 kernel.

Now I'm migrating to the newets one kernel.
Do you tell me how the kernel will be updated with the last mtd stuff
developed; or in place of it how to patch a standard kernel?

Thanks a  lot and sorry for my question if it is improper


In data venerdì 22 ottobre 2010 17:42:39, yidong zhang ha scritto:
: > On Fri, Oct 22, 2010 at 11:36 PM, Guillaume LECERF <glecerf@gmail.com>
wrote:
> > 2010/10/22 yidong zhang <zhangyd6@gmail.com>:
> >>> Could you try setting cif->cfiq->EraseRegionInfo[0] to 0x02003FF in
> >>> fixup_sst39vf_rev_b() ?
> >>
> >> Hi
> >>  how about this attached patch.
> >
> > If it works for you, I'll send a patch series for SST 39VF640xB and
> > 38VF640x, because both chips needs 0x50 as erase command.
>
> Sorry, i cannot test it right now.  I will sent the result as soon as i
> can.
>
> > --
> > Guillaume LECERF
> > GeeXboX developer - www.geexbox.org
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 
Ing. Fabio Giovagnini

Aurion s.r.l.
P.I e C.F.
00885711200
skype: aurion.giovagnini
Tel. +39.051.594.78.24
Cell. +39.335.83.50.919
www.aurion-tech.com

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [Help] SST39VF6401B Support

[Flávio Silveira]

[-- Attachment #1: Type: text/plain, Size: 7052 bytes --]

Hi,

  I'm attaching some other files to see if it helps finding what's wrong.

  Thanks in advance!

----- Original Message ----- 
From: "Flávio Silveira" <fggs@terra.com.br>
To: "Fabio Giovagnini" <fabio.giovagnini@aurion-tech.com>; 
<linux-mtd@lists.infradead.org>
Cc: "yidong zhang" <zhangyd6@gmail.com>; <David.Woodhouse@intel.com>; 
"Wolfram Sang" <w.sang@pengutronix.de>; <yegorslists@googlemail.com>; 
"Guillaume LECERF" <glecerf@gmail.com>; <taliaferro62@gmail.com>
Sent: Wednesday, June 15, 2011 9:55 PM
Subject: Re: [Help] SST39VF6401B Support


Hi guys,

  I've tested this patch on kernel 2.6.23 (actually it's called 2.6.24.111)
and didn't work.

  Below are my diffs and I can post original files as well, please help me
make it work!

Thanks in advance!

cfi_util.c

29a30,107
> int __xipram cfi_qry_present(struct map_info *map, __u32 base,
>         struct cfi_private *cfi)
> {
>  int osf = cfi->interleave * cfi->device_type; /* scale factor */
>  map_word val[3];
>  map_word qry[3];
>
>  qry[0] = cfi_build_cmd('Q', map, cfi);
>  qry[1] = cfi_build_cmd('R', map, cfi);
>  qry[2] = cfi_build_cmd('Y', map, cfi);
>
>  val[0] = map_read(map, base + osf*0x10);
>  val[1] = map_read(map, base + osf*0x11);
>  val[2] = map_read(map, base + osf*0x12);
>
>  if (!map_word_equal(map, qry[0], val[0]))
>   return 0;
>
>  if (!map_word_equal(map, qry[1], val[1]))
>   return 0;
>
>  if (!map_word_equal(map, qry[2], val[2]))
>   return 0;
>
>  return 1;  /* "QRY" found */
> }
> EXPORT_SYMBOL_GPL(cfi_qry_present);
>
> int __xipram cfi_qry_mode_on(uint32_t base, struct map_info *map,
>         struct cfi_private *cfi)
> {
>  cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x98, 0x55, base, map, cfi, cfi->device_type, NULL);
>  if (cfi_qry_present(map, base, cfi))
>   return 1;
>  /* QRY not found probably we deal with some odd CFI chips */
>  /* Some revisions of some old Intel chips? */
>  cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0xFF, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x98, 0x55, base, map, cfi, cfi->device_type, NULL);
>  if (cfi_qry_present(map, base, cfi))
>   return 1;
>  /* ST M29DW chips */
>  cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x98, 0x555, base, map, cfi, cfi->device_type, NULL);
>  if (cfi_qry_present(map, base, cfi))
>   return 1;
>  /* some old SST chips, e.g. 39VF160x/39VF320x */
>  cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0xAA, 0x5555, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x55, 0x2AAA, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x98, 0x5555, base, map, cfi, cfi->device_type, NULL);
>  if (cfi_qry_present(map, base, cfi))
>   return 1;
>  /* SST 39VF640xB */
>  cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0xAA, 0x555, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x55, 0x2AA, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0x98, 0x555, base, map, cfi, cfi->device_type, NULL);
>  if (cfi_qry_present(map, base, cfi))
>   return 1;
>  /* QRY not found */
>  return 0;
> }
> EXPORT_SYMBOL_GPL(cfi_qry_mode_on);
>
> void __xipram cfi_qry_mode_off(uint32_t base, struct map_info *map,
>           struct cfi_private *cfi)
> {
>  cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
>  cfi_send_gen_cmd(0xFF, 0, base, map, cfi, cfi->device_type, NULL);
>  /* M29W128G flashes require an additional reset command
>     when exit qry mode */
>  if ((cfi->mfr == CFI_MFR_ST) && (cfi->id == 0x227E || cfi->id == 0x7E))
>   cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
> }
> EXPORT_SYMBOL_GPL(cfi_qry_mode_off);
>

cfi_cmdset_0002.c

219a220,253
> static void fixup_old_sst_eraseregion(struct mtd_info *mtd)
> {
>    struct map_info *map = mtd->priv;
>    struct cfi_private *cfi = map->fldrv_priv;
>
>    /*
>     * These flashes report two seperate eraseblock regions based on the
>     * sector_erase-size and block_erase-size, although they both operate 
> on the
>     * same memory. This is not allowed according to CFI, so we just pick 
> the
>     * sector_erase-size.
>     */
>    cfi->cfiq->NumEraseRegions = 1;
> }
>
> static void fixup_sst39vf_rev_b(struct mtd_info *mtd, void *param)
> {
>    struct map_info *map = mtd->priv;
>    struct cfi_private *cfi = map->fldrv_priv;
>
>    fixup_old_sst_eraseregion(mtd);
>
>    cfi->addr_unlock1 = 0x555;
>    cfi->addr_unlock2 = 0x2AA;
> }
>
> /* Used to fix CFI-Tables of chips without Extended Query Tables */
> static struct cfi_fixup cfi_nopri_fixup_table[] = {
>    { CFI_MFR_SST, 0x235C, fixup_sst39vf_rev_b, NULL, }, // SST39VF3202B
>    { CFI_MFR_SST, 0x235D, fixup_sst39vf_rev_b, NULL, }, // SST39VF3201B
>    { CFI_MFR_SST, 0x236C, fixup_sst39vf_rev_b, NULL, }, // SST39VF6402B
>    { CFI_MFR_SST, 0x236D, fixup_sst39vf_rev_b, NULL, }, // SST39VF6401B
>    { 0, 0, NULL, NULL }
> };
>


----- Original Message ----- 
From: "Fabio Giovagnini" <fabio.giovagnini@aurion-tech.com>
To: <linux-mtd@lists.infradead.org>
Cc: "yidong zhang" <zhangyd6@gmail.com>; <David.Woodhouse@intel.com>;
"Wolfram Sang" <w.sang@pengutronix.de>; <yegorslists@googlemail.com>;
"Guillaume LECERF" <glecerf@gmail.com>; <taliaferro62@gmail.com>
Sent: Friday, October 22, 2010 2:50 PM
Subject: Re: [Help] SST39VF6401B Support


Hi Guys,
As Gullelm remeber for sure, I used the jedec probe for such a flash in a
very
old 2.6 kernel.

Now I'm migrating to the newets one kernel.
Do you tell me how the kernel will be updated with the last mtd stuff
developed; or in place of it how to patch a standard kernel?

Thanks a  lot and sorry for my question if it is improper


In data venerdì 22 ottobre 2010 17:42:39, yidong zhang ha scritto:
: > On Fri, Oct 22, 2010 at 11:36 PM, Guillaume LECERF <glecerf@gmail.com>
wrote:
> > 2010/10/22 yidong zhang <zhangyd6@gmail.com>:
> >>> Could you try setting cif->cfiq->EraseRegionInfo[0] to 0x02003FF in
> >>> fixup_sst39vf_rev_b() ?
> >>
> >> Hi
> >>  how about this attached patch.
> >
> > If it works for you, I'll send a patch series for SST 39VF640xB and
> > 38VF640x, because both chips needs 0x50 as erase command.
>
> Sorry, i cannot test it right now.  I will sent the result as soon as i
> can.
>
> > --
> > Guillaume LECERF
> > GeeXboX developer - www.geexbox.org
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 
Ing. Fabio Giovagnini

Aurion s.r.l.
P.I e C.F.
00885711200
skype: aurion.giovagnini
Tel. +39.051.594.78.24
Cell. +39.335.83.50.919
www.aurion-tech.com

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[-- Attachment #2: cfi_cmdset_0002.c --]
[-- Type: application/octet-stream, Size: 54745 bytes --]

/*
 * Common Flash Interface support:
 *   AMD & Fujitsu Standard Vendor Command Set (ID 0x0002)
 *
 * Copyright (C) 2000 Crossnet Co. <info@crossnet.co.jp>
 * Copyright (C) 2004 Arcom Control Systems Ltd <linux@arcom.com>
 * Copyright (C) 2005 MontaVista Software Inc. <source@mvista.com>
 *
 * 2_by_8 routines added by Simon Munton
 *
 * 4_by_16 work by Carolyn J. Smith
 *
 * XIP support hooks by Vitaly Wool (based on code for Intel flash
 * by Nicolas Pitre)
 *
 * Occasionally maintained by Thayne Harbaugh tharbaugh at lnxi dot com
 *
 * This code is GPL
 *
 * $Id: cfi_cmdset_0002.c,v 1.122 2005/11/07 11:14:22 gleixner Exp $
 *
 */

#include <linux/module.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/init.h>
#include <asm/io.h>
#include <asm/byteorder.h>

#include <linux/errno.h>
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/mtd/compatmac.h>
#include <linux/mtd/map.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/cfi.h>
#include <linux/mtd/xip.h>

#define AMD_BOOTLOC_BUG
#define FORCE_WORD_WRITE 0

#define MAX_WORD_RETRIES 3

#define MANUFACTURER_AMD	0x0001
#define MANUFACTURER_ATMEL	0x001F
#define MANUFACTURER_SST	0x00BF
#define SST49LF004B	        0x0060
#define SST49LF040B	        0x0050
#define SST49LF008A		0x005a
#define AT49BV6416		0x00d6
#define MANUFACTURER_SAMSUNG    0x00ec

static int cfi_amdstd_read (struct mtd_info *, loff_t, size_t, size_t *, u_char *);
static int cfi_amdstd_write_words(struct mtd_info *, loff_t, size_t, size_t *, const u_char *);
static int cfi_amdstd_write_buffers(struct mtd_info *, loff_t, size_t, size_t *, const u_char *);
static int cfi_amdstd_erase_chip(struct mtd_info *, struct erase_info *);
static int cfi_amdstd_erase_varsize(struct mtd_info *, struct erase_info *);
static void cfi_amdstd_sync (struct mtd_info *);
static int cfi_amdstd_suspend (struct mtd_info *);
static void cfi_amdstd_resume (struct mtd_info *);
static int cfi_amdstd_secsi_read (struct mtd_info *, loff_t, size_t, size_t *, u_char *);

static void cfi_amdstd_destroy(struct mtd_info *);

struct mtd_info *cfi_cmdset_0002(struct map_info *, int);
static struct mtd_info *cfi_amdstd_setup (struct mtd_info *);

static int get_chip(struct map_info *map, struct flchip *chip, unsigned long adr, int mode);
static void put_chip(struct map_info *map, struct flchip *chip, unsigned long adr);
#include "fwh_lock.h"

static int cfi_atmel_lock(struct mtd_info *mtd, loff_t ofs, size_t len);
static int cfi_atmel_unlock(struct mtd_info *mtd, loff_t ofs, size_t len);

static struct mtd_chip_driver cfi_amdstd_chipdrv = {
	.probe		= NULL, /* Not usable directly */
	.destroy	= cfi_amdstd_destroy,
	.name		= "cfi_cmdset_0002",
	.module		= THIS_MODULE
};


/* #define DEBUG_CFI_FEATURES */


#ifdef DEBUG_CFI_FEATURES
static void cfi_tell_features(struct cfi_pri_amdstd *extp)
{
	const char* erase_suspend[3] = {
		"Not supported", "Read only", "Read/write"
	};
	const char* top_bottom[6] = {
		"No WP", "8x8KiB sectors at top & bottom, no WP",
		"Bottom boot", "Top boot",
		"Uniform, Bottom WP", "Uniform, Top WP"
	};

	printk("  Silicon revision: %d\n", extp->SiliconRevision >> 1);
	printk("  Address sensitive unlock: %s\n",
	       (extp->SiliconRevision & 1) ? "Not required" : "Required");

	if (extp->EraseSuspend < ARRAY_SIZE(erase_suspend))
		printk("  Erase Suspend: %s\n", erase_suspend[extp->EraseSuspend]);
	else
		printk("  Erase Suspend: Unknown value %d\n", extp->EraseSuspend);

	if (extp->BlkProt == 0)
		printk("  Block protection: Not supported\n");
	else
		printk("  Block protection: %d sectors per group\n", extp->BlkProt);


	printk("  Temporary block unprotect: %s\n",
	       extp->TmpBlkUnprotect ? "Supported" : "Not supported");
	printk("  Block protect/unprotect scheme: %d\n", extp->BlkProtUnprot);
	printk("  Number of simultaneous operations: %d\n", extp->SimultaneousOps);
	printk("  Burst mode: %s\n",
	       extp->BurstMode ? "Supported" : "Not supported");
	if (extp->PageMode == 0)
		printk("  Page mode: Not supported\n");
	else
		printk("  Page mode: %d word page\n", extp->PageMode << 2);

	printk("  Vpp Supply Minimum Program/Erase Voltage: %d.%d V\n",
	       extp->VppMin >> 4, extp->VppMin & 0xf);
	printk("  Vpp Supply Maximum Program/Erase Voltage: %d.%d V\n",
	       extp->VppMax >> 4, extp->VppMax & 0xf);

	if (extp->TopBottom < ARRAY_SIZE(top_bottom))
		printk("  Top/Bottom Boot Block: %s\n", top_bottom[extp->TopBottom]);
	else
		printk("  Top/Bottom Boot Block: Unknown value %d\n", extp->TopBottom);
}
#endif

#ifdef AMD_BOOTLOC_BUG
/* Wheee. Bring me the head of someone at AMD. */
static void fixup_amd_bootblock(struct mtd_info *mtd, void* param)
{
	struct map_info *map = mtd->priv;
	struct cfi_private *cfi = map->fldrv_priv;
	struct cfi_pri_amdstd *extp = cfi->cmdset_priv;
	__u8 major = extp->MajorVersion;
	__u8 minor = extp->MinorVersion;

	if (((major << 8) | minor) < 0x3131) {
		/* CFI version 1.0 => don't trust bootloc */
		if (cfi->id & 0x80) {
			printk(KERN_WARNING "%s: JEDEC Device ID is 0x%02X. Assuming broken CFI table.\n", map->name, cfi->id);
			extp->TopBottom = 3;	/* top boot */
		} else {
			extp->TopBottom = 2;	/* bottom boot */
		}
	}
}
#endif

static void fixup_use_write_buffers(struct mtd_info *mtd, void *param)
{
	struct map_info *map = mtd->priv;
	struct cfi_private *cfi = map->fldrv_priv;
	if (cfi->cfiq->BufWriteTimeoutTyp) {
		DEBUG(MTD_DEBUG_LEVEL1, "Using buffer write method\n" );
		mtd->write = cfi_amdstd_write_buffers;
	}
}

/* Atmel chips don't use the same PRI format as AMD chips */
static void fixup_convert_atmel_pri(struct mtd_info *mtd, void *param)
{
	struct map_info *map = mtd->priv;
	struct cfi_private *cfi = map->fldrv_priv;
	struct cfi_pri_amdstd *extp = cfi->cmdset_priv;
	struct cfi_pri_atmel atmel_pri;

	memcpy(&atmel_pri, extp, sizeof(atmel_pri));
	memset((char *)extp + 5, 0, sizeof(*extp) - 5);

	if (atmel_pri.Features & 0x02)
		extp->EraseSuspend = 2;

	if (atmel_pri.BottomBoot)
		extp->TopBottom = 2;
	else
		extp->TopBottom = 3;
}

static void fixup_use_secsi(struct mtd_info *mtd, void *param)
{
	/* Setup for chips with a secsi area */
	mtd->read_user_prot_reg = cfi_amdstd_secsi_read;
	mtd->read_fact_prot_reg = cfi_amdstd_secsi_read;
}

static void fixup_use_erase_chip(struct mtd_info *mtd, void *param)
{
	struct map_info *map = mtd->priv;
	struct cfi_private *cfi = map->fldrv_priv;
	if ((cfi->cfiq->NumEraseRegions == 1) &&
		((cfi->cfiq->EraseRegionInfo[0] & 0xffff) == 0)) {
		mtd->erase = cfi_amdstd_erase_chip;
	}

}

/*
 * Some Atmel chips (e.g. the AT49BV6416) power-up with all sectors
 * locked by default.
 */
static void fixup_use_atmel_lock(struct mtd_info *mtd, void *param)
{
	mtd->lock = cfi_atmel_lock;
	mtd->unlock = cfi_atmel_unlock;
	mtd->flags |= MTD_STUPID_LOCK;
}

static void fixup_old_sst_eraseregion(struct mtd_info *mtd)
{
	struct map_info *map = mtd->priv;
	struct cfi_private *cfi = map->fldrv_priv;

	/*
	 * These flashes report two seperate eraseblock regions based on the
	 * sector_erase-size and block_erase-size, although they both operate on the
	 * same memory. This is not allowed according to CFI, so we just pick the
	 * sector_erase-size.
	 */
	cfi->cfiq->NumEraseRegions = 1;
}

static void fixup_sst39vf(struct mtd_info *mtd, void *param)
{
	struct map_info *map = mtd->priv;
	struct cfi_private *cfi = map->fldrv_priv;

	fixup_old_sst_eraseregion(mtd);

	cfi->addr_unlock1 = 0x5555;
	cfi->addr_unlock2 = 0x2AAA;
}

static void fixup_sst39vf_rev_b(struct mtd_info *mtd, void *param)
{
	struct map_info *map = mtd->priv;
	struct cfi_private *cfi = map->fldrv_priv;

	fixup_old_sst_eraseregion(mtd);

	cfi->addr_unlock1 = 0x555;
	cfi->addr_unlock2 = 0x2AA;
}

/* Used to fix CFI-Tables of chips without Extended Query Tables */
static struct cfi_fixup cfi_nopri_fixup_table[] = {
	{ MANUFACTURER_SST, 0x234A, fixup_sst39vf, NULL, }, // SST39VF1602
	{ MANUFACTURER_SST, 0x234B, fixup_sst39vf, NULL, }, // SST39VF1601
	{ MANUFACTURER_SST, 0x235A, fixup_sst39vf, NULL, }, // SST39VF3202
	{ MANUFACTURER_SST, 0x235B, fixup_sst39vf, NULL, }, // SST39VF3201
	{ MANUFACTURER_SST, 0x235C, fixup_sst39vf_rev_b, NULL, }, // SST39VF3202B
	{ MANUFACTURER_SST, 0x235D, fixup_sst39vf_rev_b, NULL, }, // SST39VF3201B
	{ MANUFACTURER_SST, 0x236C, fixup_sst39vf_rev_b, NULL, }, // SST39VF6402B
	{ MANUFACTURER_SST, 0x236D, fixup_sst39vf_rev_b, NULL, }, // SST39VF6401B
	{ 0, 0, NULL, NULL }
};

static struct cfi_fixup cfi_fixup_table[] = {
#ifdef AMD_BOOTLOC_BUG
	{ CFI_MFR_AMD, CFI_ID_ANY, fixup_amd_bootblock, NULL },
#endif
	{ CFI_MFR_AMD, 0x0050, fixup_use_secsi, NULL, },
	{ CFI_MFR_AMD, 0x0053, fixup_use_secsi, NULL, },
	{ CFI_MFR_AMD, 0x0055, fixup_use_secsi, NULL, },
	{ CFI_MFR_AMD, 0x0056, fixup_use_secsi, NULL, },
	{ CFI_MFR_AMD, 0x005C, fixup_use_secsi, NULL, },
	{ CFI_MFR_AMD, 0x005F, fixup_use_secsi, NULL, },
#if !FORCE_WORD_WRITE
	{ CFI_MFR_ANY, CFI_ID_ANY, fixup_use_write_buffers, NULL, },
#endif
	{ CFI_MFR_ATMEL, CFI_ID_ANY, fixup_convert_atmel_pri, NULL },
	{ 0, 0, NULL, NULL }
};
static struct cfi_fixup jedec_fixup_table[] = {
	{ MANUFACTURER_SST, SST49LF004B, fixup_use_fwh_lock, NULL, },
	{ MANUFACTURER_SST, SST49LF040B, fixup_use_fwh_lock, NULL, },
	{ MANUFACTURER_SST, SST49LF008A, fixup_use_fwh_lock, NULL, },
	{ 0, 0, NULL, NULL }
};

static struct cfi_fixup fixup_table[] = {
	/* The CFI vendor ids and the JEDEC vendor IDs appear
	 * to be common.  It is like the devices id's are as
	 * well.  This table is to pick all cases where
	 * we know that is the case.
	 */
	{ CFI_MFR_ANY, CFI_ID_ANY, fixup_use_erase_chip, NULL },
	{ CFI_MFR_ATMEL, AT49BV6416, fixup_use_atmel_lock, NULL },
	{ 0, 0, NULL, NULL }
};


struct mtd_info *cfi_cmdset_0002(struct map_info *map, int primary)
{
	struct cfi_private *cfi = map->fldrv_priv;
	struct mtd_info *mtd;
	int i;

	mtd = kzalloc(sizeof(*mtd), GFP_KERNEL);
	if (!mtd) {
		printk(KERN_WARNING "Failed to allocate memory for MTD device\n");
		return NULL;
	}
	mtd->priv = map;
	mtd->type = MTD_NORFLASH;

	/* Fill in the default mtd operations */
	mtd->erase   = cfi_amdstd_erase_varsize;
	mtd->write   = cfi_amdstd_write_words;
	mtd->read    = cfi_amdstd_read;
	mtd->sync    = cfi_amdstd_sync;
	mtd->suspend = cfi_amdstd_suspend;
	mtd->resume  = cfi_amdstd_resume;
	mtd->flags   = MTD_CAP_NORFLASH;
	mtd->name    = map->name;
	mtd->writesize = 1;

	if (cfi->cfi_mode==CFI_MODE_CFI){
		unsigned char bootloc;
		/*
		 * It's a real CFI chip, not one for which the probe
		 * routine faked a CFI structure. So we read the feature
		 * table from it.
		 */
		__u16 adr = primary?cfi->cfiq->P_ADR:cfi->cfiq->A_ADR;
		struct cfi_pri_amdstd *extp;

		extp = (struct cfi_pri_amdstd*)cfi_read_pri(map, adr, sizeof(*extp), "Amd/Fujitsu");
		if (!extp) {
			kfree(mtd);
			return NULL;
		}

		if (extp->MajorVersion != '1' ||
		  (extp->MinorVersion < '0' || extp->MinorVersion > '4')) {
				if (cfi->mfr == MANUFACTURER_SAMSUNG &&
				  (extp->MajorVersion == '3' && extp->MinorVersion == '3')) {
					printk(KERN_NOTICE "  Newer Samsung flash detected, "
					       "should be compatibile with Amd/Fujitsu.\n");
				}
				else if (cfi->mfr == MANUFACTURER_SAMSUNG && extp->MajorVersion == '0') {
					printk(KERN_NOTICE "  Newer Samsung flash detected, "
					       "should be compatibile with Amd/Fujitsu.\n");
					switch (cfi->id) {
						case 0x257e:
						case 0x22e2:
						extp->MajorVersion = '1';
						break;
					}
				}
				else {
					printk(KERN_ERR