[U-Boot-Users] multicast tftp: RFC2090
Hi.
looking for interest to support mutlicast tftp in u-boot. I have a version working according to RFC2090 working with 'atftp' with only a dozen or so lines patch in net/tftp.c and a few in net/net.c. But the messy part is that the ethernet driver needs to have hooks to set up mcast ether-addrs...
Has there already been a discussion about this that I missed that someone could refer me to?
thnx.
-dbu.
In message f0l75r$jem$1@sea.gmane.org you wrote:
looking for interest to support mutlicast tftp in u-boot. I have a version working according to RFC2090 working with 'atftp' with only a dozen or so lines patch in net/tftp.c and a few in net/net.c. But the messy part is that the ethernet driver needs to have hooks to set up mcast ether-addrs...
Has there already been a discussion about this that I missed that someone could refer me to?
This has indeed been discussed before; the thread was started here:
Date: Tue, 29 Aug 2006 09:55:34 -0400 From: mitsy mitsy12@gmail.com To: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] multicast tftp client?
Short summary: we are waiting for a clever implementation (i. e. yours :-)
Best regards,
Wolfgang Denk
Hi Dave,
On Tue, 2007-04-24 at 10:19 -0500, David Updegraff wrote:
Hi.
looking for interest to support mutlicast tftp in u-boot. I have a version working according to RFC2090 working with 'atftp' with only a dozen or so lines patch in net/tftp.c and a few in net/net.c. But the messy part is that the ethernet driver needs to have hooks to set up mcast ether-addrs...
Has there already been a discussion about this that I missed that someone could refer me to?
This looks interesting. Have you done much testing to see how it reduces network traffic and server loading? I imagine you'd probably need quite a few boards booting simultaneously to see any benefit.
Anyway, I wouldn't worry too much about having to modify Ethernet drivers to add mcast addresses. I expect that interest in this feature will be fairly low, and adding an mcast address to a MAC is typically not very complicated. It's pretty common in Linux drivers so people can always steal from there.
I'm a little more worried about purging the entries when you're done, since I imagine you would typically want to enter Linux or whatever with an empty multicast hash table. Maybe this isn't an issue, though.
regards, Ben
Ben
lemme test a bit and I'll post a patch in a day or so; see what the more experienced folks on the list think.
-dbu.
Here is a first pass; not yet request for merge.
Only have been able to test with 8343 TSEC and an old SC520-based rtl8139 so far, and with only two concurrent downloads; against atftpd server. Re-cycling the existing ext2 bitmap functions to do housekeeping.
In about a month I should have access to enough hardware to test 20+ concurrent tftpboots.
Suggestions & comments appreciated.
thnx.
On 5/1/07, David Updegraff dave@cray.com wrote:
Here is a first pass; not yet request for merge.
Only have been able to test with 8343 TSEC and an old SC520-based rtl8139 so far, and with only two concurrent downloads; against atftpd server. Re-cycling the existing ext2 bitmap functions to do housekeeping.
In about a month I should have access to enough hardware to test 20+ concurrent tftpboots.
Suggestions & comments appreciated.
I have to NACK this portion:
@@ -378,6 +378,28 @@ uint mii_parse_sr(uint mii_reg, struct tsec_private * priv) priv->link = 1; }
+ /* take a stab at 10/100 and Duplex info too; from linux mii.c */ + mii_reg = (read_phy_reg(priv, PHY_ANAR) & read_phy_reg(priv, PHY_ANLPAR)); + if ( mii_reg & PHY_ANLPAR_TXFD ) { + priv->duplexity = 1; + priv->speed = 100; + } + else if ( mii_reg & PHY_ANLPAR_TX ) { + priv->duplexity = 0; + priv->speed = 100; + } + else if ( mii_reg & PHY_ANLPAR_TX ) { + priv->duplexity = 0; + priv->speed = 100; + } + else if ( mii_reg & PHY_ANLPAR_10FD ) { + priv->duplexity = 1; + priv->speed = 10; + } else { + priv->duplexity = 0; + priv->speed = 10; + } + return 0; }
@@ -1056,6 +1078,26 @@ struct phy_info phy_info_VSC8244 = { {miim_end,} }, }; +/* a generic flavor. */ +struct phy_info phy_info_generic = { + 0, + "Unknown/Generic PHY", + 32, + (struct phy_cmd[]) { /* config */ + {PHY_BMCR, PHY_BMCR_RESET, NULL}, + {PHY_BMCR, PHY_BMCR_AUTON|PHY_BMCR_RST_NEG, NULL}, + {miim_end,} + }, + (struct phy_cmd[]) { /* startup */ + {PHY_BMSR, miim_read, NULL}, + {PHY_BMSR, miim_read, &mii_parse_sr}, + {miim_end,} + }, + (struct phy_cmd[]) { /* shutdown */ + {miim_end,} + } +}; +
struct phy_info phy_info_dm9161 = { 0x0181b88, @@ -1203,6 +1245,7 @@ struct phy_info *phy_info[] = { &phy_info_lxt971, &phy_info_VSC8244, &phy_info_dp83865, + &phy_info_generic, NULL };
Sadly, I've already applied it to my tree, but I've just determined that it breaks gigabit links, even on boards with known PHYs.
I'm going to fix that, but these two hunks need to be in a separate patch, anyway. I will post the updated version.
Andy
Andy
whoops! I see your point now! the parse_sr shouldn't be taking the stab at determining lnk.etc. if the curphy != generic I guess.
On 5/1/07, David Updegraff dave@cray.com wrote:
Here is a first pass; not yet request for merge.
Only have been able to test with 8343 TSEC and an old SC520-based rtl8139 so far, and with only two concurrent downloads; against atftpd server. Re-cycling the existing ext2 bitmap functions to do housekeeping.
In about a month I should have access to enough hardware to test 20+ concurrent tftpboots.
Suggestions & comments appreciated.
I have to NACK this portion:
@@ -378,6 +378,28 @@ uint mii_parse_sr(uint mii_reg, struct tsec_private
- priv) priv->link = 1; }
- /* take a stab at 10/100 and Duplex info too; from linux mii.c */
- mii_reg = (read_phy_reg(priv, PHY_ANAR) & read_phy_reg(priv,
PHY_ANLPAR));
- if ( mii_reg & PHY_ANLPAR_TXFD ) {
priv->duplexity = 1;priv->speed = 100;- }
- else if ( mii_reg & PHY_ANLPAR_TX ) {
priv->duplexity = 0;priv->speed = 100;- }
- else if ( mii_reg & PHY_ANLPAR_TX ) {
priv->duplexity = 0;priv->speed = 100;- }
- else if ( mii_reg & PHY_ANLPAR_10FD ) {
priv->duplexity = 1;priv->speed = 10;- } else {
priv->duplexity = 0;priv->speed = 10;- }
- return 0;
}
@@ -1056,6 +1078,26 @@ struct phy_info phy_info_VSC8244 = { {miim_end,} }, }; +/* a generic flavor. */ +struct phy_info phy_info_generic = {
- 0,
- "Unknown/Generic PHY",
- 32,
- (struct phy_cmd[]) { /* config */
{PHY_BMCR, PHY_BMCR_RESET, NULL},{PHY_BMCR, PHY_BMCR_AUTON|PHY_BMCR_RST_NEG, NULL},{miim_end,}- },
- (struct phy_cmd[]) { /* startup */
{PHY_BMSR, miim_read, NULL},{PHY_BMSR, miim_read, &mii_parse_sr},{miim_end,}- },
- (struct phy_cmd[]) { /* shutdown */
{miim_end,}- }
+};
struct phy_info phy_info_dm9161 = { 0x0181b88, @@ -1203,6 +1245,7 @@ struct phy_info *phy_info[] = { &phy_info_lxt971, &phy_info_VSC8244, &phy_info_dp83865,
- &phy_info_generic, NULL
};
Sadly, I've already applied it to my tree, but I've just determined that it breaks gigabit links, even on boards with known PHYs.
I'm going to fix that, but these two hunks need to be in a separate patch, anyway. I will post the updated version.
Andy
On 5/1/07, David Updegraff dave@cray.com wrote:
Andy
whoops! I see your point now! the parse_sr shouldn't be taking the stab at determining lnk.etc. if the curphy != generic I guess.
Yeah. I've got a bead on a solution now, though. I will have a patch in an hour or so.
Andy
Ok; here my mulicast TFTP patch. Have had the opportunity to test with both the RTL8139 and TSEC ethernet drivers, with up to a dozen clients concurrent.
In a way I'm tempted to simply remove the #if CONFIG_RFC7090 clutter as it is benign if you happen to be talking to a non-multicast tftp server; and would make things rather more readable. But too timid...
-dbu.
David Updegraff wrote:
Ok; here my mulicast TFTP patch. Have had the opportunity to test with both the RTL8139 and TSEC ethernet drivers, with up to a dozen clients concurrent.
In a way I'm tempted to simply remove the #if CONFIG_RFC7090 clutter as it is benign if you happen to be talking to a non-multicast tftp server; and would make things rather more readable. But too timid...
-dbu.
Hi Dave,
Interesting, not as much change needed as I would have guessed.
Now I'm dying of curiosity... what is your impression of the usefulness of RFC7090? It always struck me as a lab curiosity: in fairly artificial cases where a bunch of CPU boards are powered up simultaneously... * a room full of machines with a master breaker * a rack of CPUs it would be a big win, but that is a fairly unusual setup in the areas I hang out in.
On the other hand, we have a customer that currently has up to 4 units in a rack, and in the future possibly more units in a rack, that could possibly benefit from RFC2090.
Best regards, gvb
Jerry
IMHO.. its a no-brainer: it costs almost nothing, adds _very_ litte code, incurs no penatly for FTP servers that dont support it or that have no other concurrent downloaders... but has a _H_U_G_E_ impact where its usefull.
I.e. to my view, RCF7090 should be _the_ tftp protocol. All upside, no downside that I see. Aside -- of course! -- from the bugs we have not yet found in that patch. -;)
David Updegraff wrote:
Ok; here my mulicast TFTP patch. Have had the opportunity to test with both the RTL8139 and TSEC ethernet drivers, with up to a dozen clients concurrent.
In a way I'm tempted to simply remove the #if CONFIG_RFC7090 clutter as it is benign if you happen to be talking to a non-multicast tftp server; and would make things rather more readable. But too timid...
-dbu.
Hi Dave,
Interesting, not as much change needed as I would have guessed.
Now I'm dying of curiosity... what is your impression of the usefulness of RFC7090? It always struck me as a lab curiosity: in fairly artificial cases where a bunch of CPU boards are powered up simultaneously...
- a room full of machines with a master breaker
- a rack of CPUs
it would be a big win, but that is a fairly unusual setup in the areas I hang out in.
On the other hand, we have a customer that currently has up to 4 units in a rack, and in the future possibly more units in a rack, that could possibly benefit from RFC2090.
Best regards, gvb
participants (5)
-
Andy Fleming -
Ben Warren -
David Updegraff -
Jerry Van Baren -
Wolfgang Denk