public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
* problems with 28F320B still
@ 2001-09-25 20:40 Larry Doolittle
  2001-09-25 21:00 ` David Woodhouse
  0 siblings, 1 reply; 7+ messages in thread
From: Larry Doolittle @ 2001-09-25 20:40 UTC (permalink / raw)
  To: linux-mtd

I have troubles turning on the MTD subsystem on
a Bright Star nanoEngine, one of those infamous
boards with an Intel 28F320B3 (non-CFI-compliant)
chip on it. 

With DEBUG_CFI set in drivers/mtd/chips/cfi_probe.c,
a linux-2.4.9-ac9-rmk1-np1 boot log shows:

physmap flash device: 4194304 at 0
Physically mapped flash: Found 1 x16 devices at 0x0 in 16-bit mode
Number of erase regions: 2
  Erase Region #0: BlockSize 0xFFFF00 bytes, 65536 blocks
  Erase Region #1: BlockSize 0xFFFF00 bytes, 65536 blocks
Primary Vendor Command Set: 0003 (Intel/Sharp Standard)
Primary Algorithm Table at 0035
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
Vpp Minimum: b.4 V
Vpp Maximum: c.6 V
Typical byte/word write timeout: 32 5s
Maximum byte/word write timeout: 512 5s
Full buffer write not supported
Typical block erase timeout: 1024 5s
Maximum block erase timeout: 8192 5s
Chip erase not supported
Device size: 0x0 bytes (0 MiB)
Flash Device Interface description: 0xFFFF
  - Not Allowed / Reserved
Max. bytes in buffer write: 0x1
Number of Erase Block Regions: 2

.... and then hangs.  If I don't try to turn on MTD support,
this machine boots and runs very nicely, thankyouverymuch.

I won't post my full .config file here, it's pretty normal,
the MTD stuff comes out looking like this:

CONFIG_MTD=y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_JEDEC=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0
CONFIG_MTD_PHYSMAP_LEN=4194304
CONFIG_MTD_PHYSMAP_BUSWIDTH=2
CONFIG_MTD_SA1100=y

(I had to select CONFIG_MTD_CFI in order to get CONFIG_MTD_SA1100;
is that a bug?)

I read the recent postings from Alex Kremer and Daniel Belz.
I don't see that either of their work has been folded into
the current CVS tree, or I'd try that.  If someone is going
to forward port and merge their work into the CVS tree and
from there to np->rmk->ac->lt, I don't want it to be me.
I have other battles to fight ;-) .

Of course, maybe there is something simpler that I'm doing wrong.
Suggestions, anyone?

       - Larry Doolittle   <LRDoolittle@lbl.gov>

P.S. Hi, Erik -- I see we bump into each other again!

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: problems with 28F320B still
  2001-09-25 20:40 problems with 28F320B still Larry Doolittle
@ 2001-09-25 21:00 ` David Woodhouse
  2001-09-25 21:25   ` Larry Doolittle
                     ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: David Woodhouse @ 2001-09-25 21:00 UTC (permalink / raw)
  To: Larry Doolittle; +Cc: linux-mtd

ldoolitt@recycle.lbl.gov said:
> boards with an Intel 28F320B3 (non-CFI-compliant) chip on it. 
> With DEBUG_CFI set in drivers/mtd/chips/cfi_probe.c, a
> linux-2.4.9-ac9-rmk1-np1 boot log shows: 

It's not a CFI chip. Why is cfi_probe claiming to recognise it? The CFI 
structure you quoted is obviously wrong. 

>  Erase Region #0: BlockSize 0xFFFF00 bytes, 65536 blocks
>  Erase Region #1: BlockSize 0xFFFF00 bytes, 65536 blocks
> Device size: 0x0 bytes (0 MiB)


--
dwmw2

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: problems with 28F320B still
  2001-09-25 21:00 ` David Woodhouse
@ 2001-09-25 21:25   ` Larry Doolittle
  2001-09-25 21:28     ` David Woodhouse
  2001-09-26 19:38   ` problems with 28F320B still Larry Doolittle
  2001-09-27 22:39   ` Larry Doolittle
  2 siblings, 1 reply; 7+ messages in thread
From: Larry Doolittle @ 2001-09-25 21:25 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-mtd

David -

> [the 28F320B3] is not a CFI chip. Why is cfi_probe claiming to
> recognise it? The CFI structure you quoted is obviously wrong. 

I can't tell you why it was recognized, but the probe was
triggered by the line in drivers/mtd/maps/physmap.c :

	mymtd = do_map_probe("cfi_probe", &physmap_map);

I added a coupla printk's, and find it entered cfi_probe_chip with
cfi->device_type==2.  The line in the logfile
   Physically mapped flash: Found 1 x16 devices at 0x0 in 16-bit mode
came from the first of two cfi_probe_chip_1() calls within cfi_probe_chip(),
which returned index == 0.

I'll happily apply patches and help debug, but I'm not terribly
familiar with this corner of the Linux kernel, so suggestions
and comments will be greatly appreciated.

    - Larry

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: problems with 28F320B still
  2001-09-25 21:25   ` Larry Doolittle
@ 2001-09-25 21:28     ` David Woodhouse
       [not found]       ` <20010925143742.A22632@recycle.lbl.gov>
  0 siblings, 1 reply; 7+ messages in thread
From: David Woodhouse @ 2001-09-25 21:28 UTC (permalink / raw)
  To: Larry Doolittle; +Cc: linux-mtd

Ideally, this would be done by implementing a new probe routine which can 
detect these chips, make up a fake CFI structure, and pass control to the 
normal cfi_cmdset_000x back end. 

Alternatively, a patch was posted to the mailing list recently which 
contained a standalone driver for these chips alone. 

--
dwmw2

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: problems with 28F320B still
  2001-09-25 21:00 ` David Woodhouse
  2001-09-25 21:25   ` Larry Doolittle
@ 2001-09-26 19:38   ` Larry Doolittle
  2001-09-27 22:39   ` Larry Doolittle
  2 siblings, 0 replies; 7+ messages in thread
From: Larry Doolittle @ 2001-09-26 19:38 UTC (permalink / raw)
  To: linux-mtd

I can make the (current CVS) MTD system on a nanoEngine recognize
the on-board Intel TE28F320B3 if I do the following:
1. disable BLKGETSIZE64 support in drivers/mtd/mtdblock.c.  :-p
2. configure for CONFIG_MTD_CFI, CONFIG_MTD_JEDECPROBE, and
   CONFIG_MTD_CFI_AMDSTD, among other things.
3. adjust drivers/mtd/maps/sa1100-flash.c to create nanoEngine
   Flash mappings.
4. Change the first argument in the call to do_map_probe() in
   sa1100-flash.c from "cfi_probe" to "jedec_probe".

I'm nervous about progressing from here, in part because of the
amount of fussing that Daniel Belz did to the cfi_cmdset_0002
driver, when _he_ tackled the 320B3.  I append the diff between 
the CVS copy with Id:
   cfi_cmdset_0002.c,v 1.49 2001/07/14 00:59:16 thockin Exp
and Daniel's posting of Tue, 04 Sep 2001.  I'd appreciate advice
on which, if any, of these changes should be adapted to the current
CVS tree.  I'd really rather not corrupt the data on this chip!

If I leave off item 4 above, something triggers a false positive
detection of a CFI-compliant device.  I added more printk's to
qry_present() in cfi_probe.c, and forced its output to 0, like this:
        printk(KERN_NOTICE "qry_present: base=%x, osf=%d\n", base, osf);
        printk(KERN_NOTICE " 'Q': %.8x == %.8x\n", cfi_read(map,base+osf*0x10), cfi_build_cmd('Q',map,cfi));
        printk(KERN_NOTICE " 'R': %.8x == %.8x\n", cfi_read(map,base+osf*0x11), cfi_build_cmd('R',map,cfi));
        printk(KERN_NOTICE " 'Y': %.8x == %.8x\n", cfi_read(map,base+osf*0x12), cfi_build_cmd('Y',map,cfi));
        return 0;       // disable false positive on nanoEngine
with the result:
SA1100 flash: probing 16-bit flash bus
qry_present: base=0, osf=2
 'Q': 00000051 == 00000051
 'R': 00000052 == 00000052
 'Y': 00000059 == 00000059
qry_present: base=0, osf=2
 'Q': 00000051 == 00005151
 'R': 00000052 == 00005252
 'Y': 00000059 == 00005959
qry_present: base=0, osf=4
 'Q': 00000000 == 00005151
 'R': 00000000 == 00005252
 'Y': 00000000 == 00005959
CFI: Found no SA1100 flash device at location zero

It sure looks like 'QRY' is in there!

     - Larry


--- mtd/drivers/mtd/chips/cfi_cmdset_0002.c	Fri Jul 13 17:59:16 2001
+++ cfi_cmdset_0002.c	Wed Sep 26 12:05:52 2001
@@ -106,7 +106,7 @@
 		}
 	}
     }
-
+    //JEDEC so pega daqui em diante -- belz
     /* If there was an old setup function, decrease its use count */
     if (map->fldrv)
       if(map->fldrv->module)
@@ -199,11 +199,11 @@
 	case 1:
 	case 2:
 	case 4:
-#if 1
+//#if 1
 		if (mtd->numeraseregions > 1)
 			mtd->erase = cfi_amdstd_erase_varsize;
 		else
-#endif
+//#endif
 			mtd->erase = cfi_amdstd_erase_onesize;
 		mtd->read = cfi_amdstd_read;
 		mtd->write = cfi_amdstd_write;
@@ -230,6 +230,7 @@
 {
 	DECLARE_WAITQUEUE(wait, current);
 	unsigned long timeo = jiffies + HZ;
+        struct cfi_private *cfi = map->fldrv_priv;
 
  retry:
 	cfi_spin_lock(chip->mutex);
@@ -256,6 +257,10 @@
 
 	chip->state = FL_READY;
 
+        
+        cfi_write(map, CMD(0xFF), adr); //belz
+
+
 	map->copy_from(map, buf, adr, len);
 
 	wake_up(&chip->wq);
@@ -308,12 +313,15 @@
 static int do_write_oneword(struct map_info *map, struct flchip *chip, unsigned long adr, __u32 datum, int fast)
 {
 	unsigned long timeo = jiffies + HZ;
-	unsigned int Last[4];
-	unsigned long Count = 0;
+        //unsigned int Last[4];    //com belz
+        //unsigned long Count = 0; //com belz
 	struct cfi_private *cfi = map->fldrv_priv;
 	DECLARE_WAITQUEUE(wait, current);
 	int ret = 0;
+        __u32 status, status_OK; //belz
 
+
+        status_OK = CMD(0x80);
  retry:
 	cfi_spin_lock(chip->mutex);
 
@@ -340,7 +348,8 @@
 
 	adr += chip->start;
 	ENABLE_VPP(map);
-	if (fast) { /* Unlock bypass */
+        
+        if (fast) { // Unlock bypass
 		cfi_send_gen_cmd(0xA0, 0, chip->start, map, cfi, cfi->device_type, NULL);
 	}
 	else {
@@ -349,18 +358,58 @@
 	        cfi_send_gen_cmd(0xA0, cfi->addr_unlock1, chip->start, map, cfi, CFI_DEVICETYPE_X8, NULL);
 	}
 
+        //cfi_write(map, CMD(0x50), adr); //belz
+        cfi_write(map, CMD(0x40), adr); //belz
 	cfi_write(map, datum, adr);
 
+
 	cfi_spin_unlock(chip->mutex);
 	cfi_udelay(chip->word_write_time);
 	cfi_spin_lock(chip->mutex);
 
+        
+        
+        
+        //belz inicio
+        
+        
+        while ( ( (status = cfi_read(map,adr)) & status_OK ) != status_OK ) {
+                static int z=0;
+                /* OK Still waiting */
+                if (time_after(jiffies, timeo)) {
+                        chip->state = FL_READY;
+                        cfi_spin_unlock(chip->mutex);
+                        printk("waiting for writing to complete timed out.");
+                        DISABLE_VPP(map);
+                        return -EIO;
+                }
+                
+                /* Latency issues. Drop the lock, wait a while and retry */
+                cfi_spin_unlock(chip->mutex);
+
+                z++;
+                if ( 0 && !(z % 100 ))
+                        printk("chip not ready yet after write. looping\n");
+
+                cfi_udelay(1);
+                
+                cfi_spin_lock(chip->mutex);
+                continue;
+        }
+
+        
+        
+        
+        
+        //belz fim
+        /*
+        
 	Last[0] = cfi_read(map, adr);
-	//	printk("Last[0] is %x\n", Last[0]);
+                printk("Last[0] is %x\n", Last[0]);
 	Last[1] = cfi_read(map, adr);
-	//	printk("Last[1] is %x\n", Last[1]);
+                printk("Last[1] is %x\n", Last[1]);
 	Last[2] = cfi_read(map, adr);
-	//	printk("Last[2] is %x\n", Last[2]);
+                printk("Last[2] is %x\n", Last[2]);
 
 	for (Count = 3; Last[(Count - 1) % 4] != Last[(Count - 2) % 4] && Count < 10000; Count++){
 		cfi_spin_unlock(chip->mutex);
@@ -376,7 +425,7 @@
 	        cfi_send_gen_cmd(0xF0, 0, chip->start, map, cfi, cfi->device_type, NULL);
 		DISABLE_VPP(map);
 		ret = -EIO;
-	}       
+        } */
 	DISABLE_VPP(map);
 	chip->state = FL_READY;
 	wake_up(&chip->wq);
@@ -425,7 +474,6 @@
 				bus_ofs, datum, 0);
 		if (ret) 
 			return ret;
-		
 		ofs += n;
 		buf += n;
 		(*retlen) += n;
@@ -436,6 +484,7 @@
 			if (chipnum == cfi->numchips)
 				return 0;
 		}
+
 	}
 	
 	/* Go into unlock bypass mode */
@@ -443,6 +492,8 @@
 	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chipstart, map, cfi, CFI_DEVICETYPE_X8, NULL);
 	cfi_send_gen_cmd(0x20, cfi->addr_unlock1, chipstart, map, cfi, CFI_DEVICETYPE_X8, NULL);
 
+        //cfi_write(map, CMD(0x40), 0); //belz
+
 	/* We are now aligned, write as much as possible */
 	while(len >= CFIDEV_BUSWIDTH) {
 		__u32 datum;
@@ -564,7 +615,7 @@
 	cfi_send_gen_cmd(0x80, cfi->addr_unlock1, chip->start, map, cfi, CFI_DEVICETYPE_X8, NULL);
 	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi, CFI_DEVICETYPE_X8, NULL);
 	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi, CFI_DEVICETYPE_X8, NULL);
-	cfi_write(map, CMD(0x30), adr);
+        //cfi_write(map, CMD(0x20), adr);
 	
 	timeo = jiffies + (HZ*20);
 
@@ -573,7 +624,9 @@
 	cfi_spin_lock(chip->mutex);
 	
 	rdy_mask = CMD(0x80);
-
+        cfi_write(map, CMD(0x50), adr);//<----foi inserido e com
+        cfi_write(map, CMD(0x20), adr);//<----foi inserido
+        cfi_write(map, CMD(0xD0), adr);//<----foi inserido
 	/* FIXME. Use a timer to check this, and return immediately. */
 	/* Once the state machine's known to be working I'll do that */
 
@@ -603,7 +656,7 @@
 		if (time_after(jiffies, timeo)) {
 			chip->state = FL_READY;
 			cfi_spin_unlock(chip->mutex);
-			printk("waiting for erase to complete timed out.");
+                        printk("--->(status:%X, cfi_read:%X) waiting for erase to complete timed out.",chip->state,cfi_read(map, adr));
 			DISABLE_VPP(map);
 			return -EIO;
 		}

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: problems with 28F320B still
  2001-09-25 21:00 ` David Woodhouse
  2001-09-25 21:25   ` Larry Doolittle
  2001-09-26 19:38   ` problems with 28F320B still Larry Doolittle
@ 2001-09-27 22:39   ` Larry Doolittle
  2 siblings, 0 replies; 7+ messages in thread
From: Larry Doolittle @ 2001-09-27 22:39 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-mtd

I think I am slowly starting to grok at least part of the MTD chip
driver layer.  Tell me if I'm on the right track.

All the chips listed in
	static const struct amd_flash_info jedec_table[]
in drivers/mtd/chips/jedec_probe.c use the cfi_cmdset_0002.c driver.
This is implemented with the line
	p_cfi->cfiq->P_ID = P_ID_AMD_STD;
deep inside cfi_jedec_setup().

Now I come along trying to turn on an Intel TE28B320B3B, which
is a non-CFI chip, with a valid JEDEC code (manufacturer=0x0089,
product=0x8897), but which needs to use the cfi_cmdset_0001.c
driver.

Maybe I should modify jedec_probe.c to add another field to
the amd_flash_info structure, telling which command set to use.
All existing chips would set that to P_ID_AMD_STD, but my new
entry would have P_ID_INTEL_STD.  Such a change would obsolete
the name of the structure, which I wouldn't worry about for now.

If Intel is really a special case, an alternative would be to say:
	p_cfi->cfiq->P_ID =
 (p_cfi->mfr==MANUFACTURER_INTEL) ? P_ID_INTEL_STD : P_ID_AMD_STD;

The only chip feature that I found that is used in cfi_cmdset_0001.c
that is not shown in the data sheet for the 'B3 series chip data
sheet is block program (command code 0xe8).  I would have to find
some way to disable that section of the code in do_write_buffer(),
and fall back to single word programming.  Not hard to hack, but
in order for main branch code to claim 'B3 support, a flag would
need to be communicated from jedec_probe to cfi_cmdset_0001.

       - Larry Doolittle   <LRDoolittle@lbl.gov>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* problems with 28F320B: resolved?
       [not found]                     ` <20010928123452.A6016@recycle.lbl.gov>
@ 2001-09-28 23:07                       ` Larry Doolittle
  0 siblings, 0 replies; 7+ messages in thread
From: Larry Doolittle @ 2001-09-28 23:07 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-mtd

David -

Hah!  I can prove that I can read, write, and erase a sector in my
28F320B3 Flash chip!

This patch is pretty much similar to what I sent you last night.
In particular, I haven't heard back from Nico on the sa1100-flash
change, and I kept the quick Intel hack instead of adding another
field.  I don't think the override I put in to keep non-CFI chipos
from using block write is necessary, it looks like that happens
anyway in cfi_intelext_setup() because cfi->cfiq->BufWriteTimeoutTyp
is not set.

Unless you want to muck around with adding another field yourself
(probably reclaiming space from the unused InterfaceDesc field),
this looks good enough to put in CVS.  Read through this patch,
I found a couple of other trivial improvements that should go in.

     - Larry

diff -urN --exclude=Repository --exclude=Root --exclude=Entries --exclude=Rules.make --exclude=GNUmakefile /home/ldoolitt/cvs/mtd/drivers/mtd/chips/cfi_cmdset_0001.c linux-2.4.9-ac9-rmk1-np1-lrd1/drivers/mtd/chips/cfi_cmdset_0001.c
--- /home/ldoolitt/cvs/mtd/drivers/mtd/chips/cfi_cmdset_0001.c	Sun Sep  2 11:53:17 2001
+++ linux-2.4.9-ac9-rmk1-np1-lrd1/drivers/mtd/chips/cfi_cmdset_0001.c	Fri Sep 28 13:28:55 2001
@@ -889,7 +889,9 @@
 	}
 
 	/* Write buffer is worth it only if more than one word to write... */
-	while(len > CFIDEV_BUSWIDTH) {
+	/* Assume only CFI chips have this feature, until otherwise specified.
+	 * The non-CFI chips this intends to support are the Intel 28FxxxB3 series. */
+	while(cfi->cfi_mode && len > CFIDEV_BUSWIDTH) {
 		/* We must not cross write block boundaries */
 		int size = wbufsize - (ofs & (wbufsize-1));
 
diff -urN --exclude=Repository --exclude=Root --exclude=Entries --exclude=Rules.make --exclude=GNUmakefile /home/ldoolitt/cvs/mtd/drivers/mtd/chips/cfi_cmdset_0002.c linux-2.4.9-ac9-rmk1-np1-lrd1/drivers/mtd/chips/cfi_cmdset_0002.c
--- /home/ldoolitt/cvs/mtd/drivers/mtd/chips/cfi_cmdset_0002.c	Sun Sep  2 11:53:17 2001
+++ linux-2.4.9-ac9-rmk1-np1-lrd1/drivers/mtd/chips/cfi_cmdset_0002.c	Fri Sep 28 13:17:53 2001
@@ -148,7 +148,7 @@
 	unsigned long devsize = (1<<cfi->cfiq->DevSize) * cfi->interleave;
 
 	mtd = kmalloc(sizeof(*mtd), GFP_KERNEL);
-	printk("number of %s chips: %d\n", (cfi->cfi_mode)?"JEDEC":"CFI",cfi->numchips);
+	printk("number of %s chips: %d\n", (cfi->cfi_mode)?"CFI":"JEDEC",cfi->numchips);
 
 	if (!mtd) {
 	  printk("Failed to allocate memory for MTD device\n");
diff -urN --exclude=Repository --exclude=Root --exclude=Entries --exclude=Rules.make --exclude=GNUmakefile /home/ldoolitt/cvs/mtd/drivers/mtd/chips/jedec_probe.c linux-2.4.9-ac9-rmk1-np1-lrd1/drivers/mtd/chips/jedec_probe.c
--- /home/ldoolitt/cvs/mtd/drivers/mtd/chips/jedec_probe.c	Wed Sep 19 14:27:38 2001
+++ linux-2.4.9-ac9-rmk1-np1-lrd1/drivers/mtd/chips/jedec_probe.c	Fri Sep 28 13:21:47 2001
@@ -25,6 +25,7 @@
 #define MANUFACTURER_ATMEL	0x001f
 #define MANUFACTURER_ST		0x0020
 #define MANUFACTURER_SST	0x00BF
+#define MANUFACTURER_INTEL	0x0089
 #define MANUFACTURER_TOSHIBA	0x0098
 
 /* AMD */
@@ -52,6 +53,14 @@
 #define SST39LF800	0x2781
 #define SST39LF160	0x2782
 
+/* Intel */
+#define TE28F160B3T	0x8890
+#define TE28F160B3B	0x8891
+#define TE28F320B3T	0x8896
+#define TE28F320B3B	0x8897
+#define TE28F640B3T	0x8898
+#define TE28F640B3B	0x8899
+
 /* Toshiba */
 #define TC58FVT160	0x00C2
 #define TC58FVB160	0x0043
@@ -248,6 +257,24 @@
                           ERASEINFO(0x08000,2),
 			  ERASEINFO(0x02000,8)
                 }
+	}, {
+		mfr_id: MANUFACTURER_INTEL,
+		dev_id: TE28F320B3T,
+		name: "Intel TE28F320B3-T",
+		DevSize: SIZE_4MiB,
+		NumEraseRegions: 2,
+		regions: {ERASEINFO(0x10000,63),
+			  ERASEINFO(0x02000,8)
+		}
+	}, {
+		mfr_id: MANUFACTURER_INTEL,
+		dev_id: TE28F320B3B,
+		name: "Intel TE28F320B3-B",
+		DevSize: SIZE_4MiB,
+		NumEraseRegions: 2,
+		regions: {ERASEINFO(0x02000,8),
+			  ERASEINFO(0x10000,63)
+		}
 	} 
 };
 
@@ -269,15 +296,16 @@
 
 	num_erase_regions = jedec_table[index].NumEraseRegions;
 	
-	p_cfi->cfiq = kmalloc(sizeof(struct cfi_ident) + num_erase_regions * 4, GFP_KERNEL);
+	p_cfi->cfiq = kmalloc(sizeof(struct cfi_ident) + num_erase_regions * sizeof(ulong), GFP_KERNEL);
 	if (!p_cfi->cfiq) {
 		//xx printk(KERN_WARNING "%s: kmalloc failed for CFI ident structure\n", map->name);
 		return 0;
 	}
 
+	/* all fields default to zero, _especially_ cfi_mode, where zero represents "fake CFI" */
 	memset(p_cfi->cfiq,0,sizeof(struct cfi_ident));	
 	
-	p_cfi->cfiq->P_ID = P_ID_AMD_STD;
+	p_cfi->cfiq->P_ID = (p_cfi->mfr == MANUFACTURER_INTEL) ? P_ID_INTEL_STD : P_ID_AMD_STD;
 	p_cfi->cfiq->NumEraseRegions = jedec_table[index].NumEraseRegions;
 	p_cfi->cfiq->DevSize = jedec_table[index].DevSize;
 
diff -urN --exclude=Repository --exclude=Root --exclude=Entries --exclude=Rules.make --exclude=GNUmakefile /home/ldoolitt/cvs/mtd/drivers/mtd/maps/sa1100-flash.c linux-2.4.9-ac9-rmk1-np1-lrd1/drivers/mtd/maps/sa1100-flash.c
--- /home/ldoolitt/cvs/mtd/drivers/mtd/maps/sa1100-flash.c	Fri Sep 21 09:10:59 2001
+++ linux-2.4.9-ac9-rmk1-np1-lrd1/drivers/mtd/maps/sa1100-flash.c	Thu Sep 27 15:56:32 2001
@@ -528,6 +528,27 @@
 
 #endif
 
+#ifdef CONFIG_SA1100_NANOENGINE
+/* nanoEngine has one 28F320B3B Flash part in bank 0: */
+static unsigned long nanoengine_max_flash_size = 0x00400000;
+static struct mtd_partition nanoengine_partitions[] = {
+	{
+		name: "nanoEngine boot firmware and parameter table",
+		size: 0x00010000,  /* 32K */
+		offset: 0,
+		mask_flags: MTD_WRITEABLE  /* force read-only */
+	},{
+		name: "kernel/initrd reserved",
+		size: 0x002f0000,
+		offset: 0x10000
+	},{
+		name: "experimental filesystem allocation",
+		size: 0x00100000,
+		offset: 0x300000
+	}
+};
+#endif
+
 #define NB_OF(x)  (sizeof(x)/sizeof(x[0]))
 
 
@@ -641,6 +662,13 @@
 		sa1100_map.size = flexanet_max_flash_size;
 	}
 #endif
+#ifdef CONFIG_SA1100_NANOENGINE
+	if (machine_is_nanoengine()) {
+		parts = nanoengine_partitions;
+		nb_parts = NB_OF(nanoengine_partitions);
+		sa1100_map.size = nanoengine_max_flash_size;
+	}
+#endif
 #ifdef CONFIG_SA1100_STORK
 	if (machine_is_stork()) {
 		parts = stork_partitions;
@@ -654,7 +682,9 @@
 	 * specific machine settings might have been set above.
 	 */
 	printk(KERN_NOTICE "SA1100 flash: probing %d-bit flash bus\n", sa1100_map.buswidth*8);
-	mymtd = do_map_probe("cfi_probe", &sa1100_map);
+	mymtd = do_map_probe("jedec_probe", &sa1100_map);
+	if (!mymtd)
+		mymtd = do_map_probe("cfi_probe", &sa1100_map);
 	if (!mymtd)
 		return -ENXIO;
 	mymtd->module = THIS_MODULE;
diff -urN --exclude=Repository --exclude=Root --exclude=Entries --exclude=Rules.make --exclude=GNUmakefile /home/ldoolitt/cvs/mtd/drivers/mtd/mtdblock.c linux-2.4.9-ac9-rmk1-np1-lrd1/drivers/mtd/mtdblock.c
--- /home/ldoolitt/cvs/mtd/drivers/mtd/mtdblock.c	Sun Sep 23 14:16:32 2001
+++ linux-2.4.9-ac9-rmk1-np1-lrd1/drivers/mtd/mtdblock.c	Thu Sep 27 16:05:22 2001
@@ -540,8 +540,11 @@
 	switch (cmd) {
 	case BLKGETSIZE:   /* Return device size */
 		return put_user((mtdblk->mtd->size >> 9), (long *) arg);
+
+#ifndef CONFIG_ARM
 	case BLKGETSIZE64:
 		return put_user((u64)mtdblk->mtd->size, (u64 *)arg);
+#endif
 		
 	case BLKFLSBUF:
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2001-09-28 22:58 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-09-25 20:40 problems with 28F320B still Larry Doolittle
2001-09-25 21:00 ` David Woodhouse
2001-09-25 21:25   ` Larry Doolittle
2001-09-25 21:28     ` David Woodhouse
     [not found]       ` <20010925143742.A22632@recycle.lbl.gov>
     [not found]         ` <25445.1001454134@redhat.com>
     [not found]           ` <20010925150341.A22897@recycle.lbl.gov>
     [not found]             ` <26239.1001455701@redhat.com>
     [not found]               ` <20010925153929.A24347@recycle.lbl.gov>
     [not found]                 ` <20010927163205.A4845@recycle.lbl.gov>
     [not found]                   ` <24249.1001660788@redhat.com>
     [not found]                     ` <20010928123452.A6016@recycle.lbl.gov>
2001-09-28 23:07                       ` problems with 28F320B: resolved? Larry Doolittle
2001-09-26 19:38   ` problems with 28F320B still Larry Doolittle
2001-09-27 22:39   ` Larry Doolittle

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox