This commit adds support for a dual-band AC1200 wall plug
manufactured by Shenzhen Century Xinyang Tech Co., Ltd.
SoC: Mediatek MT7628AN (MIPS 24KEc single core, 580 MHz)
RAM: 128 MiB DDR2 (Hynix HY5PS1G1631C)
ROM: 8 MiB SPI NOR (Zbit ZB25VQ64ASIG)
Wired: one FE RJ45 port (+ an unpopulated footprint for a 2nd)
WiFi: Mediatek MT7612E
Ant.: four 2 dBi external antennas (two 2.4GHz, two 5 GHz)
LEDs: - Power (green, always on)
- 2.4G (green, controlled by MT7628)
- 5G (green, controlled by MT7612)
- Extender (green, GPIO 37, used as status LED)
- LAN (green/yellow, controlled by RT3050 ESW)
Buttons: WPS and reset (both connected to GPIO 38)
Power: 5V 2-pin JST-XH on main PCB
110/220V AC to 5V 1.5A DC on auxiliary PCB
UART: 57600 8n1 3.3v, holes available on the PCB as J5
pinout is (Gnd) (Tx) (Rx)
MAC: 1C:BF:CE:xx:xx:xx (2.4 GHz, label)
1C:BF:CE:xx:xx:xx + 1 (LAN)
1C:BF:CE:xx:xx:xx + 2 (WAN, not in use)
1C:BF:CE:xx:xx:xx + 3 (5 GHz)
Original firmware is Chaos Calmer 15.05.01 (kernel 3.10.108)
with a few custom packages and a non-LuCI web interface.
Telnet is enabled, requiring an unknown root password [1].
Root password is also needed to access the router via UART console,
but passwordless telnet can be enabled via a trivial web exploit [2]
and then the root password can be removed by editing `/etc/shadow`.
Installation: Upload `sysupgrade` binary via web interface at
`http://192.168.188.1/settings.shtml`. Alternatively, remove
root password and use u-boot menu to flash image via TFTP.
Notes:
- Device model in Chaos Calmer is "mtk-apsoc-demo".
- It is sold under several brands, e.g., Fenvi and Linkavenir.
It is available in two colors: white and black.
- PCB is marked "WD206AD v1.0".
- Instead of a standard ethernet transformer, the PCB has a few tiny
SMD coils.
- The housing is identical to the one used by a 2020 model,
WD-R1203U, which is RTL8812-based. The older model has an FCC
listing with external and internal images: ZNPWD-R1203U.
The FCC listing contains a letter [3] claiming WD-R1203U and
WD-R1208U are internally identical, but evidently they are not.
[1] root:$1$7rmMiPJj$91iv9LWhfkZE/t7aCBdo.0:18388:0:99999:7:::
This is the same hash as in Wodesys WD-R1802U.
There are other root password hashes in `/etc/shadow_sf` and
`/etc/shadow_yn`.
[2] curl -X POST http://192.168.188.1/cgi-bin/adm.cgi \
-d page=Lang -d langType="en;killall telnetd;telnetd -l /bin/sh"
[3] https://fcc.report/FCC-ID/ZNPWD-R1203U/4767033
realtek: rtl931x: Sync family parameters with RTL930x
Some of the parameters added to RTL9300_FAMILY_ID are missing for
RTL9310_FAMILY_ID. Simply add the missing ones to keep sharing code between
the two SoCs.
Harshal Gohel [Tue, 17 Jun 2025 12:46:42 +0000 (12:46 +0000)]
realtek: rtl931x: Fix VLAN tagging and untagging
* In RTL931x, bit 31 of the (4th column) of 802_1Q_VLAN_QINQ table
indicates the validity of l2 tunnel. Before bit 63 (3rd column)
was being checked for validity of l2 tunnel.
* The untagged_ports requires 64 bits to represent 56 ports. Do not
store u64 in u32 variable
* First 24 ports are represented in the 2nd register not just first 20
OpenFi 6C is a portable Wi-Fi 6 travel router based on MediaTek MT7981B+MT7976CN.
Two slightly different versions have been sold. The V1 board has a green color and lacks the modem LED. The V2 board is black and has a LED for the modem. The firmware should work on both of them.
Specifications:
- SoC: MediaTek MT7981B (Filogic 820) 1.3GHz dual-core ARM Cortex-A53
- RAM: 1GB DDR4
- Flash: 256MB SPI NAND
- Wireless: 2.4GHz/5GHz 802.11ax
- Ethernet: 1x 10/100/1000M LAN
- USB: 1x USB 3.0 Type-A port
- Expansion: M.2 slot for 5G modem
- Cooling: PWM-controlled fan
- Buttons: Reset, Mode switch
- LEDs: System, Ethernet, 5G WiFi, Modem status
**Installation via U-Boot web page**
1. Set static IP 192.168.21.2/255.255.255.0 on your computer.
2. Connect to the Ethernet port and hold the reset button while booting the device. Wait for 6-8 seconds, and release the reset button.
3. Open U-boot web page on your browser at http://192.168.21.1
4. Select the OpenWRT sysupgrade image, upload it, and start the upgrade.
5. Wait for automatic reboot.
**Installation via sysupgrade**
Flash the sysupgrade file via LuCI upgrade page without saving the settings.
TFTP Installation(recommend)
------------
1. Set local tftp server IP "192.168.1.254" and NetMask "255.255.255.0".
2. Rename initramfs-kernel.bin to "factory.bin" and put it in the root
directory of the tftp server. tftpd64 is a good choice for Windows.
3. Remove all Ethernet cables and WiFi connections from the PC, except
for the one connected to the SIMAX1800U. Start the TFTP server, plug
in the power adapter and wait for the OpenWrt system to boot.
4. Backup "firmware" partition and rename it to "firmware.bin". We need
it to back to the stock firmware.
5. Use "fw_printenv" command to list envs. If "firmware_select=2" is
observed then set u-boot env variable via command:
`fw_setenv firmware_select 1`
6. Apply sysupgrade.bin in OpenWrt LuCI.
Web UI Installation
------------
1. Apply update by uploading initramfs-factory.bin to the web UI.
2. Use "fw_printenv" command to list envs. If "firmware_select=2" is
observed then set u-boot env variable via command:
`fw_setenv firmware_select 1`
3. Apply squashfs-sysupgrade.bin in OpenWrt LuCI.
Return to Stock Firmware
----------------------------
Restore the backup firmware partition in the installation step 4.
MAC addresses
-------------
+---------+-------------------+
| | MAC example |
+---------+-------------------+
| LABEL | 98:xx:xx:xx:xx:b2 |
| LAN | 98:xx:xx:xx:xx:b5 |
| WAN | 98:xx:xx:xx:xx:b2 |
| WLAN2G | 98:xx:xx:xx:xx:b4 |
| WLAN5G | 9a:xx:xx:xx:xx:b4 |
+---------+-------------------+
Tips:
-----------
User can use `TFTP Installation` method to recover a brick device.
The vendor DTS defined incorrect GPIOs for the LEDs, which caused them
to not function properly. Initially, the WAN, WLAN LEDs appeared to
work, but further testing showed that they were non-functional.
This patch corrects the GPIO assignments in the DTS, restoring full LED
functionality including blinking, except the power LED which cannot be
software controlled.
Tested on a CF-EW71 v2 unit.
Fixes: ee3a6adc6c22 ("ath79: add support for Comfast CF-EW71 v2") Signed-off-by: Felix Golatofski <git@xdfr.de> Link: https://github.com/openwrt/openwrt/pull/19665 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Issam Hamdi [Thu, 20 Feb 2025 15:06:00 +0000 (16:06 +0100)]
realtek: dsa: rtl83xx: flush scheduled work on removal
The workqueue items don't need to be processed directly when they are
scheduled. It can happen that they are simply processed at a much later
time. It is therefore necessary to ensure that all workqueue items of a
driver are no longer being processed before the driver (or structures of
this driver) are destroyed.
When skipping this step, the driver driver can cause a kernel Oops on
reboot.
Unfortunately, it is not recommended [1] to flush items out of the system
workqueue - simply because this can cause deadlocks. The driver itself must
have a private workqueue which is then flushed.
Harshal Gohel [Thu, 6 Mar 2025 07:47:18 +0000 (07:47 +0000)]
realtek: rtl930x: Fetch link status for all ports in switch IRQ
Link status needs to be read twice, and a single register value is
enough for determining link status for all the ports
It is not necessary to go through each potential port separately and later
actually identify for which ports the interrupt actually was. The helper
for_each_set_bit() directly iterate through all set bits.
While at it, rename the function to a proper naming scheme.
Currently the SerDes driven SFP ports give strange ethtool readings
on RTL93xx devices. Especially duplex and speed are shown even if
no link is up and running. That leads to confusion because the MAC
reports arbitrary values.
Enhance the readout by refactoring the pcs_get_state() function.
Calculate speed/duplex/pause only if link is detected.
Felix Fietkau [Thu, 7 Aug 2025 13:44:56 +0000 (15:44 +0200)]
procd: update to Git HEAD (2025-08-07)
84372dab89a8 hotplug: switch to using avl tree for hotplug subsystems 4d023b8a8c51 hotplug: send event notifications 467800980021 hotplug: ensure that the button subsystem is always registered
Steve Wavler [Sun, 3 Aug 2025 19:59:16 +0000 (15:59 -0400)]
x86: add board mapping for Sophos XG 210r3
Sophos XG 210r3 is a rackmounted x86 based firewall with 6 RJ-45 gigabit
ethernet ports (eth0-5) and 2 SFP gigabit ethernet ports (eth6, eth7)
all running Intel NICs supported by igb driver. This board update maps
eth0 (left most RJ-45 port) as wan and eth1-7 as lan.
Steve Wavler [Sun, 3 Aug 2025 13:02:55 +0000 (09:02 -0400)]
kernel: Add kmod-sfc-siena for Solarflare SFN5000/6000 series NICs
kmod-sfc should add support for Solarflare SFC9000 series based cards.
However after kernel 5.19, support for the 'Siena' subclass of
SFN5000/6000 devices has been separated out since they went EOL as they
are no longer being actively developed. As kmod-sfc no longer provides
driver support for these cards and hasn't since kernel 5.2, a new kernel
module is needed to support these 10Gb Ethernet cards. More info here:
https://cateee.net/lkddb/web-lkddb/SFC_SIENA.html and here:
https://www.phoronix.com/news/Solarflare-SFC-Siena-Linux-5.19
The module can be compiled in separately and works if kernel is custom
compiled;
OpenWRT has made these changes already with the SFC 'falcon' subclass of
drivers already. See 3c5d70a and e5ba6e9
This is building on excellent work by @ynezz and @nasbdh9
realtek: use consistent definition in DTS for SFP(+) ports
We are slowly getting to the point where the mdio driver will be
carved out from the ethernet driver. Since the beginning it had
the feature to hand out SFP serdes as phys. So one can access
them from the phy driver. This will be kept during the final
migration and it even will provide a consistent interface for the
phy/serdes registers.
With this being done we need to identify how to handle the affected
ports in a generic way for all targets. Doing first things first,
this starts with a consistent DTS. Currently we have:
for all other RTL93x devices:
phy-mode = "10gbase-r"
managed = "in-band-status"
pseudo-phy-handle = ...
Looking at the phylink kernel code one can see a nifty detail.
There is dynamic phy bringup depending on the mode.
int phylink_fwnode_phy_connect(struct phylink *pl,
const struct fwnode_handle *fwnode,
u32 flags)
{
struct fwnode_handle *phy_fwnode;
struct phy_device *phy_dev;
int ret;
/* Fixed links and 802.3z are handled without needing a PHY */
if (pl->cfg_link_an_mode == MLO_AN_FIXED ||
(pl->cfg_link_an_mode == MLO_AN_INBAND &&
phy_interface_mode_is_8023z(pl->link_interface)))
return 0;
...
}
Where 802.3z means 1000base-x or 2500base-x. Aligning this with
IEEE specs it means essentially:
- 10gbase-r defined ports with phy-handle must statically bring up
a phylink from the beginning that immediately depends on a
phy read_status() implementation.
- 1000base-x/2500base-x defined ports will dynamically bringup a
phylink during link detection regardless of a phy-handle. So
it usually runs at the moment when a SFP has been plugged in.
We currently still rely on a phy-handle but do not want to bring
up the phy immediately. Commit 4457c1eee49 ("realtek: rtl93xx:
support SFPs with phys") tried to fix exactly that error for
10gbase-r definied ports. Kernel shows "sfp sfp-p8: sfp_add_phy
failed: -EBUSY" in that case.
But it did it in the wrong way. It implemented a workaround by
introducing a DTS property "pseudo-phy-handle". Instead it
should have simply converted the DTS nodes to 1000base-x.
Revert the commit and fix the DTS with wrong definitions. From
now on we have a consistent SFP definition throughout all DTS
and targets.
Aside from the positive effect this setting has it is more or
less an arbitrary speed definition. When plugging in the SFP the
real speed will be choosen dynamically.
Fixes: 4457c1eee49 ("realtek: rtl93xx: support SFPs with phys") Tested-By: Bjørn Mork <bjorn@mork.no> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://github.com/openwrt/openwrt/pull/19648 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
realtek: rtl930x: convert Hasivo S1100W to lzma only.
The current build recipe creates a lzma based initramfs and
a gzip based sysupgrade (installation) image. No need to
use different compression methods. Use lzma for both.
Tested-by: Andrew LaMarche <andrewjlamarche@gmail.com> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://github.com/openwrt/openwrt/pull/19669 Signed-off-by: Robert Marko <robimarko@gmail.com>
Jan Hoffmann [Tue, 5 Aug 2025 00:41:32 +0000 (02:41 +0200)]
realtek: move and clean up CHIP_INFO register definitions
Move the definitions to mach-rtl83xx.h, so they can be used during init
to read more detailed SoC information. Also rename the RTL931X register,
as it has the same address on all RTL93xx.
Jan Hoffmann [Sat, 2 Aug 2025 18:28:50 +0000 (20:28 +0200)]
realtek: simplify SoC detection
Read model name from the register instead of using hard-coded values.
Also remove detection of the unsupported Realtek ESW/SSW SoCs. The Fast
Ethernet variants of the Maple and Cypress series stay for now, but are
moved to the RTL8380/RTL8390 families.
Felix Fietkau [Wed, 6 Aug 2025 09:09:57 +0000 (11:09 +0200)]
mac80211: estimate expected throughput if not provided by driver/rc
Estimate the tx throughput based on the expected per-packet tx time.
This is useful for mesh implementations that rely on expected throughput,
e.g. 802.11s or batman-adv.
Jonas Jelonek [Mon, 4 Aug 2025 09:17:55 +0000 (09:17 +0000)]
realtek: use lzma recipe for TP-Link TL-ST1008F v2.0
Use the lzma recipe for the device for both initramfs and sysupgrade to
save some flash space due to smaller image. U-Boot build on this device
has native lzma support.
realtek: rtl930x: move serdes functions over to mdio bus
The migration of the RTL930x mdio/serdes access functions over to the
mdio bus is a little more complicated than for RTL83xx. There are several
places where the serdes is accessed directly. So do it in two steps. With
this first step:
- use the rtmdio prefix for the serdes reader/writer functions
- move the functions over to the bus (inside the ethernet driver)
- Adapt all callers.
This is not only a copy/paste but the serdes access will be hardened too.
For this:
- put a mutex around the read/write functions because we have only
indirect register access through a mdio style bus.
- Verify input values to avoid data mess.
Tested-by: Bjørn Mork <bjorn@mork.no> Tested-by: Jan Hoffmann <jan@3e8.eu> Tested-by: Jonas Jelonek <jelonek.jonas@gmail.com> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://github.com/openwrt/openwrt/pull/19662 Signed-off-by: Robert Marko <robimarko@gmail.com>
Nick Hainke [Tue, 5 Aug 2025 16:21:55 +0000 (18:21 +0200)]
ead: replace legacy RETSIGTYPE with void in signal handler
The RETSIGTYPE macro was historically used for signal handler return types,
defaulting to int on some legacy systems. This is no longer needed,
so we now use void as the return type.
Fixes a compiler error:
error: assignment to 'void (*)(int)' from incompatible pointer type 'int (*)()' [-Wincompatible-pointer-types]
realtek: RTL839x: reorganize mdio functions and SerDes register layout
The RTL839x mdio functions are scattered around the code. Relocate
them to the bus (still inside the ethernet driver).
Additionally provide a consistent SerDes register access through the
mdio bus. Until now when a SerDes directly drives a SFP module there
is no clear rule of how to handle its register set that consists of
two parts:
- c22 phy registers 0-15 live in the fiber page (2) of the SerDes
- other SerDes specific registers exist in pages before and after
The mdio bus and other SerDes functions are a wild mix of directly
looking into page 2 or just using self defined methods to access
data.
Adapt the bus to the new consistent phy interface that mixes the
SerDes register set like classic Realtek phys do it.
- Use register 31 as page select (already in the bus)
- Always keep the common registers 0-15 in place and read fiber page
- Map the SerDes internal registers into the upper vendor specific
registers 16-23 according to the page select register (31).
Michael Pratt [Sat, 2 Aug 2025 08:12:17 +0000 (04:12 -0400)]
tools: gnulib: do not cache C standard option test results
After eliminating the possibility of automake having a bug
by testing a revert to the recent updates to automake,
the problems regarding autoreconf with some packages
was bisected to the gnulib update instead, through aclocal macros.
With the new module, std-gnu23, some packages are failing build
due to both the host compiler and cross compiler being tested for
availability of C23 standard features with the configure script.
The results of one is being cached and used for the other,
while the two compilers are different versions and may or may not
both support C23 options and would otherwise have conflicting results.
A similar patch may have to be done
for the next release of Autoconf
if upstream GNU does not accept this solution.
Reported-by: Georgi Valkov <gvalkov@gmail.com> Signed-off-by: Michael Pratt <mcpratt@pm.me> Link: https://github.com/openwrt/openwrt/pull/19627 Signed-off-by: Nick Hainke <vincent@systemli.org>
Felix Fietkau [Sat, 2 Aug 2025 14:45:39 +0000 (16:45 +0200)]
netifd: update to Git HEAD (2025-08-02)
3a7878065829 system-dummy: add missing vrf functions 471d9d6abb6d CMakeLists.txt: bump minimum required version c3a0255e2150 scripts: fix dummy mode on systems where libubox is in /usr/local 7a3b281230e4 update example mac80211 script and wireless config d9f2dd2614f2 wireless: replace with ucode scripts 74c22601baad wireless: add MLO support to example scripts
realtek: mdio: RTL838x: create new SerDes phy register layout
When a SerDes directly drives a SFP module there is no clear rule of
how to handle its register set that consists of two parts:
- c22 phy registers 0-15 live in the fiber page (2) of the SerDes
- other SerDes specific registers exist in pages before and after
The mdio bus and other SerDes functions are a wild mix of directly
looking into page 2 or just using self defined methods to access
data.
Provide a consistent phy interface that mixes the SerDes register
set like classic Realtek phys do it.
- Use register 31 as page select (already in the bus)
- Always keep the common registers 0-15 in place and read fiber page
- Map the SerDes internal registers into the upper vendor specific
registers 16-23 according to the page select register (31).
Christian Korber [Wed, 21 May 2025 12:36:00 +0000 (14:36 +0200)]
hostapd: fix logging of configuration content
As discussed in openwrt#17517, there are contents of hostapd's configuration file logged in syslog.
This includes critical information like `passphrase`. To circumvent this condition,
this commit logs only "inline" if config_fname is inline data.
Michael Pratt [Fri, 1 Aug 2025 04:20:48 +0000 (00:20 -0400)]
tools: util-linux: allow building with 32-bit time
Similar to several GNU tools, util-linux when built using meson
is configured by default to error when 64-bit time is not supported.
To solve this in the same way as standard configure scripts,
check for 64-bit time support ahead of time,
and allow 32-bit time when not supported.
In the future, the YEAR_2038 variable
can be used as a build prerequisite
instead of being used for configuration.
Ref: 39e8ef33bf ("build: add test for 64-bit time support") Fixes: e15d5cf752 ("tools/util-linux: build with meson") Signed-off-by: Michael Pratt <mcpratt@pm.me> Link: https://github.com/openwrt/openwrt/pull/19617 Signed-off-by: Nick Hainke <vincent@systemli.org>
Nick Hainke [Thu, 31 Jul 2025 16:05:07 +0000 (18:05 +0200)]
gettext-full: fix m4 path after gettextize update
Recent changes to gettextize altered the default path for .m4 files from
$datadir/aclocal to $datadir/gettext/m4 [0]. This caused build issues when
compiling gettext-full in OpenWrt.
This patch, originally provided by @nxhack [1], updates the OpenWrt
Makefile accordingly to ensure compatibility with the new path.
The DSA has a link to the MDIO bus and already uses the read/write functions
that are provided. In parallel the dsa_switch_ops structure provides an
interface for phy_read and phy_write. These are still open-coded and sadly
circumvent the bus. Simplify the implementation and avoid inconsistencies by
reusing the existing bus infrastructure.
Additionally, remove two unused MMD header definitions as a quick win.
Reported-by: Jan Hoffmann <jan@3e8.eu> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://github.com/openwrt/openwrt/pull/19548 Signed-off-by: Robert Marko <robimarko@gmail.com>
The function rtl93xx_setup() is called by both RTL930x and RTL931x. But
only the RTL930x specific function to print port matrix was called.
Unfortuntaly, RTL931x needs a different function to access the correct
registers to retrieve the port matrix information.
It is therefore necessary differentiate in rtl93xx_setup between the
SoC families before calling the appropriate function.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de> Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/19572 Signed-off-by: Robert Marko <robimarko@gmail.com>
realtek: rtl931x: Update irq mask to cover all ports
The RTL931x has 56 (0-55) non-CPU ports. To receive updates about the port
state, it is therefore necessary to enable the interrupts for all these
ports.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de> Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/19572 Signed-off-by: Robert Marko <robimarko@gmail.com>
Harshal Gohel [Wed, 18 Jun 2025 11:35:15 +0000 (11:35 +0000)]
realtek: rtl931x: Fix traffic on upper ports
* traffic isolation tables are different between rtl930x and rtl931x
* traffic_enable/disable/get/set functions span multiple columns in the
rtl931x as a result, previous implementation would only enable traffic
in some ports.
traffic_enable/disable and traffic_set/get should now work on all ports and
not just the initial 32
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de> Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/19572 Signed-off-by: Robert Marko <robimarko@gmail.com>
The commit d2108c2c5896 ("realtek: enhance RTL930x SerDes/PLL/CMU
interoperability") removed a couple of commands for the bringup code.
One of these commands was necessary to bring up SFP modules correctly. This
one can also be found in the RTLSDK [1].
It is currently not 100% clear what this command does. But if it works
similar to the RTL8295 [2,3] (RTL8295_SDS0_ANA_MISC_REG00_REG), we could
assume that it could be the RX_ON and RX_EN bits.
Daniel Golle [Thu, 31 Jul 2025 18:48:32 +0000 (19:48 +0100)]
kernel: add backport to fix broken PHY LEDs
A commit which broke netdev trigger LEDs offloaded to PHYs recently made
it all the way down to the Linux 6.6 stable branch. The revert has been
accepted to linux-next, however, a backport to the various -stable trees
is still pending.
Import the backported revert commit to fix in OpenWrt in the meantime
until the revert also gets picked to linux-stable.
Include the NAND specs into the DTS. It is unclear which devices
really need it. Keep it disabled for now. As the SoC register area
is defined too small until now, increase the size to an appropriate
value.
If enabled one can see the following log messages (e.g. Linksys
LGS328C or LGS352C).
[ 1.206600] spi-nand spi1.0: Macronix SPI NAND was found.
[ 1.212795] spi-nand spi1.0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64
[ 1.222217] 3 fixed-partitions partitions found on MTD device spi1.0
[ 1.229466] OF: Bad cell count for /soc/spi@1a400/flash@0/partitions
[ 1.236617] OF: Bad cell count for /soc/spi@1a400/flash@0/partitions
[ 1.244164] Creating 3 MTD partitions on "spi1.0":
[ 1.249620] 0x000000000000-0x000004000000 : "ubifs"
[ 1.423593] 0x000004000000-0x000005e00000 : "firmware"
[ 1.738268] mtdsplit_uimage: no uImage found in "firmware"
[ 1.744577] 0x000005e00000-0x000007c00000 : "runtime2"
RTL93xx devices have a NAND controller built in. Upstream already
has a driver in place. Include it downstream. Activate it in the
RTL93xx builds and disable it for the RTL83xx builds.
Michael Pratt [Wed, 30 Jul 2025 18:44:16 +0000 (14:44 -0400)]
tools: bison: do not install or uninstall macros
There is a clobbering between bison and gnulib for installing
the macro file bison-i18n.m4 where gnulib has a newer version
while bison will replace it with an outdated version if built afterward.
Other builds depend on the changes made to the bison-i18n.m4 file and are
only included using aclocal unless other modifications are made in each case
in order to force imported macros from gnulib to override aclocal macros.
Gnulib is integrated within bison, however it is not with a bootstrap script
and there is already a reverse dependency between the two, where bison
is indirectly required for gnulib to start building. Therefore, do not allow
the building or cleaning of bison to install or uninstall m4 files.
Reported-by: Tianling Shen <cnsztl@immortalwrt.org> Fixes: d19f8bc199 ("tools/gnulib: update to branch stable-202501") Signed-off-by: Michael Pratt <mcpratt@pm.me> Link: https://github.com/openwrt/openwrt/pull/19606 Signed-off-by: Nick Hainke <vincent@systemli.org>
Harshal Gohel [Tue, 17 Jun 2025 13:03:47 +0000 (13:03 +0000)]
realtek: rtl931x: Support enable/disable SMI Polling for SerDes ports
During PHY matching, the SMI polling must be disabled to avoid conflicts
during the complex detection routine. Only after this finished, SMI polling
is allowed again.
This was implemented for all realtek families besides RTL931x.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de> Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/19603 Signed-off-by: Robert Marko <robimarko@gmail.com>
A RTL930x function to read the value from an SDS register must not used on
an RTL931x SoC. Doing it with rtl930x_read_sds_phy() would corrupt the
written results when only parts of the bits are written.
Fixes: 7026084066fb ("realtek: Add SDS configuration routines for the RTL93XX platforms") Signed-off-by: Harshal Gohel <hg@simonwunderlich.de> Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/19603 Signed-off-by: Robert Marko <robimarko@gmail.com>
The Realtek RTL838x devices have a MIPS 4Kec core. This has a very simple pipeline.
OpenWrt uses CPU_TYPE:=4kec to honour this and adds a dedicated toolchain with
some GB of extra space. There would be no problem if that toolchain would do what
it is expected to do. Looking at the build process one can see:
So the kernel is optimized for the wrong cpu type while the applications fit fine.
Explanation for this is the generic/308-mips32r2_tune.patch. This forces kernel
builds to -mtune=34kc. Nevertheless everything runs fine since years on the RTL838x
targets.
It does not make sense to provide a dedicated 4kec toolchain for this mess. So
change the setup as follows:
- switch CPU type to mips24kc for RTL838x -> This drops one toolchain and saves space
- Add a RTl838x specific mtune=4kec patch -> Builds kernel with the proper setting
Downside is packages will be built with -mtune=24kc. So a look at a simple benchmark
should give insight if this has really a big impact. See numbers attached. To sum it
up in two sentences
- All non RSA benchmarks are within expectation
- RSA benchmarks show large deviations (before and after)
The normal usecase for these switches is definetly not a CPU intensive workload
so this is ok for now.
The pkgconfig file that autotools uses is wrong for static libraries.
meson does the right thing but for static libraries, .private entries
need to move to non .private.
It seems that, for whatever reason in this case,
the function "vardef ($var, $cond)" does not work
while "$var->def ($cond)" does work for conditionals.
Also, do not define it conditionally when defined unconditionally.
Even though the reordering patch would make that functionally sound,
it still throws a warning which can cause a build to fail
when warnings are treated as errors.
Instead, just add BUILT_SOURCES to every existing case
rather than only when BUILT_SOURCES is defined.
Fixes: 6d2bfe50d3 ("tools/automake: control all cleaning with clean variables") Signed-off-by: Michael Pratt <mcpratt@pm.me> Link: https://github.com/openwrt/openwrt/pull/19593 Signed-off-by: Robert Marko <robimarko@gmail.com>
Colton Pawielski [Thu, 15 May 2025 01:07:15 +0000 (20:07 -0500)]
realtek: add support for Vimin VM-S100-0800MS
Vimin VM-S100-0800MS is an 8 port Multi-Gig switch, based on RTL9303.
Ported from XikeStor SKS8300-8X with changes to support different u-boot
build.
Specification:
- SoC : Realtek RTL9303
- RAM : DDR3 512 MiB
- Flash : SPI-NOR 16 MiB (Winbond W25Q128JVSQ)
- Ethernet : 8x 1/2.5/10 Gbps (SFP+)
- LEDs/Keys (GPIO): 0x/1x
- UART : "Console" port on the front panel
- type : RS-232C
- connector : RJ-45
- settings : 115200n8
- Power : AC100-240V 50/60Hz
Flash instruction using initramfs image:
1. Prepare TFTP server with an IP address "192.168.1.111"
2. Connect your PC to Port1 on VM-S100-0800MS
3. Power on VM-S100-0800MS and interrupt boot by pressing Esc
4. Enable Port1 with the following commands
rtk 10g 0 fiber1g (or fiber10g if 10GBase-*R, dac300cm for DAC cable)
rtk ext-devInit 0
rtk ext-pinSet 2 0
Note: the last command sets tx-disable to low
7. Download initramfs image from TFTP server
tftpboot 0x82000000 <image name>
8. Boot with the downloaded image
bootm
9. On the initramfs image, backup the stock firmware if needed
10. Upload (or download) sysupgrade image to the device
11. Erase "firmware" partition to cleanup JFFS2 of stock FW
mtd erase firmware
12. Perform sysupgrade with the sysupgrade image
13. Wait ~120 sec to complete flashing
Reverting to stock firmware:
1. Prepare by downloading the stock firmware. Vimin doesn't have
the firmware on their website, tested using firmware for shared
hardware Nicgiga S100-0800S-M.
Filename: vmlinux-nicgiga-S100-0800S-M-241126EN.bix
2. Prepare TFTP server with an IP address "192.168.1.111"
3. Connect your PC to Port1 on VM-S100-0800MS
4. Power on VM-S100-0800MS and interrupt boot by pressing Esc
5. Enable Port1 with the following commands
rtk 10g 0 fiber1g (or fiber10g if 10GBase-*R, dac300cm for DAC cable)
rtk ext-devInit 0
rtk ext-pinSet 2 0
projects / thirdparty / openwrt.git / log
