Re: [U-Boot] http client?
On Wed 22 Jul 2009 10:04, jeffery palmer pondered: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Jeff: Can you look at the recent changes to the net/next tree/branch? On a slow connection -- I saw things go from 15:28 download (tftpblocksize == 1468) to 1:47 (tftpblocksize == 16268) - more than a 8x difference. Even if you look at the your stated time of 50min - that should drop it to a more reasonable ~6ish ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Me: Just tried it: U-Boot doesn't support reassembly, it seems. Robin Getz: I don't think anyone said it did. I'm sorry, I misread that in your message. Me: I don't think it's worth adding. Robin: This is based on ... ? laziness, mainly. And personal preference over simpler code where possible. But you are right, no real reason. So I've done it trivially (see patch posted today). On my LAN it doesn't make any noticeable difference: only I have more lost packets if I increase the block size too much, so it gets worse. I would like to know if it helps Jeffery Palmer. BTW: you (Jeffery) told you tried a blocksize of 16k, but how could it work if u-boot refuses fragments? Did you add defragmenting to the code first? /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
I didn't add fragmenting but without further investigation into it I would assume that the fragmented packets were discarded. The tftp program still acted like it was downloading at a larger block size but I doubt it actually was. I have noticed a reasonable amount of lost packets as well which is odd. We have a 100 meg fiber to our servers and I still get lost UDP packets. I think there is a pending bug in the network layer regarding this. I will have a look at the patch and revert. Thanks. Jeffery Palmer Project Development -Original Message- From: rubini-l...@gnudd.com [mailto:rubini-l...@gnudd.com] Sent: Friday, July 24, 2009 4:12 AM To: rg...@blackfin.uclinux.org Cc: u-boot@lists.denx.de; biggerbadder...@gmail.com; jefferypal...@hotmail.com Subject: Re: [U-Boot] http client? Me: Just tried it: U-Boot doesn't support reassembly, it seems. Robin Getz: I don't think anyone said it did. I'm sorry, I misread that in your message. Me: I don't think it's worth adding. Robin: This is based on ... ? laziness, mainly. And personal preference over simpler code where possible. But you are right, no real reason. So I've done it trivially (see patch posted today). On my LAN it doesn't make any noticeable difference: only I have more lost packets if I increase the block size too much, so it gets worse. I would like to know if it helps Jeffery Palmer. BTW: you (Jeffery) told you tried a blocksize of 16k, but how could it work if u-boot refuses fragments? Did you add defragmenting to the code first? /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Fri 24 Jul 2009 04:11, Alessandro Rubini pondered: BTW: you (Jeffery) told you tried a blocksize of 16k, but how could it work if u-boot refuses fragments? Did you add defragmenting to the code first? I believe it depends on if it your host has gig support (for jumbo frames) Most Gig hosts/routers/gateways nowadays do... http://en.wikipedia.org/wiki/Jumbo_frame However - it looks like it might be a bug in the Linux networking stack (I'll ask on netdev) that if the Gig card is connected as 100, it should not be sending jumbo frames (from what I understand -- it is a spec violation). I tried on my subnet - and was able to transfer 4k packets without issue (which is as big as I tested). (dumb repeater/hub between U-Boot the tftp server). However - my MAC running on U-Boot is 10/100 and does not support jumbo frames, and tosses the frame as a Frame too long, and is truncated to 1556 (0x614) bytes in all cases, so if the host is not fragmenting things properly - I can't test it... :( ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
I played around with setting the TFTP block size very large, like 16K,
primarily to reduce the required number of ACK's. It actually appeared as
though uboot was processing the additional frames correctly but without
doing a memory comparison I'm not sure. Here were a few bad side effects
though...
- blksize set to 16K, when fetching a 10 byte file it thinks it's
downloading a 6000 byte file
- The last packet appears to mess things up. The majority of the
transfer goes very well and then at the very end it hangs. Likely the
portion of tftp.c that checks when the file is completed.
UDP packets are either not fragmented or very easy to re-assemble. When
doing a tcpdump the udp packets go out as 1500 byte chunks. A 16K tftp block
gets broken into 11 consecutive packets and requires only 1 ACK. Because
packets can come in out of order and uboot is not very network oriented, I
would suggest just dumping the entire block if a packet comes in out of
order and re-request that block.
Anyways, you can jump right in by setting the blksize to a large number and
see how it behaves.
When I looked at the RFC data
it appears that the overhead of IP fragmentation and reassembly
(which does add overhead as the number of gateways increases) may be
worth the time...
Just tried it: U-Boot doesn't support reassembly, it seems.
I don't think anyone said it did.
net.c confirms it:
/* Can't deal with fragments */
if (ip-ip_off htons(IP_OFFS | IP_FLAGS_MFRAG)) {
return;
}
I don't think it's worth adding.
This is based on ... ?
If it reduces download time by 1/2 (1432 byte block size == 13.70 seconds,
4096 byte block size == 6.85 seconds) it might be worth the complexity...
At least worth it enough to give it a try, gather some results, and then
make a decision.
-Robin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. We would like to work to integrate or add the necessary http client functions to achieve this. If there are no patches obtainable, is anyone interested in working on this with us? Jeffery Palmer Project Development 954.709.7232 _ From: Mark T [mailto:m...@astfin.org] Sent: Wednesday, July 22, 2009 8:47 AM To: Jeff Palmer Subject: Fwd: [U-Boot] http client? fyi Begin forwarded message: From: Robin Getz rg...@blackfin.uclinux.org Date: July 22, 2009 8:26:58 AM GMT-04:00 To: u-boot@lists.denx.de Cc: Ben Warren biggerbadder...@gmail.com, Volkmar Uhlig vuh...@us.ibm.com Subject: Re: [U-Boot] http client? On Tue 21 Jul 2009 17:09, Wolfgang Denk pondered: Dear Robin Getz, In message 200907211400.21275.rg...@blackfin.uclinux.org you wrote: I know there have been discussions about adding wget to U-Boot, which I agree is not something that is worthwhile to do. I am not so sure about that, but that's just my opinion. http://lists.denx.de/pipermail/u-boot/2006-March/013697.html but a simple client would be helpful in many situations. There is such in IBM's port of U-Boot for the Blue Gene super- computer, and Volkmar Uhlig promised to submit patches. But so far he didn't. Hmm.. That sounds interesting. Do you know if there is a public repository? or Do I need to buy a Blue Gene to get access to the source :) According to: http://domino.research.ibm.com/comm/research_projects.nsf/pages/kittyhawkindex.html/$FILE/Kittyhawk%20OSR%2008.pdf We added a simple HTTP server to U-Boot so that individual nodes can be booted via a PUT command that pushes the desired boot images and kernel command line. The command line is evaluated via the scripting environment before it gets passed on to the OS kernel thereby allowing per node customizations. With this simple extension to U-Boot we are able to construct powerful scripted environments and bootstrap large numbers of nodes in a controlled, flexible, and secure way. What is in RedBoot is a HTTP GET. So -- while it shouldn't be hard to extend from there... If a port of the redboot functionality is done - any thoughts on if it would be accepted? Well, you are aware that such a thing would need a TCP/IP stack, which is far beyond what we currently have in U-Boot support? Yes - I'm aware. My thoughts were to do something like what IBM and other suggestions were - use lwip. -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot __ NOD32 4266 (20090722) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Dear Robin Getz, In message 200907220826.58333.rg...@blackfin.uclinux.org you wrote: Well, you are aware that such a thing would need a TCP/IP stack, which is far beyond what we currently have in U-Boot support? Yes - I'm aware. My thoughts were to do something like what IBM and other suggestions were - use lwip. Well, yes. Use it. And have fun debugging funny network behaviour in real life networks. I must admit that I'm not really interested in this - I will not oppose any such patches as long as they are cleanly done and can be disabled without negative impact on exitsting code and systems, but whenever I will need TCP/IP, I will boot an OS instead. Much, much less effort - much faster, and much mor reliable. 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: w...@denx.de Humans do claim a great deal for that particular emotion (love). -- Spock, The Lights of Zetar, stardate 5725.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Dear jeffery palmer, In message blu127-dav686e79b5bf3a89693a9...@phx.gbl you wrote: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. HTTP will probably not be much faster. Did you try using NFS? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Hm... but 20 minutes versus 30 seconds cannot be explained by TFTP versus HTTP alone. There must be other effects impacting your network traffic. Did you run any deeper analysis? 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: w...@denx.de Never ascribe to malice that which can adequately be explained by stupidity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Hm... but 20 minutes versus 30 seconds cannot be explained by TFTP versus HTTP alone. There must be other effects impacting your network traffic. Did you run any deeper analysis? I'm sure it depends on network delays. TCP has the sliding window mechanism, so several packets can be in flight before you get a single ack. TFTP requires one ack for each data packet, doesn't it? If you have high delays, TCP is usually a win, even with relatively low bandwidth. Otherwise, we need a an UDP protocol that doesn't require individual ack. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
The ACK delays are exactly what cause the extremely long download times. There are approx 16,000 ACK cycles for my 8MB image on a 512K blksize. I upped this to 1432 to stay under the MTU which cut the ACK cycles by three, but still, on a 180ms round trip time the math is simple. 8MB/1432bytes=5580 ACK's * 180 ms = 17 minutes. There are good reasons to use TCP/IP for doing the updates. Some of our reasons are: - Firewall/NAT/filter transversals - Passing arguments and status information to our update server, such as serial numbers, status's, etc. - Receiving uboot specific commands via update server - Error checking in TCP streams vs UDP (Alreading using checksums, but another layer of reliability wouldn't hurt) NFS is still be stuck to the same rules as TFTP so it's not a very good option. We already have equipment using UIP (UDP + TCP) which works great and is extremely small at ~30K of compiled code. I am not yet familiar with the underlying network code in uboot, but is it entirely written from the ground up or based off of another project? There are quite a few additions you can achieve with a TCP stack but of course it needs to be very clean and well tested. Jeffery Palmer Project Development -Original Message- From: rubini-l...@gnudd.com [mailto:rubini-l...@gnudd.com] Sent: Wednesday, July 22, 2009 11:23 AM To: w...@denx.de Cc: jefferypal...@hotmail.com; u-boot@lists.denx.de Subject: Re: [U-Boot] http client? Hm... but 20 minutes versus 30 seconds cannot be explained by TFTP versus HTTP alone. There must be other effects impacting your network traffic. Did you run any deeper analysis? I'm sure it depends on network delays. TCP has the sliding window mechanism, so several packets can be in flight before you get a single ack. TFTP requires one ack for each data packet, doesn't it? If you have high delays, TCP is usually a win, even with relatively low bandwidth. Otherwise, we need a an UDP protocol that doesn't require individual ack. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Wed, 2009-07-22 at 12:00 -0400, jeffery palmer wrote: There are quite a few additions you can achieve with a TCP stack but of course it needs to be very clean and well tested. http://www.sics.se/~adam/uip/uip-1.0-refman/ I used it before on a small arm platform (small =16k ram) and used it for a tftp server and http server. Have no idea about performance I was only interested in it working at all so never tried to measure anything or tune any parameters. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Wed 22 Jul 2009 10:04, jeffery palmer pondered: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ? Do you have a patch to send - or that I can clean up and submit? We would like to work to integrate or add the necessary http client functions to achieve this. If there are no patches obtainable, is anyone interested in working on this with us? Yes - Although it sounds like your schedule is more immediate than mine... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Robin Getz wrote: On Wed 22 Jul 2009 10:04, jeffery palmer pondered: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ? Do you have a patch to send - or that I can clean up and submit? Requesting a bigger blocksize is already implemented and should work if the server supports it. It's been a while since I used this, but it was added along with support for multicast TFTP, probably about a year ago. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Wed 22 Jul 2009 16:32, Ben Warren pondered: Robin Getz wrote: On Wed 22 Jul 2009 10:04, jeffery palmer pondered: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ? Do you have a patch to send - or that I can clean up and submit? Requesting a bigger blocksize is already implemented and should work if the server supports it. It's been a while since I used this, but it was added along with support for multicast TFTP, probably about a year ago. I see: #define TFTP_MTU_BLOCKSIZE 1468blksize static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE; /* try for more effic. blk size */ pkt += sprintf((char *)pkt,blksize%c%d%c, 0,TftpBlkSizeOption,0); but that is it... No CONFIG_ options for anything else? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Robin Getz wrote: On Wed 22 Jul 2009 16:32, Ben Warren pondered: Robin Getz wrote: On Wed 22 Jul 2009 10:04, jeffery palmer pondered: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ? Do you have a patch to send - or that I can clean up and submit? Requesting a bigger blocksize is already implemented and should work if the server supports it. It's been a while since I used this, but it was added along with support for multicast TFTP, probably about a year ago. I see: #define TFTP_MTU_BLOCKSIZE 1468blksize static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE; /* try for more effic. blk size */ pkt += sprintf((char *)pkt,blksize%c%d%c, 0,TftpBlkSizeOption,0); but that is it... No CONFIG_ options for anything else? Right, it's hard-coded to 1468 (maximum TFTP frame that will fit in a 1500-byte Ethernet frame, due to UDP overhead). By default, TFTP requests a blocksize that will fill the frame. If not, it uses the default TFTP block size (512, I think). Is this not good enough? Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Wed 22 Jul 2009 16:53, Ben Warren pondered: Robin Getz wrote: I see: #define TFTP_MTU_BLOCKSIZE 1468blksize static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE; /* try for more effic. blk size */ pkt += sprintf((char *)pkt,blksize%c%d%c, 0,TftpBlkSizeOption,0); but that is it... No CONFIG_ options for anything else? Right, it's hard-coded to 1468 (maximum TFTP frame that will fit in a 1500-byte Ethernet frame, due to UDP overhead). By default, TFTP requests a blocksize that will fill the frame. If not, it uses the default TFTP block size (512, I think). Is this not good enough? When I looked at the RFC data blocksize no gateway with gateway - -- 51223.85 37.05 102416.15 25.65 143213.70 23.10 204810.90 16.90 4096 6.85 9.65 8192 4.90 6.15 it appears that the overhead of IP fragmentation and reassembly (which does add overhead as the number of gateways increases) may be worth the time... -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
When I looked at the RFC data
it appears that the overhead of IP fragmentation and reassembly (which does
add overhead as the number of gateways increases) may be worth the time...
Just tried it: U-Boot doesn't support reassembly, it seems.
net.c confirms it:
/* Can't deal with fragments */
if (ip-ip_off htons(IP_OFFS | IP_FLAGS_MFRAG)) {
return;
}
I don't think it's worth adding.
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Wed 22 Jul 2009 18:00, Alessandro Rubini pondered:
When I looked at the RFC data
it appears that the overhead of IP fragmentation and reassembly (which
does add overhead as the number of gateways increases) may be worth
the time...
Just tried it: U-Boot doesn't support reassembly, it seems.
I don't think anyone said it did.
net.c confirms it:
/* Can't deal with fragments */
if (ip-ip_off htons(IP_OFFS | IP_FLAGS_MFRAG)) {
return;
}
I don't think it's worth adding.
This is based on ... ?
If it reduces download time by 1/2 (1432 byte block size == 13.70 seconds,
4096 byte block size == 6.85 seconds) it might be worth the complexity...
At least worth it enough to give it a try, gather some results, and then make
a decision.
-Robin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Sorry - first time I sent this -- I forgot to cc the list... On Tue 21 Jul 2009 12:37, Robin Getz pondered: redboot supports (and has since 2002) a mini-http client: This is just a transfer data via the network using HTTP protocol, no better or worse than tftp. (no https, no proxy, no other protocols). http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/packages/redboot/current/src/net/http_client.c?rev=1.11content-type=text/x-cvsweb-markupcvsroot=ecos I know there have been discussions about adding wget to U-Boot, which I agree is not something that is worthwhile to do. http://lists.denx.de/pipermail/u-boot/2006-March/013697.html but a simple client would be helpful in many situations. If a port of the redboot functionality is done - any thoughts on if it would be accepted? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Hi Robin, Robin Getz wrote: Sorry - first time I sent this -- I forgot to cc the list... On Tue 21 Jul 2009 12:37, Robin Getz pondered: redboot supports (and has since 2002) a mini-http client: This is just a transfer data via the network using HTTP protocol, no better or worse than tftp. (no https, no proxy, no other protocols). http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/packages/redboot/current/src/net/http_client.c?rev=1.11content-type=text/x-cvsweb-markupcvsroot=ecos I know there have been discussions about adding wget to U-Boot, which I agree is not something that is worthwhile to do. http://lists.denx.de/pipermail/u-boot/2006-March/013697.html but a simple client would be helpful in many situations. If a port of the redboot functionality is done - any thoughts on if it would be accepted? I have no philosophical objection - in fact it seems kinda cool. As always, if you're able to make a good case for why something should be included, it probably will be. cheers, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Hi Robin, Robin Getz wrote: Sorry - first time I sent this -- I forgot to cc the list... On Tue 21 Jul 2009 12:37, Robin Getz pondered: redboot supports (and has since 2002) a mini-http client: This is just a transfer data via the network using HTTP protocol, no better or worse than tftp. (no https, no proxy, no other protocols). http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/packages/redboot/current/src/net/http_client.c?rev=1.11content-type=text/x-cvsweb-markupcvsroot=ecos I know there have been discussions about adding wget to U-Boot, which I agree is not something that is worthwhile to do. http://lists.denx.de/pipermail/u-boot/2006-March/013697.html but a simple client would be helpful in many situations. If a port of the redboot functionality is done - any thoughts on if it would be accepted? I have no philosophical objection - in fact it seems kinda cool. As always, if you're able to make a good case for why something should be included, it probably will be. The wget functionality would be the easy part. Adding TCP support to U-Boot would be the very, very hard part in my opinion:) For what its worth, we used the lwip stack for our proprietary bootloader in the past and it worked reasonable well for both TCP and UDP at a somewhat reasonable code size: http://savannah.nongnu.org/projects/lwip/ Anyway, I think it'd be neat too and it would open the doors for other interesting apps, but adding TCP support is no small task at all. My $.02, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Dear Robin Getz, In message 200907211400.21275.rg...@blackfin.uclinux.org you wrote: I know there have been discussions about adding wget to U-Boot, which I agree is not something that is worthwhile to do. I am not so sure about that, but that's just my opinion. http://lists.denx.de/pipermail/u-boot/2006-March/013697.html but a simple client would be helpful in many situations. There is such in IBM's port of U-Boot for the Blue Gene super- computer, and Volkmar Uhlig promised to submit patches. But so far he didn't. If a port of the redboot functionality is done - any thoughts on if it would be accepted? Well, you are aware that such a thing would need a TCP/IP stack, which is far beyond what we currently have in U-Boot support? 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: w...@denx.de The human race is a race of cowards; and I am not only marching in that procession but carrying a banner. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
