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