Q: MTD and NIC Roms...

Q: MTD and NIC Roms...

[Eric W. Biederman]

Currently I have a patch to eepro100.c that adds an MTD map driver so
the onboard rom can be written.  Making code like etherboot easier to
flash etc. 

This works by default except when everything is compiled into the
kernel.  In the latter case the map driver fails because NIC are
initialized before the mtd subsystem.  This can be handled be
modifying the link order of the kernel in 2.4. but that is not
a pretty situation.

I am currently looking for ideas on ways to cleanly get this code
into the kernel, and I am looking for ideas.  The map driver is
part of the eepro100 driver because it needs to share a lock or
multiple accesses to the same part of the chip by other parts of the
driver may cause problems.  Though looking at my code I cannot see it
now.

Anyway here is the diff with respect to the eepro100.c in 2.4.17,
suggestions on how to do this cleanly are welcome.

I think I might even have the bandwidth right now to do something
about it.

Eric


diff -uNrX linux-exclude-files linux-2.4.17-mtd/drivers/net/eepro100.c linux-2.4.17.eb-mtd2/drivers/net/eepro100.c
--- linux-2.4.17-mtd/drivers/net/eepro100.c	Fri Dec 21 10:41:54 2001
+++ linux-2.4.17.eb-mtd2/drivers/net/eepro100.c	Wed Jan  9 10:31:29 2002
@@ -116,6 +116,11 @@
 #include <linux/ethtool.h>
 #include <linux/delay.h>
 
+#ifdef CONFIG_MTD
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#endif
+
 MODULE_AUTHOR("Maintainer: Andrey V. Savochkin <saw@saw.sw.com.sg>");
 MODULE_DESCRIPTION("Intel i82557/i82558/i82559 PCI EtherExpressPro driver");
 MODULE_LICENSE("GPL");
@@ -286,7 +291,8 @@
 
 */
 
-static int speedo_found1(struct pci_dev *pdev, long ioaddr, int fnd_cnt, int acpi_idle_state);
+static int speedo_found1(struct pci_dev *pdev, long ioaddr, 
+	unsigned long romio_addr, int fnd_cnt, int acpi_idle_state);
 
 enum pci_flags_bit {
 	PCI_USES_IO=1, PCI_USES_MEM=2, PCI_USES_MASTER=4,
@@ -383,6 +389,10 @@
 	PortReset=0, PortSelfTest=1, PortPartialReset=2, PortDump=3,
 };
 
+enum SCBflash_states {
+	FlashDisable=2, FlashEnable=1,
+};
+
 /* The Speedo3 Rx and Tx frame/buffer descriptors. */
 struct descriptor {			    /* A generic descriptor. */
 	s32 cmd_status;				/* All command and status fields. */
@@ -502,6 +512,10 @@
 #ifdef CONFIG_PM
 	u32 pm_state[16];
 #endif
+#ifdef CONFIG_MTD
+	struct map_info map;
+	struct mtd_info *mtd;
+#endif
 };
 
 /* The parameters for a CmdConfigure operation.
@@ -556,6 +570,14 @@
 static void set_rx_mode(struct net_device *dev);
 static void speedo_show_state(struct net_device *dev);
 
+#ifdef CONFIG_MTD
+static u8 eepro100rom_read8(struct map_info *map, unsigned long ofs);
+static void eepro100rom_copy_from(struct map_info *map, void *to, 
+	unsigned long from, ssize_t len);
+static void eepro100rom_write8(struct map_info *map, u8 data, unsigned long ofs);
+static void eepro100rom_copy_to(struct map_info *map, unsigned long to, 	
+	const void *from, ssize_t len);
+#endif
 \f

 
 #ifdef honor_default_port
@@ -568,7 +590,7 @@
 static int __devinit eepro100_init_one (struct pci_dev *pdev,
 		const struct pci_device_id *ent)
 {
-	unsigned long ioaddr;
+	unsigned long ioaddr, romio_addr = 0;
 	int irq;
 	int acpi_idle_state = 0, pm;
 	static int cards_found /* = 0 */;
@@ -595,8 +617,8 @@
 		printk("Found Intel i82557 PCI Speedo at I/O %#lx, IRQ %d.\n",
 			   ioaddr, irq);
 #else
-	ioaddr = (unsigned long)ioremap(pci_resource_start(pdev, 0),
-									pci_resource_len(pdev, 0));
+	ioaddr = (unsigned long)ioremap(pci_resource_start(pdev, 0), 
+		pci_resource_len(pdev, 0));
 	if (!ioaddr) {
 		printk (KERN_ERR "eepro100: cannot remap MMIO region %lx @ %lx\n",
 				pci_resource_len(pdev, 0), pci_resource_start(pdev, 0));
@@ -607,6 +629,24 @@
 			   pci_resource_start(pdev, 0), irq);
 #endif
 
+#ifdef CONFIG_MTD
+	if (pci_resource_start(pdev, 2) == 0) {
+		pci_assign_resource(pdev, 2);
+	}
+	if ((pci_resource_start(pdev, 2) != 0) &&
+		(request_mem_region(
+			pci_resource_start(pdev, 2),
+			pci_resource_len(pdev, 2), 
+			"eepro100") != 0)) {
+		romio_addr = (unsigned long)ioremap(
+			pci_resource_start(pdev, 2),
+			pci_resource_len(pdev, 2));
+		printk(KERN_INFO "eepro100 Boot ROM enabled at 0x%08lx mapped at 0x%08lx\n", 
+			pci_resource_start(pdev, 2),
+			romio_addr);
+	}
+#endif
+
 	/* save power state b4 pci_enable_device overwrites it */
 	pm = pci_find_capability(pdev, PCI_CAP_ID_PM);
 	if (pm) {
@@ -616,18 +656,20 @@
 	}
 
 	if (pci_enable_device(pdev))
-		goto err_out_free_mmio_region;
+		goto err_out_iounmap;
 
 	pci_set_master(pdev);
 
-	if (speedo_found1(pdev, ioaddr, cards_found, acpi_idle_state) == 0)
+	if (speedo_found1(pdev, ioaddr, romio_addr, cards_found, acpi_idle_state) == 0)
 		cards_found++;
 	else
 		goto err_out_iounmap;
 
 	return 0;
 
-err_out_iounmap: ;
+err_out_iounmap: 
+	if (romio_addr) 
+		iounmap((void *)romio_addr);
 #ifndef USE_IO
 	iounmap ((void *)ioaddr);
 #endif
@@ -640,7 +682,7 @@
 }
 
 static int speedo_found1(struct pci_dev *pdev,
-		long ioaddr, int card_idx, int acpi_idle_state)
+	long ioaddr, unsigned long romio_addr, int card_idx, int acpi_idle_state)
 {
 	struct net_device *dev;
 	struct speedo_private *sp;
@@ -846,6 +888,34 @@
 	dev->set_multicast_list = &set_rx_mode;
 	dev->do_ioctl = &speedo_ioctl;
 
+#ifdef CONFIG_MTD
+	/* Enable Writes to the flash chpi */
+	outw(FlashEnable, ioaddr + SCBflash);
+
+	/* Now setup the data structures */
+	sp->map.name = "eepro100 rom";
+	sp->map.size = pci_resource_len(pdev, 2);
+	sp->map.buswidth = 1;
+	sp->map.read8 = eepro100rom_read8;
+	sp->map.copy_from = eepro100rom_copy_from;
+	sp->map.write8 = eepro100rom_write8;
+	sp->map.copy_to = eepro100rom_copy_to;
+	sp->map.map_priv_1 = romio_addr;
+	sp->mtd = 0;
+	if (romio_addr) {
+		sp->mtd = do_map_probe("jedec_probe", &sp->map);
+		if (!sp->mtd) {
+			sp->mtd = do_map_probe("map_rom", &sp->map);
+		}
+		if (sp->mtd) {
+			sp->mtd->module = THIS_MODULE;
+			add_mtd_device(sp->mtd);
+			printk(KERN_INFO "eepro100: found flash boot rom\n");
+		}
+	} else {
+		printk(KERN_NOTICE "eepro100: No boot rom address??\n");
+	}
+#endif /* CONFIG_MTD */
 	return 0;
 }
 \f

@@ -1834,7 +1904,7 @@
 	if (speedo_debug > 3)
 		speedo_show_state(dev);
 
-    /* Free all the skbuffs in the Rx and Tx queues. */
+	/* Free all the skbuffs in the Rx and Tx queues. */
 	for (i = 0; i < RX_RING_SIZE; i++) {
 		struct sk_buff *skb = sp->rx_skbuff[i];
 		sp->rx_skbuff[i] = 0;
@@ -2192,6 +2262,29 @@
 	sp->rx_mode = new_rx_mode;
 }
 \f

+#ifdef CONFIG_MTD
+static u8 eepro100rom_read8(struct map_info *map, unsigned long ofs)
+{
+	return readb(map->map_priv_1 + ofs);
+}
+
+static void eepro100rom_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
+{
+	memcpy_fromio(to, map->map_priv_1 + from, len);
+}
+
+static void eepro100rom_write8(struct map_info *map, u8 data, unsigned long ofs)
+{
+	writeb(data, map->map_priv_1 + ofs);
+}
+
+static void eepro100rom_copy_to(struct map_info *map, unsigned long to, 
+	const void *from, ssize_t len)
+{
+	memcpy_toio(map->map_priv_1 + to, from, len);
+}
+#endif
+\f

 #ifdef CONFIG_PM
 static int eepro100_suspend(struct pci_dev *pdev, u32 state)
 {
@@ -2243,11 +2336,27 @@
 {
 	struct net_device *dev = pci_get_drvdata (pdev);
 	struct speedo_private *sp = (struct speedo_private *)dev->priv;
+	long ioaddr = dev->base_addr;
 	
 	unregister_netdev(dev);
 
+#ifdef CONFIG_MTD
+	if (sp->mtd) {
+		del_mtd_device(sp->mtd);
+		map_destroy(sp->mtd);
+		sp->mtd = 0;
+	}
+	/* Disable writes to the flash chip */
+	outw(FlashDisable, ioaddr + SCBflash);
+	release_mem_region(
+		pci_resource_start(pdev, 2), pci_resource_len(pdev, 2));
+	iounmap((void *)sp->map.map_priv_1);
+#endif 
+
+
 	release_region(pci_resource_start(pdev, 1), pci_resource_len(pdev, 1));
 	release_mem_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0));
+
 
 #ifndef USE_IO
 	iounmap((char *)dev->base_addr);

Q: MTD and NIC Roms...

[Jeff Garzik]

Eric W. Biederman wrote:
> Currently I have a patch to eepro100.c that adds an MTD map driver so
> the onboard rom can be written.  Making code like etherboot easier to
> flash etc. 
[...]
> I am currently looking for ideas on ways to cleanly get this code
> into the kernel, and I am looking for ideas.  The map driver is


Well... this functionality has existed for a while, and it doesn't need 
to be in the kernel :)

Donald Becker's diag suite can do flashing. 
ftp://www.scyld.com/pub/diag/  He provides means to program the flash 
from userspace.

And I think that's the best place for it.  We _could_ bloat up the 
kernel code by adding the ability flash -- but how many users is that 
going to serve, that are not already served by existing programs?  So, I 
disagree with getting this stuff into the kernel at all.

	Jeff

Q: MTD and NIC Roms...

[David Woodhouse]

On Thu, 2003-02-13 at 05:45, Eric W. Biederman wrote:
> Currently I have a patch to eepro100.c that adds an MTD map driver so
> the onboard rom can be written.  Making code like etherboot easier to
> flash etc. 
> 
> This works by default except when everything is compiled into the
> kernel.  In the latter case the map driver fails because NIC are
> initialized before the mtd subsystem.  This can be handled be
> modifying the link order of the kernel in 2.4. but that is not
> a pretty situation.
> 
> I am currently looking for ideas on ways to cleanly get this code
> into the kernel, and I am looking for ideas. 

grep --after-context=15 'BIG UGLY NOTE' drivers/mtd/

Thankfully, the inter_module_register() abortion is now gone and we can
fix it all again in 2.5 by reverting to get_module_symbol() as it was
before.

-- 
dwmw2

Q: MTD and NIC Roms...

[David Woodhouse]

On Thu, 2003-02-13 at 06:14, Jeff Garzik wrote:
> And I think that's the best place for it.  We _could_ bloat up the 
> kernel code by adding the ability flash -- but how many users is that 
> going to serve, that are not already served by existing programs?  So, I 
> disagree with getting this stuff into the kernel at all.

I see your point, but OTOH that it's under a separate config option and
it's actually a _tiny_ amount of code. 

And we all know that hardware drivers don't live in userspace. 

-- 
dwmw2

Q: MTD and NIC Roms...

[Jeff Garzik]

On Thu, Feb 13, 2003 at 06:29:13AM +0000, David Woodhouse wrote:
> On Thu, 2003-02-13 at 06:14, Jeff Garzik wrote:
> > And I think that's the best place for it.  We _could_ bloat up the 
> > kernel code by adding the ability flash -- but how many users is that 
> > going to serve, that are not already served by existing programs?  So, I 
> > disagree with getting this stuff into the kernel at all.
> 
> I see your point, but OTOH that it's under a separate config option and
> it's actually a _tiny_ amount of code. 
> 
> And we all know that hardware drivers don't live in userspace. 

ATM all users are using an existing userspace tools, so
this would be a CONFIG_EEPRO100_ERIC_BIEDERMAN option.  No thanks :)

	Jeff

Q: MTD and NIC Roms...

[Eric W. Biederman]

Jeff Garzik <jgarzik@pobox.com> writes:

> Eric W. Biederman wrote:
> > Currently I have a patch to eepro100.c that adds an MTD map driver so
> > the onboard rom can be written.  Making code like etherboot easier to
> > flash etc.
> [...]
> > I am currently looking for ideas on ways to cleanly get this code
> > into the kernel, and I am looking for ideas.  The map driver is
> 
> 
> Well... this functionality has existed for a while, and it doesn't need to be in
> the kernel :)
> 
> Donald Becker's diag suite can do flashing. ftp://www.scyld.com/pub/diag/  He
> provides means to program the flash from userspace.

Not on the eepro100, it does look like one or two other kinds of nic
are supported though.  His libflash.c is quite deficient when it comes
to the number of flash chips supported, the correctness of the
implementation of the cfi command set 2, and the completeness of it's
probe routine.

None of which goes into the races, or the portability problems
that arise from doing this in user space.

The linux mtd layer with it's larger user base, and the fact it sits
in the does not have any of those problems with handling flash chips.
And it steadily gets fewer problems as more kinds of flash chips are
looked at, and the problems in the code are addressed generically.

> And I think that's the best place for it.  We _could_ bloat up the kernel code
> by adding the ability flash -- but how many users is that going to serve, that
> are not already served by existing programs?  So, I disagree with getting this
> stuff into the kernel at all.

Given the lack of existing programs for the eepro100 every user served
is a new one.  Plus with the better support libraries provided by the 
linux mtd layer it is easier to do a quality job in the kernel.

I totally agree that this is not day to day functionality, and so it
should not burden the fast common paths of the kernel.  The code was
enclosed in a config option.  It is worth noting one of the busiest
booths at LinuxWorld was the etherboot booth.  And by other counts
as well there are quite a large number of users network booting.   So
the potential user base is significant.

And as David said it really is not that much code.

Eric

Q: MTD and NIC Roms...

[Eric W. Biederman]

David Woodhouse <dwmw2@infradead.org> writes:

> On Thu, 2003-02-13 at 05:45, Eric W. Biederman wrote:
> > Currently I have a patch to eepro100.c that adds an MTD map driver so
> > the onboard rom can be written.  Making code like etherboot easier to
> > flash etc. 
> > 
> > This works by default except when everything is compiled into the
> > kernel.  In the latter case the map driver fails because NIC are
> > initialized before the mtd subsystem.  This can be handled be
> > modifying the link order of the kernel in 2.4. but that is not
> > a pretty situation.
> > 
> > I am currently looking for ideas on ways to cleanly get this code
> > into the kernel, and I am looking for ideas. 
> 
> grep --after-context=15 'BIG UGLY NOTE' drivers/mtd/
> 
> Thankfully, the inter_module_register() abortion is now gone and we can
> fix it all again in 2.5 by reverting to get_module_symbol() as it was
> before.

That one is good to hear.

Eric

Q: MTD and NIC Roms...

[Jeremy Jackson]

On Thu, 2003-02-13 at 01:14, Jeff Garzik wrote:
> Eric W. Biederman wrote:
> > Currently I have a patch to eepro100.c that adds an MTD map driver so
> > the onboard rom can be written.  Making code like etherboot easier to
> > flash etc. 
> [...]
> > I am currently looking for ideas on ways to cleanly get this code
> > into the kernel, and I am looking for ideas.  The map driver is
> 
> 
> Well... this functionality has existed for a while, and it doesn't need 
> to be in the kernel :)
> 
> Donald Becker's diag suite can do flashing. 
> ftp://www.scyld.com/pub/diag/  He provides means to program the flash 
> from userspace.

I tried it on a tulip, and it caused a hard reset. PCI bus issues? 

Also, by making it a map driver, I can flash LinuxBIOS into EEPROM,
disable write access to the EEPROM, and put the *DoC* in the NIC
socket.  Putting a public key in the EEPROM and making it RO makes the
whole system secure.  Or I could port DoC and jffs driver to
userspace...

Porting devbios to MTD will then give a large library of NOR flash,
including quirks (like ATMEL has different versions, and none work if
you just use the datasheet), and allow them to be used in arbitrary
sockets.

Also, say bye bye to the "pull out the eeprom and put in DoC quick so
the electrons don't notice" trick.  Just put the DoC into the NIC, boot
up, flash, power down, swap to BIOS socket.  Sorry LinuxBIOS guys, I
guess you'll have to switch back to drinking coffee.

> 
> And I think that's the best place for it.  We _could_ bloat up the 
> kernel code by adding the ability flash -- but how many users is that 
> going to serve, that are not already served by existing programs?  So, I 
> disagree with getting this stuff into the kernel at all.
> 
> 	Jeff
> 
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
-- 
Jeremy Jackson <jerj@coplanar.net>

Q: MTD and NIC Roms...

[yxh]

----- Original Message ----- 
From: "Eric W. Biederman" <ebiederman@lnxi.com>
To: "Jeff Garzik" <jgarzik@pobox.com>
Cc: <linux-mtd@lists.infradead.org>; "David Woodhouse" <dwmw2@infradead.org>
Sent: Thursday, February 13, 2003 3:38 PM
Subject: Re: Q: MTD and NIC Roms...


> Jeff Garzik <jgarzik@pobox.com> writes:
> 
> > Eric W. Biederman wrote:
> > > Currently I have a patch to eepro100.c that adds an MTD map driver so
> > > the onboard rom can be written.  Making code like etherboot easier to
> > > flash etc.
> > [...]
> > > I am currently looking for ideas on ways to cleanly get this code
> > > into the kernel, and I am looking for ideas.  The map driver is
> > 
> > 
> > Well... this functionality has existed for a while, and it doesn't need to be in
> > the kernel :)
> > 
> > Donald Becker's diag suite can do flashing. ftp://www.scyld.com/pub/diag/  He
> > provides means to program the flash from userspace.
> 
> Not on the eepro100, it does look like one or two other kinds of nic
> are supported though.  His libflash.c is quite deficient when it comes
> to the number of flash chips supported, the correctness of the
> implementation of the cfi command set 2, and the completeness of it's
> probe routine.
> 
> None of which goes into the races, or the portability problems
> that arise from doing this in user space.
> 
> The linux mtd layer with it's larger user base, and the fact it sits
> in the does not have any of those problems with handling flash chips.
> And it steadily gets fewer problems as more kinds of flash chips are
> looked at, and the problems in the code are addressed generically.
> 
> > And I think that's the best place for it.  We _could_ bloat up the kernel code
> > by adding the ability flash -- but how many users is that going to serve, that
> > are not already served by existing programs?  So, I disagree with getting this
> > stuff into the kernel at all.
> 
> Given the lack of existing programs for the eepro100 every user served
> is a new one.  Plus with the better support libraries provided by the 
> linux mtd layer it is easier to do a quality job in the kernel.
> 
> I totally agree that this is not day to day functionality, and so it
> should not burden the fast common paths of the kernel.  The code was
> enclosed in a config option.  It is worth noting one of the busiest
> booths at LinuxWorld was the etherboot booth.  And by other counts
> as well there are quite a large number of users network booting.   So
> the potential user base is significant.
> 
> And as David said it really is not that much code.
> 
> Eric
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Q: MTD and NIC Roms...

[邹应双]

ok?
----- Original Message ----- 
From: "yxh" <yangxhui@i-net.com.cn>
To: "Eric W. Biederman" <ebiederman@lnxi.com>; "Jeff Garzik" <jgarzik@pobox.com>
Cc: <linux-mtd@lists.infradead.org>; "David Woodhouse" <dwmw2@infradead.org>
Sent: Friday, February 14, 2003 8:33 AM
Subject: Re: Q: MTD and NIC Roms...


> 
> ----- Original Message ----- 
> From: "Eric W. Biederman" <ebiederman@lnxi.com>
> To: "Jeff Garzik" <jgarzik@pobox.com>
> Cc: <linux-mtd@lists.infradead.org>; "David Woodhouse" <dwmw2@infradead.org>
> Sent: Thursday, February 13, 2003 3:38 PM
> Subject: Re: Q: MTD and NIC Roms...
> 
> 
> > Jeff Garzik <jgarzik@pobox.com> writes:
> > 
> > > Eric W. Biederman wrote:
> > > > Currently I have a patch to eepro100.c that adds an MTD map driver so
> > > > the onboard rom can be written.  Making code like etherboot easier to
> > > > flash etc.
> > > [...]
> > > > I am currently looking for ideas on ways to cleanly get this code
> > > > into the kernel, and I am looking for ideas.  The map driver is
> > > 
> > > 
> > > Well... this functionality has existed for a while, and it doesn't need to be in
> > > the kernel :)
> > > 
> > > Donald Becker's diag suite can do flashing. ftp://www.scyld.com/pub/diag/  He
> > > provides means to program the flash from userspace.
> > 
> > Not on the eepro100, it does look like one or two other kinds of nic
> > are supported though.  His libflash.c is quite deficient when it comes
> > to the number of flash chips supported, the correctness of the
> > implementation of the cfi command set 2, and the completeness of it's
> > probe routine.
> > 
> > None of which goes into the races, or the portability problems
> > that arise from doing this in user space.
> > 
> > The linux mtd layer with it's larger user base, and the fact it sits
> > in the does not have any of those problems with handling flash chips.
> > And it steadily gets fewer problems as more kinds of flash chips are
> > looked at, and the problems in the code are addressed generically.
> > 
> > > And I think that's the best place for it.  We _could_ bloat up the kernel code
> > > by adding the ability flash -- but how many users is that going to serve, that
> > > are not already served by existing programs?  So, I disagree with getting this
> > > stuff into the kernel at all.
> > 
> > Given the lack of existing programs for the eepro100 every user served
> > is a new one.  Plus with the better support libraries provided by the 
> > linux mtd layer it is easier to do a quality job in the kernel.
> > 
> > I totally agree that this is not day to day functionality, and so it
> > should not burden the fast common paths of the kernel.  The code was
> > enclosed in a config option.  It is worth noting one of the busiest
> > booths at LinuxWorld was the etherboot booth.  And by other counts
> > as well there are quite a large number of users network booting.   So
> > the potential user base is significant.
> > 
> > And as David said it really is not that much code.
> > 
> > Eric
> > 
> > 
> > ______________________________________________________
> > 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/

Q: MTD and NIC Roms...

[Jeremy Jackson]

--=-SlNl+AU9ngP78MtCnq3w
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, 2003-02-13 at 00:45, Eric W. Biederman wrote:
> Currently I have a patch to eepro100.c that adds an MTD map driver so
> the onboard rom can be written.  Making code like etherboot easier to
> flash etc. 
> 

> Anyway here is the diff with respect to the eepro100.c in 2.4.17,
> suggestions on how to do this cleanly are welcome.

Here it is diffed against 2.4.19.  I removed the local variable ioaddr
in eepro100_remove_one() because it caused a compile warning when
CONFIG_MTD was not set.

Did you have any mtd chip drivers to use with it?  I'm looking at
devbios now to port it's NOR flash chip drivers.

Regards,

Jeremy
-- 
Jeremy Jackson <jerj@coplanar.net>

--=-SlNl+AU9ngP78MtCnq3w
Content-Disposition: attachment; filename=mtd_eepro_2.4.19.diff
Content-Type: text/plain; name=mtd_eepro_2.4.19.diff; charset=UTF-8
Content-Transfer-Encoding: 7bit

--- linux-2.4.19/drivers/net/eepro100.c.orig	2002-08-02 20:39:44.000000000 -0400
+++ linux-2.4.19/drivers/net/eepro100.c	2003-03-06 13:44:15.000000000 -0500
@@ -114,6 +114,12 @@
 #include <linux/etherdevice.h>
 #include <linux/skbuff.h>
 #include <linux/ethtool.h>
+#include <linux/delay.h>
+
+#ifdef CONFIG_MTD
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#endif
 
 MODULE_AUTHOR("Maintainer: Andrey V. Savochkin <saw@saw.sw.com.sg>");
 MODULE_DESCRIPTION("Intel i82557/i82558/i82559 PCI EtherExpressPro driver");
@@ -278,7 +284,8 @@
 
 */
 
-static int speedo_found1(struct pci_dev *pdev, long ioaddr, int fnd_cnt, int acpi_idle_state);
+static int speedo_found1(struct pci_dev *pdev, long ioaddr, 
+	unsigned long romio_addr, int fnd_cnt, int acpi_idle_state);
 
 enum pci_flags_bit {
 	PCI_USES_IO=1, PCI_USES_MEM=2, PCI_USES_MASTER=4,
@@ -375,6 +382,10 @@
 	PortReset=0, PortSelfTest=1, PortPartialReset=2, PortDump=3,
 };
 
+enum SCBflash_states {
+	FlashDisable=2, FlashEnable=1,
+};
+
 /* The Speedo3 Rx and Tx frame/buffer descriptors. */
 struct descriptor {			    /* A generic descriptor. */
 	s32 cmd_status;				/* All command and status fields. */
@@ -494,6 +505,10 @@
 #ifdef CONFIG_PM
 	u32 pm_state[16];
 #endif
+#ifdef CONFIG_MTD
+	struct map_info map;
+	struct mtd_info *mtd;
+#endif
 };
 
 /* The parameters for a CmdConfigure operation.
@@ -546,6 +561,14 @@
 static void set_rx_mode(struct net_device *dev);
 static void speedo_show_state(struct net_device *dev);
 
+#ifdef CONFIG_MTD
+static u8 eepro100rom_read8(struct map_info *map, unsigned long ofs);
+static void eepro100rom_copy_from(struct map_info *map, void *to, 
+	unsigned long from, ssize_t len);
+static void eepro100rom_write8(struct map_info *map, u8 data, unsigned long ofs);
+static void eepro100rom_copy_to(struct map_info *map, unsigned long to, 	
+	const void *from, ssize_t len);
+#endif
 \f

 
 #ifdef honor_default_port
@@ -558,7 +581,7 @@
 static int __devinit eepro100_init_one (struct pci_dev *pdev,
 		const struct pci_device_id *ent)
 {
-	unsigned long ioaddr;
+	unsigned long ioaddr, romio_addr = 0;
 	int irq;
 	int acpi_idle_state = 0, pm;
 	static int cards_found /* = 0 */;
@@ -598,8 +621,8 @@
 		printk("Found Intel i82557 PCI Speedo at I/O %#lx, IRQ %d.\n",
 			   ioaddr, irq);
 #else
-	ioaddr = (unsigned long)ioremap(pci_resource_start(pdev, 0),
-									pci_resource_len(pdev, 0));
+	ioaddr = (unsigned long)ioremap(pci_resource_start(pdev, 0), 
+		pci_resource_len(pdev, 0));
 	if (!ioaddr) {
 		printk (KERN_ERR "eepro100: cannot remap MMIO region %lx @ %lx\n",
 				pci_resource_len(pdev, 0), pci_resource_start(pdev, 0));
@@ -610,15 +633,34 @@
 			   pci_resource_start(pdev, 0), irq);
 #endif
 
+#ifdef CONFIG_MTD
+	if (pci_resource_start(pdev, 2) == 0) {
+		pci_assign_resource(pdev, 2);
+	}
+	if ((pci_resource_start(pdev, 2) != 0) &&
+		(request_mem_region(
+			pci_resource_start(pdev, 2),
+			pci_resource_len(pdev, 2), 
+			"eepro100") != 0)) {
+		romio_addr = (unsigned long)ioremap(
+			pci_resource_start(pdev, 2),
+			pci_resource_len(pdev, 2));
+		printk(KERN_INFO "eepro100 Boot ROM enabled at 0x%08lx mapped at 0x%08lx\n", 
+			pci_resource_start(pdev, 2),
+			romio_addr);
+	}
+#endif
 
-	if (speedo_found1(pdev, ioaddr, cards_found, acpi_idle_state) == 0)
+	if (speedo_found1(pdev, ioaddr, romio_addr, cards_found, acpi_idle_state) == 0)
 		cards_found++;
 	else
 		goto err_out_iounmap;
 
 	return 0;
 
-err_out_iounmap: ;
+err_out_iounmap: 
+	if (romio_addr) 
+		iounmap((void *)romio_addr);
 #ifndef USE_IO
 	iounmap ((void *)ioaddr);
 #endif
@@ -631,7 +673,7 @@
 }
 
 static int __devinit speedo_found1(struct pci_dev *pdev,
-		long ioaddr, int card_idx, int acpi_idle_state)
+		long ioaddr, unsigned long romio_addr, int card_idx, int acpi_idle_state)
 {
 	struct net_device *dev;
 	struct speedo_private *sp;
@@ -842,6 +884,34 @@
 	dev->set_multicast_list = &set_rx_mode;
 	dev->do_ioctl = &speedo_ioctl;
 
+#ifdef CONFIG_MTD
+	/* Enable Writes to the flash chpi */
+	outw(FlashEnable, ioaddr + SCBflash);
+
+	/* Now setup the data structures */
+	sp->map.name = "eepro100 rom";
+	sp->map.size = pci_resource_len(pdev, 2);
+	sp->map.buswidth = 1;
+	sp->map.read8 = eepro100rom_read8;
+	sp->map.copy_from = eepro100rom_copy_from;
+	sp->map.write8 = eepro100rom_write8;
+	sp->map.copy_to = eepro100rom_copy_to;
+	sp->map.map_priv_1 = romio_addr;
+	sp->mtd = 0;
+	if (romio_addr) {
+		sp->mtd = do_map_probe("jedec_probe", &sp->map);
+		if (!sp->mtd) {
+			sp->mtd = do_map_probe("map_rom", &sp->map);
+		}
+		if (sp->mtd) {
+			sp->mtd->module = THIS_MODULE;
+			add_mtd_device(sp->mtd);
+			printk(KERN_INFO "eepro100: found flash boot rom\n");
+		}
+	} else {
+		printk(KERN_NOTICE "eepro100: No boot rom address??\n");
+	}
+#endif /* CONFIG_MTD */
 	return 0;
 }
 \f

@@ -2197,6 +2267,29 @@
 	sp->rx_mode = new_rx_mode;
 }
 \f

+#ifdef CONFIG_MTD
+static u8 eepro100rom_read8(struct map_info *map, unsigned long ofs)
+{
+	return readb(map->map_priv_1 + ofs);
+}
+
+static void eepro100rom_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
+{
+	memcpy_fromio(to, map->map_priv_1 + from, len);
+}
+
+static void eepro100rom_write8(struct map_info *map, u8 data, unsigned long ofs)
+{
+	writeb(data, map->map_priv_1 + ofs);
+}
+
+static void eepro100rom_copy_to(struct map_info *map, unsigned long to, 
+	const void *from, ssize_t len)
+{
+	memcpy_toio(map->map_priv_1 + to, from, len);
+}
+#endif
+\f

 #ifdef CONFIG_PM
 static int eepro100_suspend(struct pci_dev *pdev, u32 state)
 {
@@ -2255,6 +2348,20 @@
 	
 	unregister_netdev(dev);
 
+#ifdef CONFIG_MTD
+	if (sp->mtd) {
+		del_mtd_device(sp->mtd);
+		map_destroy(sp->mtd);
+		sp->mtd = 0;
+	}
+	/* Disable writes to the flash chip */
+	outw(FlashDisable, dev->base_addr + SCBflash);
+	release_mem_region(
+		pci_resource_start(pdev, 2), pci_resource_len(pdev, 2));
+	iounmap((void *)sp->map.map_priv_1);
+#endif 
+
+
 	release_region(pci_resource_start(pdev, 1), pci_resource_len(pdev, 1));
 	release_mem_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0));
 

--=-SlNl+AU9ngP78MtCnq3w--

Re: Q: MTD and NIC Roms...

[Eric W. Biederman]

Jeremy Jackson <jerj@coplanar.net> writes:

> On Thu, 2003-02-13 at 00:45, Eric W. Biederman wrote:
> > Currently I have a patch to eepro100.c that adds an MTD map driver so
> > the onboard rom can be written.  Making code like etherboot easier to
> > flash etc. 
> > 
> 
> > Anyway here is the diff with respect to the eepro100.c in 2.4.17,
> > suggestions on how to do this cleanly are welcome.
> 
> Here it is diffed against 2.4.19.  I removed the local variable ioaddr
> in eepro100_remove_one() because it caused a compile warning when
> CONFIG_MTD was not set.
> 
> Did you have any mtd chip drivers to use with it?  I'm looking at
> devbios now to port it's NOR flash chip drivers.

Sorry for the delayed reply.  

Yes.  But that one is already in jedec_probe.c 

Eric