Re: [U-Boot-Users] uploading OS over network instead of u-boot do wnloading it from a server.
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@nielsenmedia.com
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.
- 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.
- 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
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@corelis.com (562) 926-6727 x143 --------------------------------------------------------------- Everything we do helps our customers get to market FASTER with HIGHER quality and LOWER cost ===============================================================
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.
- 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 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
Dear Wolfgang,
The advantage I see is this.
- 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.
- 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@corelis.com (562) 926-6727 x143 --------------------------------------------------------------- Everything we do helps our customers get to market FASTER with HIGHER quality and LOWER cost ===============================================================
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
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@corelis.com (562) 926-6727 x143 --------------------------------------------------------------- Everything we do helps our customers get to market FASTER with HIGHER quality and LOWER cost ===============================================================
participants (4)
-
Brian S. Park -
Robert Schwebel -
Wells, Charles -
Wolfgang Denk