Intel protection register read

Intel protection register read

[Clive Davies]

I sent the patch below to this list a few days ago but had no response. Has 
anyone had a chance to look at it? If its ok, could someone apply it?
(its against 2.3.13-ac4-rmk1)

Thanks,
Clive

diff -purN linux_2.4.13/drivers/mtd/chips/cfi_cmdset_0001.c linux/drivers/mtd/chips/cfi_cmdset_0001.c
--- linux_2.4.13/drivers/mtd/chips/cfi_cmdset_0001.c	Thu Oct  4 23:14:59 2001
+++ linux/drivers/mtd/chips/cfi_cmdset_0001.c	Thu Nov  1 14:37:51 2001
@@ -31,6 +31,7 @@
 #include <linux/mtd/compatmac.h>
 
 static int cfi_intelext_read (struct mtd_info *, loff_t, size_t, size_t *, u_char *);
+static int cfi_intelext_read_prot_reg (struct mtd_info *, loff_t, size_t, size_t *, u_char *);
 static int cfi_intelext_write_words(struct mtd_info *, loff_t, size_t, size_t *, const u_char *);
 static int cfi_intelext_write_buffers(struct mtd_info *, loff_t, size_t, size_t *, const u_char *);
 static int cfi_intelext_erase_varsize(struct mtd_info *, struct erase_info *);
@@ -151,7 +152,23 @@ struct mtd_info *cfi_cmdset_0001(struct 
 		/* Do some byteswapping if necessary */
 		extp->FeatureSupport = cfi32_to_cpu(extp->FeatureSupport);
 		extp->BlkStatusRegMask = cfi32_to_cpu(extp->BlkStatusRegMask);
+		extp->ProtRegAddr = cfi32_to_cpu(extp->ProtRegAddr);
 		
+		
+		/* Read the protection register area from flash */
+		if(extp->NumProtectionFields){
+			cfi_send_gen_cmd(0x90, 0x55, base, map, cfi, cfi->device_type, NULL);
+			cfi->ProtRegData=kmalloc((1<<extp->FactProtRegSize)+(1<<extp->UserProtRegSize),GFP_KERNEL);
+			if(!cfi->ProtRegData){
+				printk(KERN_ERR "Failed to allocate memory\n");
+				return 0;
+			}
+			for (i=0; i<((1<<extp->FactProtRegSize)+(1<<extp->UserProtRegSize));i++){
+				cfi->ProtRegData[i]=
+					map->read8(map,(base+(extp->ProtRegAddr*ofs_factor)+i));
+			}
+		}
+			
 #ifdef DEBUG_CFI_FEATURES
 		/* Tell the user about it in lots of lovely detail */
 		cfi_tell_features(extp);
@@ -247,6 +264,7 @@ static struct mtd_info *cfi_intelext_set
 		//printk(KERN_INFO "Using word write method\n" );
 		mtd->write = cfi_intelext_write_words;
 	}
+	mtd->read_prot_reg = cfi_intelext_read_prot_reg;
 	mtd->sync = cfi_intelext_sync;
 	mtd->lock = cfi_intelext_lock;
 	mtd->unlock = cfi_intelext_unlock;
@@ -432,6 +450,30 @@ static int cfi_intelext_read (struct mtd
 	}
 	return ret;
 }
+
+static int cfi_intelext_read_prot_reg (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf)
+{
+	struct map_info *map = mtd->priv;
+	struct cfi_private *cfi = map->fldrv_priv;
+	struct cfi_pri_intelext *extp=cfi->cmdset_priv;
+	unsigned char* data=cfi->ProtRegData+from;
+	int   count=len;
+	
+	while(count){
+		if(data>=cfi->ProtRegData + 
+		   (1<<extp->FactProtRegSize)+(1<<extp->UserProtRegSize)){
+		   return len-count;
+		}
+		*buf=*data;
+		buf++;		
+		data++;
+		count--;	     
+	}
+	return len-count;
+}
+	
+	
+
 
 static int do_write_oneword(struct map_info *map, struct flchip *chip, unsigned long adr, __u32 datum)
 {
diff -purN linux_2.4.13/drivers/mtd/maps/Makefile linux/drivers/mtd/maps/Makefile
--- linux_2.4.13/drivers/mtd/maps/Makefile	Mon Oct 29 15:47:07 2001
+++ linux/drivers/mtd/maps/Makefile	Wed Oct 24 10:17:47 2001
@@ -31,6 +31,7 @@ obj-$(CONFIG_MTD_SUN_UFLASH)    += sun_u
 obj-$(CONFIG_MTD_VMAX)		+= vmax301.o
 obj-$(CONFIG_MTD_DBOX2)		+= dbox2-flash.o
 obj-$(CONFIG_MTD_OCELOT)	+= ocelot.o
+obj-$(CONFIG_MTD_EPXA10DB)	+= epxa10db-flash.o
 obj-$(CONFIG_MTD_SOLUTIONENGINE)+= solutionengine.o
 obj-$(CONFIG_MTD_PCI)		+= pci.o
 
diff -purN linux_2.4.13/include/linux/mtd/mtd.h linux/include/linux/mtd/mtd.h
--- linux_2.4.13/include/linux/mtd/mtd.h	Tue Jun 12 18:30:27 2001
+++ linux/include/linux/mtd/mtd.h	Thu Nov  1 14:47:05 2001
@@ -180,6 +180,12 @@ struct mtd_info {
 	int (*read_oob) (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf);
 	int (*write_oob) (struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf);
 
+	/* 
+	 * Method to access the protection register or OTP area, 
+	 * present in some flash devices
+	 */
+	int (*read_prot_reg) (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf);
+
 	/* iovec-based read/write methods. We need these especially for NAND flash,
 	   with its limited number of write cycles per erase.
 	   NB: The 'count' parameter is the number of _vectors_, each of 
diff -purN linux_2.4.13/drivers/mtd/mtdpart.c linux/drivers/mtd/mtdpart.c
--- linux_2.4.13/drivers/mtd/mtdpart.c	Thu Oct  4 23:14:59 2001
+++ linux/drivers/mtd/mtdpart.c	Thu Nov  1 14:31:45 2001
@@ -195,6 +195,7 @@ int add_mtd_partitions(struct mtd_info *
 		slave->mtd.oobsize = master->oobsize;
 		slave->mtd.ecctype = master->ecctype;
 		slave->mtd.eccsize = master->eccsize;
+		slave->mtd.read_prot_reg = master->read_prot_reg;
 
 		slave->mtd.name = parts[i].name;
 		slave->mtd.bank_size = master->bank_size;
diff -purN linux_2.4.13/include/linux/mtd/cfi.h linux/include/linux/mtd/cfi.h
--- linux_2.4.13/include/linux/mtd/cfi.h	Thu Oct  4 23:13:18 2001
+++ linux/include/linux/mtd/cfi.h	Thu Nov  1 14:23:45 2001
@@ -206,6 +206,10 @@ struct cfi_pri_intelext {
   __u16 BlkStatusRegMask;
   __u8  VccOptimal;
   __u8  VppOptimal;
+  __u8  NumProtectionFields;
+  __u16 ProtRegAddr;
+  __u8  FactProtRegSize;
+  __u8  UserProtRegSize;
 } __attribute__((packed));
 
 struct cfi_pri_query {
@@ -248,6 +252,7 @@ struct cfi_private {
 	int numchips;
 	unsigned long chipshift; /* Because they're of the same type */
 	const char *im_name;	 /* inter_module name for cmdset_setup */
+	unsigned char *ProtRegData;  /* Protection register data bytes */
 	struct flchip chips[0];  /* per-chip data structure for each chip */
 };
 

Re: Intel protection register read

[David Woodhouse]

cdavies@altera.com said:
> I sent the patch below to this list a few days ago but had no
> response. Has  anyone had a chance to look at it? If its ok, could
> someone apply it?

Sorry. Thanks for retrying :)

> +	unsigned char *ProtRegData;  /* Protection register data bytes */
> 	struct flchip chips[0];  /* per-chip data structure for each chip */

The ProtRegData are per-chip, but you've only left space for one pointer. 
What happens when people have arrays of multiple chips side-by-side and/or
consecutively mapped?

Also, isn't it possible to _write_ to the user areas of the chips?

Is this present in all versions of the Intel command sets, or do you need 
to check the version number?


--
dwmw2

RE: Intel protection register read

[Clive Davies]

> > +	unsigned char *ProtRegData;  /* Protection register 
> data bytes */
> > 	struct flchip chips[0];  /* per-chip data structure for 
> each chip */
> 
> The ProtRegData are per-chip, but you've only left space for 
> one pointer. 
> What happens when people have arrays of multiple chips 
> side-by-side and/or
> consecutively mapped?
> 

Hmm, this is a problem. Am I correct in thinking that the code only reads
the cfi tables from the first device and assumes that any additional devices
are of the same type? (That's what it looks like to me) If so there is no
way to read the protection register data from subsequent devices. 

I reckon the best way to handle the multiple/interleaved chip configuration
would be to concatenate all the protection registers together into one
block. All the other interfaces I can think of would require a chip number
to be passed in, which doesn't seem that nice to me. Does that sound
reasonable?

> Also, isn't it possible to _write_ to the user areas of the chips?
> 

Yes it is, but I haven't implemented that because I don't need it. If adding
writes is a condition for getting read functionality into cvs then I can do
that too.

> do you need 
> to check the version number?
Yes, I'd assumed that the data in the table would default to zero for
earlier versions but I'm not so sure now. I'll fix that.

Thanks,
Clive

Re: Intel protection register read

[David Woodhouse]

cdavies@altera.com said:
>  Hmm, this is a problem. Am I correct in thinking that the code only
> reads the cfi tables from the first device and assumes that any
> additional devices are of the same type? (That's what it looks like to
> me) If so there is no way to read the protection register data from
> subsequent devices. 

You can do whatever you like in ->read_prot_reg(), so there's nothing that 
prevents you from doing this.

>  I reckon the best way to handle the multiple/interleaved chip
> configuration would be to concatenate all the protection registers
> together into one block. All the other interfaces I can think of would
> require a chip number to be passed in, which doesn't seem that nice to
> me. Does that sound reasonable?

Seems like a sane approach to me. We possibly need to couple it with a way
to query the size of protection register data available. 

> > Also, isn't it possible to _write_ to the user areas of the chips?
> 
> Yes it is, but I haven't implemented that because I don't need it. If
> adding writes is a condition for getting read functionality into cvs
> then I can do that too. 

Implementing it isn't absolutely necessary, although it would be nice. We 
do have to make sure that the framework is sane, and whoever _does_ finally 
implement writes isn't going to have to change stuff around for it, though.

--
dwmw2