The U-Boot env file is generated by
mkenvimage, which prefixes the variable data with a 4-byte CRC32 by default.
ixpreboot.sh previously imported it with `env import -b` as per uboot docs(-b assume binary format (’0’ separated, “00” terminated).),
which treats the buffer as raw binary and does not strip the CRC.
As a result the first variable's name is parsed a part of CRC.
Later variables import correctly because by then the parser is past the CRC.
Switching to `env import -c` as per uboot docs (-c assume checksum protected environment format.)
makes U-Boot validate and strip the CRC before parsing, so the first variable imports under its real name.
Tested on:
- QEMU
Signed-off-by: Ejub Sabic <ejub1946@outlook.com>
Add board support for the BananaPi BPI-R4 router board, based on the
MediaTek MT7988A (Filogic 880) SoC with quad-core Cortex-A73 CPU.
The BPI-R4 is the successor to the BPI-R3 but uses entirely different
silicon: the internal switch runs at 2.5 GbE per port, the two SFP+
uplinks use native USXGMII at up to 10 Gbps, and WiFi is provided by
a MediaTek MT7996E PCIe module supporting tri-band WiFi 7 (2.4/5/6 GHz).
Two board variants, BPI-R4-2g5 and BPI-R4P, replace one SFP+ cage with
a 2.5 GbE RJ45 port (using the MT7988A internal 2.5G PHY); the R4P adds
an optional PoE daughterboard on that port. Both use the upstream
mt7988a-bananapi-bpi-r4-2g5 device tree.
Interfaces:
- Standard R4: eth1 (gmac1/sfp2 LAN cage) → sfp2, eth2 (gmac2/sfp1 WAN cage) → sfp1
- R4-2g5/R4P: eth1 (2.5G PHY) → wan, eth2 (gmac2/sfp1 WAN cage) → sfp1
Factory reset / WPS button (GPIO14, active-low): detected by U-Boot at
boot for factory reset; reused by Linux as KEY_WPS_BUTTON at runtime.
eMMC install note: the MT7988A eMMC (pins 38-49) and SD card (pins 32-37)
use separate physical pads so there is no electrical bus sharing, unlike
some BPi-R3 configurations. However, a single MMC controller
(mmc@11230000) handles both, so only one is active per boot session.
The eMMC install procedure therefore still requires an intermediate SPI
NAND bootloader step until a Linux-side install path is tested.
SD card build (bpi_r4_sd_boot_defconfig) now uses the new
mt7988a_bpir4_sd U-Boot defconfig with cap-sd-highspeed enabled,
giving 50 MHz SD transfers instead of the previous 25 MHz legacy mode.
Also adds MT7988/MT7996 firmware support to the buildroot linux-firmware
package, for 2.5 GbE port PHY and WiFi7 extension board, and updates the
aarch64_defconfig, aarch64_minimal_defconfig, the arch README, CI
boot/image workflows, mkimage.sh, and the ChangeLog.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
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
