[U-Boot] How to download image to U-Boot
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:
1) Telnet to the board and download an image (binary or S-Record) using the x/y-modem protocol over the telnet connection.
2) Download a binary image directly using a TCP connection to a dedicated port.
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.
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 into a serial console (also not going to be acceptible to customers). The requirement is to update the image using just the network and a user-space application that doesn't require any system privledges to run.
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 the customer to change the IP address of their machine (not acceptible).
Dear Grant Edwards,
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 which makes it unacceptable even for mimimum security envrionments. If you need such a szenario, then boot into a (minimal) Linux kernel, and run the update in a real OS.
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?
Alternatively, you can use NFS (but I guess you will argument that setting up a NFS server is also not acceptable).
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.
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".
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.
the customer to change the IP address of their machine (not acceptible).
Why am I not surprised that this is not acceptable, either?
Wolfgang Denk
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.
Dear Grant Edwards,
In message hdv4ns$4lk$1@ger.gmane.org you wrote:
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.
Now check who is rude and insulting.
U-Boot is a boot loader, and as such it provides a certain level of functionality. Its features are therefore limited (but still far better than available in most other boot loaders). But we definitly don't want to grow it into an operating system. There are certaing things like full network stack with authentication, encryption and who knows what else that simply have no place in a boot loader. If you need something like that (and your requirements say so), then use the appropriate tool, i. e. use an OS.
Best regards,
Wolfgang Denk
participants (2)
-
Grant Edwards -
Wolfgang Denk