Add support for SMSC95XX USB 2.0 10/100MBit Ethernet Adapter

The SMSC95XX is a USB hub with a built-in Ethernet adapter. This adds support for this, using the USB host network framework.

TEST=usb start; bootp; tftp ...

---
Changes for v2:
- Coding style cleanup
- Changed some comments as suggested
- eth_set_hwaddr -> eth_write_hwaddr
- tided up other users of eth_getenv_enetaddr_by_index()

---
 drivers/usb/eth/Makefile    |    1 +
 drivers/usb/eth/smsc95xx.c  |  922 +++++++++++++++++++++++++++++++++++++++++++
 drivers/usb/eth/usb_ether.c |    7 +
 3 files changed, 930 insertions(+), 0 deletions(-)
 create mode 100644 drivers/usb/eth/smsc95xx.c

index 6a5f25a..e28793d 100644
@@ -28,6 +28,7 @@ COBJS-$(CONFIG_USB_HOST_ETHER) += usb_ether.o
 ifdef CONFIG_USB_ETHER_ASIX
 COBJS-y += asix.o
 endif
+COBJS-$(CONFIG_USB_ETHER_SMSC95XX) += smsc95xx.o
 
 COBJS	:= $(COBJS-y)
 SRCS	:= $(COBJS:.o=.c)

index 68a0883..7b55da3 100644
@@ -45,6 +45,13 @@ static const struct usb_eth_prob_dev prob_dev[] = {
 		.get_info = asix_eth_get_info,
 	},
 #endif
+#ifdef CONFIG_USB_ETHER_SMSC95XX
+	{
+		.before_probe = smsc95xx_eth_before_probe,
+		.probe = smsc95xx_eth_probe,
+		.get_info = smsc95xx_eth_get_info,
+	},
+#endif
 	{ },		/* END */
 };
 

1.7.3.1

Built-in Ethernet adapters support setting the mac address by means of a ethaddr environment variable for each interface (ethaddr, eth1addr, eth2addr).

This adds similar support to the USB network side, using the names usbethaddr, usbeth1addr, etc. They are kept separate since we don't want a USB device taking the MAC address of a built-in device or vice versa.

TEST=build, test on harmony, with setenv usbethaddr c0:c1:c0:13:0b:b8, bootp, tftp ...

---
 board/davinci/common/misc.c |    2 +-
 drivers/net/designware.c    |    2 +-
 drivers/usb/eth/usb_ether.c |    8 ++++-
 include/net.h               |   28 ++++++++++++++++-
 net/eth.c                   |   71 ++++++++++++++++++++++++++-----------------
 5 files changed, 78 insertions(+), 33 deletions(-)

index 2bfdf23..b2b980b 100644
@@ -101,7 +101,7 @@ void davinci_sync_env_enetaddr(uint8_t *rom_enetaddr)
 {
 	uint8_t env_enetaddr[6];
 
-	eth_getenv_enetaddr_by_index(0, env_enetaddr);
+	eth_getenv_enetaddr_by_index(NULL, 0, env_enetaddr);
 	if (!memcmp(env_enetaddr, "\0\0\0\0\0\0", 6)) {
 		/* There is no MAC address in the environment, so we initialize
 		 * it from the value in the EEPROM. */

index 3f5eeb7..5e0f9e3 100644
@@ -500,7 +500,7 @@ int designware_initialize(u32 id, ulong base_addr, u32 phy_addr)
 	dev->iobase = (int)base_addr;
 	dev->priv = priv;
 
-	eth_getenv_enetaddr_by_index(id, &dev->enetaddr[0]);
+	eth_getenv_enetaddr_by_index(NULL, id, &dev->enetaddr[0]);
 
 	priv->dev = dev;
 	priv->mac_regs_p = (struct eth_mac_regs *)base_addr;

index 7b55da3..08b491c 100644
@@ -80,6 +80,7 @@ int is_eth_dev_on_usb_host(void)
  */
 static void probe_valid_drivers(struct usb_device *dev)
 {
+	struct eth_device *eth;
 	int j;
 
 	for (j = 0; prob_dev[j].probe && prob_dev[j].get_info; j++) {

@@ -88,9 +89,10 @@ static void probe_valid_drivers(struct usb_device *dev)
 		/*
 		 * ok, it is a supported eth device. Get info and fill it in
 		 */
+		eth = &usb_eth[usb_max_eth_dev].eth_dev;
 		if (prob_dev[j].get_info(dev,
 			&usb_eth[usb_max_eth_dev],
-			&usb_eth[usb_max_eth_dev].eth_dev)) {
+			eth)) {
 			/* found proper driver */
 			/* register with networking stack */
 			usb_max_eth_dev++;

@@ -100,7 +102,9 @@ static void probe_valid_drivers(struct usb_device *dev)
 			 * call since eth_current_changed (internally called)
 			 * relies on it
 			 */
-			eth_register(&usb_eth[usb_max_eth_dev - 1].eth_dev);
+			eth_register(eth);
+			if (eth_set_hwaddr(eth, "usbeth", usb_max_eth_dev - 1))
+				puts("Warning: failed to set MAC address\n");
 			break;
 			}
 		}

index 95ef8ab..c3abf56 100644
@@ -123,7 +123,18 @@ extern int eth_get_dev_index (void);		/* get the device index */
 extern void eth_parse_enetaddr(const char *addr, uchar *enetaddr);
 extern int eth_getenv_enetaddr(char *name, uchar *enetaddr);
 extern int eth_setenv_enetaddr(char *name, const uchar *enetaddr);
-extern int eth_getenv_enetaddr_by_index(int index, uchar *enetaddr);
+
+/*
+ * Get the hardware address for an ethernet interface .
+ * Args:
+ *	base_name - base name for device (NULL for "eth")
+ *	index - device index number (0 for first)
+ *	enetaddr - returns 6 byte hardware address
+ * Returns:
+ *	Return true if the address is valid.
+ */
+extern int eth_getenv_enetaddr_by_index(const char *base_name, int index,
+					uchar *enetaddr);
 
 extern int usb_eth_initialize(bd_t *bi);
 extern int eth_init(bd_t *bis);			/* Initialize the device */

@@ -136,6 +147,18 @@ extern int eth_rx(void);			/* Check for received packets */
 extern void eth_halt(void);			/* stop SCC */
 extern char *eth_get_name(void);		/* get name of current device */
 
+/*
+ * Set the hardware address for an ethernet interface based on 'eth%daddr'
+ * environment variable (or just 'ethaddr' if eth_number is 0).
+ * Args:
+ *	base_name - base name for device (NULL for "eth")
+ *	eth_number - value of %d (0 for first device of this type)
+ * Returns:
+ *	0 is success, non-zero is error status from driver.
+ */
+int eth_write_hwaddr(struct eth_device *dev, const char *base_name,
+		     int eth_number);
+
 #ifdef CONFIG_MCAST_TFTP
 int eth_mcast_join( IPaddr_t mcast_addr, u8 join);
 u32 ether_crc (size_t len, unsigned char const *p);

@@ -332,6 +355,9 @@ extern uchar		NetOurEther[6];		/* Our ethernet address		*/
 extern uchar		NetServerEther[6];	/* Boot server enet address	*/
 extern IPaddr_t		NetOurIP;		/* Our    IP addr (0 = unknown)	*/
 extern IPaddr_t		NetServerIP;		/* Server IP addr (0 = unknown)	*/
+
+/* Tftp Server IP addr (0 = unknown)*/
+extern IPaddr_t		NetTftpServerIP;
 extern volatile uchar * NetTxPacket;		/* THE transmit packet		*/
 extern volatile uchar * NetRxPackets[PKTBUFSRX];/* Receive packets		*/
 extern volatile uchar * NetRxPacket;		/* Current receive packet	*/

1.7.3.1

Le 13/04/2011 05:48, Mike Frysinger a ?crit :

Technically it is not. A C string constant can be made of several quote-delimited string literals separated by whitespace -- so this change is a no-op, and does not remove any newline btw. I suspect the change is to keep checkpatch.pl happy about the line length.

Amicalement,

Albert.

Yes it was, but on-line reviewers are noisier than checkpatch so have changed it. Also I was actually reverting a previous change so there is no need for my change at all. But thank you for your kind understanding.

I do find it quite confusing adding code which fits with U-Boot's coding style to a file which doesn't :-)

Regards,
Simon

you truncated my quote which changes things significantly. i wasnt talking about the string when i said newline.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110413/5baa3e96/attachment.pgp

Le 13/04/2011 23:05, Mike Frysinger a ?crit :

Sorry about that -- I did truncate indeed, to keep your comment and the change that was immediately before it, which I thought the comment was referring to exclusively.

Amicalement,

Albert.

also, checkpatch is a tool in the toolbox. people should not be blindly following it, but reviewing its output to see what should be changed and which should be ignored.

if checkpatch is complaining about code that you arent changing, then you probably shouldnt worry about it. especially when the only thing you're doing is changing style.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110413/364226d6/attachment.pgp

Le 14/04/2011 01:30, Mike Frysinger a ?crit :

I tend to see this "don't worry about some checkpatch.pl messages" appraoch as similar to "don't worry about some C compiler warnings". in that indeed "you probably shouldn't worry about it", and the key is "probably": when it bites you back later on, you realize you "probably" should have worried. If you apply a zero-C-warning policy, then a zero-checkpatch-warning policy makes sense as well...

... with the exception of Linux-centric warning or a coding style warning which would conflict with U-Boot's coding style -- anyone interested in introducing 'flavors' or 'style' in checkpatch.pl, with oone Linux and one U-Boot flavor/style to begin with?

So ignoring /some specific/ checkpatch.pl diagnostic is ok, but that's as long as it is established that the specific diagnostic is purely linux-centric" or voluntarily ignored as a coding rule; but then we'd need a list of such 'non-warnings' somewhere on the Wiki, I think, along with a rationale for ignoring it.

Amicalement,

Albert.

how about when it's plain wrong ? or it's applying a rule that (most of the time) is correct, but not *all* the time ? or it complains about code that your patch isnt touching (as is the case here) ? or it complains about code that is being imported (from linux or other projects) ?

so i stand by my statement that checkpatch is a tool and does *not* get the final say. blindly following a tool is good -- if you're blind.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110414/b76f0c76/attachment.pgp

Le 14/04/2011 08:12, Mike Frysinger a ?crit :

As for "plain wrong" warnings, I think this was addressed in the two paragraphs of my answer which followed the one you quote here. :)

As for rule exceptions, nothing prohibits submitters from stating the number of checkpatch warnings in their patch and justifying why they did not resolve them.

As for code the patch is not touching, again, it could be one of these established exceptions -- but again, it has to be a global decision so that reviewers don't emit contradicting requests about it.

As for code imported from Linux or any other project, there is an exception already, right on the second paragraph of the Wiki page on coding style <http://www.denx.de/wiki/U-Boot/CodingStyle>.

When it emits warnings, the C toolchain is also just a tool and does also not have the final say ; that's why they are warnings and not errors, because they might indicate something wrong, or not.

Besides, the coding rules for U-Boot make the tool checkpatch.pl mandatory, and I don't think it means "run it then don't care if some warnings are there"; I think it means "run it and make sure you eliminate all warnings if you can, and if there are some left, either justify them when you submit the patch, or ask about them on the list".

As for the 'blind' part, please re-read the two paragraphs right after the one you commented here; I believe it makes it clear that I do not advocate blindness, but on the contrary, strictness in which warnings we would agree to turn a blind eye to, and which we would not.

Anyway, I think we've both made our opinions clear; to avoid spending too much time here, I guess the best is that Wolfgang, who has the final say :), states exactly how he intends submitters and reviewers to handle checkpatch diagnostics.

Amicalement,

Albert.

sounds like you agree with me. nothing left to say :p.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110415/2d5b62fe/attachment.pgp

Le 15/04/2011 09:56, Mike Frysinger a ?crit :

I agree about those being tools. What I disagree upon is that just because they're tools we should disregard their warnings, or more precisely, I advocate setting common rules about which warnings we can disregard and which ones we cannot -- after all, the common rules are there already for C warnings and they're quite simple :)

Amicalement,

Albert.

i never said any such thing
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110415/380264fe/attachment.pgp

Le 15/04/2011 10:25, Mike Frysinger a ?crit :

My bad. What I disagree upon is that just because they're tools we should disregard *some of* their warnings.

More precisely, which checkpatch warnings must/should [not] be disregarded should not be a matter of personal choice but a coding style requirement.

Amicalement,

Albert.

This describes what it is for, devices supported, how to enable for your board in U-Boot, setting up the server, and notes about MAC addresses.

---
 doc/README.usb |  163 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 162 insertions(+), 1 deletions(-)

index 9aa4f62..8693a05 100644
@@ -79,4 +79,165 @@ CONFIG_USB_UHCI	    defines the lowlevel part.A lowlevel part must be defined
 		    if using CONFIG_CMD_USB
 CONFIG_USB_KEYBOARD enables the USB Keyboard
 CONFIG_USB_STORAGE  enables the USB storage devices
-CONFIG_USB_HOST_ETHER	enables USB ethernet dongle support
+CONFIG_USB_HOST_ETHER	enables USB ethernet adapter support
+
+
+USB Host Networking
+===================
+
+If you have a supported USB Ethernet adapter you can use it in U-Boot
+to obtain an IP address and load a kernel from a network server.
+
+USB Host Networking is different from making your board act as a USB
+client. In that case your board is pretending to be an Ethernet adapter
+and will appear as a network interface to an attached computer. The
+connection is via a USB cable with the computer acting as the host.
+
+With USB Host Networking, your board is the USB host. It controls the
+Ethernet adapter to which it is directly connected and the connection to
+the outside world is your adapter's Ethernet cable. Your board becomes a
+first class network device, able to connect and perform network
+operations independently of your computer.
+
+
+Device support
+--------------
+
+Currently supported devices are listed in the drivers according to
+their vendor and product IDs. You can check your device by connecting it
+to a Linux machine and typing 'lsusb'. The drivers are in
+drivers/usb/eth.
+
+For example this lsusb output line shows a device with Vendor ID 0x0x95
+and product ID 0x7720:
+
+Bus 002 Device 010: ID 0b95:7720 ASIX Electronics Corp. AX88772
+
+If you look at drivers/usb/eth/asix.c you will see this line within the
+supported device list, so we know this adapter is supported.
+
+        { 0x0b95, 0x7720 },     /* Trendnet TU2-ET100 V3.0R */
+
+If your adapter is not listed there is a still a chance that it will
+work. Try looking up the manufacturer of the chip inside your adapter.
+or take the adapter apart and look for chip markings. Then add a line
+for your vendor/product ID into the table of the appropriate driver,
+build U-Boot and see if it works. If not then there might be differences
+between the chip in your adapter and the driver. You could try to get a
+datasheet for your device and add support for it to U-Boot. This is not
+particularly difficult - you only need to provide support for four basic
+functions: init, halt, send and recv.
+
+
+Enabling USB Host Networking
+----------------------------
+
+The normal U-Boot commands are used with USB networking, but you must
+start USB first. For example:
+
+usb start
+setenv bootfile /tftpboot/uImage
+setenv autoload y
+bootp
+
+
+(The autoload option makes bootp automatically load the boot file.)
+
+To enable USB Host Ethernet in U-Boot, your platform must of course
+support USB with CONFIG_CMD_USB enabled and working. You will need to
+add some config settings to your board header file:
+
+#define CONFIG_USB_HOST_ETHER   /* Enable USB Ethernet adapters */
+#define CONFIG_USB_ETHER_ASIX   /* Asix, or whatever driver(s) you want */
+
+You will also want to enable the network commands:
+
+#define CONFIG_CMD_NET
+#define CONFIG_NET_MULTI
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_DHCP
+
+and some bootp options, which tell your board to obtain its subnet,
+gateway IP, host name and boot path from the bootp/dhcp server:
+
+#define CONFIG_BOOTP_SUBNETMASK
+#define CONFIG_BOOTP_GATEWAY
+#define CONFIG_BOOTP_HOSTNAME
+#define CONFIG_BOOTP_BOOTPATH
+
+You should also set the default IP address of your board and the server
+as well as the default file to load when a 'bootp' command is issued.
+
+#define CONFIG_IPADDR           10.0.0.2
+#define CONFIG_SERVERIP         10.0.0.1
+#define CONFIG_BOOTFILE         uImage
+
+
+The 'usb start' command should identify the adapter something like this:
+
+CrOS> usb start
+(Re)start USB...
+USB EHCI 1.00
+scanning bus for devices... 3 USB Device(s) found
+       scanning bus for storage devices... 0 Storage Device(s) found
+       scanning bus for ethernet devices... 1 Ethernet Device(s) found
+CrOS> print ethact
+ethact=asx0
+
+You can see that it found an ethernet device and we can print out the
+device name (asx0 in this case).
+
+Then 'bootp' should use it to obtain an IP address from DHCP, perhaps
+something like this:
+
+CrOS> bootp
+Waiting for Ethernet connection... done.
+BOOTP broadcast 1
+BOOTP broadcast 2
+DHCP client bound to address 172.22.73.81
+Using asx0 device
+TFTP from server 172.22.72.144; our IP address is 172.22.73.81
+Filename '/tftpboot/uImage-sjg-seaboard-261347'.
+Load address: 0x40c000
+Loading: #################################################################
+         #################################################################
+         #################################################################
+         ################################################
+done
+Bytes transferred = 3557464 (364858 hex)
+CrOS>
+
+
+MAC Addresses
+-------------
+
+Most Ethernet dongles have a built-in MAC address which is unique in the
+world. This is important so that devices on the network can be
+distinguised from each other. MAC address conflicts are evil and
+generally result in strange and eratic behaviour.
+
+Some boards have USB Ethernet chips on-board, and these sometimes do not
+have an assigned MAC address. In this case it is up to you to assign
+one which is unique. You should obtain a valid MAC address from a range
+assigned to you before you ship the product.
+
+Built-in Ethernet adapters support setting the MAC address by means of
+an ethaddr environment variable for each interface (ethaddr, eth1addr,
+eth2addr). There is similar support on the USB network side, using the
+names usbethaddr, usbeth1addr, etc. They are kept separate since we
+don't want a USB device taking the MAC address of a built-in device or
+vice versa.
+
+So if your USB Ethernet chip doesn't have a MAC address available then
+you must set usbethaddr to a suitable MAC address. At the time of
+writing this functionality is only supported by the SMSC driver.
+
+
+Server Setup
+------------
+
+For setting up the server side (dhcpd, tftpd, nfsd) you might find this
+Chromium OS page useful:
+
+http://www.chromium.org/network-based-development
+

1.7.3.1

This is a small clean-up patch.

TEST=Build U-Boot, try bootp and check it auto-loads.

---
 net/bootp.c |   76 +++++++++++++++++++++++++---------------------------------
 1 files changed, 33 insertions(+), 43 deletions(-)

index 1a71786..a3d0e63 100644
@@ -137,6 +137,36 @@ static int truncate_sz (const char *name, int maxlen, int curlen)
 	return (curlen);
 }
 
+/*
+ * Check if autoload is enabled. If so, use either NFS or TFTP to download
+ * the boot file.
+ */
+static void auto_load(void)
+{
+	char *s = getenv("autoload");
+
+	if (s != NULL) {
+		if (*s == 'n') {
+			/*
+			 * Just use BOOTP to configure system;
+			 * Do not use TFTP to load the bootfile.
+			 */
+			NetState = NETLOOP_SUCCESS;
+			return;
+#if defined(CONFIG_CMD_NFS)
+		} else if (strcmp(s, "NFS") == 0) {
+			/*
+			 * Use NFS to load the bootfile.
+			 */
+			NfsStart();
+			return;
+#endif
+		}
+	}
+
+	TftpStart();
+}
+
 #if !defined(CONFIG_CMD_DHCP)
 
 static void BootpVendorFieldProcess (u8 * ext)

@@ -278,6 +308,7 @@ static void BootpVendorProcess (u8 * ext, int size)
 	if (NetBootFileSize)
 		debug("NetBootFileSize: %d\n", NetBootFileSize);
 }
+
 /*
  *	Handle a BOOTP received packet.
  */

@@ -285,7 +316,6 @@ static void
 BootpHandler(uchar * pkt, unsigned dest, unsigned src, unsigned len)
 {
 	Bootp_t *bp;
-	char	*s;
 
 	debug("got BOOTP packet (src=%d, dst=%d, len=%d want_len=%zu)\n",
 		src, dest, len, sizeof (Bootp_t));

@@ -312,26 +342,7 @@ BootpHandler(uchar * pkt, unsigned dest, unsigned src, unsigned len)
 
 	debug("Got good BOOTP\n");
 
-	if ((s = getenv("autoload")) != NULL) {
-		if (*s == 'n') {
-			/*
-			 * Just use BOOTP to configure system;
-			 * Do not use TFTP to load the bootfile.
-			 */
-			NetState = NETLOOP_SUCCESS;
-			return;
-#if defined(CONFIG_CMD_NFS)
-		} else if (strcmp(s, "NFS") == 0) {
-			/*
-			 * Use NFS to load the bootfile.
-			 */
-			NfsStart();
-			return;
-#endif
-		}
-	}
-
-	TftpStart();
+	auto_load();
 }
 #endif
 

@@ -904,34 +915,13 @@ DhcpHandler(uchar * pkt, unsigned dest, unsigned src, unsigned len)
 		debug("DHCP State: REQUESTING\n");
 
 		if ( DhcpMessageType((u8 *)bp->bp_vend) == DHCP_ACK ) {
-			char *s;
-
 			if (NetReadLong((ulong*)&bp->bp_vend[0]) == htonl(BOOTP_VENDOR_MAGIC))
 				DhcpOptionsProcess((u8 *)&bp->bp_vend[4], bp);
 			BootpCopyNetParams(bp); /* Store net params from reply */
 			dhcp_state = BOUND;
 			printf ("DHCP client bound to address %pI4\n", &NetOurIP);
 
-			/* Obey the 'autoload' setting */
-			if ((s = getenv("autoload")) != NULL) {
-				if (*s == 'n') {
-					/*
-					 * Just use BOOTP to configure system;
-					 * Do not use TFTP to load the bootfile.
-					 */
-					NetState = NETLOOP_SUCCESS;
-					return;
-#if defined(CONFIG_CMD_NFS)
-				} else if (strcmp(s, "NFS") == 0) {
-					/*
-					 * Use NFS to load the bootfile.
-					 */
-					NfsStart();
-					return;
-#endif
-				}
-			}
-			TftpStart();
+			auto_load();
 			return;
 		}
 		break;

1.7.3.1

In many environments the DHCP server (which provides IP addresses) is not under control of the individual engineer. While it is required in order to connect to the corporate network, it doesn't provide useful information for booting. For example, it may be set up for PC imaging and provide a bootfile and tftp server for pxelinux.

To deal with this, this commit provides for a separate tftpserverip environment variable. If this is defined, then this IP address is used in preference to serverip. A new CONFIG_BOOTP_IGNORE_BOOTFILE option is provided to indicate that any bootfile name returned by the DHCP server is bogus and should be ignored.

To use this feature, just setenv tftpserverip to the address of your TFTP server and define CONFIG_BOOTP_IGNORE_BOOTFILE in your board file.

To use a unified DHCP and TFTP server, don't do either of these steps.

TEST=build U-Boot, try bootp with and without tftpserverip set and with and without CONFIG_BOOTP_IGNORE_BOOTFILE.

---
 net/bootp.c |    3 ++-
 net/net.c   |   12 ++++++++++--
 net/tftp.c  |    2 +-
 3 files changed, 13 insertions(+), 4 deletions(-)

index a3d0e63..1f4523f 100644
@@ -113,9 +113,10 @@ static void BootpCopyNetParams(Bootp_t *bp)
 		NetCopyIP(&NetServerIP, &bp->bp_siaddr);
 	memcpy (NetServerEther, ((Ethernet_t *)NetRxPacket)->et_src, 6);
 #endif
+#if !defined(CONFIG_BOOTP_IGNORE_BOOTFILE)
 	if (strlen(bp->bp_file) > 0)
 		copy_filename (BootFile, bp->bp_file, sizeof(BootFile));
-
+#endif
 	debug("Bootfile: %s\n", BootFile);
 
 	/* Propagate to environment:

index a609632..77bd192 100644
@@ -138,6 +138,7 @@ uchar		NetServerEther[6] =	/* Boot server enet address		*/
 			{ 0, 0, 0, 0, 0, 0 };
 IPaddr_t	NetOurIP;		/* Our IP addr (0 = unknown)		*/
 IPaddr_t	NetServerIP;		/* Server IP addr (0 = unknown)		*/
+IPaddr_t	NetTftpServerIP;	/* Tftp Server IP addr (0 = unknown) */
 volatile uchar *NetRxPacket;		/* Current receive packet		*/
 int		NetRxPacketLen;		/* Current rx packet length		*/
 unsigned	NetIPID;		/* IP packet ID				*/

@@ -289,6 +290,7 @@ NetInitLoop(proto_t protocol)
 		NetOurGatewayIP = getenv_IPaddr ("gatewayip");
 		NetOurSubnetMask= getenv_IPaddr ("netmask");
 		NetServerIP = getenv_IPaddr ("serverip");
+		NetTftpServerIP = getenv_IPaddr("tftpserverip");
 		NetOurNativeVLAN = getenv_VLAN("nvlan");
 		NetOurVLAN = getenv_VLAN("vlan");
 #if defined(CONFIG_CMD_DNS)

@@ -1720,8 +1722,14 @@ static int net_check_prereq (proto_t protocol)
 #endif
 	case NETCONS:
 	case TFTP:
-		if (NetServerIP == 0) {
-			puts ("*** ERROR: `serverip' not set\n");
+		/*
+		 * If there is no specific Tftp server defined, just use the
+		 * generic one */
+		if (NetTftpServerIP == 0)
+			NetTftpServerIP = NetServerIP;
+		if (NetTftpServerIP == 0) {
+			puts("*** ERROR: `serverip' and 'tcpserverip'"
+				"not set\n");
 			return (1);
 		}
 #if defined(CONFIG_CMD_PING) || defined(CONFIG_CMD_SNTP)

index ed559b7..4f6b1a2 100644
@@ -547,7 +547,7 @@ TftpStart (void)
 	debug("TFTP blocksize = %i, timeout = %ld ms\n",
 		TftpBlkSizeOption, TftpTimeoutMSecs);
 
-	TftpServerIP = NetServerIP;
+	TftpServerIP = NetTftpServerIP;
 	if (BootFile[0] == '\0') {
 		sprintf(default_filename, "%02lX%02lX%02lX%02lX.img",
 			NetOurIP & 0xFF,

1.7.3.1

perhaps this should be a #define ? i cant see anything that changes its value in this driver ...

OK, I have changed this to a compile-time option.

I could do, but halting is not in the driver at present. Do you think it is important?

It is called on a 'usb start'. I think we should keep it so people can call this repeatedly without problems.

Regards,
Simon

Dear Simon Glass,

Yes, it is important to shut down devices. Especially with USB devices.

BTW: can you *please* fix your mail addresses?
It's not "Remy Bohmerl <[email protected]>"
but "Remy Bohmer <[email protected]>" instead. Don't you get tons of bounce messages?

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Every living thing wants to survive.
	-- Spock, "The Ultimate Computer", stardate 4731.3

OK I will put something together. I am finding the rebase juggling a little tricky so there will be a delay while I sort that out so I can test properly.

Have fixed it. No bounces yet, maybe you have a brother? :-)

Regards,
Simon

Actually on second thoughts this actually conflicts which what you are telling me on the rejected patch.

If the Ethernet adapter shuts down when halt() is called, then presumably it will lose the link. Then when a tftp comes along, there is a delay while it re-establishes the link.

So we have:

bootp (calls init, send, recv, halt)
tftp (calls init, send, recv, halt)

If halt takes the link down then there will be a delay, which is what my rejected patch was trying to work around.

So I think either halt should leave the link up, or we need a way to not call init/halt all the time.

Thoughts?

Regards,
Simon

...

And another note....'usb stop' will stop the device. So I feel that leaving the link up is OK in this case, and I believe this is the behavior of non-USB ethernet devices. I would prefer to leave halt() as a no-op.

Regards,
Simon

Dear Simon Glass,

...

Not really.

The second is probably true. See the discussion we had about this when Stefano Babic implemented netconsole over ethernet over USB.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
panic: kernel trap (ignored)

as long as the devices created in between are also punted, this should be fine. i was thinking of this case as you dont want:
- usb start
- probe some usb net devices (get usbnet0 and usbnet1)
- usb start
- previous usbnet0/usbnet1 still exist, and the counter has been reset to 0
so the new devices start back at usbnet0

if there's something in the bigger picture that takes care of this already, then this is probably fine.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110413/072e80c6/attachment.pgp

Yes if you do 'usb start' then the old devices go away.

Regards,
Simon