[U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.
wd at denx.de
Tue Jun 24 20:21:01 CEST 2003
in message <DF2B720CF774D21189EE00805FA7FA220B909B67 at 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
> 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
> 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
> 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
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
I'm sorry, but IMHO there is no advantage running a server in the
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.]
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
More information about the U-Boot