[U-Boot] TFTP Server in U-Boot / Pushing files to U-Boot

[Joe Hershberger]

On Mon, Sep 21, 2009 at 4:56 PM, Wolfgang Denk <w... at denx.de> wrote:
>
> In message <4b538920909211414o3a7e9c84se0df6e1622f49a18 at 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