All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian S. Park <brian@corelis.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.
Date: Tue, 24 Jun 2003 12:16:09 -0700	[thread overview]
Message-ID: <5.1.1.6.2.20030624115306.0131de20@corelis.com> (raw)
In-Reply-To: <20030624182106.17373C5FD7@atlas.denx.de>

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
===============================================================

  reply	other threads:[~2003-06-24 19:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-24 13:45 [U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server Wells, Charles
2003-06-24 18:21 ` Wolfgang Denk
2003-06-24 19:16   ` Brian S. Park [this message]
2003-06-24 20:33     ` Wolfgang Denk
2003-06-24 21:20       ` Brian S. Park
2003-06-25  5:16         ` Robert Schwebel
2003-06-25 19:03           ` Brian S. Park
  -- strict thread matches above, loose matches on Subject: below --
2003-06-24 21:38 Woodruff, Richard
2003-06-27 13:25 Wells, Charles
2003-06-27 14:24 ` Wolfgang Denk
2003-06-27 14:51   ` Wolfgang Denk
2003-06-27 21:01 mvincent at systemem.com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5.1.1.6.2.20030624115306.0131de20@corelis.com \
    --to=brian@corelis.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.