[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.

[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.

[Wells, Charles]

Wolfgang,

I feel obliged to comment on your response to Brian's post.

>> It won't be practical (support nightmare!) for us to ask our customers to

>> setup a tftp server in order to use our product.
>
>What's so complicated about this? See for example how  Abatron  ships
>their  BDI2000s  -  they  include  a free TFTP server on their floppy
>disks which is so simple that even a Windoze user can start it.

You're making assumptions here that I don't believe are appropriate:

1. You are assuming that Brian's customers are at least as sophisticated as
Abatron customers.  Brian's original statement leads me to believe this is
not so.

2. You are assuming that you know more about Brian's customers than either
he or his Marketing group does.  Ultimately, it is the responsibility of a
company's Marketing group to determine what a customer is capable of and
will tolerate.

>> However, if the boot loader is capable of receiving the OS image over the

>> network, our PC side application can upload the OS and Ram disk image to 
>> our custom board the first time it connects to it.
>> 
>> Is this not a good idea?
>
>No, it is not. You are trying to re-invent the wheel. 

This is certainly an emphatic statement.  The least you could have done here
is to prefix it with "IMHO".  

U-boot supports the target-as-client method of downloading but does not
support the target-as-server method.  I've used both methods a number of
times over the years and both have their advantages and disadvantages.  Your
position seems to be that u-boot does everything useful for downloading.
Therefore, if u-boot doesn't "do it", then "it" must be a duplication.  I
disagree.  IMHO, target-as-server boot loading is a good idea.  The two
methods are useful in different circumstances and are not, IMHO, a
reinvention.  

At the company I work for, we have three different MPC850 designs that work
together to form our new system.  The boot code in all three units contains
a target-as-server (UDP over Ethernet) loader.  We use this UDP/Ethernet
boot loader in exactly the mode that Brian is referring to above.  It
supports Linux, VxWorks and stand-alone images.  It's used every day by the
Development team, SQA team and Field Support team.  It works great.

The main advantage is simplicity.  Our boot code occupies less than 6k-bytes
of FLASH (that would fit in a 2708 ;-) ).  The small size attests to its
simplicity as well as the capabilities of the Ethernet controller in the
'850.  It was written and debugged in a very short time over a year ago and
has not required any maintenance since.  No head-scratching, no
hair-pulling, no patches.  It just works.

The way I see it, one of the benefits of these lists is discussion.  To cut
off discussion as you did is, IMHO, not productive.

Regards,
Charlie

Charles.Wells at nielsenmedia.com

[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.

[Wolfgang Denk]

Charles,

in message <DF2B720CF774D21189EE00805FA7FA220B909B67@nmrusdunsx3.nielsenmedia.com> you wrote:
> 
> >What's so complicated about this? See for example how  Abatron  ships
> >their  BDI2000s  -  they  include  a free TFTP server on their floppy
> >disks which is so simple that even a Windoze user can start it.
> 
> You're making assumptions here that I don't believe are appropriate:

It is your assumption that I make assumptions, or maybe  my  lack  of
skill  of  the  English language, which is not my native language. In
any case, I was just trying to suggest alternative solutions.

> 1. You are assuming that Brian's customers are at least as sophisticated as
> Abatron customers.  Brian's original statement leads me to believe this is
> not so.

Indeed I think they are. Typing "tftpsrv" (or which other ways  there
are to start the supplied application "tftpsrv.exe") is IMHO no a big
challenge. And this is all you need to do.

> 2. You are assuming that you know more about Brian's customers than either
> he or his Marketing group does.  Ultimately, it is the responsibility of a
> company's Marketing group to determine what a customer is capable of and
> will tolerate.

I don't think I gave any indication of such assumptions.


> >No, it is not. You are trying to re-invent the wheel. 
> 
> This is certainly an emphatic statement.  The least you could have done here
> is to prefix it with "IMHO".  

Then I will have to prefix all my  statements  that  way.  Of  course
_everything_  I  write  is  just  my opinion. Sometime MHO, sometimes
MNSHO.


> U-boot supports the target-as-client method of downloading but does not
> support the target-as-server method.  I've used both methods a number of
> times over the years and both have their advantages and disadvantages.  Your

Can you please explain the advantages of the  boot  loader  providing
server function?

> position seems to be that u-boot does everything useful for downloading.
> Therefore, if u-boot doesn't "do it", then "it" must be a duplication.  I
> disagree.  IMHO, target-as-server boot loading is a good idea.  The two
> methods are useful in different circumstances and are not, IMHO, a
> reinvention.  
> 
> At the company I work for, we have three different MPC850 designs that work
> together to form our new system.  The boot code in all three units contains
> a target-as-server (UDP over Ethernet) loader.  We use this UDP/Ethernet
> boot loader in exactly the mode that Brian is referring to above.  It

Did you use any standard download protocol, like  TFTP,  or  did  you
implement  your  own  proprietary download protocol? Maybe you had to
implement your own upload tool, too? If so, I see no  real  advantage
of  starting  your  upload  application  or  starting  a  TFTP server
application. IMHO, of course.

> The way I see it, one of the benefits of these lists is discussion.  To cut
> off discussion as you did is, IMHO, not productive.

OK, so let's discuss a little of U-Boot design philosophy - as I  see
it. YMMV.

U-Boot is a Boot Loader, not an OS.

U-Boot shall be powerful to use, yet simple  in  design  to  make  it
easily portable to new boards and architectures.

This means U-Boot will be strictly single-tasking; it  will  not  use
virtual  memory; it will use polling drivers (versus interrupt driven
ones) whenever possible.

U-Boot shall use standard protocols and interfaces whenever possible.


If you implement a TFTP server  function  within  U-Boot,  this  will
block  until  it's finished (probably after a succesful upload?). OK,
you can use a canned command sequence to accept an  upload  and  then
start the uploaded image.

But the same can be done when using TFTP on U-Boot.


And if - for example during development -  interactive  operation  is
required  or  wanted,  you  will have to type to _one_ interface only
(U-Boot). Otherwise you have to switch between U-Boot  (start  server
function),  host (run upload client), and back to U-Boot (start image
or so).

I'm sorry, but IMHO there is no advantage running  a  server  in  the
boot loader.

Perhaps you might be so kind as to elucidate.



[There _is_  some  use  for  server-like  functions  in  U-Boot:  for
example,  many  people  have  asked why U-Boot does not reply to ICMP
messages (ping requests). There is no doubt that this would be a nice
feature. On the other hand, think what it needs:  you  will  have  to
always  enable  the  network interface(s), you will have to deal with
situations like when MAC addresses and/or IP addresses are  not  set,
and you will have to deal with incoming network packets at any time -
this  would  make  the U-Boot design much more complicated. It _is_ a
nice feature, but not worth the effort. IMHO.]



Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
My challenge to the goto-less programmer  is  to  recode  tcp_input()
without any gotos ... without any loss of efficiency (there has to be
a catch).                                             - W. R. Stevens

[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.

[Brian S. Park]

Wonfgang,

 > U-boot supports the target-as-client method of downloading but does not
> > support the target-as-server method.  I've used both methods a number of
> > times over the years and both have their advantages and 
> disadvantages.  Your
>
>Can you please explain the advantages of the  boot  loader  providing
>server function?

The advantage I see is this.
1. You ship 1 less piece of software. Less number of application that needs 
to be installed/started is always better, IMHO, when it comes to support.
2. It makes the network configuration a bit simpler. If you do not have a 
dedicated TFTP server, you must use serial console to setup the  server IP 
before you can boot if you change the tftp server. Users only have to worry 
about 1 IP instead of 2 when setting up our product. Since large number of 
our users are not very network savvy, things like this make a difference 
when it comes to support.


>And if - for example during development -  interactive  operation  is
>required  or  wanted,  you  will have to type to _one_ interface only
>(U-Boot). Otherwise you have to switch between U-Boot  (start  server
>function),  host (run upload client), and back to U-Boot (start image
>or so).
>
>I'm sorry, but IMHO there is no advantage running  a  server  in  the
>boot loader.

I think this will be useful only when it is deployed to the field. I agree 
that during the development, it has little advantages.


>[There _is_  some  use  for  server-like  functions  in  U-Boot:  for
>example,  many  people  have  asked why U-Boot does not reply to ICMP
>messages (ping requests). There is no doubt that this would be a nice
>feature. On the other hand, think what it needs:  you  will  have  to
>always  enable  the  network interface(s), you will have to deal with
>situations like when MAC addresses and/or IP addresses are  not  set,
>and you will have to deal with incoming network packets at any time -
>this  would  make  the U-Boot design much more complicated. It _is_ a
>nice feature, but not worth the effort. IMHO.]

I have no idea how complicated it will be to implement server feature. 
Hopefully, it would be easier to do than ping since u-boot would listen to 
the incoming traffic only when commanded to do so.

Thanks.

Brian


===============================================================
Brian S. Park  brian at corelis.com  (562) 926-6727 x143
---------------------------------------------------------------
Everything we do helps our customers get to market
FASTER with HIGHER quality and LOWER cost
===============================================================

[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.

[Wolfgang Denk]

Dear Brian,

in message <5.1.1.6.2.20030624115306.0131de20@corelis.com> you wrote:
> Wonfgang,

s/n/l/

> >Can you please explain the advantages of the  boot  loader  providing
> >server function?
> 
> The advantage I see is this.
> 1. You ship 1 less piece of software. Less number of application that needs 
> to be installed/started is always better, IMHO, when it comes to support.

Don't you have to ship a (proprietary?) upload client instead of  the
(standard) TFTP server?

> 2. It makes the network configuration a bit simpler. If you do not have a 
> dedicated TFTP server, you must use serial console to setup the  server IP 
> before you can boot if you change the tftp server. Users only have to worry 
> about 1 IP instead of 2 when setting up our product. Since large number of 
> our users are not very network savvy, things like this make a difference 
> when it comes to support.

As mentioned before, the TFTP server which is  used  for  example  by
Abatron does not require any special setup on the host.

In any case you will have to setup both the network interfaces on the
host and the target.


> I think this will be useful only when it is deployed to the field. I agree 
> that during the development, it has little advantages.

So what are the advantages in the field, then?

> I have no idea how complicated it will be to implement server feature. 

It is not complicated. But IMHO not worth the effort.



Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Clothes make the man. Naked people have little  or  no  influence  on
society.                                                 - Mark Twain

[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.

[Brian S. Park]

Dear Wolfgang,

> > The advantage I see is this.
> > 1. You ship 1 less piece of software. Less number of application that 
> needs
> > to be installed/started is always better, IMHO, when it comes to support.
>
>Don't you have to ship a (proprietary?) upload client instead of  the
>(standard) TFTP server?

It could be integrated to our PC side application which can upload it the 
first time it connects to the target. Integrating TFTP server to our 
application would require it to start before the user powering up the target.


> > 2. It makes the network configuration a bit simpler. If you do not have a
> > dedicated TFTP server, you must use serial console to setup the  server IP
> > before you can boot if you change the tftp server. Users only have to 
> worry
> > about 1 IP instead of 2 when setting up our product. Since large number of
> > our users are not very network savvy, things like this make a difference
> > when it comes to support.
>
>As mentioned before, the TFTP server which is  used  for  example  by
>Abatron does not require any special setup on the host.
>
>In any case you will have to setup both the network interfaces on the
>host and the target.

With TFTP client approach, I need to set the serverip environmental 
variable to IP of PC with the TFTP server. If I move the controller to 
another room, and found out that the PC with TFTP server is not powered up, 
I need to either change the serverip variable to the new PC I intended to 
use or go back to the other room and power up the PC. :)

I think it's easiest for the user and the developer if the firmware is 
entirely stored on the flash. If we can upload the OS, we can make it work 
as if the firmware is on the target (i.e. hide TFTP stuff from the user).

> > I have no idea how complicated it will be to implement server feature.
>
>It is not complicated. But IMHO not worth the effort.

I always appreciate your comments and opinion.

Thank you.

Brian


===============================================================
Brian S. Park  brian at corelis.com  (562) 926-6727 x143
---------------------------------------------------------------
Everything we do helps our customers get to market
FASTER with HIGHER quality and LOWER cost
===============================================================

[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.

[Woodruff, Richard]

If system requirements allow for it, adding in a simple zeroconf ip address
assignment would seem to be ideal in a lot of situations.  All you need to
do is a hash on a mac, some arp broadcasts, and you up :)  www.zeroconf.org
.  There also is some service discovery stuff but I've not looked to deeply
at that aspect of it.  Linux has a patch for it, microsoft and apple have
been using it for a while. Next time you see a 169.x.x.x address you know
where it came from. :)

> -----Original Message-----
> From: Brian S. Park [mailto:brian at corelis.com] 
> Sent: Tuesday, June 24, 2003 4:20 PM
> To: Wolfgang Denk
> Cc: 'u-boot-users at lists.sourceforge.net'; Wells, Charles
> Subject: Re: [U-Boot-Users] uploading OS over network instead 
> of u-boot do wnloading it from a server. 
> 
> 
> Dear Wolfgang,
> 
> > > The advantage I see is this.
> > > 1. You ship 1 less piece of software. Less number of application 
> > > that
> > needs
> > > to be installed/started is always better, IMHO, when it comes to 
> > > support.
> >
> >Don't you have to ship a (proprietary?) upload client instead of  the
> >(standard) TFTP server?
> 
> It could be integrated to our PC side application which can 
> upload it the 
> first time it connects to the target. Integrating TFTP server to our 
> application would require it to start before the user 
> powering up the target.
> 
> 
> > > 2. It makes the network configuration a bit simpler. If 
> you do not 
> > > have a dedicated TFTP server, you must use serial console 
> to setup 
> > > the  server IP before you can boot if you change the tftp server. 
> > > Users only have to
> > worry
> > > about 1 IP instead of 2 when setting up our product. Since large 
> > > number of our users are not very network savvy, things like this 
> > > make a difference when it comes to support.
> >
> >As mentioned before, the TFTP server which is  used  for  
> example  by 
> >Abatron does not require any special setup on the host.
> >
> >In any case you will have to setup both the network 
> interfaces on the 
> >host and the target.
> 
> With TFTP client approach, I need to set the serverip environmental 
> variable to IP of PC with the TFTP server. If I move the 
> controller to 
> another room, and found out that the PC with TFTP server is 
> not powered up, 
> I need to either change the serverip variable to the new PC I 
> intended to 
> use or go back to the other room and power up the PC. :)
> 
> I think it's easiest for the user and the developer if the 
> firmware is 
> entirely stored on the flash. If we can upload the OS, we can 
> make it work 
> as if the firmware is on the target (i.e. hide TFTP stuff 
> from the user).
> 
> > > I have no idea how complicated it will be to implement server 
> > > feature.
> >
> >It is not complicated. But IMHO not worth the effort.
> 
> I always appreciate your comments and opinion.
> 
> Thank you.
> 
> Brian
> 
> 
> ===============================================================
> Brian S. Park  brian at corelis.com  (562) 926-6727 x143
> ---------------------------------------------------------------
> Everything we do helps our customers get to market
> FASTER with HIGHER quality and LOWER cost 
> ===============================================================
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU 
> Hosting Partner. Refer Dedicated Servers. We Manage Them. You 
> Get 10% Monthly Commission! INetU Dedicated Managed Hosting 
> http://www.inetu.net/partner/index.php
> 
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 

[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.

[Robert Schwebel]

On Tue, Jun 24, 2003 at 02:20:00PM -0700, Brian S. Park wrote:
> It could be integrated to our PC side application which can upload it
> the first time it connects to the target. Integrating TFTP server to
> our application would require it to start before the user powering up
> the target.

It might be a good idea that you explain how your users handle your
board; in which cases is it important that the board is powered on
_before_ the upload program was started? 

> With TFTP client approach, I need to set the serverip environmental 
> variable to IP of PC with the TFTP server. If I move the controller to 
> another room, and found out that the PC with TFTP server is not powered up, 
> I need to either change the serverip variable to the new PC I intended to 
> use or go back to the other room and power up the PC. :)

Or you can use DHCP/BOOTP to find your host pc (a dhcp server could be
included in the upload program as well). Ok - this might find your
company's DHCP server instead of your upload program, but that could
surely be fixed with some special DHCP option and a small u-boot shell
script which checks for the "correct" magick string. 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.

[Brian S. Park]

>It might be a good idea that you explain how your users handle your
>board; in which cases is it important that the board is powered on
>_before_ the upload program was started?

There is no important technical reason. It's just one more thing for the 
user to remember.


> > With TFTP client approach, I need to set the serverip environmental
> > variable to IP of PC with the TFTP server. If I move the controller to
> > another room, and found out that the PC with TFTP server is not powered 
> up,
> > I need to either change the serverip variable to the new PC I intended to
> > use or go back to the other room and power up the PC. :)
>
>Or you can use DHCP/BOOTP to find your host pc (a dhcp server could be
>included in the upload program as well). Ok - this might find your
>company's DHCP server instead of your upload program, but that could
>surely be fixed with some special DHCP option and a small u-boot shell
>script which checks for the "correct" magick string.

The idea is to make it as simple as possible for the users to set it up using
as little flash memory as possible.
I still think things could be simpler if boot loader can act as the server
and receive the OS image.

As to whether it's worth the trouble to implement such feature, I no not have
an opinion one way or the other since I'm not familiar with 
bootloader/network stuff.

Maybe when I become more familiar with u-boot & tftp protocol, I'll 
implement such feature
as my contribution to open source community. :)

Thanks to every one for the comments and opinions.

Brian


===============================================================
Brian S. Park  brian at corelis.com  (562) 926-6727 x143
---------------------------------------------------------------
Everything we do helps our customers get to market
FASTER with HIGHER quality and LOWER cost
===============================================================

[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.

[Wells, Charles]

Wolfgang,

Sorry for the delay, but I've been unexpectedly out of the office.  You make
some good points that I'd like to address.

>> 1. You are assuming that Brian's customers are at least as sophisticated
as
>> Abatron customers.  Brian's original statement leads me to believe this
is
>> not so.
>
>Indeed I think they are. Typing "tftpsrv" (or which other ways  there
>are to start the supplied application "tftpsrv.exe") is IMHO no a big
>challenge. And this is all you need to do.

Typing "tftpd" or whatever is not what I'd worry about.  Many systems are
installed and operated these days by folks with very limited technical
skills.  The problem I see is that 6 months after installation the
customer's MIS group makes network changes and the target device stops
working.  At this point, the operator needs to diagnose the problem and
determine what needs to be done.  No matter how trivial that act of typing
"tftpd" is, the person diagnosing the problem must first determine that the
trivial act is required.  While this diagnosis task is not hard for
programmers and consultants, it may be quite a challenge for the customer.

Now, some might say that the appropriate thing to do in such a situation is
to call MIS or the help desk.  My experience with MIS departments is they do
a good job of networking together Windows (or Solaris or Linux) boxes and
printers, but they want nothing to do with other TCP/IP devices.  The
customer is on their own.  I've seen this problem kill a project.  Remember,
the customer doesn't have to be embarrassed by the triviality of typing
"tftpd", they can just switch to a competitor's product.  They don't even
have to give your sales person a reason.

>> U-boot supports the target-as-client method of downloading but does not
>> support the target-as-server method.  I've used both methods a number of
>> times over the years and both have their advantages and disadvantages.
Your
>
>Can you please explain the advantages of the  boot  loader  providing
>server function?

It is a unavoidable fact of standard client/server pairs that the client has
a-priori knowledge about the server, the server has no a-priori knowledge
about the client.  If the target is a multicast server, there is NO NETWORK
SETUP AT ALL.  In the case of target-as-client, the client must know at
least the server's IP address (or DNS name).  That knowledge increases the
amount of setup.  Further, during the course of maintenance and expansion,
this information may become invalid.  You can make the required information
as small as possible, but you have to go through the analysis to test
whether this is acceptable to the customer.  My experience is that making
the amount of information used by the client (that can be unilaterally
changed by the MIS department) nil is the best approach.

The key to this is that my download server uses standard UDP over multicast
IP.  This has a number of advantages, including the fact that the download
server is receive-only and has no traditional TCP/IP stack (I won't go into
error control here, but that's taken care of as well).

Another advantage is that this technique can be used very early in the
manufacturing process to load the software (via UDP/IP) that programs the
MAC address (as well as model and serial numbers) into EEPROM.  When this
software is loaded, the target has no IP address or MAC address.  I can even
load many units in parallel on a test rack.

>U-Boot is a Boot Loader, not an OS.
>
>U-Boot shall be powerful to use, yet simple  in  design  to  make  it
>easily portable to new boards and architectures.
>
>This means U-Boot will be strictly single-tasking; it  will  not  use
>virtual  memory; it will use polling drivers (versus interrupt driven
>ones) whenever possible.
>
>U-Boot shall use standard protocols and interfaces whenever possible.

My server-loader meets all of these criteria, except the "powerful to use"
one.  It is not only extremely simple in design but also extremely simple in
implementation (which explains its small size of less than 8k).  It only
does two things, it loads programs in to memory and jumps to that program.
Occum's razor seemed appropriate since we have to strongly avoid updating
the boot code in the field.  Note that my boot code does have a FLASH boot
component that I haven't discussed here.

<> Standard Protocols and Custom Clients

My loader uses standard protocols as well.  It uses UDP over multicast IP.
Since I wanted a passive, receive-only server loader, I rejected TFTP early
because it wouldn't solve all my problems.

You mentioned in a subsequent email to Brian that he would have to write a
custom client.  You are quite correct.  My version of this client is written
as a command-line tool that does the following: 0) create a standard
multicast UDP socket and bind it appropriately, 1) open a file for binary
read, 2) read 1k blocks from the file, 3) prefix a small payload header, and
4) send the block to the socket.  Since we already had a socket library,
this task took an afternoon and the result was just 5-6 pages of C code.
This client hasn't been maintained after it's original creation and testing
(although it has been extended with new features; e.g., alternate binary
file formats, etc.).

It's one thing to say that you have found a boot loader (u-boot) and an
operating system (Linux) for free off the web and made them work.  In fact,
this is very well received by many managers.  But, I do have to develop my
own embedded-target and host applications.  For this I need programmers.
The overhead of writing this custom client program (using standard
protocols) was tiny compared to the entire project.  Further, we were able
to code this functionality into the host-based Visual Basic client used by
our field reps. with very little effort.  This is, I believe one of the
features that Brian is thinking about.

>I'm sorry, but IMHO there is no advantage running  a  server  in  the
>boot loader.

I'm sorry, but IMHO YHO is wrong.  :-)

>Perhaps you might be so kind as to elucidate.

Perhaps I have.

<> Summary

Ultimately, I believe the difference in the two approaches is in where the
control is.  I prefer to view the host as "in control" and the target as
subservient.  It has simply been my experience, over many projects, that
this way works out better.

This whole discussion may not be appropriate on this list.  Since I did this
work as a paid employee, I must honor my employeer's policies that prevent
sharing source code.  I can, however, freely discuss the details and answer
questions  If Brian or anyone else cares to find out more about this
technique, they are welcome to contact me directly.

Regards,
Charlie

Charles.Wells at nielsenmedia.com
c.wells at ieee.org

[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.

[Wolfgang Denk]

Dear Charles,

in message <DF2B720CF774D21189EE00805FA7FA220B909B75@nmrusdunsx3.nielsenmedia.com> you wrote:
> 
> It is a unavoidable fact of standard client/server pairs that the client has
> a-priori knowledge about the server, the server has no a-priori knowledge
> about the client.  If the target is a multicast server, there is NO NETWORK

This is wrong. The only a-priori knowledge needed by  the  client  to
ruin  any of the standard network boot protocols (like BOOTP or DHCP)
is it's own MAC address, which should have  been  programmed  by  the
manufacturer and which will never need to be changed.

> SETUP AT ALL.  In the case of target-as-client, the client must know at
> least the server's IP address (or DNS name).  That knowledge increases the
> amount of setup.  Further, during the course of maintenance and expansion,

I disagree. For standard network boot protocols no such knowl;edge is
required.

> whether this is acceptable to the customer.  My experience is that making
> the amount of information used by the client (that can be unilaterally
> changed by the MIS department) nil is the best approach.

The use BOOTP or DHCP.

> The key to this is that my download server uses standard UDP over multicast
> IP.  This has a number of advantages, including the fact that the download

You mention "standard UDP" - but are you using  a  standard  download
protocol?

> Another advantage is that this technique can be used very early in the
> manufacturing process to load the software (via UDP/IP) that programs the
> MAC address (as well as model and serial numbers) into EEPROM.  When this
> software is loaded, the target has no IP address or MAC address.  I can even
> load many units in parallel on a test rack.

OK, this  obviously  means  that  you  are  NOT  using  any  standard
protocols. I understand that such a solution might make sense for you
(although  I think that error handling is not easy to implement), but
IMHO there are already more than  enough  proprietary  protocols  and
devices  that cannot talk to each other just because the manufacturer
tried to be especially clever.

As I wrote before:

> >U-Boot shall use standard protocols and interfaces whenever possible.
> 
> My server-loader meets all of these criteria, except the "powerful to use"

Which is the standard protocol you are using, then? [Note: UDP  alone
is _not_ a download protocol.]

> My loader uses standard protocols as well.  It uses UDP over multicast IP.

C'me on. UDP is _NOT_ a file transfer protocol.

> You mentioned in a subsequent email to Brian that he would have to write a
> custom client.  You are quite correct.  My version of this client is written
> as a command-line tool that does the following: 0) create a standard
> multicast UDP socket and bind it appropriately, 1) open a file for binary
> read, 2) read 1k blocks from the file, 3) prefix a small payload header, and
> 4) send the block to the socket.  Since we already had a socket library,
> this task took an afternoon and the result was just 5-6 pages of C code.

This is OK, and there is  no  reason  for  you  not  to  use  such  a
proprietary approach.

> This client hasn't been maintained after it's original creation and testing
> (although it has been extended with new features; e.g., alternate binary
> file formats, etc.).

This requirement can be also met with U-Boot using  widely  available
standard protocols (like DHCP or BOOTP).

> >I'm sorry, but IMHO there is no advantage running  a  server  in  the
> >boot loader.
> 
> I'm sorry, but IMHO YHO is wrong.  :-)

Well, YMMV ;-)

> Ultimately, I believe the difference in the two approaches is in where the
> control is.  I prefer to view the host as "in control" and the target as
> subservient.  It has simply been my experience, over many projects, that
> this way works out better.

The only argument I want to reopeart here is that  in  my  experience
the use of open standards is a very strong benefit for everybody, and
if  there is a solution for a problem based on standard protocols and
interfaces I do not want to use or invent some  proprietary  solution
instead.

> This whole discussion may not be appropriate on this list.  Since I did this

I don't think so. It may be beneficial to many  people,  one  way  or
another.  To  be  honest,  the idea of running a server on the target
never even crossed my mind before. It  is  always  a  good  thing  to
discuss  alternative  solutions  -  and  if  it's only to come to the
conclusion that everything was done correctly :-)

> work as a paid employee, I must honor my employeer's policies that prevent
> sharing source code.  I can, however, freely discuss the details and answer
> questions  If Brian or anyone else cares to find out more about this
> technique, they are welcome to contact me directly.

Thanks!


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Writing a book is like washing an elephant: there's no good place  to
begin  or  end,  and  it's  hard to keep track of what you've already
covered.

[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.

[Wolfgang Denk]

In message <20030627142446.9EC7FC592A@atlas.denx.de> I wrote:
> 
> This is wrong. The only a-priori knowledge needed by  the  client  to
> ruin  any of the standard network boot protocols (like BOOTP or DHCP)
> is it's own MAC address, which should have  been  programmed  by  the
> manufacturer and which will never need to be changed.

Nice typo, but of course I meant "...to _run_  any  of  the  standard
network boot protocols...".



Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I have been over into the future, and it works.
                - Lincoln Steffens in _Letters_ (1938) vol. 1, p. 463

[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.

[mvincent at systemem.com]

Hello Wolfgang, Charles. Sorry to jump in uninvited. I have been following 
this list for a while and this topic is particularly important to me so I 
thought I would add my 2 Pfennig's worth...

> > This whole discussion may not be appropriate on this list.

> I don't think so. It may be beneficial to many  people,  one  way  or 
> another.  To  be  honest,  the idea of running a server on the target 
> never even crossed my mind before. It  is  always  a  good  thing  to 
> discuss  alternative  solutions  -  and  if  it's only to come to the 
> conclusion that everything was done correctly :-)

Background: I designed a MPC8250 board with both WiFi and GPRS onboard (plus 
serial, Ethernet and other goodies) and I am currently working on the 
bootloader and OS ports. When I mentionned that I wanted to use U-Boot, I was 
asked if it would be possible to upload new firmware/config/etc over the 
wireless links. The expectation is that whoever is handling this update wants 
to "push" it, ie. initiate it remotely (which is easier in our case
since the 
hardware is meant to be installed in vehicles). 

My answer was that wireless links should be established only by the OS (Linux 
kernel and utilities in this case), not by the KISS bootloader. But more 
importantly, once you have a full OS running with spare memory and CPU cycles, 
it should not be a problem to run the standard servers (telnet, ftp...) that 
let you remotely manage anything that's on the filesystem, right? If security 
is a concern (it is for us), you can again rely on open standards such as SSH 
to secure your links.

My point is I like Wolfgang's approach: keep the U-Boot simple (uhmmmm, a bit 
late for that! ;^) ), using standard protocols only, and primarily make it 
serve the developpers well. Of course, some people have special requirements 
(not enough flash...) that force them to boot from Ethernet, others may have a 
problem with BOOTP/DHCP, and some may simply have a different perspective. 
It's an open discussion.

For the record, I have done my fair share of proprietary protocols, 
bootloaders and download utilities, and I don't care if I never have 
the "chance" to do another one!

Heartfelt THANK YOU to all the contributors to U-Boot!

Best regards,
 
Marc Vincent


ps: I apologize if you received this twice. My first attempt bounced 
on SF and I also goofed on the CC. I hate my mail setup...