These were found by running:
comm -12 <(sort target/linux/generic/config-6.18) \
<(sort target/linux/armsr/config-6.18)
A similar process has been run between armsr/config-6.18
and armsr/armv8/config-6.18, though I have not pruned
the armv8 as much. Once the main branch switches armsr
to 6.18 we can do a more aggressive deduplication.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Link: https://github.com/openwrt/openwrt/pull/21433
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The armv8 configuration has more features enabled compared to armv7,
as armv8 is intended to run on a selection of real hardware, while
armsr/armv7 almost always runs only in QEMU.
Some kmod dependency issues were appearing on armv7 builds which
did not appear elsewhere. To minimise these issues, we will
move the framebuffer feature set to the top level of the target.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Link: https://github.com/openwrt/openwrt/pull/21433
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Set the configuration options that were prompted for
by the new kernel.
ARCH_CIX (Cixtech) has been enabled as their SoCs
have appeared in high end arm64 hardware.
There are also new Arm64 SoCs from Renesas and
Allwinner that should be bootable with the right
firmware stack.
There are minimal changes in the armv7 config,
only CONFIG_PAGE_BLOCK_MAX_ORDER has a unique
setting.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Link: https://github.com/openwrt/openwrt/pull/21433
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
NXP has introduced an evolved version of the LS1028A ENETC
IP in their new i.MX94/5 family. While the two devices
share a common lineage, they are different enough that
they cannot be implemented in the same driver.
Hence some functions from the LS1028A ENETC driver have been
split into a 'library'.
When a kmod package for the new ENETC (nxp-enetc4) is introduced then
the packaging for the common library will need to be reworked.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Link: https://github.com/openwrt/openwrt/pull/21433
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
In target/linux/generic/backport-6.18/ we have backported
bitfield changes from 6.19.
This change to drivers/soc/renesas/rz-sysc.c was part
of the same patch series and is needed to resolve
a duplicate definition compile error.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Link: https://github.com/openwrt/openwrt/pull/21433
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
In OpenWrt we have backported changes to bitfield.h
from kernel 6.19.
A backport fix, 9966c8cc987e ("irqchip/renesas-rzv2h:
Prevent TINT spurious interrupt during resume") into
linux-stable/linux-6.18.y modified irq-renesas-rzv2h.c
to include it's own field_get, which does not exist
in the 6.18 branch, causing a compile error.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Link: https://github.com/openwrt/openwrt/pull/21433
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The memory mapped TPM interface (TIS) can be used for
emulated or virtualized TPM instances with QEMU and
a simulation package like swtpm.
On QEMU the device will appear in the device tree
with a "tcg,tpm-tis-mmio" compatible.
For example:
qemu-system-aarch64 -machine virt -cpu max \
-bios u-boot.bin \
-nographic \
.... \
-hda openwrt-armsr-armv8-combined-efi.img \
-chardev socket,id=chrtpm,path=/tmp/mytpm/swtpm-sock \
-tpmdev emulator,id=tpm0,chardev=chrtpm \
-device tpm-tis-device,tpmdev=tpm0
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Link: https://github.com/openwrt/openwrt/pull/19188
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The kernel CONFIG_ARM_PMUV3 option was not being presented
for 6.12 kernels with armsr/armv7.
As the minimum kernel version is now 6.6, there is no need
to limit this to specific kernel versions anymore.
This caused a kernel compile stoppage when attempting to
compile the 'perf' tool for armsr/armv7.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Link: https://github.com/openwrt/openwrt/pull/18849
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This includes both new additions to 6.12
and an attempted "refresh" of the config
to remove duplicates from target/generic/config-6.12.
(The OpenWrt kernel_makeoldconfig does not
work well with the armv8 subtarget for reasons
I am yet to determine, so that file has been
pruned manually)
Most new options are in armv8, where the
KConfig relates to a platform that will likely
be armsr compatible (like the i.MX91/93/95),
it has been enabled.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Link: https://github.com/openwrt/openwrt/pull/18849
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
We have modified the kernel to setup all "default" consoles,
including serial ports and framebuffers/screens, providing
no console= argument is supplied on the kernel command line.
Adding 'console=tty1' caused the 'default' serial port on
device tree systems to break, as the kernel would not carry
over the settings (like baud rate) from the bootloader.
The system administrator can still force the use of a
specific console by adding their own console= arguments.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Fixes: c099523d66 ("armsr: use console=tty1 to make
console more readily available")
Link: https://github.com/openwrt/openwrt/pull/17012
Signed-off-by: Robert Marko <robimarko@gmail.com>
A previous change added 'console=tty1' to the default kernel command
line on armsr, in order to ensure the framebuffer console is enabled
on systems capable of graphics output.
Unfortunately, this change broke boards that used device tree
(DT) firmware with serial consoles, as the serial console
specified by the system firmware (stdout-path) was no longer
setup by the kernel.
A bit of probing determined that the SPCR (serial port console
direction table) on ACPI systems was preventing Linux from setting
up a default framebuffer console on these systems (which is why
console=tty1 was added).
(The affected ACPI systems are usually VMs using QEMU's
'virt' machine and EDK2 firmware. The firmware on these systems
does not remove the SPCR when a screen is present)
So to ensure all possible systems are setup correctly, we modify
the kernel so all "default" console types (serial and screen)
are setup when no console= arguments are specified on the kernel
command line.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Fixes: c099523d66 ("use console=tty1 to make console more
readily available")
Link: https://github.com/openwrt/openwrt/pull/17012
Signed-off-by: Robert Marko <robimarko@gmail.com>
This U-Boot version is used to generate a 'reference'
U-Boot binary for QEMU's 'virt' machine on both
armv7 and armv8.
It has not been updated since EFI support was merged
into the then-armvirt target, so we should bring it up
to the latest version.
The 'mkeficapsule' tool is disabled due to a host-side
dependency on GnuTLS.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Link: https://github.com/openwrt/openwrt/pull/18862
Signed-off-by: Robert Marko <robimarko@gmail.com>
luci-app-attendedsysupgrade expects images to be named
'combined-efi' when the system is using EFI images.
This came about as x86 has 'combined' images for legacy
(BIOS) boot and 'combined-efi' for EFI systems.
armsr images were originally named 'combined' only
as there was no 'legacy' image type.
To avoid special handling in the attendedsysupgrade
code, name EFI images consistent with other targets.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Link: https://github.com/openwrt/luci/pull/6430
Link: https://github.com/openwrt/openwrt/pull/12963
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This adds two more common PHY brands to the image.
Realtek is used on the Google Coral "Phanbell" board (i.MX8MQ).
SMSC has been used on various Raspberry Pi boards.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Support for 'fsl,imx8mq-usb-phy' is needed for USB to work
on NXP i.MX8MQ and i.MX8MP platforms.
Tested with a Google Coral "Phanbell" board.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
This was discovered when trying to run OpenWrt on Hetzner Cloud's
Arm-based instances.
Hetzner uses QEMU/KVM with virtio-gpu as the main display device,
together with an ACPI firmware. This was not displaying a console
previously.
This setup can be emulated by qemu using options below:
qemu-system-aarch64 \
-machine virt \
-bios QEMU_EFI.fd \
-device virtio-gpu \
-usb \
-device qemu-xhci,id=xhci \
-device usb-tablet,bus=xhci.0 \
-device usb-kbd,bus=xhci.0 \
-vnc :0
Signed-off-by: Mathew McBride <matt@traverse.com.au>
This PMU (performance management unit) related kernel option
can appear under certain kernel configurations (such as
KVM being enabled).
Disable them, as we do with other PMU-related options.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Two hardware-specific PMU (performance management unit) related
options can appear under certain circumstances.
Disable them, as we do with other PMU-related options.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Support for Renesas Arm families was added in commit 1ff4f4df23
("armsr: armv8: enable CONFIG_ARCH_RENESAS"), but this did not
enable the console/tty hardware for these SoCs, which is derived
from the SuperH family (CONFIG_SERIAL_SH_SCI).
Link: https://github.com/openwrt/openwrt/issues/15284
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Due to a change in kernel 6.2, the GPIO numbers on certain
architectures (including arm64) have changed. This script
will update any defined GPIO switches to the new numbering.
See https://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042448.html
for more information.
In the future, the GPIO switch mechanism will likely be
replaced with something using libgpiod.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
A change in kernel 6.2[1] caused the base numbers of GPIOs to
change significantly on some architectures like aarch64.
We have to number our GPIOs accordingly.
Ideally the board.d scripts should look through sysfs
to find the basenum (like cat "/sys/devices/platform/soc/2000000.i2c/
i2c-0/0-0076/gpio/gpiochip640/base"), but the problem is
that this occurs before modules are loaded, meaning I2C and other
runtime devices may be missing.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
[1] https://lore.kernel.org/lkml/cover.1662116601.git.christophe.leroy@csgroup.eu/T/
Introduce new configuration options prompted by 6.6 (relative to 6.1).
The kernel arm64 defconfig is used as guide for 'core' options, while
video/camera/other media drivers are turned off by default.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
vfat support is needed to mount the EFI System Partition (ESP)
during sysupgrade. If it is not available, the sysupgrade process
will not complete
Signed-off-by: Mathew McBride <matt@traverse.com.au>
These suboptions (PLATFORM, FSL_MC and MLX5_VFIO_PCI)
may be prompted for when VFIO is enabled, regardless of
architecture.
These are not related to the main vfio use case
(passthrough of PCIe devices)
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Arm platforms with the right hardware blocks (such as
GICv3.0+ interrupt controller and SMMU/IOMMU) are
able to use vfio-pci to pass through PCI devices
to a VM.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
The vfio module only exposes the enable_unsafe_noiommu_mode parameter
if CONFIG_VFIO_NOIOMMU is enabled. When it isn't, the module
will complain about an unknown parameter:
vfio: unknown parameter 'enable_unsafe_noiommu_mode' ignored
As CONFIG_VFIO_NOIOMMU is disabled by the module package,
we can remove the module loading parameter.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
vhost-net is used to accelerate traffic to virtualisation
guests that use the virtio-net network card in QEMU.
Generally it is invoked by specifying "vhost=on" to a
QEMU -netdev device:
qemu-system-aarch64 -nographic -M virt -cpu host \
--enable-kvm -bios u-boot.bin -smp 1 -m 2048 \
-drive file=openwrt-armsr-armv8.img,format=raw,index=0,media=disk \
-device "virtio-net,netdev=landev,disable-legacy=off,disable-modern=off" \
-netdev "tap,id=landev,helper=/usr/lib/qemu-bridge-helper --br=br-lan,vhost=on"
Signed-off-by: Mathew McBride <matt@traverse.com.au>
The kernel FSL_ENETC_QOS option is only a compile time
option, it does not result in a separate module being built.
Set it to 'y' to resolve a warning from the kernel compile:
.config:2654:warning: symbol value 'm' invalid for FSL_ENETC_QOS
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Fixes: c3151b6f04 ("armvirt: 64: add support for other SystemReady-compatible vendors")
When comparing the generated OpenWrt .config to the Linux arm64
defconfig, I noticed these SATA controllers were not included.
As they may be used as a boot drive, they should be built into
the kernel.
CONFIG_SATA_MVEBU is for Marvell platforms.
CONFIG_SATA_QORIQ is for NXP Layerscape.
CONFIG_SATA_SIL24 is for Arm's Juno development board, see Linux
kernel commit d7c38ff1cd86 ("arm64: defconfig: Add Juno SATA
controller").
Signed-off-by: Mathew McBride <matt@traverse.com.au>
This MDIO driver was already being built, but not installed due
to being selected by the ThunderX Ethernet driver.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
The initial armv8 module incorrectly labelled the Thunder(v1) as
supporting the ThunderX2, when they have different drivers.
Add kmod-octeon-tx2 to support the newer devices.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
This turns on various PCI related options which are enabled
in the Linux kernel arch/arm64/configs/defconfig but not
yet in the OpenWrt config.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
These are used by common Broadcom SoC's like
the BCM2711 (RPi4) and iProc network processor.
Tested on the RPi4B using the Raspberry Pi
UEFI+ACPI firmware[1].
Signed-off-by: Mathew McBride <matt@traverse.com.au>
[1] - https://github.com/pftf/RPi4
This is part of an effort to reduce differences between
the OpenWrt armsr/armv8 config and Linux arm64 defconfig.
This enables CONFIG_ARCH_BCM and downstream
CONFIG_ARCH_BCM2835 (= BCM2711 like Raspberry Pi 4)
and CONFIG_ARCH_BCM_IPROC (Broadcom iProc packet processors).
The broadband specific SoC's (ARCH_BCMBCA) are left out
as it is assumed these will not be doing EFI boot.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Renesas markets several embedded Arm64 SoCs in the
RZ series (RZ/G, RZ/V), so should be enabled in
a general purpose target.
Automotive (R-Car) SoC's are not enabled by this change.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Due to an error on my part, Anton Antonov's
i.MX changes[1] did not fully make it into my
armvirt kernel 6.1 EFI pull request. I have updated
them using the options he supplied[1] as well
as comparing to the Linux arm64 defconfig.
The notable exception is:
CONFIG_USB_DWC3_OF_SIMPLE currently disabled
due to an issue with i.MX8P and i.MX8Q.
Fixes: 3efb3b8 ("armvirt: 64: Add NXP i.MX 8M Mini/Nano/Quad/Plus EVK support")
Signed-off-by: Mathew McBride <matt@traverse.com.au>
[1] - https://github.com/anta5010/openwrt/commit/ccf826c3444fd5fa8fac08aac05f66568ae0c242
A review of the generated OpenWrt kernel .config
vs the Linux arm64 defconfig showed that this
option was not being enabled, as it is disabled
in OpenWrt's generic config.
ACPI_BUTTON is needed to report and respond to
power button events, so it should be enabled.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
To bring the armsr/armv8 kernel configuration closer to the Linux
arm64 defconfig, synchronize options related to CPU features
(especially more recent Armv8.X variants), scheduler, EFI vars,
CMA and scheduler options.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
CONFIG_ARM_PMU (Arm Performance Monitor Unit) is a requirement
to use KVM (virtualization) from Linux 5.11+, as the virtualised
guest has virtualized PMU access.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
x86/64 enables support for KVM so I can't see a reason why
not on armsr/armv8 as well.
Arm CPU errata workaround items related to virtualization
are also enabled by this change.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
To reduce differences with the Linux arm64 defconfig,
sync the enabled erratum items with defconfig.
There are still some options not selected due to
CONFIG_KVM or other options not enabled in OpenWrt
by default.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
luci-app-attendedsysupgrade expects images to be named
'combined-efi' when the system is using EFI images.
This came about as x86 has 'combined' images for legacy
(BIOS) boot and 'combined-efi' for EFI systems.
armsr images were originally named 'combined' only
as there was no 'legacy' image type.
To avoid special handling in the attendedsysupgrade
code, name EFI images consistent with other targets.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
All the tools (e.g fw_setenv, ubiupdatevol) and config (fw_env.config)
needed for sysupgrade are already included in /lib/upgrade/stage2
Signed-off-by: Mathew McBride <matt@traverse.com.au>
The Traverse LS1043 boards were not publicly released,
all the production has been going to OEM customers who
do not use the image format defined in the OpenWrt tree.
Only a few samples were circulated outside Traverse
and our OEM customers. The public release (then called
Five64) of this series was cancelled in favour of our
LS1088A based design (Ten64).
It is best to remove these boards to avoid wasting
OpenWrt project and contributor resources.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
When using an Intel AX210 card, the Bluetooth hci interface failed
to start due to a missing "ibt-0041-0041.sfi" file.
Bluetooth: hci0: Failed to load Intel firmware file intel/ibt-0041-0041.sfi (-2)
A device specific configuration file (DDC) is also required:
Bluetooth: hci0: Found device firmware: intel/ibt-0041-0041.sfi
Bluetooth: hci0: Waiting for firmware download to complete
...
Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-0041-0041.ddc
Bluetooth: hci0: Applying Intel DDC parameters completed
Bluetooth: hci0: Firmware timestamp 2023.13 buildtype 1 build 62562
Fixes: #8558
Signed-off-by: Mathew McBride <matt@traverse.com.au>
This is required for managed operation of the SFP ports on
the Ten64 (LS1088A) and other boards.
The two issues resolved are:
- Validation of 10G SFP link modes fail as Linux did not
consider the equivalence of modes like XFI, 10GBase-R
- Fix a locking issue that prevented the system rebooting
when SFP ports were controlled by the SFP driver.
Please note, these patches are replaced by upstream ones
in 6.x, see: commit 61ec9a8154 ("armvirt: add SFP support
patches for NXP Layerscape DPAA2 platforms") in OpenWrt for
the relevant patches.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
The Ten64 board[1] is based around NXP's Layerscape LS1088A SoC.
It is capable of booting both standard Linux distributions
from disk devices, using EFI, and booting OpenWrt
from NAND.
See the online manual for more information, including the
flash layout[2].
This patchset adds support for generating Ten64 images
for NAND boot.
For disk boot, one can use the EFI support that was
recently added to the armvirt target.
We previously supported NAND users by building
inside our armvirt/EFI target[3], but this approach
is not suitable for OpenWrt upstream. Users who
used our supplied NAND images will be able to upgrade
to this via sysupgrade.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
[1] - https://www.traverse.com.au/hardware/ten64
[2] - https://ten64doc.traverse.com.au/hardware/flash/
[3] - Example:
https://gitlab.com/traversetech/ls1088firmware/openwrt/-/commit/285e4360e1604eb466880d245d48efd9962143a5
The armvirt target has been renamed to 'armsr' (Arm SystemReady)
after inclusion of EFI support.
Change references (including subtargets) accordingly.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
The armvirt target has been renamed to armsr (Arm SystemReady),
so the GRUB configuration also needs to change.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
armvirt target has been renamed to armsr (Arm SystemReady),
so the config defaults need to be changed as well.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Now that the armvirt target supports real hardware, not just
VMs, thanks to the addition of EFI, rename it to something
more appropriate.
'armsr' (Arm SystemReady) was chosen after the name of
the Arm standards program.
The 32 and 64 bit targets have also been renamed
armv7 and armv8 respectively, to allow future profiles
where required (such as armv9).
See https://developer.arm.com/documentation/102858/0100/Introduction
for more information.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
armvirt was migrated to 6.1 as part of the EFI implementation.
As we are renaming the target, there is no need to take the old
kernel configs with us.
See abcb30d ("armvirt: switch to kernel 6.1") for the previous
change.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
The Amazon ENA network devices are also used on the
AWS Arm (Graviton) instance types, so move it from
the x86-only module file to the top level netdevices.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
The SMC91X family is a ISA-age Ethernet controller.
I'm not particularly sure what it's doing in armvirt/64,
as it's unlikely there is a QEMU or real hardware configuration
that exists with it.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
These Kconfig options are required to get a screen console
working with the VMware Fusion ARM (Apple Silicon) preview.
They are likely to be the same for other Arm standard
"desktop" hardware that may emerge.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
The MDIO bus multiplexing framework is used by some drivers
such as dwmac-sun8i.
As this is a per-driver requirement, set it to be hidden in the menu.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
These changes are to support other vendors that have SystemReady/EFI
support, including:
* Marvell Armada
** (This is speculative as I don't have a machine of my own to test)
* Amazon Graviton (tested bare-metal and virtualized instances)
* VMware (Fusion for ARM Mac preview)
* NXP/Freescale (Layerscape series not already selected)
* HiSilicon
* Allwinner/sunxi
* Rockchip (untested, options taken from arm64 defconfig)
To give an idea of the hardware certified for SystemReady,
see
https://www.arm.com/architecture/system-architectures/systemready-certification-program/ir
and
https://www.arm.com/architecture/system-architectures/systemready-certification-program/es
Other vendors that _should_ work include Marvell Octeon 10
and Ampere. I understand these systems should work
"out of the box" in ACPI mode but may require other drivers
(e.g PCIe NICs and storage controllers).
Signed-off-by: Mathew McBride <matt@traverse.com.au>
ACPI support is required for Arm 'SystemReady' server and workstation
systems (and as an option on embedded platforms).
These config changes allow OpenWrt to boot in a QEMU virtual machine
with a UEFI/EDKII 'BIOS', but with no other hardware enabled yet.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
The nominal partition type for EFI boot partitions is FAT32,
which has a minimum size of 32MiB on a 512-byte-sector block device.
To ensure that the boot partition is created as FAT32 set a size
well above this minimum.
A useful discussion about EFI partition sizes can be found here:
https://superuser.com/questions/1310927/what-is-the-absolute-minimum-size-a-uefi-system-partition-can-be
I have found 128MiB works pretty consistently across both
tools (mkfs.fat) and firmwares (EDKII)
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Now that armvirt has been expanded to boot on more generic
ARM machines, remove the board and model name override.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
U-Boot with EFI boot manager functionality will store
EFI boot order data on the ESP in the ubootefi.var file.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
The use case for this is to set the kernel partition as the
EFI system partition. Versions of U-Boot with the
EFI boot manager (eficonfig and efidebug commands) will
store their boot order data on the ESP.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
This adds a separate package for EFI on Arm SystemReady
compatible machines. 32-bit Arm UEFI is supported as well.
It is very similar to x86-64 EFI setup, without the
need for BIOS backward compatibility and slightly
different default modules.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
The introduction of EFI support has changed how armvirt
images are generated. The kernel and filesystem binaries
can still be used as before with QEMU directly.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
This interferes with the generation of the EFI stub section for
ARM32. As this target is not size constrained, disable the dead code
data elimination hack.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
EFI booting is used on newer machines compatible with the
Arm SystemReady specifications.
This commit restructures armvirt into a more 'generic'
target similar to x86.
See https://github.com/openwrt/openwrt/pull/4956
for a history of this port.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
OpenWrt contains a 2012 copy of glibc's elf.h, which predates the
introduction of some newer architectures like Arm64 and RISC-V.
Linux 5.13 introduced the "gen-hyprel" tool into the kernel compile
(when virtualization/KVM is enabled) which requires EM_AARCH64 to be
defined.
arch/arm64/kvm/hyp/nvhe/gen-hyprel.c: In function 'init_elf':
arch/arm64/kvm/hyp/nvhe/gen-hyprel.c:289:43: error: 'EM_AARCH64'
undeclared (first use in this function); did you mean 'EM_IA_64'?
289 | assert_eq(elf16toh(elf.ehdr->e_machine), EM_AARCH64, "%u");
| ^~~~~~~~~~
Update the copy of elf.h from the latest glibc to fix this.
Compile-tested: ath79, armvirt, mpc85xx, x86
Run-tested: armvirt
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Traverse LS1043 boards are set up with a dual-system layout, rootfs{1,2} and kernel{1,2}.
nand_do_upgrade can do the image replacement work we were doing before as long as we give it the partition names.
This greatly simplifies the /lib/upgrade/platform.sh.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Upcoming product specification and branding changes mean that the names in tree do not accurately reflect released products.
To reduce any confusion, sort our boards by SoC family, e.g traverse-ls1043. Any future boards using Layerscape family SoC's
will be treated the same way, e.g Device/traverse-ls/lx/laXXXX.
The affected boards so far have only been available through OEM channels and those aren't using the provided sysupgrade.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
