This adds support for the Kontron i.MX8MP OSM-S size system-on-module +
eval board.
CPU: NXP i.MX8MP @ 1600MHz (quad-core A53)
Memory: 4 (up to 8) GByte LPDDR4-RAM
Storage: 32 (up to 128) GByte eMMC + microSD slot
Ethernet: 2x 1 Gbit/s IEEE (1x with TSN)
UART: 1x UART console output on the Mini-B USB Debug Port
(signals are really UART on this Mini-B USB port!!!, there is
an adapter with ftdi available from Kontron)
1x RS232, 1x RS485
USB: 2x USB 2.0 Type-A, 1x USB 3.0 Type-C DRP
Misc: 8 (up to 128) kByte EEPROM (at24), RTC, 2x CAN, HDMI, 1x PCIe
This will create an SD card image for the board.
To use this image you have to bring the board to the recovery boot mode
(normal boot mode is eMMC). At the time of writing, the SoM (or the SoC)
has a bug that the FORCE_RECOVERY signal (switch S1 on the eval board)
doesn't work as long as the eMMC boot0 partition contains data.
Therefore you have to wipe this boot0 partition to be able to boot from
SD card. To do this call the following commands at uboot:
mmc dev 0 1
mmc erase 0 0x2000
After that, the system will try to boot from SD card.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Add support for the Micro Crystal RV3028 I2C real-time clock chip.
Tested on a Kontron OSM-S/BL i.MX8MP eval board.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Build ATF images for i.MX8MP. Tested on Kontron OSM-S/BL i.MX8MP.
The default IMX_BOOT_UART_BASE for imx8mp platforms is 0x30890000, which
would be UART2. The Kontron board however uses UART3 as serial debug
console. As a result, after loading BL31 the system hangs.
Setting IMX_BOOT_UART_BASE=auto will fix it.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Introduce a variable inside probe to avoid having to cast const away.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22619
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add a per-SerDes supported_modes bitmap, filled at probe by each
variant from the SerDes id or type, and reject unsupported modes in
determine_hw_mode() via test_bit().
This replaces the rtl838x is_hw_mode_supported() switch and adds the
same gating to rtl839x/rtl93xx, which previously relied only on the
per-variant mode-value table. Unlike that table, the bitmap is per
SerDes instance, so it also rejects modes the table can encode but that
a given SerDes cannot actually use. Rejection uses the uapi -EOPNOTSUPP
instead of the internal -ENOTSUPP.
Link: https://github.com/openwrt/openwrt/pull/23608
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
SerDes modes HISGMII and QHSGMII are practically dead but were added/kept
for documentation purposes. However, these modes will likely never be
used and we have other documentation than in the code. Drop them to
reduce the modes to what we actually use.
Link: https://github.com/openwrt/openwrt/pull/23608
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Some devices have a ton of unused space found in other partitions that
can be used to expand rootfs_data.
In particular, the D-Link DIR-X3260 device can squeeze another ~24MiB
from its backup partition, with a few tricks, allowing for ~48MiB of
usable space rather than ~24MiB by itself.
As of v25.12.1, with the official release build config, this gives us
~35MiB of rootfs_data, where without it there would only be ~11MiB.
Enable this config to allow this function.
Signed-off-by: Han Sol Jin <jhs@jinhansol.com>
Link: https://github.com/openwrt/openwrt/pull/22555
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
In mtd_replace_jffs2(), the return value of malloc(erasesize) is never
checked. If the allocation fails, buf remains NULL and the subsequent
memcpy(buf + ofs, ...) in add_data() will dereference NULL, causing a
segfault.
Add a NULL check and return -1 on allocation failure. Match the
diagnostic message used by the sibling mtd_write_jffs2() so the
out-of-memory cause is visible at the call site.
Signed-off-by: Anna Kiri <bredcorn@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23553
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
% git log --oneline f762cc..4070d80
4070d808bea1 sdio-common: Fix buffer overflow in scanf %mc [BZ #34008]
2890b35cd361 libio: Fix ungetwc operating on byte stream [BZ #33998]
e9517114acc7 abilist.awk: Handle weak unversioned defined symbols
1634cc11a5a5 Linux: Only define OPEN_TREE_* macros in <sys/mount.h> if undefined (bug 33921)
d1d8d27164e9 include: isolate __O_CLOEXEC flag for sys/mount.h and fcntl.h
8362e8ce10b2 Use pending character state in IBM1390, IBM1399 character sets (CVE-2026-4046)
ce1013a197eb tests: fix tst-rseq with Linux 7.0
60cabd0464c6 riscv: Resolve calls to memcpy using memcpy-generic in early startup
02ffd413cf83 elf: Use dl-symbol-redir-ifunc.h instead _dl_strlen
26953143787b elf: parse /proc/self/maps as the last resort to find the gap for tst-link-map-contiguous-ldso
dd9945c0ba40 resolv: Check hostname for validity (CVE-2026-4438)
5c6fca0c62ce resolv: Count records correctly (CVE-2026-4437)
2be6cf2e75d0 posix: Run tst-wordexp-reuse-mem test
305ce0b58809 aarch64: Tests for locking GCS
2ee41ba6ecd3 aarch64: Lock GCS status at startup
fa4a40c7d497 tests: aarch64: fix makefile dependencies for dlopen tests for BTI
9898ea58b538 malloc: Avoid accessing /sys/kernel/mm files
c3ceb93dc4f6 Add BZ 33904 entry to NEWS
911bd469f80c debug: Fix build with --enable-fortify-source=1 (BZ 33904)
48f5a05a7a1e nss: Missing checks in __nss_configure_lookup, __nss_database_get (bug 28940)
d6cb7ce0e98b Linux: In getlogin_r, use utmp fallback only for specific errors
140c760d711d nss: Introduce dedicated struct nss_database_for_fork type
856c426a7534 Don't include <bits/openat2.h> directly (bug 33848)
144ba302089c po: Incorporate translatins (nl updated, ar new)
022abaeacbc8 Fix ldbl-128ibm ceill, floorl, roundl and truncl zero-sign handling
45b58d6bd185 NEWS: add new section 2.43.1
f02515d8a696 Replace advisories directory with file ADVISORIES
Build system: x86/64
Build-tested: x86/64-glibc
Run-tested: x86/64-glibc
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/23467
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
A recent target-wide change missed the DTSI for a few devices causing a
build issue for RTL930x. Fix that.
Fixes: 43562f97e7 ("realtek: dts: add link index cell to pcs-handle phandles")
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
When we look up the PHY for each switch port, we traverse to the parent
node to find the corresponding MDIO bus. This approach breaks down
when an explicit ethernet-phy-package is used to bundle multiple
PHYs in the same chip.
Signed-off-by: Manuel Stocker <mensi@mensi.ch>
Link: https://github.com/openwrt/openwrt/pull/23591
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Drop the shared rtpcs_create function and references in both drivers
since that is now done via the fwnode PCS provider framework.
Link: https://github.com/openwrt/openwrt/pull/23539
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
PCS driver registers each SerDes as an fwnode_pcs provider in probe;
the resolver returns the cached or freshly-allocated rtpcs_link for
the requested (sds, link_idx) cell. DSA glue stops calling
rtpcs_create directly, drops .mac_select_pcs, and instead populates
phylink_config.num_available_pcs / fill_available_pcs from each
port's pcs-handle in phylink_get_caps. The rtl838x_port.pcs pointer
becomes a has_pcs bool populated at port probe via fwnode_property_
present, since nothing assigns the actual phylink_pcs anymore but the
"does this port use a PCS?" checks elsewhere still need a presence
flag.
Without .mac_select_pcs, phylink_major_config only searches the
pcs_list when state->interface is set in phylink_config.pcs_interfaces
(drivers/net/phy/phylink.c:1378). Populate it per port whenever the
port has a pcs-handle, listing the SerDes-routable interface modes for
each SoC variant -- without this, pcs_config / pcs_link_up are never
called and the SerDes is left unconfigured.
pcs_get_state still needs the MAC port number to index per-port link
status registers. Recover it at probe via rtpcs_map_links: walk the
sibling switch's ethernet-ports subtree (same backwards topology
lookup the sibling MDIO driver does for phy-handle), and for every
port whose pcs-handle resolves to one of our SerDes, store the port's
reg in sds->link_port[]. The resolver consults link_port[] when
allocating rtpcs_link and fails with -ENODEV if a consumer requested
a link the map step didn't record. Avoids a driver-side port_base
table that would have to encode per-SoC SerDes-to-port wiring (and
would silently break on non-contiguous variants); the DT is the
single source of truth.
Kconfig selects FWNODE_PCS.
Assisted-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23539
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add an s16 link_port[] array to struct rtpcs_serdes, initialised to
-1 in probe. This is preparatory storage for the port number that
each link serves; it will be populated in the follow-up fwnode_pcs
migration commit by scanning consumer DT nodes for their reg, and
consumed by the resolver when allocating rtpcs_link.
Assisted-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23539
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Move the rtpcs_link pointer array from rtpcs_ctrl (keyed by global
DSA port) into rtpcs_serdes (keyed by the per-SerDes link index).
This matches how the hardware is structured -- a SerDes hosts up to
RTPCS_MAX_LINKS_PER_SDS PCS links -- and aligns the in-driver
addressing with the cell the DTSes just gained on pcs-handle, so the
upcoming fwnode_pcs resolver becomes a direct sds->link[cell] lookup.
rtpcs_create() takes a new link_idx parameter and stores into
sds->link[link_idx] instead of ctrl->link[port]; the DSA glue switches
its phandle lookup to of_parse_phandle_with_args() and forwards the
cell. The port number stays on rtpcs_link for legacy callers that
still need it. Bounds and double-bind checks (-EINVAL, -EBUSY) guard
against malformed DT references that would otherwise OOB or silently
overwrite an existing link.
Drops RTPCS_PORT_CNT, whose only user was the relocated array, and
fixes a pre-existing of_node_put leak on the pcs-handle phandle in
the DSA glue as a side effect of the parse-with-args conversion.
Link: https://github.com/openwrt/openwrt/pull/23539
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
A SerDes can host multiple PCS links: QSGMII binds four ports to one
SerDes, USXGMII variants up to eight. Today pcs-handle references the
SerDes as a whole, with no way to express which link inside the SerDes
a port wants. The driver gets away with this because it carries its own
port->link bookkeeping and the link slot is implicit in DSA's port
iteration order -- functional, but the wiring information lives nowhere
in DT.
The upcoming fwnode_pcs migration moves PCS lookup to the generic
fwnode provider API, which disambiguates multiple instances per fwnode
via phandle cells. To make that landable as small, code-only commits,
the DT needs to carry the link index ahead of time.
Bump #pcs-cells from 0 to 1 on every SerDes node in the four SoC DTSIs
and append the link cell to every pcs-handle reference across boards
and the SWITCH_PORT_* macros. Cell values match the existing wiring:
0 for single-link SerDes (10GBase-R, SGMII, fiber, single-link
USXGMII), 0..3 per SerDes for QSGMII and USXGMII-QX, 0..7 for the
RTL9311 octal USXGMII layout.
No code reads the new cell yet -- of_parse_phandle_with_args() in the
PCS driver already cooperates with cells = 0 or 1, and the DSA glue
uses of_parse_phandle() which ignores cells entirely. The change is
runtime-neutral on its own; it exists so the follow-up code patches
can be a few lines each instead of dragging a bridge counter into the
driver to invent slot numbers DT could have provided directly.
Link: https://github.com/openwrt/openwrt/pull/23539
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Switch rtpcs_serdes from struct device_node * to struct fwnode_handle *
in preparation for fwnode_pcs_add_provider, which keys providers by
fwnode. Storing the fwnode directly avoids of_fwnode_handle() wrappers
at every API boundary.
The conversion is mechanical: of_node_get/put become fwnode_handle_get/
put (same refcount on OF-backed fwnodes), polarity helpers drop their
of_fwnode_handle() wrapping, and the link counter compares fwnodes
directly via of_fwnode_handle(arg_np). No behavior change.
Link: https://github.com/openwrt/openwrt/pull/23539
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Set max RX size configuration (AIROHA_MAX_RX_SIZE) to 0x3f00.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://github.com/openwrt/openwrt/pull/23585
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add a watchdog driver for the external management MCU on Hasivo /
Horaco network switches, reachable over I2C. Without periodic
keepalive the MCU resets the board every ~3 minutes.
The driver arms the MCU at probe and registers a struct
watchdog_device with WDOG_HW_RUNNING so the watchdog core feeds the
chip via a kernel timer until userspace opens the watchdog node.
Timeout is fixed at 15s; the hardware threshold is baked into MCU
firmware and is not software-configurable.
The I2C address is supplied per-board in the device tree via the
`reg` property. The driver does not constrain or probe a specific
address. Known addresses across current Hasivo / Horaco silicon:
- 0x6F: Hasivo S1300WP-8XGT-4S+, Hasivo F5800W-12S+,
Horaco ZX-SW82TS-L2P (default / most common)
- 0x6E: alternate Hasivo / Horaco variant
The driver, its device-tree binding and the Kconfig/Makefile wiring
are added to the kernel tree as a realtek target patch and exposed as
the kmod-hasivo-mcu-wdt KernelPackage. Keeping the binding in the
kernel tree lets dt_binding_check exercise it during the build and
makes the whole driver easy to drop once it lands upstream.
Tested on Hasivo S1300WP-8XGT-4S+ (RTL9313). Unbinding the driver
causes the MCU to power-cycle the board within ~15s.
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: https://github.com/openwrt/openwrt/pull/23418
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Like other RTL931x devices, the Plasma Cloud ESX28 and PSX28 also have
inverted polarity on the SerDes which drive the SFP ports. Commonly,
those always seem to have inverted TX polarity. This was missing from
when the devices were added at which time SFP on RTL931x wasn't working
at all yet. Add the polarity to the DTS now.
Verified on Plasma Cloud PSX28.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Disable unused crypto algorithms. If needed, install required packages.
Suggested-by: Qingfang Deng <dqfext@gmail.com>
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Link: https://github.com/openwrt/openwrt/pull/23536
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Drop the legacy receive handling and convert the driver to make
use of a zero-copy receive path. To save memory use the page
pool fragment feature. This way two SKBs will fit into one 4KB
page. With the parametrization of this patch the driver will
allocate about 600KB of receive buffers (2 rings with 300KB
each. This already includes space for the SKB header.
iperf3 benchmark gives:
RTL930x
- 1x stream send / from switch 170 Mbit -> 170 MBit
- 4x stream send / from switch 150 MBit -> 150 MBit
- 1x stream receive / to switch 320 MBit -> 400 MBit
- 4x stream receive / to switch 260 MBit -> 300 MBit
Link: https://github.com/openwrt/openwrt/pull/23483
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Although never observed, a transmit timeout might happen.
In that case there is a resource leak inside rteth_tx_timeout().
This happens when rteth_setup_ring_buffer() reinitializes the
transmit buffers and overwrites all transmit slots. Any linked
SKB is lost and leaked at this point.
Be defensive and add a cleanup rteth_free_tx_buffers() function.
Call this alongside rteth_free_rx_buffers() where needed.
Link: https://github.com/openwrt/openwrt/pull/23483
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
There are two helpers to cleanup SKBs that call iternally
dev_kfree_skb_any_reason() but with different error codes.
- dev_kfree_skb_any() reason SKB_DROP_REASON_NOT_SPECIFIED
- dev_consume_skb_any() reason SKB_CONSUMED
The driver does not distinct between the two. Change this and
clean up a SKB that was handed over to the hardware with
dev_consume_skb_any(). This way kernel knows that everything
went well.
Link: https://github.com/openwrt/openwrt/pull/23483
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The cleanup order of the driver is quite confusing. At least
two issues exist.
- phylink_destroy() is missing
- The implicit unregister_netdev() at the end of rteth_remove() is called
too late. The manually managed resources are removed before. This can
lead to stale data access.
Convert to register_netdev() and bring rteth_remove() into a meaningful
order to avoid such issues when converting to page_pool.
Link: https://github.com/openwrt/openwrt/pull/23483
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
In the future this function will work on page_pool and might fail.
Add a return code to it and handle it where needed.
Link: https://github.com/openwrt/openwrt/pull/23483
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
In the future there will be some error paths inside locking.
Make cleanup easier by converting the sections to scoped_guard.
Link: https://github.com/openwrt/openwrt/pull/23483
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The error handling flow during probing has some shortcomings.
1. In case an error occurs after netif_napi_add() this must be
cleaned up with a call to netif_napi_del().
2. If devm_register_netdev() fails not only NAPI must be cleaned
up but also the phylink.
Add a cleanup section for the probe. Implement it generically
(checking for 0/NULL values) so it can be called any time when
encountering probe failures.
Link: https://github.com/openwrt/openwrt/pull/23483
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
In commit d89cb72c23 , a new rootfs type "targz" was introduced, to correctly pack the rootfs AFTER `DEVICE_PACKAGES` installation (unlike the old simple `rootfs.tar.gz`) .
The expected release artifact shall be a single corresponding tar gz release accompanying or relacing the old simple `rootfs.tar.gz`.
However, if one take a look at the v25.12 series release download pages, e.g. [25.12.4/x86/64](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/), one could see that there're now four release artifacts related to rootfs targz:
- [generic-targz-combined-efi.img.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-generic-targz-combined-efi.img.gz)
- [generic-targz-combined.img.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-generic-targz-combined.img.gz)
- [generic-targz-rootfs.img.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-generic-targz-rootfs.img.gz)
- [rootfs.tar.gz](https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-rootfs.tar.gz)
It's obvious the new `targz` release actually reuses the same `TARGET_ROOTFS_{TYPE}` handler same as `squashfs`, `ext4` and alike. And the three `generic-targz` img.gz contains the same expected tar gz either as their second partition, or as the whole image. This could be verified by the following script:
```bash
URL_PARENT=https://downloads.openwrt.org/releases/25.12.4/targets/x86/64/openwrt-25.12.4-x86-64-
for TYPE in combined-efi combined rootfs; do
curl -L "${URL_PARENT}generic-targz-${TYPE}.img.gz" | gzip -cd > "${TYPE}.img"
done
for TYPE in combined-efi combined; do
INFO=$(sfdisk -d "${TYPE}.img" | sed -n 's/^'"${TYPE}.img"'2 : start= \+\([0-9]\+\), size= \+\([0-9]\+\),.\+.\+$/\1 \2/p')
dd if="${TYPE}.img" of="${TYPE}.tar.gz" bs=512 skip="${INFO%% *}" count="${INFO##* }"
done
cp rootfs.img rootfs.tar.gz
sha256sum combined-efi.tar.gz combined.tar.gz rootfs.tar.gz
file rootfs.tar.gz
```
Output:
```log
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13.12M 100 13.12M 0 0 194.6M 0 0
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 12.93M 100 12.93M 0 0 190.9M 0 0
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7.13M 100 7.13M 0 0 257.6M 0 0
GPT PMBR size mismatch (246304 != 246334) will be corrected by write.
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
The backup GPT table is not on the end of the device.
212992+0 records in
212992+0 records out
109051904 bytes (109 MB, 104 MiB) copied, 0.258064 s, 423 MB/s
212992+0 records in
212992+0 records out
109051904 bytes (109 MB, 104 MiB) copied, 0.261621 s, 417 MB/s
18b98d3562dc3067ae095ee44d4ff3158cf84e89063c3df66c0ef6638922ba71 combined-efi.tar.gz
18b98d3562dc3067ae095ee44d4ff3158cf84e89063c3df66c0ef6638922ba71 combined.tar.gz
18b98d3562dc3067ae095ee44d4ff3158cf84e89063c3df66c0ef6638922ba71 rootfs.tar.gz
rootfs.tar.gz: gzip compressed data, max compression, from Unix, original size modulo 2^32 0
```
The checksum of the extracted, actually expected .tar.gz are all same. And if we peek inside its content, it's indeed what we expected:
```
> tar -tzf rootfs.tar.gz
./
./bin/
./bin/ash
./bin/board_detect
./bin/busybox
./bin/cat
./bin/chgrp
./bin/chmod
./bin/chown
./bin/config_generate
./bin/cp
./bin/date
...
```
A disk image with a `tar.gz` as its second partiton doesn't boot anyway and I doubt if there's any mechanic to make it bootable. So `generic-targz-combined-efi.img.gz` and `generic-targz-combined.img.gz` are not needed at all, and `generic-targz-rootfs.img.gz` shall be renamed to have a `tar.gz` suffix instead.
Therefore work around this by skipping creating images for fs `targz` in the general loop, and only create the rootfs.tar.gz later for `targz` "fs"
This affects both the real builder and imagebuilder. I've tested this with multiple imagebuilders.
Tested with `openwrt-imagebuilder-25.12.4-mvebu-cortexa53.Linux-x86_64`:
```sh
rm -rf bin && make image PROFILE=generic
```
Without the fix:
```
> tree bin/
bin/
└── targets
└── x86
└── 64
├── openwrt-25.12.4-x86-64-generic.bom.cdx.json
├── openwrt-25.12.4-x86-64-generic-ext4-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-ext4-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-ext4-rootfs.img.gz
├── openwrt-25.12.4-x86-64-generic-kernel.bin
├── openwrt-25.12.4-x86-64-generic.manifest
├── openwrt-25.12.4-x86-64-generic-rootfs.tar.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-rootfs.img.gz
├── openwrt-25.12.4-x86-64-generic-targz-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-targz-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-targz-rootfs.img.gz
├── profiles.json
└── sha256sums
```
With the fix:
```
> tree bin/
bin/
└── targets
└── x86
└── 64
├── openwrt-25.12.4-x86-64-generic.bom.cdx.json
├── openwrt-25.12.4-x86-64-generic-ext4-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-ext4-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-ext4-rootfs.img.gz
├── openwrt-25.12.4-x86-64-generic-kernel.bin
├── openwrt-25.12.4-x86-64-generic.manifest
├── openwrt-25.12.4-x86-64-generic-rootfs.tar.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-combined-efi.img.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-combined.img.gz
├── openwrt-25.12.4-x86-64-generic-squashfs-rootfs.img.gz
├── openwrt-25.12.4-x86-64-generic-targz-rootfs.tar.gz
├── profiles.json
└── sha256sums
```
And with `openwrt-imagebuilder-25.12.4-mvebu-cortexa53.Linux-x86_64`:
```sh
rm -rf bin && make image PROFILE=ripe_atlas-v5
```
Without the fix:
```
> tree bin/
bin/
└── targets
└── mvebu
└── cortexa53
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.bom.cdx.json
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-ext4-sdcard.img.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.manifest
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-rootfs.tar.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-squashfs-sdcard.img.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-targz-sdcard.img.gz
├── profiles.json
└── sha256sums
```
With the fix:
```
> tree bin/
bin/
└── targets
└── mvebu
└── cortexa53
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.bom.cdx.json
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-ext4-sdcard.img.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5.manifest
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-rootfs.tar.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-squashfs-sdcard.img.gz
├── openwrt-25.12.4-mvebu-cortexa53-ripe_atlas-v5-targz-rootfs.tar.gz
├── profiles.json
└── sha256sums
```
Signed-off-by: Guoxin Pu <pugokushin@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23570
Signed-off-by: Robert Marko <robimarko@gmail.com>
Version 7.0 - Apr 28, 2026
* Feature: support MSE display (--show-mse)
* Feature: add 2 new link_ext_state names
* Fix: fix index calculation in ixgbe register dump (-d)
* Fix: cmis wavelength tolerance output (-m)
* Fix: duplicate sfpid Active Cu compliance output (-m)
Signed-off-by: Paul Donald <newtwen+github@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23574
Signed-off-by: Robert Marko <robimarko@gmail.com>
The MASKROM button was added to the device tree for FriendlyELEC NanoPi R5C/R5S in Linux 6.17 in
07e04c071a35 ("arm64: dts: rockchip: Add maskrom button to NanoPi R5S + R5C").
Now that rockchip target has switched to 6.18 in 67740e311b ("rockchip: switch to kernel 6.18"),
add `kmod-button-hotplug` and `kmod-input-adc-keys` to the default packages for NanoPi R5C/R5S
Signed-off-by: Ryan Leung <untilscour@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/23558
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
This version supports boards with 1.5GB or 3GB of RAM.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://github.com/openwrt/openwrt/pull/23360
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Changes:
https://github.com/lldpd/lldpd/releases/tag/1.0.22
Fixes:
- Fix out-of-bound read access when removing VLAN tag (CVE-2026-46433, issue 787)
- Reject 0-length management address in LLDP
- Fix race condition when creating the control socket
- Fix FDP MAC address
- Fix memory leak in the BSD bridge query path
- Fix duplicate management addresses when merging EDP VLAN frames
Signed-off-by: Paul Donald <newtwen+github@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23567
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
This commit adds support for the Hasivo F1100W-4SX-4XGT ethernet 10Gbase and PoE switch.
It also adds support for a whole matrix of variants of this device:
| Device | Revision | RAM | PoE | Console |
|---------------------|----------|--------|-----|----------|
| F1100W-4SX-4XGT | v1.03 | 256 MB | n/a | RJ45 |
| F1100W-4SX-4XGT | v1.02 | 512 MB | n/a | RJ45 |
| F1100W-4SX-4XGT-SE | v1.03 | 256 MB | n/a | internal |
| F1100W-4SX-4XGT-SE | v1.02 | 512 MB | n/a | internal |
| F1100WP-4SX-4XGT | v1.03 | 256 MB | yes | RJ45 |
| F1100WP-4SX-4XGT | v1.02 | 512 MB | yes | RJ45 |
| F1100WP-4SX-4XGT-SE | v1.03 | 256 MB | yes | internal |
| F1100WP-4SX-4XGT-SE | v1.02 | 512 MB | yes | internal |
The devices are identical except for presence of the PoE daughter board,
RJ45 console port, and 256 or 512 MB RAM.
The non-512 MB image also works on the older 512 MB board revisions, but not vice versa.
Credit to @mensi @bevanweiss @markc1984
Hardware
--------
| | |
|----------|-----------------------------------------------------------|
| SoC | RTL9303 rev B |
| RAM | 256 MB Samsung K4B2G1646F DDR3L (board revision v1.03), |
| | or 512 MB unknown module (board revision v1.02 and older) |
| Flash | 32 MB Macronix MX25L25645G SPI NOR, |
| | 29 MiB usable by OpenWrt |
| Ethernet | 4x SFP+ via SoC (10G/2.5G/1G), |
| | 4x RJ45 via 4x RTL8261BE PHY (10G/5G/2.5G/1G/100M/10M) |
| PoE | only on WP variants |
| | 1x 802.3bt 90 W (port 5) |
| | 3x 802.3at 30 W (ports 6, 7, 8) |
| | via daughter board with Hasivo HS104PTI controller |
| | PoE works but is unmanaged --> future work |
| LEDs | 1x system orange/green, 8x link green/red, 4x PoE orange |
| Button | Reset |
| Console | RJ45 38400 bps 8n1, or pin holes on SE variants |
Installing OpenWrt
------------------
Note: With vendor firmware 7.1.9, the bootloader's network profile is broken.
We need to select a different profile with port/phy overlap to make the TFTP
transfer work. Then only port 5 works in the OpenWrt initramfs, but all ports
work fine after flashing, when we don't need the profile trick anymore.
1. Attach to RJ45 serial console port using a cisco cable.
2. Attach your computer to Port 5 (the first RJ45 port).
3. Serve initramfs-kernel.bin on TFTP 192.168.1.111.
4. Power on the device.
5. Interrupt U-Boot by pressing `Ctrl+C`, then `Z`, then `H`, during 3 second countdown.
6. Run: `setenv boardmodel 'RTL9303_5x8261BE_2XGE_ZHIHUI' ; rtk network on`
7. Run: `tftpboot 0x84f00000 initramfs-kernel.bin ; bootm 0x84f00000`
8. Use `mtd dump` to make backups of all flash partitions.
9. Use SCP to copy `squashfs-sysupgrade.bin` to the device, then run `sysupgrade`.
Restoring factory firmware
--------------------------
OpenWrt uses the `RUNTIME` and `RUNTIME2` partitions as one combined partition.
To restore them from backups, boot from `initramfs-kernel.bin` just like during
the installation, then use `mtd write` to write your backups of the factory
`mtd5` and `mtd6` partitions.
Notes/Quirks
------------
- U-Boot interruption is obfuscated. Press `Ctrl+C`, then `Z`, then `H`,
during the 3 second countdown.
- U-Boot rtk network profile is broken. Use the `RTL9303_5x8261BE_2XGE_ZHIHUI` profile
instead, it makes at least port 5 work.
- MAC address is stored on the `RUNTIME` or `RUNTIME2` partitions, which are used by OpenWrt.
Instead, we generate one random MAC address and store it in the U-Boot environment.
- PoE works but is unmanaged. The HS104 driver is worked on in
https://github.com/openwrt/openwrt/pull/22245 and will work with ethtool and the
kernel's new `pse-pd` subsystem.
Signed-off-by: Lars Gierth <larsg@systemli.org>
Link: https://github.com/openwrt/openwrt/pull/23020
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The kernel has two helper defines that guide about hardware
characteristics.
MIPS_L1_CACHE_SHIFT defines the cache line sizes (1<<x) of the
target. It defaults to 5 - so it is assumed that the device has
a cache line size of 32 bytes. This is not true for MIPS 4KEc
cores that are driving the RTL838x SOCs. These cores have 16
byte cache line sizes. Adapt the CONFIG properties for this
target to match the hardware.
ARCH_DMA_MINALIGN definies the alignment for memory allocations.
Other than its name suggests on MIPS devices that have non
coherent DMA kmalloc() respects this configuration. This ensures
that no normal memory is corrupted by DMA blocks that share the
same cache line.
The default for this is 128 bytes. And kernel states itself
"Total overkill for most systems but need as a safe default. Set
this one if any device in the system might do non-coherent DMA".
Realtek devices use non coherent DMA so they are affected by the
setting of ARCH_DMA_MINALIGN. Set this to cache line size for
all devices to reduce memory waste.
Link: https://github.com/openwrt/openwrt/pull/23492
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Apply minor fixup for PPE_MTU configuration and LRO queue configuration.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
[ improve commit title/description ]
Link: https://github.com/openwrt/openwrt/pull/23566
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Lets refresh the config as generic config was wastly updated, and we
need the CONFIG_PAGE_BLOCK_MAX_ORDER to be defined.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Specifications:
SOC: Atheros AR9344 @ 560MHz
RAM: 2x Winbond W9751G6KB-25 (128 MiB)
FLASH: Hynix H27U1G8F2BTR (128 MiB)
WIFI1: Atheros AR9340 5.0GHz (SoC)
WIFI2: Atheros AR9280 2.4GHz
SWITCH: Atheros AR8327 (5x Gigabit (1x WAN, 4x LAN)
LED: 1x Power-LED, 1 x RGB Tricolor-LED
INPUT: One Reset Button
USB: One USB 2.0 Port
UART: JP1 on PCB (Labeled UART), 3.3v-Level, 115200n8
(GND, TX, RX, VCC - GND is next to the UART silk screen)
Flashing Instructions:
If your device still has vulnerable firmware, then existing installation
instructions can be used. Devices currently running ar71xx firmware can
be upgraded directly, although ar71xx firmware will complain,
because of changed metadata format. So you'll have to force the upgrade.
If your firmware is too new, there are two options
- temporarily adding a SPI-NOR flash to boot initramfs from
(recommended)
- patching NAND image with initramfs with external programmer
(recommended if and only if you have access to 360-clip, or
similar device, that doesn't require desoldering a TSOP48 chip))
Since this device is brought over from an old AR71xx, there's
already a wiki-page with detailed instructions:
<https://openwrt.org/toh/meraki/z1>
Installing from SPI-NOR:
- Download pre-built image from
<https://github.com/Leo-PL/OpenWrt-Meraki-Z1>
or assemble your own by splicing
router-u-boot <https://github.com/CodeFetch/router-u-boot>
image for TP-Link WDR4300 with Z1 initramfs in uImage format.
To build uImage initramfsf from source, remove the "KERNEL_INITRAMFS"
variable from target/linux/ath79/image/nand.mk for Z1.
Put the U-boot image at offset 0, initramfs at offset 131072.
- Write the image to an 8MB (or greater) SPI flash
- Temporarily bridge - or solder in a 220-ohm resistor between pins 6
and 8 of the SPI-NOR chip to override boot source to SPI
- When the initramfs first boots, write the standard initramfs to NAND,
to both 'kernel' and 'recovery' partitions
$ mtd write /tmp/openwrt-ath79-nand-meraki_z1-initramfs-kernel.bin kernel
$ mtd write /tmp/openwrt-ath79-nand-meraki_z1-initramfs-kernel.bin recovery
Now you can disconnect the resistor and try to boot the system from
NAND. If it works, continue with installation, as described for legacy
method using vulnerable stock firmware.
- When done, you can remove SPI-NOR chip and the resistor altogether,
it can be reused to perform installation on other devices,
or act as a recovery boot source if needed, if the recovery initramfs
fails for any reason.
Installing by patching NAND
- If you'd like to desolder NAND to perform this, I highly advise
against it, use SPI-NOR method above instead.
- If you have external programmer and a NAND clip, read out the whole
chip image, while keeping the device in reset by shorting SRST
(pin 11) to ground in JTAG connector,
and store a backup in a safe place.
- Patch the chip image with initramfs for raw NAND from
<https://github.com/Leo-PL/OpenWrt-Meraki-Z1>, by using a script
there, or manually:
$ dd if=openwrt-ath79-nand-meraki_z1-initramfs-kernel-rawnand.bin of=z1_dump.img bs=135168 seek=1 conv=notrunc
$ dd if=openwrt-ath79-nand-meraki_z1-initramfs-kernel-rawnand.bin of=z1_dump.img bs=135168 seek=65 conv=notrunc
This will write the initramfs to both kernel and recovery partitions,
which is highly recommended, as due to device architecture it is
notoriously hard to unbrick.
- Write the image back to the NAND, again, keeping the CPU in the reset.
- When the unit boots to initramfs, proceed as per existing instructions
for volnerable firmware.
Legacy installation on vulnerable stock firmware:
The gist:
1. Get a root-shell on the device (see wiki). (needs UART access)
2. make a backup (to a PC/safe location) of the existing Meraki
firmware.
3. copy over the OpenWrt initramfs kernel for the Z1.
This gets written into the kernel NAND partition.
(Verify that written image is complete!)
After the following reboot and successfull boot of the staging
OpenWrt initramfs image:
4. Free up space by removing Meraki firmware partitions from UBI volume
to free up space for OpenWrt (example given for the latest wired-14
version):
$ ubirmvol -N storage /dev/ubi0
$ ubirmvol -N rootfs-wired-14-202005181203-G201ba9ed-rel-gazebo-1 /dev/ubi0
$ ubirmvol -N rootfs-wired-14-202005181203-G201ba9ed-rel-gazebo-2 /dev/ubi0
4. copy over the sysupgrade.bin for the router and use sysupgrade
to make the installation permanent.
Notable changes from ar71xx support:
- LED colors are now different, because nu801 userspace driver is used
for the RGB LED.
Acknowledgments:
- Hal Martin, for providing additional devices for research, including
one modded for SPI boot and with removable NAND
- Christian Lamparter for initial device tree and image configuration
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
[Finished support, updated commit message with new installation
methods]
Co-authored-by: Christian Lamparter <chunkeey@gmail.com>
Co-authored-by: Lech Perczak <lech.perczak@gmail.com>
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17665
Signed-off-by: Robert Marko <robimarko@gmail.com>
The 6.18 kernel port and PWM patches were developed independently. the
initial 6.18 port did not include the PWM patches, so add them now.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
Since upstream commit 60e3f1e9b7a5 ("lib/crypto: arm64/sha512:
Migrate optimized SHA-512 code to library"), the kernel module is no
longer available, and its fucntionality os provided by the kernel
core. Thus do not try to package this for linux 6.18 and later.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
Now that everything is in place for kernel 6.18, enable it as a
testing kernel for qualcommbe.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
Generate new patches for 6.18 from my ipq95xx development branch.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
