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>
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>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Detach of-mdio dependency from stmmac-core kmod to fix support for
x86_64 target. This target doesn't use OpenFirmware infrastructure and
stmmac-core for the dwmac-intel driver doesn't depends on it.
Add kmod-of-mdio to any other user of stmmac-core as it's not inherit
from stmmac-core anymore.
Fixes: #14209
Fixes: 4b4c940fbc ("x86: Add kmod-dwmac-intel")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Move pcs-xpcs kmod from armsr modules.mk to generic modules package.
Also add additional dependency to x86_64 as stmmac-core it's now used
by x86_64 target and depends on this package.
Fixes: 4b4c940fbc ("x86: Add kmod-dwmac-intel")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
GRUB_SERIAL is also used for the default serial on the target and not
only in grub. When no grub was build it was not available and the build
fails.
Rename GRUB_SERIAL to TARGET_SERIAL and make it always available on x86
and armsr targets.
Fixes: #14063
Fixes: b10768476f ("x86,armsr: interpolate GRUB_SERIAL into /etc/inittab")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Some platforms have their console on other ports than ttyS0, so
allow the developer to tailor this on bespoke platform images.
Fixes issue #13401.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Copy configuration to boot partition (partition 1) instead of root
partition (partition 2) because the root partition is not writable if
it's a suqashfs image.
Move configuration back to root during preinit.
Fixes: https://github.com/openwrt/openwrt/issues/13695
Signed-off-by: Christian Buschau <cbuschau@d00t.de>
In userspace, ASLR is enabled, but it's missing to enable KASLR on the
kernel side to improve security as part of SystemReady recommendations.
Signed-off-by: Javier Tia <javier.tia@linaro.org>
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>
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] - ccf826c344
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>
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>
the Marvell 10G PHY driver is no way specific to ARM SystemReady
systems, it frequently occurs on SFP+ copper modules and is useful on
many targets.
Hence it been added to package/kernel/linux/modules/netdevices and we
can remove the now redundant target-specific module.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This option was removed from upstream kernel back in 2022.
See commits:
2d16803c562ecc644803d42ba98a8e0aef9c014e (>=6.0)
3dd33a09f5dc12ccb0902923c4c784eb0f8c7554 (>=5.15.61 backport)
Signed-off-by: Christian Svensson <blue@cmd.nu>
Manually rebased:
generic/hack-6.1/220-arm-gc_sections.patch
armsr/patches-6.1/221-armsr-disable_gc_sections_armv7.patch
All other patches automatically rebased.
Signed-off-by: John Audia <therealgraysky@proton.me>
CONFIG_FRAME_WARN is set dynamically, so there is no need for it to be set
in target kernel configs, so lets remove it from all configs.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
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>
