On 2009-11-17, Wolfgang Denk <w...@denx.de> wrote: > In message <hdurn4$2b...@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. -- Grant Edwards grante Yow! Am I SHOPLIFTING? at visi.com _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot