MTD Patches

MTD Patches

[Florian Schirmer / TayTron]

Hi!

I've two little patches pending. Can someone please commit them to cvs?

Patch1:

Adds partition support to physmap.c. Support can be enabled via kernel
config, so if you dont need it you wont get bigger modules/kernels.

Patch2: Fixes a small bug (?) in mtdblock_ro.c Please verify this. Seems
someone disabled a function but did not disable the corresponding function
call :-)

Thanks for your help and happing hacking
   Florian Schirmer

[......]

diff -Naur mtd-old/kernel/Config.in mtd/kernel/Config.in
--- mtd-old/kernel/Config.in Sat Feb 17 22:17:48 2001
+++ mtd/kernel/Config.in Mon Mar  5 10:51:27 2001
@@ -79,6 +79,7 @@
       hex '    Physical start address of flash mapping'
CONFIG_MTD_PHYSMAP_START 0x8000000
       hex '    Physical length of flash mapping' CONFIG_MTD_PHYSMAP_LEN
0x4000000
       int '    Bus width in octets' CONFIG_MTD_PHYSMAP_BUSWIDTH 2
+      bool '    Partition suport' CONFIG_MTD_PHYSMAP_PARTITION
    fi
    dep_tristate '  CFI Flash device mapped on Nora' CONFIG_MTD_NORA
$CONFIG_MTD_CFI
    dep_tristate '  CFI Flash device mapped on Photron PNC-2000'
CONFIG_MTD_PNC2000 $CONFIG_MTD_CFI
diff -Naur mtd-old/kernel/mtdblock_ro.c mtd/kernel/mtdblock_ro.c
--- mtd-old/kernel/mtdblock_ro.c Fri Nov 17 09:51:35 2000
+++ mtd/kernel/mtdblock_ro.c Mon Mar  5 11:20:51 2001
@@ -222,7 +222,9 @@
       // Grab the lock and re-thread the item onto the linked list
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
  spin_lock_irq(&io_request_lock);
+#if 0
  mtdblock_end_request(current_request, res);
+#endif
 #endif
  end_request(res);
    }
diff -Naur mtd-old/kernel/physmap.c mtd/kernel/physmap.c
--- mtd-old/kernel/physmap.c Sat Mar  3 19:17:09 2001
+++ mtd/kernel/physmap.c Mon Mar  5 11:17:25 2001
@@ -12,6 +12,21 @@
 #include <linux/mtd/map.h>
 #include <linux/config.h>

+#ifdef CONFIG_MTD_PHYSMAP_PARTITION
+#include <linux/mtd/partitions.h>
+
+/* partition_info gives details on the logical partitions that the split
the
+ * single flash device into. If the size if zero we use up to the end of
the
+ * device. */
+const static struct mtd_partition partition_info[] = {/*{name:
"Bootloader",
+             offset: MTDPART_OFS_APPEND,
+             size: 128 * 1024},*/
+            {name: "Physically mapped flash",
+             offset: MTDPART_OFS_APPEND,
+             size: MTDPART_SIZ_FULL}};
+
+#define NUM_PARTITIONS (sizeof(partition_info) / sizeof(partition_info[0]))
+#endif // CONFIG_MTD_PHYSMAP_PARTITION

 #define WINDOW_ADDR CONFIG_MTD_PHYSMAP_START
 #define WINDOW_SIZE CONFIG_MTD_PHYSMAP_LEN
@@ -95,7 +110,13 @@
 #ifdef MODULE
   mymtd->module = &__this_module;
 #endif
+
+#ifdef CONFIG_MTD_PHYSMAP_PARTITION
+                /* Create MTD devices for each partition. */
+         add_mtd_partitions(mymtd, partition_info, NUM_PARTITIONS);
+#else
   add_mtd_device(mymtd);
+#endif // CONFIG_MTD_PHYSMAP_PARTITION
   return 0;
  }

@@ -106,7 +127,11 @@
 mod_exit_t cleanup_physmap(void)
 {
  if (mymtd) {
+#ifdef CONFIG_MTD_PHYSMAP_PARTITION
+  del_mtd_partitions(mymtd);
+#else
   del_mtd_device(mymtd);
+#endif // CONFIG_MTD_PHYSMAP_PARTITION
   map_destroy(mymtd);
  }
  if (physmap_map.map_priv_1) {




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

MTD patches

[Ian Campbell]

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

Hi David, 

I've had a couple of patches to MTD sitting in my 2.6 tree for a while
now and wonder if you would consider including them.

All of the patches are against 2.6.8.1, although they have been applying
unchanged for many versions now.

mtd-redboot-partition-fixes.patch

        This patch has two parts. 
        
        The first is to factor out the offset to look at for the RedBoot
        partition table into a variable. This has no impact on the code
        as is, but makes it easier and clearer for platforms that have
        the partition table at some other offset to wrap a #ifdef
        CONFIG_ARCH_ around the variable rather than introducing errors
        by cloning the whole master->read call.
        
        The second part looks for any partition name starting with
        "RedBoot" rather than looking for "RedBoot\0". On my platform
        RedBoot lives in a separate boot ROM, but the RedBoot config and
        partition table are in the main flash so we can find them.
        
mtd-add_full.patch
        
        This patch adds a new api call add_mtd_device_full() that allows
        a device to be added to a specific minor number (if it is
        available). I use this in my platform drivers to ensure that the
        SRAM device is always minor 14 and the BIOS device is always
        minor 15, even if the user changes the redboot partitioning
        scheme and changes the number of flash partitions.
        
        add_mtd_device now just calls _full with a minor of -1 to
        allocate any available device.
        
mtd-jedec-probe-parts
        
        This patch adds a few new part numbers to jedec_probe.c. They
        are AMD AM29F002T, Hyundai HY29F002T and Macronix MX29FOO2T.
        
Cheers,
Ian.

-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road, 			Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom	Phone:  +44 (0)1223 411 200

[-- Attachment #2: mtd-redboot-partition-fixes.patch --]
[-- Type: text/x-patch, Size: 994 bytes --]

%patch
Index: linux-2.6-bk/drivers/mtd/redboot.c
===================================================================
--- linux-2.6-bk.orig/drivers/mtd/redboot.c	2004-07-19 09:35:43.000000000 +0100
+++ linux-2.6-bk/drivers/mtd/redboot.c	2004-07-19 10:27:23.169539161 +0100
@@ -49,6 +49,7 @@
 	char *nullname;
 	int namelen = 0;
 	int nulllen = 0;
+	unsigned long offset;
 #ifdef CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED
 	static char nullstring[] = "unallocated";
 #endif
@@ -59,7 +60,9 @@
 		return -ENOMEM;
 
 	/* Read the start of the last erase block */
-	ret = master->read(master, master->size - master->erasesize,
+	offset = master->size - master->erasesize;
+
+	ret = master->read(master, offset,
 			   master->erasesize, &retlen, (void *)buf);
 
 	if (ret)
@@ -72,7 +75,7 @@
 
 	/* RedBoot image could appear in any of the first three slots */
 	for (i = 0; i < 3; i++) {
-		if (!memcmp(buf[i].name, "RedBoot", 8))
+		if (!memcmp(buf[i].name, "RedBoot", 7))
 			break;
 	}
 	if (i == 3) {

[-- Attachment #3: mtd-add_full.patch --]
[-- Type: text/x-patch, Size: 3442 bytes --]

%patch
Index: q/drivers/mtd/mtdcore.c
===================================================================
--- q.orig/drivers/mtd/mtdcore.c	Tue Aug  5 16:46:21 2003
+++ q/drivers/mtd/mtdcore.c	Tue Aug  5 16:46:38 2003
@@ -36,30 +36,39 @@
 static LIST_HEAD(mtd_notifiers);
 
 /**
- *	add_mtd_device - register an MTD device
+ *	add_mtd_device_full - register an MTD device at a particular minor number
  *	@mtd: pointer to new MTD device info structure
+ *	@minor: requested minor number. -1 to for the first free.
  *
- *	Add a device to the list of MTD devices present in the system, and
- *	notify each currently active MTD 'user' of its arrival. Returns
- *	zero on success or 1 on failure, which currently will only happen
- *	if the number of present devices exceeds MAX_MTD_DEVICES (i.e. 16)
+ *	Add a device to the list of MTD devices present in the system,
+ *	and notifies each currently active MTD 'user' of its
+ *	arrival. Returns zero on success or 1 on failure, which
+ *	currently only occurs if the requested minor number has
+ *	already been allocated or if minor exceeds MAX_MTD_DEVICES
+ *	(i.e. 16)
  */
-
-int add_mtd_device(struct mtd_info *mtd)
+int add_mtd_device_full(struct mtd_info *mtd, int minor)
 {
-	int i;
-
 	down(&mtd_table_mutex);
 
-	for (i=0; i < MAX_MTD_DEVICES; i++)
-		if (!mtd_table[i]) {
+	if ( minor == -1 ) {
+		for (minor = 0; minor < MAX_MTD_DEVICES; minor++)
+			if (!mtd_table[minor])
+				break;
+	}
+
+	if ( minor >= MAX_MTD_DEVICES || minor < 0 || mtd_table[minor] ) {
+		up(&mtd_table_mutex);
+		return 1;
+	}
+
 			struct list_head *this;
 
-			mtd_table[i] = mtd;
-			mtd->index = i;
+	mtd_table[minor] = mtd;
+	mtd->index = minor;
 			mtd->usecount = 0;
 
-			DEBUG(0, "mtd: Giving out device %d to %s\n",i, mtd->name);
+	DEBUG(0, "mtd: Giving out device %d to %s\n",minor, mtd->name);
 			/* No need to get a refcount on the module containing
 			   the notifier, since we hold the mtd_table_mutex */
 			list_for_each(this, &mtd_notifiers) {
@@ -76,8 +85,18 @@
 			return 0;
 		}
 	
-	up(&mtd_table_mutex);
-	return 1;
+/**
+ *	add_mtd_device - register an MTD device
+ *	@mtd: pointer to new MTD device info structure
+ *
+ *	Add a device to the list of MTD devices present in the system, and
+ *	notify each currently active MTD 'user' of its arrival. Returns
+ *	zero on success or 1 on failure, which currently will only happen
+ *	if the number of present devices exceeds MAX_MTD_DEVICES (i.e. 16)
+ */
+int add_mtd_device(struct mtd_info *mtd)
+{
+	return add_mtd_device_full(mtd, -1);
 }
 
 /**
@@ -288,6 +307,7 @@
 
 
 EXPORT_SYMBOL(add_mtd_device);
+EXPORT_SYMBOL(add_mtd_device_full);
 EXPORT_SYMBOL(del_mtd_device);
 EXPORT_SYMBOL(get_mtd_device);
 EXPORT_SYMBOL(put_mtd_device);
Index: q/include/linux/mtd/mtd.h
===================================================================
--- q.orig/include/linux/mtd/mtd.h	Tue Aug  5 16:46:22 2003
+++ q/include/linux/mtd/mtd.h	Tue Aug  5 16:46:38 2003
@@ -238,6 +238,7 @@
 	/* Kernel-side ioctl definitions */
 
 extern int add_mtd_device(struct mtd_info *mtd);
+extern int add_mtd_device_full(struct mtd_info *mtd, int minor);
 extern int del_mtd_device (struct mtd_info *mtd);
 
 extern struct mtd_info *get_mtd_device(struct mtd_info *mtd, int num);

%diffstat
 drivers/mtd/mtdcore.c   |   52 +++++++++++++++++++++++++++++++++---------------
 include/linux/mtd/mtd.h |    1 
 2 files changed, 37 insertions(+), 16 deletions(-)


[-- Attachment #4: mtd-jedec-probe-parts --]
[-- Type: text/plain, Size: 1850 bytes --]

%description
Add support for a couple of BIOS ROM devices.

%patch
Index: linux-2.6-bk/drivers/mtd/chips/jedec_probe.c
===================================================================
--- linux-2.6-bk.orig/drivers/mtd/chips/jedec_probe.c	2004-08-10 17:49:44.000000000 +0100
+++ linux-2.6-bk/drivers/mtd/chips/jedec_probe.c	2004-08-17 09:28:05.001562971 +0100
@@ -36,7 +36,8 @@
 #define MANUFACTURER_ST		0x0020
 #define MANUFACTURER_TOSHIBA	0x0098
 #define MANUFACTURER_WINBOND	0x00da
-
+#define MANUFACTURER_HYUNDAI	0x00AD
+#define MANUFACTURER_MACRONIX	0x00C2
 
 /* AMD */
 #define AM29DL800BB	0x22C8
@@ -56,6 +57,7 @@
 #define AM29F040	0x00A4
 #define AM29LV040B	0x004F
 #define AM29F032B	0x0041
+#define AM29F002T	0x00B0
 
 /* Atmel */
 #define AT49BV512	0x0003
@@ -154,6 +156,11 @@
 /* Winbond */
 #define W49V002A	0x00b0
 
+/* Hyundai */
+#define HY29F002T	0x00B0
+
+/* Macronix */
+#define MX29F002T	0x00B0
 
 /*
  * Unlock address sets for AMD command sets.
@@ -1570,7 +1577,40 @@
 			ERASEINFO(0x02000, 2),
 			ERASEINFO(0x04000, 1),
 		}
-	} 
+	}, {
+		mfr_id: MANUFACTURER_AMD,
+		dev_id: AM29F002T,
+		name: "AMD AM29F002T",
+		DevSize: SIZE_256KiB,
+		NumEraseRegions: 4,
+		regions: {ERASEINFO(0x10000,3),
+			  ERASEINFO(0x08000,1),
+			  ERASEINFO(0x02000,2),
+			  ERASEINFO(0x04000,1)
+		}
+	}, {
+		mfr_id: MANUFACTURER_HYUNDAI,
+		dev_id: HY29F002T,
+		name: "Hyundai HY29F002T",
+		DevSize: SIZE_256KiB,
+		NumEraseRegions: 4,
+		regions: {ERASEINFO(0x10000,3),
+			  ERASEINFO(0x08000,1),
+			  ERASEINFO(0x02000,2),
+			  ERASEINFO(0x04000,1)
+		}
+	}, {
+		mfr_id: MANUFACTURER_MACRONIX,
+		dev_id: MX29F002T,
+		name: "Macronix MX29F002T",
+		DevSize: SIZE_256KiB,
+		NumEraseRegions: 4,
+		regions: {ERASEINFO(0x10000,3),
+			  ERASEINFO(0x08000,1),
+			  ERASEINFO(0x02000,2),
+			  ERASEINFO(0x04000,1)
+		}
+	}
 };
 
 

Re: MTD patches

[David Woodhouse]

On Tue, 2004-08-17 at 09:32 +0100, Ian Campbell wrote:
> I've had a couple of patches to MTD sitting in my 2.6 tree for a while
> now and wonder if you would consider including them.

Thanks for these.

> mtd-redboot-partition-fixes.patch
> 
>         This patch has two parts. 
>         
>         The first is to factor out the offset to look at for the RedBoot
>         partition table into a variable. This has no impact on the code
>         as is, but makes it easier and clearer for platforms that have
>         the partition table at some other offset to wrap a #ifdef
>         CONFIG_ARCH_ around the variable rather than introducing errors
>         by cloning the whole master->read call.

Hmmm. Isn't this why we introduced an extra argument to the partition
parsers in the first place? The map code should be able to pass a
suitable argument, rather than having ifdefs in the parser code? Gary?

>         The second part looks for any partition name starting with
>         "RedBoot" rather than looking for "RedBoot\0". On my platform
>         RedBoot lives in a separate boot ROM, but the RedBoot config and
>         partition table are in the main flash so we can find them.

Seems reasonable.
        
> mtd-add_full.patch
>         
>         This patch adds a new api call add_mtd_device_full() that allows
>         a device to be added to a specific minor number (if it is
>         available).

Hmm. I don't like this much -- if you want stable device naming that's
what udev is for. I don't want to accept this before the equivalent for
fixed numbering of SCSI or IDE drives is accepted upstream. :)

> mtd-jedec-probe-parts
>         
>         This patch adds a few new part numbers to jedec_probe.c. They
>         are AMD AM29F002T, Hyundai HY29F002T and Macronix MX29FOO2T.

OK, please apply this -- you have CVS access don't you?

-- 
dwmw2

Re: MTD patches

[Ian Campbell]

Hi, 

I noticed that you had to moderate this message due to a suspicious
header. Is this a false positive or can I do something to fix it? The
message didn't say which header.

On Tue, 2004-08-17 at 10:15, David Woodhouse wrote:
> On Tue, 2004-08-17 at 09:32 +0100, Ian Campbell wrote:
> > I've had a couple of patches to MTD sitting in my 2.6 tree for a while
> > now and wonder if you would consider including them.
> 
> Thanks for these.
> 
> > mtd-redboot-partition-fixes.patch
> > 
> >         This patch has two parts. 
> >         
> >         The first is to factor out the offset to look at for the RedBoot
> >         partition table into a variable. This has no impact on the code
> >         as is, but makes it easier and clearer for platforms that have
> >         the partition table at some other offset to wrap a #ifdef
> >         CONFIG_ARCH_ around the variable rather than introducing errors
> >         by cloning the whole master->read call.
> 
> Hmmm. Isn't this why we introduced an extra argument to the partition
> parsers in the first place? The map code should be able to pass a
> suitable argument, rather than having ifdefs in the parser code? Gary?

I had a solution based on this idea for a bit, but I didn't like it in
the end since mtd_parse_partitions only takes a single parameter which
is passed to all the partition modules you might be using (I have
command line then redboot in my setup). Hence it didn't seem to make
sense to pass a redboot partition table specific parameter to this
function.

> > mtd-add_full.patch
> >         
> >         This patch adds a new api call add_mtd_device_full() that allows
> >         a device to be added to a specific minor number (if it is
> >         available).
> 
> Hmm. I don't like this much -- if you want stable device naming that's
> what udev is for. I don't want to accept this before the equivalent for
> fixed numbering of SCSI or IDE drives is accepted upstream. :)

Fair enough, I will carry it as my own patch til I figure embedded udev
out.

> > mtd-jedec-probe-parts
> >         
> >         This patch adds a few new part numbers to jedec_probe.c. They
> >         are AMD AM29F002T, Hyundai HY29F002T and Macronix MX29FOO2T.
> 
> OK, please apply this -- you have CVS access don't you?

I don't believe I do, one of my colleagues here at Arcom does (David
Vrabel). I can ask him to commit this patch, or else I can send you
whatever you need to get an account setup for me, just a ssh public
key?.

I guess cvs.infradead.org is still IPv6 only, do you have any advice for
a tunnel to use that will work from within a corporate firewall, or on a
dynamic IPv4 cable modem address?

Ian.

-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road, 			Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom	Phone:  +44 (0)1223 411 200

Re: MTD patches

[David Woodhouse]

On Tue, 2004-08-17 at 10:38 +0100, Ian Campbell wrote:
> Hi, 
> 
> I noticed that you had to moderate this message due to a suspicious
> header. Is this a false positive or can I do something to fix it? The
> message didn't say which header.

All mail with attachments gets stopped for moderation. If you're posting
only _one_ patch then inline it instead of attaching it -- if you're
posting three then the only sane way would be to send it as three
patches. Or just wait for moderation ;)

> > Hmmm. Isn't this why we introduced an extra argument to the partition
> > parsers in the first place? The map code should be able to pass a
> > suitable argument, rather than having ifdefs in the parser code? Gary?
> 
> I had a solution based on this idea for a bit, but I didn't like it in
> the end since mtd_parse_partitions only takes a single parameter which
> is passed to all the partition modules you might be using (I have
> command line then redboot in my setup). Hence it didn't seem to make
> sense to pass a redboot partition table specific parameter to this
> function.

True. I'm growing to hate our partitioning code. I think it all needs
rewriting.

> > > mtd-jedec-probe-parts
> > >         
> > >         This patch adds a few new part numbers to jedec_probe.c. They
> > >         are AMD AM29F002T, Hyundai HY29F002T and Macronix MX29FOO2T.
> > 
> > OK, please apply this -- you have CVS access don't you?
> 
> I don't believe I do, one of my colleagues here at Arcom does (David
> Vrabel). I can ask him to commit this patch, or else I can send you
> whatever you need to get an account setup for me, just a ssh public
> key?.

Yep.

> I guess cvs.infradead.org is still IPv6 only, do you have any advice for
> a tunnel to use that will work from within a corporate firewall, or on a
> dynamic IPv4 cable modem address?

If you have a public IPv4 address of any kind, that's sufficient. If
it's got initscripts like Red Hat/Fedora then add the four config lines
shown at http://www.linux-mtd.infradead.org/ and it should just work.
Other distributions are similarly trivial.

If you have an account on a box _anywhere_ with both IPv6 and IPv4, you
can use that in conjunction with SSH's 'ProxyCommand' option which makes
it run a command and use stdin/stdout instead of trying to connect
directly. I have this in my ~/.ssh/config at work, where there's no
IPv6:

Host cvs.infradead.org phoenix.infradead.org phoenix
 ProxyCommand ssh pentafluge.infradead.org nc -6 %h %p




-- 
dwmw2

Re: MTD patches

[Ian Campbell]

On Tue, 2004-08-17 at 10:15, David Woodhouse wrote:
> > mtd-jedec-probe-parts
> >         
> >         This patch adds a few new part numbers to jedec_probe.c. They
> >         are AMD AM29F002T, Hyundai HY29F002T and Macronix MX29FOO2T.
> 
> OK, please apply this

What is the procedure WRT updating upstream when committing to CVS?
Should I commit and then send a patch via Linus or do you like to bundle
up changes and send them all together?

Ian.

-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road, 			Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom	Phone:  +44 (0)1223 411 200
-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road, 			Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom	Phone:  +44 (0)1223 411 200

Re: MTD patches

[David Woodhouse]

On Tue, 2004-08-17 at 15:00 +0100, Ian Campbell wrote:
> What is the procedure WRT updating upstream when committing to CVS?
> Should I commit and then send a patch via Linus or do you like to bundle
> up changes and send them all together?

It depends -- in general I prefer changes to go to Linus _via_ CVS, so
that the $Id$ change gets to Linus too, and then it's easier for me to
later work out what changes have been made in Linus' tree by comparing
against the version in CVS with matching $Id$.

In this case, however, there have been other changes to that file since
I last merged with Linus, which probably want a little more testing
before they're sent upstream. So if you're desperate for it to go
upstream immediately, just send it without the ident change (and _also_
commit to CVS).

-- 
dwmw2