On Mon, Sep 21, 2009 at 4:56 PM, Wolfgang Denk w...@denx.de wrote:
In message 4b538920909211414o3a7e9c84se0df6e1622f49a18@mail.gmail.com you wrote:
I am considering the same thing (TFTP server in U-Boot), but I believe I have a good reason for wanting it. At the same time, I don't want to waste effort if others have a better idea for how to accomplish what I need.
The big question is: why do you want to do this in U-Boot?
The primary reason was to maintain a fail-safe update procedure without requiring much more flash memory.
The main sticking point for me with using TFTP client from U-Boot is firewalls. My system will be accessed by machines inside a firewall and if I use TFTP client from U-Boot, then I must poke a hole in the firewall... however, I have no control over the firewall so that isn't possible. If the host machine connects to the U-Boot running TFTP server, then all is well.
If you really have no control over the firewall, then I seriously doubt that you will be able to use TFTP at all - no matter if it's incoming or outgoing traffic.
I intend to control U-Boot remotely using netconsole. Is there a better way to push files to U-Boot over netconsole than implementing TFTP server? It
Are you sure you get the netconsole traffic through your (uncon- trollable, as you wrote) firewall?
I see your point here. Since UDP traffic is just datagrams and there is no concept of connections, the reply messages for both TFTP and netconsole may be blocked by the firewall. Some firewalls will open a return port for UDP traffic, but it does seem that there's no guarantee. So no... I'm not sure.
By the way, the firewall I'm referring to is generic. The device will be installed into foreign networks where the only requirement is that outbound (toward the device) TCP traffic on port 80 is allowed. This is very common and can be assumed for my purposes. One of my goals is to not increase the requirements on the network / firewall configuration to facilitate updating the kernel (or to minimally increase... i.e. within the bounds of a "typical" configuration).
seems like this would be a common concern, so it seems likely that it has been solved (in some other way, since there is no TFTP server support in U-Boot).
Well, most people use an operating system to perform such complex tasks.
Several of the design alternatives do include the operating system.
To more completely address your original "big question", I am considering the following design alternatives. For the OS based designs, the updated files are all simply sent using a post to a webservice running in the OS.
1. Define redundant partitions in the flash to store the kernel, ramdisk, and device tree, overwrite the inactive partitions in the OS, and once complete, update a flag in the U-Boot env to switch the active partitions, then reboot. This requires the most flash, but there are no "special" images, therefore there is less development effort and less maintenance.
2. Define a set of "safe-mode image" partitions that can be used in the event that U-Boot detects a corrupt main image. The safe-mode image can be stripped down to support the bare minimum needed to update and therefore be smaller than the main image. It would use less flash than option 1, but require more effort to develop and maintain the special image.
3. Simply overwrite the main partitions in flash of the currently running live image and hope for the best. The only recourse in the case of failure being to go to the device (or at least somewhere on the device side of the firewall) to repair the failed update using U-Boot. This requires no additional flash partitions, but includes a non-ideal user experience (in the failure case) and it requires implementing the host side of the updating twice in two different ways, which means increased development effort, complexity, and maintenance.
4. Utilize U-Boot directly to perform all updates so that every update is essentially in "recovery mode". U-Boot is never updated so it will always be valid and able to replace firmware, regardless of the state of the device otherwise. This, like option 3, requires no additional flash partitions, but reduces complexity by having a single update / recovery procedure. This option, however, has the awful user experience that the user must always go to the device (or to the device side of the firewall) to update it.
Naturally, if the user happens to have control of the firewall (or is not using one), then they can avoid "going anywhere" with option 4 (and option 3, should disaster strike) and the user experience is great. For the purpose of the design, however, I assume the typical firewall configuration stated above.
My goal is to attempt to salvage the benefits of option 4 while addressing the primary shortcoming.
Are there other designs that you have in mind that may more completely or elegantly address the problem?
Thanks, -Joe