efifb, the simple-framebuffer fbdev driver, hyperv_fb and xen-fbfront
carry the display on these two subtargets, with fbcon and DRM fbdev
emulation on top. A DRM driver can claim the firmware framebuffer on its
own, so the legacy hardware drivers only add size to every image.
Mark the firmware framebuffer as a generic system framebuffer so sysfb
registers it as simple-framebuffer for simpledrm, and enable hyperv_drm
for Hyper-V guests as its help text asks. DRM fbdev emulation and fbcon
stay, so the boot log and the console prompt still reach the screen; the
emulation serves fbcon, as generic leaves FB_DEVICE off and no /dev/fb
node appears. VGA_CONSOLE and VT stay as well: a BIOS boot through GRUB
pc leaves the machine in VGA text mode, where the firmware offers no
framebuffer for simpledrm to drive, so vgacon is the only console there.
A Xen PV or PVH guest has neither, and keeps its console on hvc0. The
shared x86 config and the legacy and geode subtargets are untouched.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Both features describe an SoC family, which is the wrong granularity: a
mediatek/mt7623 board claims a display while a filogic board with a MIPI
DBI panel cannot, and rockchip claims audio for a NanoPi R2S as much as
for a Rock 5B. The audio-support and video-support packages carry that
information per image, and the modules depend on them.
Drop both features from every target that declares them.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The display target feature gates every DRM module, but it says nothing
useful: it is set on ten targets, so a mediatek/mt7623 board can have a
display while a filogic board with a MIPI DBI panel cannot, and rockchip
claims it for a NanoPi R2S as much as for a Rock 5B. Whether a board
drives a panel is a per-device choice, not a property of the SoC family.
The DRM and V4L2 nodes also end up 0600 root:root, so a display server
runs as root or not at all.
Add a video-support package which allocates the video and video-capture
groups and installs the hotplug rules for the DRM and V4L2 nodes, and
make the modules depend on it. The dependency is a plain one, not a
select, so the modules are offered once the feature is chosen. Targets
whose display drivers are built into the kernel carry the package in
DEFAULT_PACKAGES, since no module pulls it in for them, and the one
device profile that ships a DRM module on another target lists it
directly. DISPLAY_SUPPORT stays for now, so this changes no existing
selection.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This adds support for sysupgrade on ONIE-installed systems.
The install is chained through ONIE (using the ONIE installer image),
rather than attempting to manually upgrade the partition.
The idea is to allow future OpenWRT installs flexibility to use
a different partition table. By putting the installer in charge
of setting up the file system partition, the upgrade process needs
to have no knowledge of the internals of the image.
Config preservation is accomplished by appending the sysupgrade .tar.gz
to the ONIE installer image. Of course this also works for a clean
install using a sysupgrade.tar.gz created via `sysupgrade -b`.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: Keno Fischer <keno@juliahub.com>
Link: https://github.com/openwrt/openwrt/pull/23062
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The current documentation for using OpenWRT on Mellanox Spectrum
switches (https://openwrt.org/toh/mellanox/spectrum) suggests
reflashing the entire harddrive from the recovery USB. This is not
the most friendly way to install a new OS on these switches. From
factory, they come with ONIE (Open Network Install Environment),
which is a linux-based preboot environment for fetching an OS
image from the network and installing it on disk. The installer
is a self-executing bash script that executes inside the ONIE
environment. The installer is expected to preserve the ONIE partition
for use as recovery environement. To be a better citizen on
these platforms, it would be preferrable to provide OpenWRT as
an ONIE-compatible installer.
This PR adds an ONIE_INSTALLER_IMAGES build option that produces
an ONIE compatible .bin. The generated .bin follows the ONIE demo
installer pattern [1]: it creates a new GPT partition
labelled OPENWRT-ROOT on the ONIE install device, formats ext4, extracts
the OpenWrt rootfs and kernel into it, installs GRUB into the existing
UEFI ESP under bootloader-id "OpenWrt", and adds a NVRAM boot entry via
efibootmgr. ONIE-BOOT is preserved so ONIE rescue remains available.
Tested with the config at [2] on a Mellanox Spectrum SN3800 to produce
a booting OpenWRT install.
[1] https://github.com/opencomputeproject/onie/demo/installer/grub-arch/install.sh
[2] https://gist.github.com/Keno/abc8c5b72645e73fadd1ff0d9616b23d
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: Keno Fischer <keno@juliahub.com>
Link: https://github.com/openwrt/openwrt/pull/23062
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
This improves on openwrt/openwrt@aeb9028aab by adding support for
other Dell EMC Edge620/640/680 devices and mapping
the interfaces to match the markings on the device.
This modifies the netdevices.mk file to set the boot flag for
ixgbe driver to load it in early stage of the boot process to
allow for proper mapping of the network interface PCI paths
inside the 02_network script. This will also allow other devices
using the ixgbe driver to do proper mapping in 02_network script.
The 02_network script is then modified to support all
dell-emc-620/640/680 devices. It now maps the network
interfaces via PCI paths to match the markings on the device.
The interface marked GE6 is still used for WAN with
interfaces GE1-GE5 used for LAN.
The SFP1 and SFP2 interfaces are left to be assigned by
the user.
Signed-off-by: Raylynn Knight <rayknight@me.com>
Link: https://github.com/openwrt/openwrt/pull/23110
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The CloudGenix ION 2000 is a discontinued entry-level SD-WAN appliance,
a rebranded Lanner FW-7525 based on the Intel Atom C2XXX family of processors
with 4 integrated GbE ports and 2 additional I210 GbE ports. It can often be
found on eBay starting below USD 30.
Specs:
* CPU: Intel Atom C2558 @2.4GHz (Quad-core)
* RAM: 1x 4GB DDR3 SO-DIMM
* Storage: 1x Compact Flash,
1x 420GB SATA 3.0 SSD
* Ethernet: 6x GbE RJ-45
* USB: 2x USB 2.0
* PCI: 1x Mini-PCIe slot
* Power: 12V/5A
The device's BIOS is password-protected, and the password somehow hasn't leaked,
but OpenWrt can be successfully booted by overwriting the stock OS on the boot
media.
See https://forum.openwrt.org/t/report-openwrt-on-cloudgenix-ion-2000/249315
for more details.
The two I210 NICs and integrated NICs are pinned to their
PCIe paths to ensure consistent interface ordering matching
the physical port layout with eth0 assigned to controller and
acting as WAN with remaining devices as LAN.
Signed-off-by: Raylynn Knight <rayknight@me.com>
Link: https://github.com/openwrt/openwrt/pull/23114
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The DFI ASL553 is a 3.5" SBC very similar to the ADN553. The network
topology is identical, so both boards share the same network
configuration.
Differences from the ADN553:
* CPU: Intel Atom x7835RE (8C, 12W) / x7433RE (4C, 9W) /
x7213RE (2C, 9W) / x7211RE (2C, 6W)
(Amston Lake / x7000RE series instead of Alder Lake-N)
* Ethernet: Intel I226IT instead of I226V
* Audio: Realtek ALC888S instead of ALC888
For installation and board detection details, see commit b6b09a2ad8
("x86: add support for DFI ADN553").
Link: https://github.com/openwrt/openwrt/pull/23003
Signed-off-by: Nick Hainke <vincent@systemli.org>
The DFI ADN553 is a 3.5" SBC based on Intel Atom Alder Lake-N
processors with three Intel I226V 2.5GbE ports.
Specs:
* CPU: Intel Atom x7425E (4C, 12W) / x7213E (2C, 10W) /
x7211E (2C, 6W)
* RAM: 1x DDR5 SO-DIMM, up to 16GB
* Storage: 1x M.2 M key 2242/2280 (PCIe Gen3 x1/SATA3),
1x SATA 3.0
* Ethernet: 3x 2.5GbE RJ-45 (Intel I226V)
* USB: 4x USB 3.2 (rear), 2x USB 2.0 (internal)
* Expansion: 1x M.2 B key 3052 (USB3/USB2, opt. PCIe x1, SIM),
1x M.2 E key 2230 (USB/PCIe x1, CNVi)
* Display: 1x HDMI, 1x Type-C DP Alt. Mode, 1x LVDS/eDP
* Power: 9-36V DC wide range input
* TPM: dTPM 2.0 (NPCT750AADYX)
* Form factor: 3.5" SBC (146mm x 102mm)
Installation:
1. Write the combined-efi.img to a USB drive:
dd if=combined-efi.img of=/dev/sdX conv=fdatasync
2. Boot the ADN553 from the USB drive via the UEFI boot menu.
3. For permanent installation, write the image to the M.2 or
SATA storage device.
The board uses "Default string" as DMI sys_vendor and product_name
placeholders, so board detection is fixed by filtering these out and
falling through to board_vendor (DFI Inc.) and board_name (ADN553).
The three I226V NICs are pinned to their PCIe paths to ensure
consistent interface ordering matching the physical left-to-right
port layout. eth0 is assigned as WAN and eth1/eth2 as LAN.
Link: https://github.com/openwrt/openwrt/pull/22980
Signed-off-by: Nick Hainke <vincent@systemli.org>
Enable CONFIG_SERIAL_8250_MID in the generic x86 configuration.
This enables hardware serial console access on Intel Atom C3000
(Denverton) platforms, which rely on the High-Speed UART driver.
It also benefits other Intel MID platforms across the x86
architecture.
Signed-off-by: Cristian Sloberg <crilleslo@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22739
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Enable Turbo Boost Max 3.0 (INTEL_TURBO_MAX_3) to allow the kernel
scheduler to utilize preferred cores on modern Intel CPUs. This has
no effect on AMD systems.
Enable core scheduling (SCHED_CORE) to provide safer SMT task
placement and better isolation. While it can reduce peak throughput
slightly, it improves scheduling correctness on heterogeneous cores
and works across both Intel and AMD.
Enable the accelerated GHASH implementation using the CLMUL instruction
(CRYPTO_GHASH_CLMUL_NI_INTEL). This provides substantial performance
improvements for AES-GCM workloads (e.g. TLS, IPsec, OpenVPN) on CPUs
with the pclmulqdq instruction. Supported on both modern Intel and AMD
processors; falls back gracefully on older CPUs.
Run-tested twice, once with the 6.12 series and again with the 6.18.
Build system: x86/64
Build-tested: x86/64-glibc
Run-tested: x86/64-glibc (Intel N150 based box)
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/19897
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add KERNEL_NR_CPUS option in Global build settings → Kernel build
options, allowing users to set maximum CPU count (2-512) for the image.
Defaults:
- x86_64: 512 CPUs (backward compatible)
- x86: 8 CPUs (fix broken single-CPU default)
Per-CPU data structures consume ~100-200KB each.
On a 4-core system configured to NR_CPUS=4, this frees approx 76 MB
of RAM: (512 - 4) × 150 KB = ~76 MB
Note: CONFIG_NR_CPUS_RANGE_{BEGIN,END}= and CONFIG_NR_CPUS_DEFAULT= are
set by the build system and will default to 2/512/64 per arch/x86/Kconfig
These are harmless metadata and don't affect memory allocation.
Note pending https://github.com/openwrt/openwrt/pull/21407
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/21078
Signed-off-by: Robert Marko <robimarko@gmail.com>
These mitigations are low-overhead, upstream-supported hardening options
that only activate on CPUs affected by their respective vulnerabilities.
Enabling them provides consistent, defense-in-depth coverage across Intel
and AMD systems without impacting unaffected hardware.
Detailed list:
- CONFIG_MITIGATION_SRSO to guard against known a vulnerability found on
AMD processors (Zen generations 1-4) for sure, maybe others. This is
tracked under CVE-2023-20569.
- CONFIG_MITIGATION_ITS to guard against a bug in BPU on some Intel CPUs
that may allow Spectre V2 style attacks. We never enabled this option
(and its dependencies).
- CONFIG_MITIGATION_SRBDS to guard against Special Register Buffer Data
Sampling on affected Intel CPUs (CVE-2020-0543), preventing cross-core
leakage of RDRAND/RDSEED/EGETKEY values.
- CONFIG_MITIGATION_SLS to guard against Spectre-v4 gadgets on x86 by
inserting speculation barriers around RET/JMP/CALL sites when required
by CPU/microcode state.
- CONFIG_MITIGATION_CALL_DEPTH_TRACKING to guard against speculative
call-stack underflow on x86 by enabling hardware-assisted depth
tracking where supported, reducing exposure to RET-based misprediction
attacks.
- CONFIG_MITIGATION_UNRET_ENTRY to guard against RET-based speculation
attacks on x86 by replacing vulnerable function returns in kernel
entry paths with UNRET sequences when required by CPU/microcode state.
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/21078
Signed-off-by: Robert Marko <robimarko@gmail.com>
This fixes a previous commit for Sophos XG 210r3 which was missing
board_name mapping and adds support for the SG related version and the
XG/SG 230r2 which is the same hardware with a faster processor.
Sophos board_name mapping was modified to support all Sophos
SG/XG devices.
Sophos SG/XG 210r3 and SG/XG 230r2 are rackmounted x86 based firewall
with 6 RJ-45 gigabit ethernet ports (eth0-5) and 2 SFP gigabit ethernet
ports (eth6, eth7) all running Intel NICs supported by igb driver. The 210r3
and 230r2 only differ in the processor used. This board update maps
eth1 (marked as WAN) as wan and eth0 and eth2-5 as lan. Leaving the
two SFP ports unmapped.
Fixes: 4880e8e338 ("x86: add board mapping for Sophos XG 210r3")
Signed-off-by: Raylynn Knight <rayknight@me.com>
Link: https://github.com/openwrt/openwrt/pull/21959
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The Sophos SG/XG-125 revision 3 like the already supported SG/XG-135
revision 3 has odd numbering of eth ports where the WAN port (as marked
on the case) is: `eth6` and `eth0`, `eth1`, `eth2`, `eth3`, `eth5`, `eth7`,
`eth8` are LAN ports.
Port `eth4` confirmed to be the SFP port.
Signed-off-by: Raylynn Knight <rayknight@me.com>
Link: https://github.com/openwrt/openwrt/pull/21914
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Running with CONFIG_HZ_PERIODIC=y keeps the scheduler tick running
continuously, which produces higher jitter and lower power efficiency.
In contrast, CONFIG_NO_HZ_IDLE=y (the upstream default) stops the tick
only when the CPU is idle, giving lower idle power and normal runtime
jitter.
An Intel N150-based router/firewall was tested using two kernel builds:
one with CONFIG_HZ_PERIODIC=y, and one with CONFIG_NO_HZ_IDLE=y. Power
consumption was measured while the system was essentially idle (no
meaningful traffic). The CONFIG_NO_HZ_IDLE=y build consistently used
less power.
Details: The two power-measurement methods were:
1. PkgWatt from turbostat (software)
2. Wall-power measurement using a Kill-A-Watt (hardware)
The test began by zeroing the Kill-A-Watt and simultaneously running:
turbostat --quiet --Summary --interval 10 --show Busy%,PkgWatt
The test duration was defined by the time required for the Kill-A-Watt
to accumulate 0.005 kWh, after which the average wattage was calculated.
Results:
+----------------------+-----------------+----------------+-----------+
| Metric | HZ_PERIODIC | NO_HZ_IDLE | Delta % |
+----------------------+-----------------+----------------+-----------+
| PkgWatt | 3.59 ± 0.38 | 3.38 ± 0.34 | -5.9 % |
+----------------------+-----------------+----------------+-----------+
| Avg wattage at wall | 12.47 | 12.00 | -3.77 % |
+----------------------+-----------------+----------------+-----------+
The mean PkgWatt difference is 210 mW (5.9%) in favor of
CONFIG_NO_HZ_IDLE=y, with a t-statistic of ~3.17 and p ≈ 0.002.
Wall-power measurements show a 470 mW (3.77%) reduction under
CONFIG_NO_HZ_IDLE=y.
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/21470
Signed-off-by: Robert Marko <robimarko@gmail.com>
This commit renames all management network ports of the
SN2100, SN2700, SN3420, and SN3700 switches based
on their PCI address during boot.
For the default network config, the management and
QSFP port(s) are put into the br-lan bridge.
Signed-off-by: Til Kaiser <mail@tk154.de>
Link: https://github.com/openwrt/openwrt/pull/17251
Signed-off-by: Robert Marko <robimarko@gmail.com>
This commit renames the network ports of the Minisforum MS-A2
Mini PC: the two 2.5G RJ45 ports are now named lan1 and lan2,
and the two 10G SFP+ ports sfp1 and sfp2.
All four ports are also added to the default lan interface.
--- Hardware Highlights ---
AMD Ryzen™ 9 9955HX/7945HX
Dual DDR5-5600MHz, up to 96GB
2x 10G SFP+, 2x 2.5G RJ45
WiFi 6E, Bluetooth 5.3
Built-in PCIe x16 Slot
Signed-off-by: Til Kaiser <mail@tk154.de>
Link: https://github.com/openwrt/openwrt/pull/19689
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Sophos XG 210r3 is a rackmounted x86 based firewall with 6 RJ-45 gigabit
ethernet ports (eth0-5) and 2 SFP gigabit ethernet ports (eth6, eth7)
all running Intel NICs supported by igb driver. This board update maps
eth0 (left most RJ-45 port) as wan and eth1-7 as lan.
Signed-off-by: Steve Wavler <trenchcoatjedi@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19647
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add driver packages for Intel Low-Power Subsystem devices which are part
of some Intel chipsets. They are mainly needed to have access to the I2C
bus used for HID devices.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Many x86 machines can boot from SD cards, and some embedded x86 devices
come with an eMMC. Include drivers for all common MMC/SDHCI controllers
to allow booting from SD/MMC on x86.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Expose the sysfs interface to userspace tools for power monitoring.
Useful for tracking energy usage in CPU package, cores, DRAM, etc.
Build system: x86/64
Build-tested: x86/64
Run-tested: x86/64
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/18255
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>