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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[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





Reply | Threaded
Open this post in threaded view
|

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

Wolfgang Denk
Dear Charles,

in message <DF2B720CF774D21189EE00805FA7FA220B909B75 at 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.



Reply | Threaded
Open this post in threaded view
|

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

Wolfgang Denk
In message <20030627142446.9EC7FC592A at 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