The factory images of the Linksys LGS3xxC switches differ between
builds in the Belkin header:
-00000000: 0780 0001 7917 f807 6ab3 0fe3 0058 2000 ....y...j....X .
+00000000: 0780 0001 2a5a 3f79 6ab3 d0c7 0058 2000 ....*Z?yj....X .
belkin-header.py stores time.time() as the image time, which also
changes the header checksum. Use SOURCE_DATE_EPOCH when it is set, like
linksys-image.sh does for the tarball inside.
Link: https://github.com/openwrt/openwrt/pull/25355
Signed-off-by: Paul Spooren <mail@aparcar.org>
Both 10G ports have a yellow and a green LED driven by the RTL8261CE
rather than by GPIO. Index 2 is yellow, index 3 green. The
index-to-colour mapping was determined empirically by inverting the
polarity bits in VEND2 0xd044 one at a time.
Configure the triggers to match the 1G ports on this board, where green
means gigabit: yellow for 10/100, green from 1000 up, and both together
for 10000. Without this the LEDs come up with no trigger and stay dark,
losing the firmware defaults they had before.
The indices were only verified on an RTL8261CE. Board revisions carrying an
RTL8261N are unaffected for now since that driver has no LED callbacks, but
the mapping should be rechecked there before relying on it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Hardware revisions of this board ship either an RTL8261N, handled by the
out-of-tree RTL826x driver, or an RTL8261CE, handled by the mainline
driver. The two need different firmware and the revision is not known at
image build time, so ship both.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The realtek PHY driver requests rtl_nic/rtl8261c.bin for the RTL8261C.
The blob has been in linux-firmware since 2026-05-28 and is present in
the 20260910 tarball already used here, but it is not matched by any of
the r8169-firmware globs, so nothing installs it today.
The RTL8261D handled by the same phy_driver entry needs no firmware, so
this stays a standalone package rather than a kmod-phy-realtek
dependency, which would pull the blob onto every board with any Realtek
PHY.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The RTL8261C/D drive their LEDs through the same register block as the
RTL8221B, with four LEDs instead of three and two more speed bits. Wire
the callbacks to the RTL8261C_CG and RTL8261CE_CG entries so the 10G
ports of the Gemtek W1700K can be driven from the netdev trigger instead
of coming up dark.
Submitted upstream in the same series as the SerDes lane polarity patch.
Apply it ahead of the out-of-tree
742-net-phy-realtek-add-5G-and-10G-PHY-support.patch as well, so it too
can be carried exactly as submitted. 742's realtek_drvs[] hunk is rebased
on top of it, which only moves its leading context.
Refresh out-of-tree patches in realtek target.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The Gemtek W1700K routes the USXGMII lanes between the AN7581 and its
RTL8261CE inverted and describes that in the device tree, but nothing in
the RTL8261C/D driver reads tx-polarity/rx-polarity and the Airoha PCS
has no polarity handling of its own. The copper side negotiates normally
while the SerDes never trains and the netdev stays NO-CARRIER.
Add a read and a read-modify-write helper for the VEND1 SerDes command
window and program the lane polarity from rtl8261x_config_init().
Submitted upstream as part of a series documenting the RTL8261C/D device
tree bindings and adding SerDes lane polarity and LED support.
Apply it ahead of the out-of-tree
742-net-phy-realtek-add-5G-and-10G-PHY-support.patch so it can be carried
exactly as submitted. 742 drops its own select PHY_COMMON_PROPS and its
phy-common-props.h include, as both come from here now. Once accepted
upstream this patch only moves to backports, so they stay dropped.
Refresh out-of-tree patches in realtek target.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Backport support for the Realtek RTL8261CE_CG (PHY ID 0x001cc899),
merged for v7.4. It shares the sub-PHY-ID and the firmware with the
RTL8261C_CG.
ca44c21fc117 ("net: phy: realtek: add support for RTL8261CE_CG")
Parts reporting this PHY ID fall through to the generic Clause 45
driver. Both 10G ports of the Gemtek W1700K carry one and never come up.
The patch applies before the out-of-tree
742-net-phy-realtek-add-5G-and-10G-PHY-support.patch, which is where the
RTL_8261N/RTL_8264/RTL_8264B context around the new define comes from, so
742 gains the RTL_8261CE_CG define as context.
Refresh various out-of-tree patches in generic and realtek target.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Backport the upstream series adding support for the Realtek RTL8261C_CG
(PHY ID 0x001cc898) and RTL8261D 10Gbps PHYs, merged for v7.3 as
"add-support-for-rtl8261c-d".
Both parts share the PHY ID and are told apart by a sub-PHY-ID read from
the vendor extension page (0x00 for the RTL8261C, 0x81 for the RTL8261D).
The RTL8261C loads rtl_nic/rtl8261c.bin, the RTL8261D needs no firmware.
Two Clause 45 helpers the driver depends on are backported along with it.
3b63c19e64f8 ("net: phy: c45: add genphy_c45_pma_soft_reset()")
d7722c03089e ("net: phy: c45: add setup and read master/slave helpers")
b772b5ae4537 ("net: phy: realtek: add support for RTL8261C_CG")
a04171a1cf32 ("net: phy: realtek: load firmware for RTL8261C_CG")
f0667918d5fc ("net: phy: realtek: add support for RTL8261D")
Refresh various out-of-tree patches in generic and realtek target.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Add support for RTL9302B-based Ubiquiti UniFi USW Pro Max 24 PoE switch
with 16x GbE and 8x 2.5G RJ45 ports, 2x SFP+, and a front display.
Hardware
========
- RTL9302B switch SoC
- 512 MiB RAM
- 32 MiB SPI-NOR flash
- 16x 100M/1G RJ45 ports via 2x RTL8218E
- 8x 100M/1G/2.5G RJ45 ports via 2x RTL8224
- PoE:
- 400W total budget
- 8x 802.3at, 32W per port (ports 1-8)
- 16x 802.3bt, 60W per port (ports 9-24)
- 2x SFP+ ports
- Buttons: 1x Reset
- LEDs: RGBW LED per port (Etherlighting)
- Front touch display via USB ACM (see below)
- Console: TTL 3.3V, 115200 8N1 (internal pin header close to SoC;
layout front to back: VCC RX TX GND)
- Etherlighting feature (lighting patterns and color control)
- Vendor firmware: U-Boot + LEDE-based Ubiquiti OS
MAC address
===========
Single MAC address in EEPROM partition, applied to all ports.
Front touch display
===================
The unit has a touch-capable front display, driven by a dedicated
STM32-based MCU. Unlike other Ubiquiti switches where the MCU is
connected to the SoC via UART directly, here it is exposed as a USB
CDC-ACM serial device through an on-board Genesys Logic GL850G USB hub.
The MCU runs Ubiquiti's LCM firmware and exposes a high-level JSON
protocol (page selection, button-press events, etc.); arbitrary
pixel-level control is not possible without replacing the MCU firmware.
Display support therefore depends on both USB host support and a driver
for the LCM protocol, neither of which is currently available.
Known issues
============
- Etherlighting not controllable, driver WIP. Port LEDs for link work
though. By default, the controller keeps the LEDs in a breathing
state, gated by the link state delivered by the Realtek SoC.
Disclaimer
==========
Stock firmware uses a dual-bank layout (kernel0/kernel1, ~15 MiB each).
OpenWrt replaces both banks with a single contiguous firmware partition.
Flashing OpenWrt writes or invalidates both stock kernel slots; U-Boot
remains intact and can be used for recovery.
Installation
============
1. Enable SSH on the stock UniFi OS and log in with user account.
2. Copy the OpenWrt sysupgrade image to /tmp on the switch (e.g. via
scp).
3. Adjust IMG below to point at the copied file, then run the block as a
whole. It verifies the expected stock partition layout and image size,
writes kernel0, splits into kernel1 if the image is larger than that
slot (otherwise invalidates kernel1 so U-Boot cannot pick a stale
bank), and reboots:
set -e
IMG=/tmp/openwrt-realtek-rtl930x-ubnt_usw-pro-max-24-poe-squashfs-sysupgrade.bin
K0_SIZE=$((0xf10000))
K0_BLOCKS=$((K0_SIZE / 0x10000))
grep -q '^mtd2: 00f10000 00010000 "kernel0"$' /proc/mtd
grep -q '^mtd3: 00f20000 00010000 "kernel1"$' /proc/mtd
IMG_SIZE=$(wc -c < "$IMG")
[ "$IMG_SIZE" -gt 0 ]
[ "$IMG_SIZE" -le $((0x1e30000)) ]
dd if="$IMG" of=/dev/mtdblock2 bs=64k count=$K0_BLOCKS conv=fsync
if [ "$IMG_SIZE" -gt "$K0_SIZE" ]; then
dd if="$IMG" of=/dev/mtdblock3 bs=64k skip=$K0_BLOCKS conv=fsync
else
dd if=/dev/zero of=/dev/mtdblock3 bs=64k count=1 conv=fsync
fi
sync
reboot
The switch comes up in OpenWrt after reboot.
4. It is recommended to modify the bootcmd to speed up the boot and
prevent any issues due to the dual-boot selection. Since U-Boot by
default uses bootubnt which does a lot of (unneeded) RTK
initialization, quite some time passes until Linux is started.
Additionally, the U-Boot logic fiddles with some bits on flash which
causes JFFS2 errors in OpenWrt. While this doesn't seem to cause
issues yet, be defensive and set the bootcmd from OpenWrt with:
fw_setenv bootcmd 'bootm 0xb40b0000'
fw_printenv bootcmd
This directly boots the uImage from flash, without doing all the
initialization. OpenWrt is able to bootstrap the networking
completely on its own.
It does not matter which bank stock booted from when the dd block
runs: both banks are touched in the same pass (kernel0 written, kernel1
either written or invalidated). With kernel1 invalidated, U-Boot's
internal fallback kicks in and permanently switches to kernel0 on the
next boot, so the device stays on OpenWrt as long as kernel0 is
bootable.
Recovery
========
Since the installation procedure invalidates or partially overwrites
the second bank, recovery requires serial console access (see Hardware
above for pinout).
1. Interrupt U-Boot autoboot by spamming a key during early boot to
drop into the U-Boot prompt.
2. Bring up networking:
rtk network on
3. Transfer an OpenWrt initramfs image via TFTP and boot it:
tftpboot 0x82000000 <server>:<initramfs.bin>
bootm 0x82000000
4. From the running initramfs OpenWrt, do a sysupgrade to reflash
OpenWrt or whatever you want to recover. There is no need for the
complicated procedure from installation since OpenWrt sees the
firmware partition already as a whole.
Return to stock firmware
========================
There is no fully-supported revert path. The stock firmware blob is a
Ubiquiti UBNT archive (header + parts, see firmware-utils' fw.h) that
embeds a u-boot and a kernel0 uImage payload; only the latter is
relevant when writing back to the kernel partitions.
The snippet below extracts the kernel0 uImage from such a blob by
locating the uImage magic and using the size carried in the uImage
header itself, without parsing any UBNT framing. It is provided as a
best-effort starting point; verify the result before flashing,
otherwise you're on your own:
BLOB=<firmware.bin>
OFF=$(grep -aboF $'\x27\x05\x19\x56' "$BLOB" | head -1 | cut -d: -f1)
SIZE=$(( $(dd if="$BLOB" bs=1 skip=$((OFF + 12)) count=4 2>/dev/null \
| hexdump -e '1/4 "%u"') + 64 ))
dd if="$BLOB" of=kernel0.uImage bs=1 skip="$OFF" count="$SIZE"
Once you have a clean uImage, boot an OpenWrt initramfs as described in
Recovery, copy kernel0.uImage to /tmp, and run:
set -e
[ "$(wc -c < /tmp/kernel0.uImage)" -le $((0xf10000)) ] || exit 1
mtd write /tmp/kernel0.uImage firmware
fw_setenv bootcmd bootubnt
fw_printenv bootcmd
reboot
After rebooting, Ubiquiti's firmware should boot.
Or, if you made backups of the flash before installation, just write
the backup back to flash.
Link: https://github.com/openwrt/openwrt/pull/25280
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The RTL8218E exposes XSGMII as one logical SerDes, but its eight
MAC-side channels are represented by two groups of four. The initial
setup disables autonegotiation only for the first group on page 0x400,
leaving the second group on page 0x500 in autonegotiation mode.
Consequently, the first four package ports pass traffic while the
remaining four establish copper link but do not pass packets. Disable
XSGMII autonegotiation for the second group as well by forcing
register 0x500.12[9:8] to 01.
This changes 0x500.12 from 0x70d0 to 0x71d0 and brings
0x507.15[7:4] from 0 to 0xf on hardware, after which all eight ports
pass traffic.
Fixes: 2db820be865f ("realtek: phy: fix RTL8218E XSGMII initialization")
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25364
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Now that 6.18 is the only supported kernel version for bcm53xx,
remove the 6.12 kernel configs (config-6.12 and per-subtarget
config-6.12 files) and the entire patches-6.12 patch stack, as they
are no longer used.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25307
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The positive and negative VTH values occupy disjoint fields in the same
register. Combine them into one masked read-modify-write instead of
updating each field separately.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Program impedance, pre-amplitude, and post-amplitude in that order so
dependent enable state is not exposed before its coefficient.
Then update the main amplitude and both enable bits together. This
replaces three REG07 read-modify-write transactions with one.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
XSG fan-out is only required for the low digital pages on SerDes 2 and
3. Apply the analog configuration tables through the normal write path
and remove the now-unused XSG table helper.
Limit the XSG operation to its supported targets, reuse the normal
RTL930x write for the first SerDes, and derive the companion from the
existing physical mapping.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Document the common SerDes soft-reset register and field. Replace magic
register values in the RTL838x and RTL839x reset sequences with named,
SDK-style masked field updates. Merge the two sequences by dropping the
RTL839x-specific delay - which is unneeded according to the SDK - and
provide a combined helper.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Document RTL931x SerDes registers and fields, then replace magic offsets
and bit ranges at their call sites. Use FIELD_PREP() where values need
positioning and named masks for field updates.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Document RTL930x SerDes registers and fields, then replace magic offsets
and bit ranges at their call sites. Use FIELD_PREP() where values need
positioning and named masks for field updates.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Document SerDes registers and fields shared by RTL930x and RTL931x.
Replace magic offsets and bit ranges at their call sites with the named
registers and field masks.
Link: https://github.com/openwrt/openwrt/pull/25314
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The mvebu target enables CONFIG_CPU_V7 even for AArch64 subtargets,
which also causes CONFIG_arm_v7 to be set. This makes Valgrind use
the ARMv7 configure host triplet on AArch64, breaking the build.
Only apply the ARMv7 host override when ARCH is arm.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Link: https://github.com/openwrt/openwrt/pull/25346
Signed-off-by: Robert Marko <robimarko@gmail.com>
Host/Configure/Default supplies the bootstrap "--" separator before
CMAKE_HOST_OPTIONS. Keep BUILD_TESTING with the CMake cache options so
it is passed after that separator, without introducing a second one.
Fixes: ddb23f3a02 ("tools/cmake: pass -DBUILD_TESTING=OFF to bootstrap")
Signed-off-by: Robert Marko <robimarko@gmail.com>
Instead of carrying 100-no-testing.patch, pass -DBUILD_TESTING=OFF
directly to CMake's bootstrap script. This avoids refreshing the patch
on every CMake update.
The patch also changed the default in the installed CTest.cmake module.
Preserve that behavior by passing -DBUILD_TESTING=OFF by default in
cmake.mk for target and host builds. Packages can override it via
CMAKE_OPTIONS or CMAKE_HOST_OPTIONS.
OpenWrt never runs CMake tests, so building them only wastes build time.
This replaces the patch introduced in 8af80e79bd ("tools/cmake:
update to 3.17.0").
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24403
Signed-off-by: Robert Marko <robimarko@gmail.com>
Instead of carrying a patch (150-zstd-libarchive.patch) that modifies
Utilities/cmlibarchive/CMakeLists.txt to enable pkg-config search for
zstd, pass explicit staging library and include paths (-DZSTD_INCLUDE_DIR
and -DZSTD_LIBRARY) directly to CMake's bootstrap script.
ZSTD_INCLUDE_DIR and ZSTD_LIBRARY are the cache variables CMake itself
sets when --system-zstd is not used, so pre-seeding them guarantees that
CMake always links against OpenWrt's staging libzstd without requiring
a patch.
Fixes: 0e3d51ccae ("tools/cmake: fix compilation with host libzstd-dev")
Suggested-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24407
Signed-off-by: Robert Marko <robimarko@gmail.com>
Use mainline U-Boot with pending patches for LAN969x instead of the
old vendor U-Boot.
Both existing boards are supported.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Backports an accepted upstream patch targeted for 7.4 to extend the
Realtek SPI driver with support for the second CS. Though no devices
made use of this so far, further devices may do so.
Link: https://github.com/openwrt/openwrt/pull/25334
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Add a vendor profile for Fibocom modems so that proto ncm can drive them.
Without it ncm.sh reports UNSUPPORTED_MODEM, as the manufacturer string
returned by AT+CGMI has no matching key in ncm.json.
The FG621-EA is used in the ASUS 4G-AX56 and the TP-Link TL-MR500 v1. The
profile keys off the manufacturer string rather than any particular board,
so it applies to Fibocom NCM modems generally.
ncm.json is installed by comgt-ncm, so bump PKG_RELEASE to make sure
existing installations pick up the new vendor profile on upgrade.
This change originates from PR #19793 by kddred, open in draft since
August 2025 without review. The original commit is authored and signed
off with a GitHub noreply address, which the commit formality check
rejects, so it could not be carried unmodified, and kddred has not been
active since August 2025. Authorship is reassigned for that reason alone;
the work is theirs. Happy to restore the original authorship if a usable
address becomes available.
Tested on an ASUS 4G-AX56 (HW rev A1) on both main and openwrt-25.12.
Link: https://github.com/openwrt/openwrt/pull/19793
Signed-off-by: Fredrik Hallin <fredappsdev@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/24974
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
This reverts commit 487ff3cfa0.
Three problems:
CONFIG_AR8216_PHY is enabled and to stop it from interfering and
crashing on boot, internal MDIO needs to be used.
Once internal MDIO gets used, ports end up dying even in the absence of
traffic. This is currently believed to be an issue with qca,qca8327
specifically. There are no reports of qca,qca8337 behaving badly.
Routing speed with DSA becomes much slower. Gigabit routing is no longer
doable, even with flow offload. This needs further research.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25308
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The generic config builds CONFIG_INTEL_XWAY_PHY for all devices while
only a single one uses it. Avoid bloating the kernel by using the module
for the only device that uses this PHY.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25294
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The patch ends in an empty line where quilt writes a context line
holding a single space, so `make target/linux/refresh` rewrites it
and the kernel patch check fails on every target.
Fixes: 115209aa22 ("kernel: make the LoongArch vDSO build id independent of the build path")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25333
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Configure stage without a cache against a warm cache:
mtools 3.34 s -> 0.28 s
gengetopt 4.39 s -> 2.13 s
fakeroot 10.97 s -> 8.73 s
xz 4.32 s -> 2.17 s
libressl 3.07 s -> 1.46 s
flex 12.32 s -> 10.98 s
expat 2.74 s -> 1.52 s
bc 1.34 s -> 0.38 s
dosfstools 3.13 s -> 2.54 s
libtool 2.86 s -> 2.29 s
mtd-utils 4.06 s -> 3.56 s
flex, fakeroot, dosfstools and mtd-utils run autoreconf in the same
stage, and the cache does not reach that part.
Each of the eleven configures the same way with a warm cache as it does
without one: the check configures three times, without a cache, with a
cold cache and with a warm cache, and every generated file of the first
and the last run is identical. A static scan of each configure script
found no cache check that changes CFLAGS, CPPFLAGS, LDFLAGS or LIBS
without restoring it.
patchelf, mklibs and automake pass the same check but gain less than
half a second, so they stay out.
make world after make tools/clean now takes 121 s against 177 s with
cold caches.
Signed-off-by: John Crispin <john@phrozen.org>
Three cases kept a cached answer that no longer held:
A new configure script. A package with an autoreconf fixup regenerates
configure with the staged autoconf, automake and libtool, and a new
version of one of them can change what a cache variable means. The site
script now keeps a checksum of configure beside the cache and drops the
cache when the checksum changes. A new patch to configure is covered too.
A changed precious variable. configure aborts when LIBS, CPP or another
precious variable differs from the value in the cache, and because
nothing removes the cache, it aborts on every later run as well:
configure: error: 'LIBS' was not set in the previous run
configure: error: changes in the environment can compromise the build
The site script now makes the same comparison before configure does and
drops the cache on a difference.
Paths under other names. The libtool answers lt_cv_path_*, acl_cv_path_*
and lt_cv_sys_global_symbol_*, and gmp_cv_prog_m4, hold the path of a
system tool or of the staged sed and m4, and survived a wipe of
staging_dir. The site script now drops them with the ac_cv_path_ answers.
m4 and gmp still configure the same way with a warm cache as they do
without one, and still read it: the m4 configure stage takes 1.5 s warm
against 23 s cold.
Signed-off-by: John Crispin <john@phrozen.org>
sparse set PKG_BUILD_PARALLEL, which a host build does not read, so it
built with one job. Use HOST_BUILD_PARALLEL: 6.6 s -> 1.3 s.
It builds five times out of five with the job server, and each build
installs files that are identical to those of a serial build.
Signed-off-by: John Crispin <john@phrozen.org>
libtool 22.5 s -> 20.0 s
dosfstools 6.0 s -> 4.8 s
make-ext4fs 2.1 s -> 1.2 s
automake 3.9 s -> 3.4 s
autoconf 3.1 s -> 2.6 s
Each one builds five times out of five with the job server, and each
build installs files that are identical to those of a serial build.
Signed-off-by: John Crispin <john@phrozen.org>
host-build.mk clears MAKEFLAGS, so a custom Host/Compile that runs a bare
$(MAKE) builds with one job, whatever HOST_BUILD_PARALLEL says. mtools
sets the flag, but its compile step never used it.
Each of the three now passes $(HOST_JOBS), and mkimage and lzma set
HOST_BUILD_PARALLEL:
mkimage 11.7 s -> 7.2 s
mtools 8.3 s -> 4.8 s
lzma 4.0 s -> 1.8 s
Each one builds five times out of five with the job server, and each
build installs files that are identical to those of a serial build.
Signed-off-by: John Crispin <john@phrozen.org>
Currently, we depend on building the host Ruby support just for the two
FWU scripts that are written in Ruby.
Use Codex 5.6 to convert the scripts to Python and drop Ruby dependency.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
The initramfs step copied /init into the root filesystem directory and
never removed it again. With CONFIG_TARGET_PER_DEVICE_ROOTFS the
initramfs kernel and the rootfs image of a device come from that same
directory. Nothing orders the two steps, so /init entered the squashfs
image or not, depending on which step ran first. The reproducible build
service reports this as a difference between the published image and a
rebuild.
Add /init to the initramfs from outside the root filesystem instead. A
built in initramfs gets it through a gen_init_cpio list file. A separate
cpio gets it appended to the finished archive. The mode is now fixed at
0755 and no longer follows the umask of the checkout.
The initramfs step also normalised the mtime of the root filesystem
directory. Do that in prepare_rootfs, so no step writes to the directory
after the image build can start.
Signed-off-by: John Crispin <john@phrozen.org>
u-boot 2013.10 builds timestamp_autogenerated.h with a bare date call, so
U_BOOT_DATE and U_BOOT_TIME hold the wall clock and the banner of every
image changes on each build:
U-Boot 2013.10-openwrt4 (Sep 21 2026 - 20:47:50) ARV7506PW11
Add a patch that uses SOURCE_DATE_EPOCH when the environment provides it,
which the build already exports, and keeps the wall clock otherwise. Later
u-boot versions do the same in their own timestamp rule, which is why only
this package needs the change.
Found with two lantiq/xway trees whose directory names differ in length.
Three bytes of u-boot.bin differed, all inside the banner. After the
change the three u-boot images of arv7506pw11 are identical in both trees
and the banner follows the source date.
Signed-off-by: John Crispin <john@phrozen.org>
gcc builds the target libraries with CFLAGS_FOR_TARGET, which carries no
prefix map. __FILE__ therefore expands to an absolute path, and assert in
libstdc++ and the ryu code put seven of them into .rodata, where the strip
before packaging cannot reach them. The libstdcpp6 package differs between
two builds in different directories, and so does every image that ships it.
The published package shows the same thing. libstdcpp6-14.4.0-r5.apk of
bcm47xx/mips74k holds
/builder/shared-workdir/build/build_dir/toolchain-mipsel_74kc_gcc-14.4.0_musl/gcc-14.4.0/libstdc++-v3/src/c++11/debug.cc
so no rebuild of that package can match today.
iremap is called with BUILD_DIR for the kernel, with PKG_BUILD_DIR for a
package and with STAGING_DIR for the target headers. The toolchain build
directory has no such call. Add one for the three FOR_TARGET flag sets.
The replacement keeps the build_dir element, because the last element of
the toolchain build directory and of the toolchain staging directory is
the same string and one replacement for both would make the two roots
indistinguishable.
Tested with two bcm47xx/mips74k trees whose directory names differ in
length. The shipped libstdc++.so.6.0.33 holds no absolute path any more
and the libstdcpp6 package is now identical in both trees. It differed by
165 bytes before.
The toolchain staging directory still appears in the debug information of
the same library, 244 times. Those are DWARF include directories, they do
not survive the strip, and no shipped file carries them.
Signed-off-by: John Crispin <john@phrozen.org>
iremap is called with BUILD_DIR and with PKG_BUILD_DIR, never with
STAGING_DIR. A header taken from the staging directory therefore reaches
__FILE__ and the debug information with its absolute path, and the result
depends on the directory the tree was built in.
Measured in the published snapshot of lantiq/xway: mt76-connac-lib.ko,
mt76x02-lib.ko and mt7925-common.ko hold
/builder/shared-workdir/build/staging_dir/target-mips_24kc_musl/usr/include/mac80211/net/cfg80211.h
That path is __FILE__ in .rodata, so the strip before the package is built
cannot reach it and the module ships it.
Map STAGING_DIR as well. Keep the staging_dir element in the replacement:
the last element of STAGING_DIR and of BUILD_DIR carry the same name, so
the bare name would make the two roots indistinguishable. The map of
BUILD_DIR does not change, so only a path that leaks today changes.
Verified with the target compiler on a header below a mapped directory:
-ffile-prefix-map removes the absolute path from both __FILE__ and the
debug information, -fmacro-prefix-map removes it from __FILE__ alone. The
shipped half is __FILE__, so both variants cover it.
A local build of mt76 also holds nine staging paths, but those are debug
information: the build directory copy of mt76-connac-lib.ko is 653456
bytes with 13 debug sections and nine such paths, the shipped copy is
84688 bytes with none. They are named here so that the next reader does
not take them for the same defect.
Signed-off-by: John Crispin <john@phrozen.org>
Both SBOM generators produce a different file on every run, so the
published .bom.cdx.json of an image and of a package feed never match a
rebuild.
dump_cyclonedxsbom_json() in scripts/package-metadata.pl has three
causes. It draws the serial number from rand(), it takes the timestamp
from the wall clock, and encode_json() follows the Perl hash order, which
changes with the hash seed of each run. The last one alone reorders every
key in the file.
scripts/make-sbom.py has the first two causes, through uuid.uuid4() and
datetime.utcnow().
Take the timestamp from SOURCE_DATE_EPOCH, which the build exports. Derive
the serial number from the timestamp and the component list, so it stays a
valid RFC 4122 identifier and still changes when the content changes. Sort
the keys of the Perl output.
Tested with the package index and the image manifest of an ipq40xx build.
Two runs with the same SOURCE_DATE_EPOCH are now identical, two runs with
different values differ, and the scripts exit with an error when the value
is not a number. Both files differ between two runs without the change.
Signed-off-by: John Crispin <john@phrozen.org>
configure.in of drv_tapi and drv_vmmc compiles the whole configure command
line into the module. drv_tapi_linux.c prints it through a proc file. The
command line holds the absolute paths of the build machine, among them
--enable-kernelbuild, --with-ifxos-incl, --enable-tapiincl, CPPFLAGS and
LDFLAGS, so the module depends on the directory it was built in.
Measured in the published snapshot modules of lantiq/xway: drv_tapi.ko and
drv_vmmc.ko both hold
--enable-kernelbuild=/builder/shared-workdir/build/build_dir/...
The existing 020-not-leak-cflags.patch covers the Kbuild CFLAGS, not this
string.
Drop every argument that holds a path and keep the feature flags. The loop
repeats the idiom the file already uses for CONFIGURE_OPTIONS.
Signed-off-by: John Crispin <john@phrozen.org>
Build/boot-overlay copies the device trees and builds the boot script in
$@.boot, so every file carries the build time. mkfs.ubifs writes st_mtime
straight into the inode and has no SOURCE_DATE_EPOCH support, and the two
tar calls pass neither --sort=name nor the options that pin the owner and
the mode, so both nand.ubi and bootfs.tar.gz differ between builds.
The diffoscope of the published bootfs.tar.gz shows both: wall clock
mtimes on the device tree files, and a member order that follows readdir.
Set the times in $@.boot once, before the UBIFS image and the tar are
made. Sort the members of both archives and give them a fixed owner and
mode, as the other archive recipes do.
Signed-off-by: John Crispin <john@phrozen.org>
Build/cfe-jffs2 is the only mkfs.jffs2 call in the tree that passes
neither --squash-uids nor --squash-perms. The recipe creates the marker
files with touch and cp, so the JFFS2 inodes carry the uid, the gid and
the umask of the build machine. The published images hold uid and gid
1000.
mkfs.jffs2 already takes the timestamp from SOURCE_DATE_EPOCH, so the
owner and the mode are the remaining inputs from the environment.
Pass both options, as mvebu and ath79 already do.
Signed-off-by: John Crispin <john@phrozen.org>
mtk_image_set_mt7621_header() reads the wall clock and writes it to the
timestamp of the legacy image header, so the MT7621 boot loader image
differs on every build.
Add a patch that uses imagetool_get_source_date(), which the other image
tools already use, and keep the wall clock as the fallback.
Signed-off-by: John Crispin <john@phrozen.org>
7zr stores the modification time of the input file. The kernel image
carries the build time, so the H3C and HPE images differ between builds.
Set the time of the input to SOURCE_DATE_EPOCH before the archive is
created.
Signed-off-by: John Crispin <john@phrozen.org>
Paul Spooren
Simon Polack
Jonas Jelonek
Rosen Penev
Daniel Pawlik
Tianling Shen
Robert Marko
Josef Schlehofer
Robert Marko
Ross Barnes-Brown
Felix Fietkau
Fredrik Hallin
Julius Bairaktaris
John Crispin
Daniel Golle