Previously, when the `proto://path` format of `bootfile` was used, the
transformed argument sent to either tftp or wget would also be stored
in `bootfile` overriding the original value set by the user.
If the first boot attempt failed for some reason, the protocol
information was stripped from `bootfile` and the second attempt would
then default to TFTP, even if the user had originally specified
`http://...`.
Therefore, store the transformed value in a separate variable.
For some reason, setexpr's parsing of regex escapes changes when this
mode is used, so we need double backslashes to fetch match groups
instead of 1. Yikes.
Fixes#724
This puts the responsibility on the user to set the appropriate static
parameters. On the plus side, we avoid requiring redundant information
when the `proto://path` format is used in `bootfile`
When a device is in developer mode, drop the user directly into the
shell instead of having to go via the bootmenu, since this is usually
what you want in that case. Emit a note about how to access the menu,
for the rare cases when that is needed.
For systems with multiple paths to the network, different situations
may call for different paths to be used. Therefore, allow the user to
override the active interface via the environment on the auxiliary
partition.
The default (defined the bootloader's device tree) is still used in
cases when nothing else is specified in the environment.
Since a user has access to the shell in developer mode, we might as
well allow booting through the standard boot scripts as well. This
means that a product with a bootloader only accepting images signed by
Company A can now be configured to netboot a regular developer image
without any special user interaction.
If we receive an option 67 (bootfile) matching http://IP/rootfs.itb,
use U-Boot's wget implementation to download the file. The web server
must listen on port 80. tftp:// is also supported.
Without a protocol prefix, assume that the bootfile should be fetched
using TFTP from ${serverip}.
Generate a boot menu, accessible with C-c during a short window, where
a user can interactively select a custom boot source and/or trigger a
factory reset of the device.
With this in place, we should always be able to unbrick a device, as
the image can be fed over the network, and local data can be ignored
by opting in to a factory reset.
If the bootloader knows about a factory-reset or dev-mode button, use
them to allow stopping the boot process, and to signal the
factory-reset condition to infix.
The kernel's mounting of the rootfs may race against the underlying
device being probed - especially for media like MMC cards and USB
sticks.
Therefore, tell the kernel to wait for the root device to show up.
- Adapt boot scripts to exepect the split FIT header/SquashFS image
layout.
- Make sure that we can boot from any kind of block device (most
importantly virtio for GNS3).
- Rename net -> dhcp as we might have more kinds of netboots in the
future (http).
Ensure that whenever U-Boot is built:
- The chosen signing key and is converted to the expected format and
installed in the build tree.
- Infix's environment extensions are installed in the build tree
