[U-Boot] http client?

[U-Boot] http client?

[jeffery palmer]

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:mark at 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 <rgetz@blackfin.uclinux.org>
Date: July 22, 2009 8:26:58 AM GMT-04:00
To: u-boot at lists.denx.de
Cc: Ben Warren <biggerbadderben@gmail.com>, Volkmar Uhlig <vuhlig@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.rgetz@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, ?exible, 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 at 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] http client?

[Wolfgang Denk]

Dear "jeffery palmer",

In message <BLU127-DAV686E79B5BF3A896935555A91B0@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: wd at denx.de
Never ascribe to malice that which can  adequately  be  explained  by
stupidity.

[U-Boot] http client?

[Alessandro Rubini]

> 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] http client?

[jeffery palmer]

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-list@gnudd.com [mailto:rubini-list at gnudd.com] 
Sent: Wednesday, July 22, 2009 11:23 AM
To: wd at denx.de
Cc: jefferypalmer at hotmail.com; u-boot at 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] http client?

[Kenneth Johansson]

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] http client?

[Robin Getz]

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] http client?

[Ben Warren]

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] http client?

[Robin Getz]

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] http client?

[Ben Warren]

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] http client?

[Robin Getz]

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
---------   ----------   ------------
  512            23.85      37.05
 1024            16.15      25.65
 1432            13.70      23.10
 2048            10.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] http client?

[Alessandro Rubini]

> 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] http client?

[Robin Getz]

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] http client?

[jeffery palmer]

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] http client?

[Alessandro Rubini]

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] http client?

[jeffery palmer]

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-list@gnudd.com [mailto:rubini-list at gnudd.com] 
Sent: Friday, July 24, 2009 4:12 AM
To: rgetz at blackfin.uclinux.org
Cc: u-boot at lists.denx.de; biggerbadderben at gmail.com;
jefferypalmer at 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] http client?

[Robin Getz]

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] http client?

[Robin Getz]

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] http client?

[Robin Getz]

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.11&content-type=text/x-cvsweb-markup&cvsroot=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] http client?

[Ben Warren]

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.11&content-type=text/x-cvsweb-markup&cvsroot=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] http client?

[Peter Tyser]

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.11&content-type=text/x-cvsweb-markup&cvsroot=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] http client?

[Wolfgang Denk]

Dear Robin Getz,

In message <200907211400.21275.rgetz@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: wd at 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] http client?

[Robin Getz]

On Tue 21 Jul 2009 17:09, Wolfgang Denk pondered:
> Dear Robin Getz,
> 
> In message <200907211400.21275.rgetz@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/kittyhawk.index.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, ?exible, 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] http client?

[Wolfgang Denk]

Dear Robin Getz,

In message <200907220826.58333.rgetz@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: wd at denx.de
Humans do claim a great deal for that particular emotion (love).
	-- Spock, "The Lights of Zetar", stardate 5725.6