econet: Add new target TP-Link Archer VR1200v (v2)
The TP-Link Archer VR1200v (v2) is a low end DSL modem based on the
EcoNet EN751221 processor platform.
While it does have an unlocked bootloader, the factory upgrade feature
requires a cryptographic signature so flashing from the web UI is not
feasible.
The Archer VR1200v (v2) uses a dual-image layout. I have chosen to reuse
this to support dual-boot between OpenWRT and the factory firmware.
Flashing instructions (from bootloader):
Build and then locate the squashfs-sysupgrade.bin image file
Get the length of that file in hex: printf '%X\n' "$(stat -c%s the-file-squashfs-sysupgrade.bin)"
Connect to device with xmodem capability, e.g. picocom --send-cmd lsx -vv -b 115200 /dev/ttyUSB0
Switch device on and press a key within 3 seconds, you should get to a `bldr>` prompt
Type: xmdm 80020000 <file length hex>
Quickly start xmodem and send the file, in picocom that is ctrl+a ctrl+s <paste-the-file-name> enter If the transfer fails to start, wait 30 seconds to a minute for the bootloader prompt to return and then try the command again.
Once the transfer has completed successfully, type the following flash 80000 80020000 <file length hex>
Type `re` or simply restart the device to boot into OpenWRT
The SmartFiber XP8421-B is a fiber modem which is available for $20 online
and has 512MB of memory, 256MB of SPI NAND flash and 2 USB 2.0 ports in
addition to ethernet, wifi and XPON.
Because EcoNet is not currently producing evaluation boards, the XP8421-B
stands in as a convenient, low cost, off-the-shelf, representitive example
of the capabilities of the EN751221 econet processor. This is also the
example board that is included in the upstream Linux patchset.
The XP8421-B, and apparently many other devices of this platform, use a
dual-image layout. I have chosen to reuse this to support dual-boot between
OpenWRT and the factory firmware. Certain design decisions were made with
the goal of not overwriting data that is used by the factory OS.
This commit also introduces a utility for switching between OS_A and OS_B
which are used for OpenWRT and Factory OS respectively.
Flashing instructions (from bootloader):
Build and then locate the squashfs-tclinux.trx image file
Get the length of that file in hex: printf '%X\n' "$(stat -c%s the-file-squashfs-tclinux.trx)"
Connect to device with xmodem capability, e.g. picocom --send-cmd lsx -vv -b 115200 /dev/ttyUSB0
Switch device on and press a key within 3 seconds
Enter bootloader username and password: telecomadmin nE7jA%5m
Type: xmdm 80020000 <file length hex>
Quickly start xmodem and send the file, in picocom that is ctrl+a ctrl+s <paste-the-file-name> enter If the transfer fails to start, wait 30 seconds to a
minute for the bootloader prompt to return and then try the command again.
Once the transfer has completed successfully, type the following flash 80000 80020000 <file length hex>
Type go or simply restart the device to boot into OpenWRT
EcoNet EN75xx is a big endian MIPS platform used in XPON (fiber),
DSL, and SIM (3g/4g) applications. Complete GPL vender SDKs exist
for this platform, but are based on Linux 2.6.
The bulk of this submission has already been accepted upstream:
https://patchwork.kernel.org/project/linux-mips/list/?series=960479&state=*
This platform uses a bootloader that is derived from old TrendChip
code. This bootloader implements a frustratingly complex Bad Block
Table which is implemented here in en75_bmt.c
This BMT is not upstreamed because it depends on mtk_bmt framework
which likewise is not upstreamed.
This BMT system rewrites block indexes in flash and if the bootloader
considers it to be corrupted, it will attempt to automatically rebuild
on boot. So without implementing the algorithm, you can't safely use
the disk at all.
Hardware
--------
RockChip RK3568 ARM64 (4 cores)
1/2GB LPDDR4 RAM
2x 2500 Base-T (PCIe, r8125b)
1 LED (Power)
1 Button (Reset)
Micro-SD Slot
2x USB 3.0 Port
12V DC Jack
Installation
------------
Uncompress the OpenWrt sysupgrade and write it to a micro SD card using
dd.
Tested-by: Francisco G Luna <frangonlun@gmail.com> Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org> Link: https://github.com/openwrt/openwrt/pull/19990 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Tested-by: Francisco G Luna <frangonlun@gmail.com> Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org> Link: https://github.com/openwrt/openwrt/pull/19990 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
ramips: switched TP-Link RE305 v1 to new partition layout
After trying to implement the gluon support for this device I ended up in a boot loop due to the usable amount of flash left. With this patch layout it uses the unused and empty flash space in the original partiton layout.
The version 3 of this device the RE365 share the same approach to have more usable space.
A lot of definitions in the global mach include have been taken over
to the individual drivers. Only a few of the definitions are really
used nowadays. Remove all the unneeded lines.
Elbert Mai [Sat, 12 Jul 2025 12:58:59 +0000 (05:58 -0700)]
bcm2712: add kmod-r8169 and kmod-usb-net-rtl8152
Boards such as [1] and [2] add an extra Ethernet port to Raspberry Pi (CM)5.
These typically use Realtek PCIe or USB Ethernet NICs. Include kmod-r8169 and
kmod-usb-net-rtl8152 by default to make it easy to configure LAN/WAN ports
with these parts on Raspberry Pi 5.
Because CM5 can fit in the same carrier boards as CM4, also ensure that both
devices have the same Ethernet NIC kmods.
Zoltan HERPAI [Mon, 11 Aug 2025 16:58:20 +0000 (18:58 +0200)]
sunxi: enable at24 support
Certain boards have an at24(-compatible) EEPROM for storing various
parameters like MAC addresses. Enable support for this hardware across
the whole target.
Zoltan HERPAI [Mon, 11 Aug 2025 16:59:04 +0000 (18:59 +0200)]
uboot-sunxi: randomize ethaddr on Olimex A20 boards
While these boards have an at24 EEPROM for storing the MAC address,
early revisions (up until about 2017) did not contain actual addresses.
Create a random address to have ethernet function properly in u-boot.
airoha: backport upstream fixes for pinctrl PHY LED and MDIO
Backport fixes for Airoha pinctrl driver for PHY LED and MDIO bus. This
fix a copy-paste error for PHY LED and a misconfiguration for MT7530
embedded Switch MDIO bus GPIO pin to permit usage of external PHYs.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Jan Kardell [Mon, 8 Sep 2025 06:52:40 +0000 (08:52 +0200)]
libxml2: Add abi version
The version of libxml2 was bumped from 2.13.6 to 2.14.5. Since version
2.14, libxml2 is not binary compatible with older versions. Therefore
add an abi version.
From the NEWS file:
Binary compatibility is restricted to versions 2.14 or newer. On ELF
systems, the soname was bumped from libxml2.so.2 to libxml2.so.16.
gettext-full only provides libintl which is not licensed under
GPL-3.0.-or-later but under LGPL-2.1-or-later as stated in
gettext-runtime/intl/COPYING.LIB
Fixes: c10d97484a43375a0446dafc8cb4072e26502f37 (Add more license tags with SPDX identifiers) Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Link: https://github.com/openwrt/openwrt/pull/19943 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
elfutils libraries are not licensed under GPL-3.0-or-later, they are dual
licensed: GPL-2.0-or-later OR LGPL-3.0-or-later as clearly stated in
source files as well as on https://sourceware.org/elfutils:
The libraries and backends are dual GPLv2+/LGPLv3+. The utilities are GPLv3+.
Installation:
* Upload factory image through the tftp recovery mode.
Notes:
* This device has a dual-boot partition scheme, if installing with the
stock web interface method will flash only on the inactive ubi partitions
which are kernel and rootfs, newly flashed kernel didn't know the proper
rootfs partition so the booted kernel will panic.
Tested-by: Rhnn Hur <hurrhnn@icmp.kr> Signed-off-by: Rhnn Hur <hurrhnn@icmp.kr> Link: https://github.com/openwrt/openwrt/pull/16643 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
All devices supported by the Zynq target have either a Realtek or Marvell
PHY. The Vitesse PHY was enabled when the target was created (2d45ad07fc64).
It's not used here, so it's safe to disable it.
Ethernet PHYs used by individual devices are listed below.
Mikhail Zhilkin [Thu, 14 Aug 2025 16:15:09 +0000 (19:15 +0300)]
uboot-mediatek: add support for FudanMicro FM25S01A
This patch adds support for FudanMicro FM25S01A SPI NAND. It's required
for some CMCC RAX3000Me hardware revisions.
The patch was partially taken from ImmortalWrt.
Link:
https://raw.githubusercontent.com/immortalwrt/immortalwrt/refs/heads/master/package/boot/uboot-mediatek/patches/342-mtd-spinand-Support-fmsh.patch
Michal Halva [Sat, 2 Aug 2025 18:46:14 +0000 (20:46 +0200)]
mediatek: filogic: add support for Cudy WR3000P v1
Hardware
--------
MediaTek MT7981 WiSoC
512MB DDR4 RAM
128MB SPI-NAND
MediaTek MT7981 2x2 DBDC 802.11ax 2T2R (2.4 / 5)
4 LAN MediaTek MT7531 PHY
1 WAN RTL8221B-VB-CG 2.5Gbps PHY
UART: 115200 8N1 3.3V
USB2 Port
PoE on WAN Port
MAC:
LAN MAC: label mac
WAN MAC: label mac + 1
2.4G MAC: label mac
5G MAC: label mac + 1 with LA bit set
Gotchas:
WAN LED does not light up (might require further DTS tweaks)
PoE on WAN port was not tested
This commit is heavily based on WR3000H one, I've just ported DTS differences
from the official image to get USB support and proper LED mapping.
Installation
------------
[Untested as I've received and used a transitional image from Cudy]
1. Connect to the serial port as described in the "Hardware" section.
2. Power on the device + press reset pin. Keep pressing reset pin to enter the U-Boot shell.
3. Download the OpenWrt initramfs image. Place it on an TFTP server
connected to the Cudy LAN ports. Make sure the server is reachable at
192.168.1.88. Rename the image to "cudy3000p.bin"
So much code was distributed between phy/ethernet/dsa drivers. A lot
was already cleand up before. With this step the mdio bus gets its
own space and is no longer hidden inside the ethernet driver.
This commit is mostly a copy/paste that includes only minor changes.
- define prefixes are renamed to RTMDIO
- The driver is totally self contained (does not rely on SoC include)
- The DTS structure (mdio node below ethernet node) was kept
- The driver is added to the kernel config of all subtargets.
The ethernet and mdio code will be splitted. The dsa driver depends
on proper loading of both, before switch setup can start. Sadly there
are severe cleanup issues in the probe() function if one of the
required devices is not available.
As a temporary workaround provide a dedicated check function that
verifies if the ethernet platform device driver is loaded and can
be used.
At the end of RX NAPI polling the counter and mask registers are
cleaned up. Although this might run in parallel there is no
synchronization and the register modifications are some wild mix.
RTL83xx enables only the interrupt of a single ring while RTL93xx
just reactivates all interrupts (even for other NAPI threads).
Make use of the driver lock and only modify the interrupt bits that
the current thread owns.
Now that the counter registers work fine there is no need to
free buffers in software. Hardware will automatically block
input processing when software processing is too slow.
realtek: RTL93xx: Make use of correct ring size counters
The receive path of the RTL93xx SoCs is currently discarding packets
in software. Analysis gives the following explanation:
- RX ring size registers are setup with the full software ring size
- When packets are received the packet counter registers are increased
- After RX processing the counter registers are changed the wrong way
- From then SOC is allowed to receive more packets than software allows
- Overflow interrupts are fired
- As a reaction to that the software drops packets
Change the processing as follows:
- Setup ring size registers with a headroom of 2 buffers
- Decrease the counter registers with the real work done
With this change no more overflow interrupts occur because the SoC
disables the queues before they can overflow or hit a buffer that is
still owned by the CPU.
Benchmark from single stream iperf3 run, with server process running
on ZyXEL XGS1210 (RTL930x).
realtek: drop RTL8226/RTL8221B downstream PHY driver
Since we are using upstream PHY drivers there is no more need
for the downstream version. Side effect is that the SoC dependent
polling functions are no longer needed. This was always wrong
in this driver.
kernel: update and move net bridge patch to backport folder
Update patch 642-net-bridge-locally-receive-all-multicast-packets-if-.patch to upstream version
and move to backport folder as 625-v6.16-net-bridge-locally-receive-all-multicast-packets-if-.patch
because kernel 6.16 already includes it.
A new version of the ZyXEL XGS1210-12 has been discovered in
the wild. It includes at least two known hardware changes
- lan9/lan10 use RTL8221B instead of RTL8226
- lan9/lan10 use different SMI busses
Pave the new device the way by splitting the existing DTS.
According to the vendor website the models are named
- A1 (first version): not explicetly labeled
- B1 (second version): Label Rev. B1 on device
Rename the current OpenWrt device definition to A1 as it was
made for the first version. To stay compatible with older
installations, add the old device name to the list of
supported devices.
realtek: rt-loader: add ROM uImage lookup (aka standalone)
The rt-loader currently only supports booting piggy backed lzma
compressed kernels. This requires a data layout where the kernel
directly follows the loader. That might not be sufficient for
more complex flash layouts.
Especially bootbase devices (like ZyXEL GS1920) will need some
kind of chain loading that needs to be explored yet.
Enhance the rt-loader as follows:
- Allow to build as standalone version
- In this case a flash start address is given
- During boot loader will search the ROM starting from that address
- If it finds a uImage this will be loaded into RAM
- Afterwards it will be decompressed to its load address
- While we are here add uncompressed uImage support
As always the implementation tries to be as simple as possible.
- uImage detection works without magics
- uImage will be loaded to highest possible memory address
- Documentation in Makefile has been adapted accordingly
Funny side fact: A standalone rt-loader can chain load a piggy
backed rt-loader from flash.
During bootup loader will show
rt-loader
Running on RTL8380M (chip id 6275C) with 256MB
Relocate 15760 bytes from 0x82000000 to 0x8ffa0000
Searching for uImage starting at 0xb45a0000 ...
uImage 'MIPS OpenWrt Linux-6.12.40' found at 0xb45a0000 with load address 0x80100000
Copy 2923034 bytes of image data to 0x8fcd61e6 ...
Extract image with 2923034 bytes from 0x8fcd61e6 to 0x80100000 ...
Final kernel size is 2923034 bytes
Booting kernel from 0x80100000 ...
Registers must not be accessed in parallel by multiple drivers.
Read-modify-write operations are not atomic, and the result of parallel
access is undefined.
The MAC_L2_GLOBAL_CTRL2 register is essentially a pin configuration
register and is represented by a pinmux node in the devicetree. Operations
on this register by the realtek,rtl838x-eth driver must therefore also be
reflected in the devicetree.
Since the MDIO sets used are board-specific, the pins must be enabled in
the board’s devicetree. This can be achieved using the pinctrl properties
for the realtek,rtl83xx-switch.
Sven Eckelmann [Wed, 20 Aug 2025 03:19:31 +0000 (05:19 +0200)]
realtek: rtl931x: Add LED Sync configuration
The pinmux-related registers on the RTL931X SoC family are spread across
various non-consecutive registers. It might be tempting to modify them
directly in a specific driver (SPI, LED, etc.), but this would cause issues
with parallel, non-locked read-modify-write operations, which are required
to update individual portions of these registers.
Instead, it is better to use the devicetree pinctrl properties to define
the correct configurations for the various operation modes.
One important setting here is the LED Sync bit. This allows the LED
controller to generate an additional positive edge on the `STCP`
("STore Clock Pin", also known as `RCLK`) of the LED shift register after
the actual content has already been shifted in using the normal shift
clock. The LED shift register is then expected to copy the content from the
shift register section into the storage registers, which act as the actual
LED output control. This functionality is available in, and commonly used
with, the SNx4HC595 family of shift registers.
To activate it, simply register it in the default state of the
"realtek,rtl83xx-switch" node:
It would be nicer when this can be directly added to the led subnode. But
for this to work, `realtek,rtl9300-leds` must first be an actual driver
(known to the driver core).
Suggested-by: Bevan Weiss <bevan.weiss@gmail.com> Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://github.com/openwrt/openwrt/pull/19815 Signed-off-by: Robert Marko <robimarko@gmail.com>
The MAC_L2_GLOBAL_CTRL2 register is primarily used for pin configuration.
It is necessary to select specific modes for pins or to free them for use
as GPIOs.
Fixes: 9dbc04785c4e ("realtek: add rtl8231-aux to rtl931x.dtsi") Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://github.com/openwrt/openwrt/pull/19815 Signed-off-by: Robert Marko <robimarko@gmail.com>
The pinmux-related registers on the RTL930X SoC family are spread across
various non-consecutive registers. It might be tempting to modify them
directly in a specific driver (SPI, LED, etc.), but this would cause issues
with parallel, non-locked read-modify-write operations, which are required
to update individual portions of these registers.
Instead, it is better to use the devicetree pinctrl properties to define
the correct configurations for the various operation modes.
One important setting here is the LED Sync bit. This allows the LED
controller to generate an additional positive edge on the `STCP`
("STore Clock Pin", also known as `RCLK`) of the LED shift register after
the actual content has already been shifted in using the normal shift
clock. The LED shift register is then expected to copy the content from the
shift register section into the storage registers, which act as the actual
LED output control. This functionality is available in, and commonly used
with, the SNx4HC595 family of shift registers.
To activate it, simply register it in the default state of the
"realtek,rtl83xx-switch" node:
It would be nicer when this can be directly added to the led subnode. But
for this to work, `realtek,rtl9300-leds` must first be an actual driver
(known to the driver core).
Suggested-by: Bevan Weiss <bevan.weiss@gmail.com> Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://github.com/openwrt/openwrt/pull/19815 Signed-off-by: Robert Marko <robimarko@gmail.com>
projects / thirdparty / openwrt.git / log
