On 2009-11-17, Wolfgang Denk wd@denx.de wrote:
In message hdurn4$2bt$1@ger.gmane.org you wrote:
I've read through the U-Boot manual and FAQ, but I still haven't figured out how one downloads via the network an image to a board running U-Boot. Previous projects have used RedBoot, and it provided a couple different mechanisms:
There are many different ways in U-Boot - over serial line, over Ethernet using TFTP or NFS, from a number of different storage devices like MMC/SDCard, USB Mass Storage Devices, harddisks, ...
Both of these methods would work through firewalls and WAN connections (even through satellite links), and could easily be automated in an "updater" utility that is then provided to customers to update images in flash.
You don't have much of authentication in such an envrionment
True.
which makes it unacceptable even for mimimum security envrionments.
False.
Almost all of our customers find it acceptible and it has never proven to be a problem in the 10 years we've been shipping product. For the few customers who do use the products on an usecured network, the update mechanisms can be secured.
If you need such a szenario, then boot into a (minimal) Linux kernel, and run the update in a real OS.
So the answer is U-Boot doesn't support the sort of update mechanism I'm talking about. That's fine. There's no reason to get rude and insulting about it.
I can't seem to find out how one accomplishes the same task using U-Boot. The only method I can figure out involve setting up a TFTP server (which is not going to be acceptible to customers), and then typing a series of commands while plugging
Why would this not be acceptable?
We can't require that the box is physically accessible or that the customer have a serial port.
Alternatively, you can use NFS (but I guess you will argument that setting up a NFS server is also not acceptable).
I'm afraid it isn't.
into a serial console (also not going to be acceptible to customers). The requirement is to update the image using just
Ah, also not acceptable.
I'm sorry, what isn't acceptible?
Of course you can kill any system by just excluding all available features as "not acceptable" - without giuving reasons for this, of course. Note that this works fine for many, many others, so you might want to ask yourself if your requirements are "acceptable".
My opinions have nothing to do with it, and they're not my requirements. I'm perfectly happy setting up a TFTP server and using a serial console. Our customers, however, are neither willing or able to up special servers in order to update the firmware in our products.
I found mention of netconsole, but I don't see how it's useful since you have to know a-priori the address of the machine from which you want to use it. It would seem that you have to force
You don't have to. You can use broadcasts.
That's not going to work through firewalls.
the customer to change the IP address of their machine (not acceptible).
Why am I not surprised that this is not acceptable, either?
Because it's not something our customers are willing to do.
I take it that your position is that everying that U-Boot doesn't support is worthless and stupid as are people who desire or currently use such features.
Thanks.