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>
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 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>
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>
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>
I generate patches form git, so maintaining an old numbering scheme
does not integrate well with my workflow. renumber the pacthes here so
that the commit shows only the changes to the patches.
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>
Create the config and relevant patches for 6.18 from 6.12. The
"standard" openwrt devel process seems to be to move the files and
restore the old ones. I find this process confusing, and I don't see
any git benefits for doing things this way. So just copy the files.
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>
The lastest ethernet PPE driver, uses "mac", "rx", and "tx", without
the "port_" prefix for the port clocks and resets. The PPE ports are
declared by the device dts. In order to support v6.12 and v6.18
kernels simultaneously, update the kernel patches and kiwi-dvk
devicetree to use the newer naming scheme.
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>
- try to detect supported (hostkey) algorithms; otherwise fallback to predefined list;
- remove size constraint for ECDSA: custom build may include only 384 or 521 bit curves;
- remove size constraint for RSA: default RSA key size is 2048 bits which is sufficient for SSH security recommendations, and previous value of 1024 bits is considered insecure.
Signed-off-by: Konstantin Demin <rockdrilla@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23217
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
rev22 has been ignored in fwsquash for the lack of supported binary blobs
containing the required firmware.
Now that fwcutter is able to parse the blob included in the gpl release
of dlink dsl 3580l, fwsquash need to keep the extracted files.
Signed-off-by: Alessio Ferri <alessio.ferri.3012@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23532
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Currently, Ralink SoCs use the default ARCH_DMA_MINALIGN value of 128
bytes defined in mach-generic. This is excessive for these platforms
and leads to significant memory waste in kmalloc.
Override ARCH_DMA_MINALIGN to use L1_CACHE_BYTES, which is 16 bytes for
RT288X and 32 bytes for other Ralink SoCs.
Signed-off-by: Qingfang Deng <dqfext@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23314
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
f5d17dd60a89 mstp: add default Hello Time constant
17c36bebada1 mstp: use default Hello Time in recordTimes
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Add a function to allow drivers to query the pending AQL airtime
for a given txq, for both unicast and broadcast.
This will be used for mt76 to limit buffering in AP mode for power-save
stations.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Add hardware TCP Large Receive Offload (LRO) support to the airoha_eth
driver, leveraging the EN7581/AN7583 SoC's 8 dedicated LRO hardware queues
mapped to RX queues 24–31. LRO hw offloading does not support
Scatter-Gather (SG) so it is required to increase the page_pool allocation
order to 2 for RX queues 24–31 (LRO queues).
Performance comparison between GRO and hw LRO has been carried out using
a 10Gbps NIC:
GRO: ~2.7 Gbps
LRO: ~8.1 Gbps
Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://github.com/openwrt/openwrt/pull/23530
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Currently, sysupgrade will only upgrade the unused slot, however since the
whole dual firmware logic is in the bootscript U-boot will just use the
first bootscript it finds.
So, in a case that you are running slot A it will upgrade slot B, however
that means that slot B will be still booted by the old bootscript that came
with the previous firmware version.
This is an issue if you need to change anything, so lets add a custom
function that upgrades the active bootscript as well after flashing the
slot firmware.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Methode uDPU and eDPU devices are one of the rare ones with a completely
custom image format being used with custom partition table with F2FS.
Instead of converting the boards to dual firmware (A/B style) and further
expand the already convoluted custom scripts, especially considering that
dual firmware conversion is a breaking change anyway, lets convert to using
the generic eMMC sysupgrade based images.
F2FS ZSTD compression is preserved thanks to fstools now supporting its use
on overlays.
Dual firmware support is implemented via U-Boot scripts so no U-Boot
upgrade is required.
Since there is a partition table layout change, eMMC must be wiped and
reflashed with the generated GPT image from OpenWrt initramfs.
Then on each sysupgrade the firmware slot will be altered.
Instructions:
1. Boot into OpenWrt initramfs
2. Copy openwrt-mvebu-cortexa53-methode_edpu-squashfs-emmc-gpt.img.gz to
the device into /tmp
3. Erase eMMC:
dd if=/dev/zero of=/dev/mmcblk0 bs=1M
4. Extract image
gzip -d /tmp/openwrt-mvebu-cortexa53-methode_edpu-squashfs-emmc-gpt.img.gz
5. Flash image
dd if=/tmp/openwrt-mvebu-cortexa53-methode_edpu-squashfs-emmc-gpt.img of=/dev/mmcblk0
6. Reboot
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
ELECOM WRC-X3000GST2 is a 2.4/5 GHz band 11ax (Wi-Fi 6) router based on
IPQ5018. The only hardware difference from the WRC-X3000GS2 is the RAM
capacity; all other peripherals are identical. This port therefore
reuses the GS2 board-2.bin (ipq-wifi-elecom_wrc-x3000gs2) and ath11k
calibration variant.
Specification:
- SoC : Qualcomm IPQ5018
- RAM : DDR3 512 MiB (Kingston Technology D2516ECMDXGJD)
- Flash : SPI-NAND 128 MiB (Macronix MX35UF1G24AD-Z4I)
- WLAN : 2.4/5 GHz 2T2R
- 2.4 GHz : Qualcomm IPQ5018 (SoC)
- 5 GHz : Qualcomm QCN6122
- Ethernet : 5x 10/100/1000 Mbps
- wan (phy) : Qualcomm IPQ5018 (SoC)
- lan (switch) : Qualcomm Atheros QCA8337
- LEDs/Keys (GPIO): 8x / 3x (reset, WPS, router/AP slide switch)
- UART : through-hole on PCB, 4pins near the barcode
- assignment : 3.3V, TX, RX, NC, GND from the barcode side
- settings : 115200n8
- Power : 12 VDC, 1 A (Max. 11.5W)
Flash instruction using factory.bin image:
1. Boot WRC-X3000GST2 normally in router mode
2. Access the WebUI ("http://192.168.2.1/") and open the firmware
update page ("ファームウェア更新")
3. Select the OpenWrt factory.bin image and click apply ("適用")
4. After the device reboots automatically, wait until the green power LED
stops blinking and stays solid
5. When the green power LED is solid, hold the reset button until the red
LED starts blinking to clear remaining stock firmware settings
Switching to the stock firmware:
1. Load the elecom.sh script
. /lib/upgrade/elecom.sh
2. Check the current index of rootfs
bootconfig_rw_index 0:bootconfig rootfs
3. Set the index to inverted value
bootconfig_rw_index 0:bootconfig rootfs <value>
bootconfig_rw_index 0:bootconfig1 rootfs <value>
example:
- step2 returned "0":
bootconfig_rw_index 0:bootconfig rootfs 1
bootconfig_rw_index 0:bootconfig1 rootfs 1
- step2 returned "1":
bootconfig_rw_index 0:bootconfig rootfs 0
bootconfig_rw_index 0:bootconfig1 rootfs 0
4. Reboot
Partition Layout (Stock FW):
0x000000000000-0x000000080000 : "0:SBL1"
0x000000080000-0x000000100000 : "0:MIBIB"
0x000000100000-0x000000140000 : "0:BOOTCONFIG"
0x000000140000-0x000000180000 : "0:BOOTCONFIG1"
0x000000180000-0x000000280000 : "0:QSEE"
0x000000280000-0x000000380000 : "0:QSEE_1"
0x000000380000-0x0000003c0000 : "0:DEVCFG"
0x0000003c0000-0x000000400000 : "0:DEVCFG_1"
0x000000400000-0x000000440000 : "0:CDT"
0x000000440000-0x000000480000 : "0:CDT_1"
0x000000480000-0x000000500000 : "0:APPSBLENV"
0x000000500000-0x000000640000 : "0:APPSBL"
0x000000640000-0x000000780000 : "0:APPSBL_1"
0x000000780000-0x000000880000 : "0:ART"
0x000000880000-0x000000900000 : "0:TRAINING"
0x000000900000-0x000003c40000 : "rootfs"
0x000003c40000-0x000003fc0000 : "Config"
0x000003fc0000-0x000007300000 : "rootfs_1"
0x000007300000-0x000007680000 : "Config_2"
0x000007680000-0x000007b80000 : "Reserved"
0x000007b80000-0x000007c00000 : "FWHEADER"
0x000007c00000-0x000007c80000 : "Factory"
Notes:
- This device has dual-boot feature and it's managed by the index in the
0:bootconfig and 0:bootconfig1 partitions.
- Wi-Fi BDF is shared with WRC-X3000GS2 (ipq-wifi-elecom_wrc-x3000gs2)
as the hardware (SoC, QCN6122, antennas) is identical between the two
models.
- GST2 stock firmware keeps its configuration even when sysupgrade is
called with -n. When installing from the OEM WebUI, those stock
settings can be restored into OpenWrt overlay, so settings must be
initialized after the first OpenWrt boot.
MAC Addresses:
LAN : 38:97:A4:xx:xx:40 (0:APPSBLENV, "eth1addr"/"ethaddr" (text))
WAN : 38:97:A4:xx:xx:43 (0:APPSBLENV, "eth0addr" (text))
2.4 GHz: 38:97:A4:xx:xx:41 (0:APPSBLENV, "wifi0" (text))
5 GHz : 38:97:A4:xx:xx:42 (0:APPSBLENV, "wifi1" (text))
Signed-off-by: Taiga Ogawa <zectaiga@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23471
Signed-off-by: Robert Marko <robimarko@gmail.com>
Hardware specification
----------------------
* RTL9301 SoC, 1 MIPS 34KEc core @ 800MHz
* 512MB DRAM
* 2MB NOR Flash
* 128MB NAND Flash
* 24 x 10/100/1000BASE-T ports with PoE+
* 4 x 10G SFP+ ports
* Power LED, Fault LED, PoE Max LED, LAN Mode LED, PoE Mode LED
* Reset button and LED Mode button on front panel
* LM63 Fan Controller
* UART (115200 8N1) via RJ45
* PSE: Nuvoton M0516LDE via I2C + 3x RTL8238B (not supported yet)
Installation using serial interface
-----------------------------------
1. Press "a" "c" "p" during message "Enter correct key to stop autoboot"
2. Start network "rtk network on"
3. Load image "tftpboot <TFTP IP>:openwrt-realtek-rtl930x_nand-linksys_lgs328mpc-v2-initramfs-kernel.bin"
4. Boot image "bootm"
5. Switch to first bootpartition "fw_setsys bootpartition 0"
6. Download sysupgrade "scp <IP>:openwrt-realtek-rtl930x_nand-linksys_lgs328mpc-v2-squashfs-sysupgrade.bin /tmp/."
7. Install sysupgrade "sysupgrade /tmp/openwrt-realtek-rtl930x_nand-linksys_lgs328mpc-v2-squashfs-sysupgrade.bin"
Installation using OEM webinterface
-----------------------------------
This is not possible because the OpenWrt NAND Flash layout is different
from the vendor layout. To be precise. Vendor uses:
- 64 MB vendor UBI root_data
- 32 MB vendor kernel+root 1 (~19 MB used)
- 32 MB vendor kernel+root 2 (~19 MB used)
OpenWrt uses:
- 64 MB vendor UBI (not touched)
- 10 MB OpenWrt kernel
- 22 MB Openwrt mtd-concat UBI
- 23 MB vendor kernel 2 (space reduced, vendor data unchanged)
- 09 MB OpenWrt mtd-concat UBI
Dual-boot with stock firmware using writable u-boot-env
-------------------------------------------------------
From stock to OpenWrt / primary image 1 (CLI as admin):
- > boot system image1
- > reboot
From OpenWrt to stock / boot image 2: (shell as root)
- # fw_setsys bootpartition 1
- # reboot
Debrick using serial interface
------------------------------
1. Press "a" "c" "p" during message "Enter correct key to stop autoboot"
2. Load vendor image with "upgrade runtime <TFTP IP>:LGS328xxxxx.imag"
3. switch to primary partition "setsys bootpartition 0"
4. safe config "savesys"
MAC Address Source
------------------
The MAC address for this device is coming from the u-boot-env ethaddr cell.
Further documentation
---------------------
See https://openwrt.org/toh/linksys/lgs352c
Signed-off-by: Jan-Henrik Bruhn <git@jhbruhn.de>
Link: https://github.com/openwrt/openwrt/pull/23466
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
This is in preparation for the addition of the LGS328MPC, which is
based on the LGS328C.
It also drops the unused UBINIZE_OPTS, as UBI is only used during runtime
of the firmware, not during build.
Signed-off-by: Jan-Henrik Bruhn <git@jhbruhn.de>
Link: https://github.com/openwrt/openwrt/pull/23466
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Make deactivate fully restore the SerDes to an inert state at both the
MAC and IP layers. Previously deactivate only zeroed the MAC mode via
set_mode(OFF), which on the default branch only writes the MAC mode
register and leaves the IP mode register untouched. The IP mode register
then retained whatever the previous bring-up left behind (force=1 with
a stale mode value, or force=0 from boot defaults), making "deactivate"
not fully deactivate the SerDes.
Replace the set_mode(OFF) call with explicit set_mac_mode(OFF) plus
set_ip_mode(OFF). The latter writes force=1 with mode=OFF, pinning the
IP block to OFF until a subsequent bring-up takes a defined action.
This forced-OFF state would break MAC-driven modes (USXGMII / QSGMII /
XSGMII), which set only the MAC mode register and rely on the IP block
following along. To compensate, add an explicit unforce of the IP mode
force-bit (page 0x1f reg 0x09 bit 6) at the start of the MAC-mode branch
of rtpcs_930x_sds_set_mode. IP-mode bring-up via apply_ip_mode is
unaffected -- it re-asserts force=1 with the target mode value, which
overrides the deactivate force-OFF.
Net result: deactivate fully and explicitly deactivates the SerDes; each
set_mode path takes its own responsibility for the IP mode register
state. The previous asymmetric behaviour (set_mode default branch silently
not touching the IP register) is now explicit code rather than an
implicit accident-of-dispatch.
Verified on RTL930x hardware: SGMII, 2500BASE-X, 10GBASE-R, USXGMII-QX
and XSGMII all bring up correctly with link, traffic and iperf3 as
expected.
Link: https://github.com/openwrt/openwrt/pull/23513
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Aleksander Jan Bajkowski
Markus Stockhausen
Guoxin Pu
Paul Donald
Ryan Leung
Taiga Ogawa
Chukun Pan
Lars Gierth
John Audia
Lorenzo Bianconi
Robert Marko
Lech Perczak
Alexandru Gagniuc
Konstantin Demin
Alessio Ferri
Qingfang Deng
Daniel Golle
Stijn Tintel
Felix Fietkau
Jan-Henrik Bruhn
Tianling Shen
Rosen Penev
Jonas Jelonek