Enable the existing secure WCSS driver and describe the shared IPQ9574
remoteproc, reserved memory and interprocessor communication resources.
Keep the remoteproc node disabled until enabled by a board.
Use SCM/PAS for startup instead of extending the native WCSS driver with
manual clock and reset sequencing. Load q6_fw.mdt and the auxiliary
m3_fw.mdt from the IPQ9574 ath11k-firmware package added in this series.
With board enablement applied separately, secure WCSS startup and ath11k
registration passed on LN6001. An attended iPhone test passed association,
DHCP and four local pings on each of 2.4, 5 and 6 GHz with all three APs
enabled, using that unit's factory calibration.
Signed-off-by: Satoshi Ikeuchi <satosan.ikm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25595
Signed-off-by: Robert Marko <robimarko@gmail.com>
Move the secure WCSS driver, binding and split-firmware support from
qualcommax to the common kernel patch series. IPQ9574 support is already
provided by this driver.
Split out the unchanged TME-L client header so qualcommbe can compile the
driver without enabling the mailbox controller. Keep the qualcommax-only
follow-up patches in that target; its resulting driver is unchanged.
Describe the existing multi-file loading interface in the common binding
and leave the driver disabled unless selected by a target.
Signed-off-by: Satoshi Ikeuchi <satosan.ikm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25595
Signed-off-by: Robert Marko <robimarko@gmail.com>
json-c 0.19 frees a container object in json_object_put() in a call
inside assert(). The package builds with NDEBUG, which compiles that
call out, so every released object or array stays allocated. Each
json() of ucode leaks its result this way: netifd grew to 58 MB and a
test agent to 80 MB within a day, and a 352 MB device ran out of memory.
Add a patch that calls the function before the assertion.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The Xunison Exigo Hub D50 5G is a 5G/LTE router with Wi-Fi 6. It is also
sold as the Zearts D50 5G.
Specifications:
SoC: Qualcomm IPQ5018, dual-core Cortex-A53 @ 1.0 GHz
RAM: 512 MiB
Flash: 128 MiB SPI NAND (ESMT F50D1G41LB)
WLAN: IPQ5018 2.4 GHz, QCN9074 5 GHz (PCIe), both 802.11ax
Ethernet: 1x GbE WAN (IPQ5018 internal GE PHY, gmac0)
3x GbE LAN (QCA8337 switch, SGMII to gmac1)
WWAN: Quectel RM500Q-AE, 5G Sub-6 / LTE Cat 16, on USB 2.0 and
PCIe
Buttons: reset, WPS
LEDs: MESH (green/red), 5G (green/red), 4G, WiFi, Internet, WAN;
power is hardwired
Power: 12 V / 2 A DC
Serial: 115200 8N1, 4-pin header JP1 next to SW4 on the main board,
from pin 1: VCC, TX, RX, GND
Notes:
- WAN is gmac0 wired straight to the internal GE PHY, not a switch
port; its netdev is named wan by the label property.
- The console RX line (gpio20) is pulled up. Left floating with nothing
on the header it causes an interrupt storm and, on some units, a hang
at boot.
- USB is 2.0 only: the controller is limited to the HS PHY and clocks
its pipe from UTMI. The 5 V supply for the port and the modem is
switched by gpio24 (active low).
- MACs follow the stock firmware: LAN uses 0:art 0x0, WAN 0:art 0x6.
The label has no MAC printed, so there is no label-mac-device.
- Wi-Fi calibration data and MAC addresses come from 0:art through
nvmem cells on the Wi-Fi nodes (calibration: IPQ5018 at 0x1000,
QCN9074 at 0x26800). The caldata holds the Qualcomm placeholder MAC,
so the radios take the 0:art 0x0 MAC + 2 and + 3 instead.
- Board data for both radios is submitted separately to
firmware_qca-wireless under the calibration variant
Xunison-Exigo-Hub-D50-5G, both taken from the stock firmware:
bdwlan.b24-brax for the IPQ5018 and qcn9000/bdwlan.ba0 for the
QCN9074. The brax file is the vendor's board variant; on my unit it
outperformed the bdwlan.b24 that the stock firmware loads.
- The modem power line (gpio31) has no consumer and is kept high with a
GPIO hog.
- The Internet LED is lit while the modem's wwan0 is up. The WiFi LED
uses the network trigger in link mode, so it is lit while an AP is up
on either radio; the phyNradio triggers never light it with ath11k on
this board. The 4G and 5G LEDs have no trigger, as nothing in the
kernel reports the modem's access technology.
Modem:
The RM500Q-AE is wired to both USB and PCIe, and its data_interface
setting selects which one carries data. The stock firmware leaves it on
PCIe (data_interface 1,0) and this port uses it there, so no AT command
is needed after installing. It is driven by mhi-pci-generic with MBIM:
data on wwan0, control on /dev/wwan0mbim0 and AT commands on
/dev/wwan0at0. No modem interface is preconfigured; add one with the
"mbim" protocol on /dev/wwan0mbim0.
Installation:
The factory image is a raw UBI image for the U-Boot web recovery.
1. Power the router off, hold the reset button and power it on. Keep
holding until the Internet LED stays lit (about 10 seconds).
2. Set a computer on a LAN port to 192.168.1.2/24 and open
http://192.168.1.254
3. Upload openwrt-qualcommax-ipq50xx-xunison_exigo-hub-d50-5g-squashfs-factory.img
and wait for the router to reboot.
Later upgrades use the sysupgrade image.
The port started from George Moussalem's device support in the 4IceG
OpenWrt tree, with the device tree reworked by Lukasz Szczur (LS3434):
USB, the modem supply and the NAND/sysupgrade layout. Thanks to Hostle
for the flashing work on this board and to Rafał Wabik (4IceG) for the
tree it was developed in.
Link: https://forum.openwrt.org/t/adding-support-for-xunison-exigo-d50-5g-zearts-d50-5g-ipq5018/247016
Co-developed-by: George Moussalem <george.moussalem@outlook.com>
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
Co-developed-by: Lukasz Szczur <8sdasfasfas@royaleplaysempire.com>
Signed-off-by: Lukasz Szczur <8sdasfasfas@royaleplaysempire.com>
Co-developed-by: Rafał Wabik <4rafal@gmail.com>
Signed-off-by: Rafał Wabik <4rafal@gmail.com>
Signed-off-by: Steve Meek <stevemeek82@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25890
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add a pending patch that gives the RM500Q-AE its own MHI channel table
with doorbell burst mode disabled on its two hardware data channels.
With burst mode on, the downlink stalls under sustained multi-stream
load when the wwan0 receive work runs on the same CPU as the modem's
interrupt, which is where the default packet steering puts it. Uplink
keeps working, the MBIM control channel later times out, and only a
reboot recovers it. Ringing the channel doorbell by hand restores the
link at once, which points at a lost doorbell-mode handshake.
Tested on a Xunison Exigo Hub D50 5G: without the patch a single
25-second 16-stream download stalled the downlink; with it, about 200
seconds of multi-stream downloads with CPU0 at up to 100% ran with no
stall and no MHI errors.
Link: https://patch.msgid.link/20261013-rm500q-db-burst-v1-1-bb850d54e2c4@gmail.com
Signed-off-by: Steve Meek <stevemeek82@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25890
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport the Airoha Ethernet patches for Linux 6.18. They fix PPE flush
error handling, QDMA retry handling, BQL accounting on the shared TX ring,
DMA mapping of fragmented packets, and maximum receive size configuration.
The series also fixes MIB and ETS/QoS statistics, corrects the module
license, renames the device flags, and adds preliminary TX hardware
configuration changes.
Signed-off-by: Yalei Zang <yalei.zang@airoha.com>
Link: https://github.com/openwrt/openwrt/pull/25861
Signed-off-by: Robert Marko <robimarko@gmail.com>
To reduce code duplication across different AN7583 evaluation boards,
introduce a shared multi-EVB base device tree and utilize Device Tree
Overlays (DTSO) for board-specific configurations.
Signed-off-by: Yalei Zang <yalei.zang@airoha.com>
Link: https://github.com/openwrt/openwrt/pull/24926
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
To reduce code duplication across different AN7581 evaluation boards,
introduce a shared multi-EVB base device tree and utilize Device Tree
Overlays (DTSO) for board-specific configurations.
Signed-off-by: Yalei Zang <yalei.zang@airoha.com>
Link: https://github.com/openwrt/openwrt/pull/24926
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The rtl931x LED setup always selects serial mode. Boards whose port LEDs
are wired for scan mode stay dark with it. The rtl930x driver already
reads the interface mode from "realtek,led-mode"; read it on rtl931x
too.
Without the property the driver selects serial mode, as before. A value
outside 1-3 is reported and also falls back to serial mode. No rtl931x
DTS sets the property yet, so other boards are unchanged.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Kaloyan Naumov <knaumov@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25576
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The rtl931x LED setup always selects serial mode. Boards whose port LEDs
are wired for scan mode stay dark with it. The rtl930x driver already
reads the interface mode from "realtek,led-mode"; read it on rtl931x
too.
Without the property the driver selects serial mode, as before. A value
outside 1-3 is reported and also falls back to serial mode. No rtl931x
DTS sets the property yet, so other boards are unchanged.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Kaloyan Naumov <knaumov@gmail.com>
A flower rule with action trap redirects its frames to the CPU port.
Their CPU tag has no trap REASON, only ACL_HIT and the rule's PIE row
in ACL_IDX, so they are passed up as forwarded by hardware: they get
offload_fwd_mark and the bridge keeps them off the other switch ports,
where the hardware did not send them either.
L3 rules sit in PIE rows 640 and above and set ACL_HIT on the frames
they send to the CPU too. Those must keep the mark: they are addressed
to the switch, and the bridge has no FDB entry for an interface with
its own MAC, so it would flood them. Treat a frame as trapped only
when ACL_HIT comes from a row below the L3 rules. Only RTL839x uses
rteth_839x_decode_tag(), so the other families are unchanged.
HPE 1920-48G (RTL8393), h7 behind lan48 and x7 behind lan47 in one
VLAN, a skip_sw trap rule for x7 on lan48: none of 8 pings reach x7
on main, 8 of 8, once each, with this change. Broadcast ARP still
reaches x7 once, also with a mirror rule on it. Pings to an interface
with its own MAC leave nothing on lan47, as on main; a bench build
that took any ACL_HIT as a trap had all 8 flooded there. One change
is visible: a trap rule for such an interface now gets its frames
flooded out of lan47 by the bridge, where main keeps them at the CPU.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25919
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The ethernet driver is about to tell a frame that a tc rule sent to the
CPU from one that an L3 rule sent there, and only the PIE row in the
CPU tag tells them apart. Move RTL839X_PIE_L3_FIRST to a new shared
header, include/linux/soc/realtek/otto_common.h, and derive the number
of L3 rows from it. Both values stay as they were, 640 and 512.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25919
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
On MDIO-connected MT753x switches .get_stats64 reads the MIB counters
under the MDIO bus mutex although it runs in atomic context, so reading
/proc/net/dev reports "sleeping function called from invalid context".
With CONFIG_DEBUG_ATOMIC_SLEEP=y the sleep inside the RCU read section
can lock up a CPU. The upstream fix polls the counters from a delayed
work and returns cached values. It is in mainline from v7.1-rc3 and not
in 6.18.y.
Tested on a Keenetic KN-1012 (MT7981B, MT7531) with
CONFIG_DEBUG_ATOMIC_SLEEP=y: a loop reading /proc/net/dev locked up a
CPU within a minute without the fix, and ran 41 minutes clean with it
while the counters kept advancing.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Link: https://github.com/openwrt/openwrt/pull/25383
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
This patch adds support for Wavlink WS-WN552K1-C, also available under
other names:
EXTRALINK Dynamite C21, Renkforce RF-WMH-310 (RF-WMH-320).
Hardware specifications:
* SoC: MediaTek MT7621AT, 2C2T, 880 MHz
* RAM: 128 MB DDR3, Nanya NT5CB64M16GP-EK
* Flash: 16 MB SPI NOR flash, GigaDevice GD25Q127CSIG
* 5 GHz WiFi: MediaTek MT7615N (4x4:4) on mini PCIe slot
* 2.4 GHz WiFi: MediaTek MT7603EN (2x2:2) on mini PCIe slot
* Ethernet: 3x 1000Base-T
* LEDs: Power, dual-color WAVLINK logo LED on the top cover
* Buttons: Reset, WPS, Turbo, and touch button on the top cover via
RH6015C touch sensor
* UART: UART1 serial console (57600 8n1) on the J4 header located below
the top heatsink
* USB: 1x USB 2.0
Installation:
Flashing instructions (U-Boot TFTP):
1. Configure a TFTP server on your computer and set its IP address to
192.168.10.100.
2. Rename the OpenWrt sysupgrade image to firmware.bin and place it in
the root directory of the TFTP server.
3. Power off the device and connect an Ethernet cable from one of its
LAN ports to your computer.
4. Press and hold the Reset button.
5. Power on the device.
6. After a few seconds, when the connected LAN port LED stops blinking
rapidly, release the Reset button.
7. Flashing OpenWrt takes less than a minute and the device will reboot
automatically.
8. After reboot, the WAVLINK logo on the top cover indicates the current
OpenWrt status. Wait until the logo turns solid blue.
Revert to the OEM firmware:
U-Boot TFTP:
Follow the flashing instructions above and use the firmware.bin OEM
backup image.
OpenWrt "Flash Firmware" interface:
Upload the firmware.bin OEM backup image and select "Force update"
before continuing.
MAC address layout:
The MAC address shown on the label on the back of the device is assigned
to the 2.4 GHz WiFi adapter.
MAC addresses assigned by the OEM firmware:
* 2.4 GHz: *:XX (label) — factory@0x0004
* 5 GHz: *:XX + 1 — factory@0x8004
* WAN: *:XX - 1 — factory@0xe006
* LAN: *:XX - 2 — factory@0xe000
Signed-off-by: pawel mistrzuu <pawelm@murena.io>
Link: https://github.com/openwrt/openwrt/pull/25196
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The Fibocom FG621-EA supplies a fresh locally-administered address in its
CDC-NCM descriptor on every power-up, so usb0 changes identity across
reboots. Five consecutive boots on the same unit:
cdc_ncm 1-1:1.0: MAC-Address: d6:c4:81:03:15:77
cdc_ncm 1-1:1.0: MAC-Address: 26:aa:4f:6c:ad:ff
cdc_ncm 1-1:1.0: MAC-Address: 16:46:a8:94:fd:29
cdc_ncm 1-1:1.0: MAC-Address: 46:ad:de:0f:82:d8
cdc_ncm 1-1:1.0: MAC-Address: ea:fa:1a:b7:c9:dc
The kernel reports these as permanent rather than random
(addr_assign_type 0), because they are read from the device instead of
being generated by the host, so nothing downstream compensates for them.
Assign a stable address derived from the factory base instead. Offsets 0,
1 and 4 are already used by the LAN ports and phy0, the WAN port, and
phy1 respectively, so use offset 3.
Tested on hardware (HW rev A1). An LTE data session still passes traffic
in both directions with usb0 pinned: 5/5 ICMP replies at 1400 bytes and a
274 kB HTTP transfer, with downlink byte counts matching an unpinned run
on the same unit (293 kB vs 294 kB). This modem therefore learns the host
MAC from uplink frames rather than filtering to the address it advertised
in its own descriptor.
Note this does not change the address the carrier hands out: with usb0
pinned, the PDP address still differs between sessions, as it is issued
per context activation and does not depend on the host-side MAC of the
USB link.
Signed-off-by: Fredrik Hallin <fredappsdev@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/24975
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The device tree exports reboot:modem and reset:modem, but without a UCI
switch they cannot be reached from LuCI or enforced at boot. Add them,
following the teltonika,rutm* precedent. The defaults match the output
values already set in the device tree.
Signed-off-by: Fredrik Hallin <fredappsdev@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/24975
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The device tree declares twelve LEDs but nothing drives them, as the board
has no 01_leds entry at all. Wire up the WAN and mobile indicators.
The mapping was verified against the vendor firmware, which drives GPIO 15
(white:wan) high when the wired WAN is online and GPIO 10 (white:mobile)
high on an LTE connection.
Signed-off-by: Fredrik Hallin <fredappsdev@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/24975
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The 4G-AX56 is an LTE router, but OpenWrt ships no configuration for its
Fibocom FG621-EA modem: no network interface, no protocol handler and no
userspace package. The drivers bind and /dev/ttyUSB* appears, but the
device has no WAN at all out of the box. The commit adding the device
documents sending AT commands by hand as a workaround, which is awkward on
a router that has no internet until the modem works.
Configure it as a proto ncm device, matching tozed,zlt-s12-pro on the same
subtarget. netifd then drives connect and disconnect, so the modem's own
autoconnect flag is not needed and OpenWrt does not write persistent state
into the modem.
The Ethernet WAN remains the default WAN; the modem is added alongside it
in the wan firewall zone.
This depends on the Fibocom profile in comgt's ncm.json; without it proto
ncm reports UNSUPPORTED_MODEM.
Tested on hardware (HW rev A1) on both main and openwrt-25.12.
Signed-off-by: Fredrik Hallin <fredappsdev@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/24975
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Hardware:
- SoC: Broadcom BCM4708A0, 2x Cortex-A9 at 800 MHz
- RAM: 256 MiB
- Flash: 128 MiB NAND (BCH-8)
- Ethernet: 4x LAN + 1x WAN, gigabit (switch port 0 = WAN, 1-4 = LAN)
- Wi-Fi: BCM4331 2.4 GHz (b43), BCM4360 5 GHz
- USB: 1x USB 3.0, 1x USB 2.0
- LEDs: power (white/amber), WAN (white/amber), 2.4 GHz, 5 GHz, WPS,
WiFi, USB 1, USB 2
- Buttons: WPS, WiFi (rfkill), Reset
- Serial: 115200 8N1 on the SoC UART (ttyS0); the on-board header was
not used for this port, netconsole served as the console
- Power: 12 V DC, 2.5 A (barrel jack, included adapter)
- Board ID: U12H332T00_NETGEAR
MAC addresses (NVRAM):
- LAN: et0macaddr
- WAN: et1macaddr
- 2.4 GHz: pci/1/1/macaddr
- 5 GHz: pci/2/1/macaddr
The LED and button GPIOs were mapped by driving each line by hand on a
unit (egc112, GitHub review of the pull request). All LEDs are active
low except the WPS and WiFi button LEDs, which are active high as on the
R7000. The LEDs use the color/function bindings (white:power,
amber:power, white:wan, amber:wan, white:wlan-2ghz, white:wlan-5ghz,
white:wps, white:wlan, white:usb-1, white:usb-2); diag.sh, with the
preceding commit, picks white:power as the status LED, so boot goes
amber (bootloader), blinking white (preinit), solid white. egc112
re-tested the LEDs, buttons, board check and USB on a v1 and a v2. The
2.4 GHz LED is driven as a netdev trigger on phy0-ap0: b43 has no
phy0tpt trigger and the phy0radio/assoc/tx/rx ones stay dark in AP mode.
sysupgrade accepts only a CHK image with this board ID. The USB VBUS
regulator is left off at registration, as on the sibling boards, so VBUS
is power-cycled after CFE.
Not yet supported: 5 GHz Wi-Fi (the BCM4360 AC-PHY needs the b43
AC-PHY series, a separate pull request).
Installation from stock firmware:
1. Connect a computer to a LAN port and open http://192.168.1.1
(factory login admin / password).
2. ADVANCED > Administration > Router Update, select the factory
image (openwrt-bcm53xx-generic-netgear_r6400-v1-squashfs.chk), Upload.
3. Wait for the router to restart into OpenWrt.
Recovery: Netgear's bootloader accepts a firmware image over TFTP/NMRP
(e.g. nmrpflash) when the image does not boot.
Signed-off-by: Russell Ballestrini <russell@unturf.com>
Link: https://github.com/openwrt/openwrt/pull/25786
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
get_status_led() avoids the amber and red power LEDs with the
patterns "*:amber:*" and "*:red:*", which need a device prefix in
the LED name. LEDs named from the color/function DT properties have
none ("amber:power"), so on a board with a white and an amber power
LED both match "*:power" and head -n1 takes whichever sysfs lists
first. On the Netgear R6400 v1 that is the amber one: it blinks
through preinit and stays lit next to the white default-on LED.
Also exclude the names without a prefix. The fallback that takes any
power LED is unchanged.
Found, fixed and tested on a R6400 v1 and v2 by egc112 (GitHub).
Signed-off-by: Russell Ballestrini <russell@unturf.com>
Link: https://github.com/openwrt/openwrt/pull/25786
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
json-c 0.19 wraps the actual object free in json_object_put() inside an
assert(), so when compiled with NDEBUG (as OpenWrt does) the free is
compiled out and every JSON object/array parsed by users such as
ucode's json() leaks memory (~1.7KB per object).
Apply the upstream fix, moving the free call outside the assert:
json-c/json-c@f291fa81c6
"free objects outside assert() in json_object_put"
Fixes: https://github.com/ucode-lang/ucode/issues/495
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Replace the expanded fixed-partition 128M target with a dedicated
all-in-UBI target and OpenWrt U-Boot. Include bootloader configuration,
image generation and upgrade support together.
Share the fixed-partitions container and read-only 1 MiB BL2 range
in the common DTSI. Declare the remaining partitions and factory NVMEM
data in the variant DTS files. Keep NMBM on the legacy target and preserve
its stock partition map and 64 MiB UBI region.
The new layout uses a 1 MiB bl2 partition followed by a 127 MiB ubi
partition, with factory and fit NVMEM/rootdisk references and redundant
U-Boot environment volumes. Set the UBI variant boot arguments to
`root=/dev/fit0 rootwait` and identify its fit volume as the root disk.
The bootloader supplies memory and console parameters.
Add the U-Boot configuration, default environment and target, recovery
FIT and sysupgrade FIT images, BL2 and BL31/U-Boot artifacts, UBI
environment access and FIT upgrade checks. Recognise the new compatible
in board defaults. Bump the uboot-tools package release for the
new environment configuration support.
The installer creates fip, factory, ubootenv, ubootenv2, recovery and
initial fit volumes. U-Boot and sysupgrade manage the production FIT
and writable rootfs_data. DTS declarations identify volumes consumed
by Linux; they do not themselves create or populate factory data.
MAC address layout
------------------
Factory data is read from the legacy Factory MTD partition or the
factory UBI volume; the offsets within the data are unchanged.
Unit-specific address bytes are xx:xx:xx.
LAN: factory offset 0xe000, mac-base cell index 0.
WAN: factory offset 0xe000, mac-base cell index 1 (LAN MAC + 1).
2.4 GHz: factory offset 0x4, mac-base cell index 0.
5 GHz: factory offset 0x8000, mac-base cell index 0.
Flash instructions
------------------
Conversion requires an installer; the sysupgrade ITB alone cannot
convert the stock partition layout or preserve its factory data.
1. Start from the standard CF-WA933 OpenWrt target with stock MTD
partitions. Back up BL2, u-boot-env, Factory and FIP with mtd dump,
and copy all four files off the device before proceeding:
mtd dump BL2 > /tmp/BL2.bin
mtd dump u-boot-env > /tmp/u-boot-env.bin
mtd dump Factory > /tmp/Factory.bin
mtd dump FIP > /tmp/FIP.bin
2. Obtain the CF-WA933 installer from:
https://github.com/andros-ua/owrt-ubi-installer/releases
Its source and build script are available at:
https://github.com/andros-ua/owrt-ubi-installer/tree/cf-wa933
Connect the PC to a LAN port and use 192.168.1.254/24; the device
is at 192.168.1.1. Copy the resulting image to /tmp and run:
cd /tmp
sysupgrade -n \
openwrt-*-comfast_cf-wa933-ubi-initramfs-recovery-installer.itb
This external installer extracts calibration/MAC data from the old
Factory region before erasing it, creates and populates the static
factory UBI volume, writes BL2 and fip, and creates the redundant
environment, recovery and initial fit volumes. It copies one NAND
eraseblock of factory data; keep the full external Factory backup.
The blue WLAN LED blinks during installation and stays lit for five
seconds before reboot. Run the installer only for initial conversion.
3. Once recovery boots, copy the production image to /tmp and run:
cd /tmp
sysupgrade -n \
openwrt-*-comfast_cf-wa933-ubi-squashfs-sysupgrade.itb
To return to the legacy layout, boot the standard CF-WA933 initramfs
in RAM, restore the saved BL2/u-boot-env/Factory/FIP to their original
MTD partitions (using kmod-mtd-rw when needed), then sysupgrade to the
standard CF-WA933 image. The restored vendor bootloader's recovery
page can install vendor firmware. UART recovery of BL2/FIP is also
available using https://github.com/981213/mtk_uartboot.
Signed-off-by: Andrii Kuiukoff <andros.ua@gmail.com>
Signed-off-by: Guillaume RISCHARD <git@stereo.lu>
Link: https://github.com/openwrt/openwrt/pull/24590
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Remove the fixed memory node and console bootargs override, relying on
the bootloader to supply the memory map and command line. Drop the DTB
padding and explicit kernel/FDT load addresses so the image definitions
use the Filogic defaults. I have boot-tested the standard target with
these settings removed. Both existing variants inherit the changes.
Remove the redundant crypto status override. The inherited SoC node
has no status property, which leaves it available; this does not disable
the EIP-97 engine.
Remove the CPU port's user-facing label while keeping its Ethernet link
and switch topology.
Remove the explicit SPI address and size cell properties.
Drop the standard target's 64M display suffix, which describes its UBI
region size rather than a different NAND device. Keep its 64 MiB image
limit. Add cf-wa933 as a supported-device alias for the standard target,
matching the short compatibility alias used by the CF-WR632AX.
Keep both existing targets and their NMBM partition maps intact.
Signed-off-by: Andrii Kuiukoff <andros.ua@gmail.com>
Signed-off-by: Guillaume RISCHARD <git@stereo.lu>
Link: https://github.com/openwrt/openwrt/pull/24590
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Set openwrt,netdev-name to wan on the dedicated GMAC and update the
default network and WAN LED configuration for both existing CF-WA933
variants. Filogic preinit reads this property to rename the interface.
Keep the physical port, PHY and MAC address assignment intact.
This follows the dedicated WAN naming used by similar Filogic devices,
using the explicit OpenWrt naming property as on the MERCUSYS MR85X.
Compat version can be avoided here, since the device hasn't shipped in
any stable builds yet.
Signed-off-by: Andrii Kuiukoff <andros.ua@gmail.com>
Signed-off-by: Guillaume RISCHARD <git@stereo.lu>
Link: https://github.com/openwrt/openwrt/pull/24590
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Use the MAC stored at Factory offset 0x8000 directly for Wi-Fi band 1.
The cell is a mac-base provider with one argument, so the previous
argument of 1 incremented the stored address rather than selecting
another EEPROM offset.
The CF-WA933 testing reported in PR #24590 identifies the stored
address as the 5 GHz MAC. Remove the extra increment, consistent with
the direct per-band factory MAC assignments on the COMFAST CF-WR632AX
and CF-XR186 Filogic devices. Both existing flash layouts use this cell.
The 1 incremented MAC address seems to have been cargo culted from other
devices that have three radios. The CF-WA933 has only two radios.
Signed-off-by: Andrii Kuiukoff <andros.ua@gmail.com>
Signed-off-by: Guillaume RISCHARD <git@stereo.lu>
Link: https://github.com/openwrt/openwrt/pull/24590
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The "virtual,mdio-gpio" bus on the Meraki MR52 muxed GPIO_0/GPIO_1 to
the SoC's dedicated "mdio" function via the shared mdio0_pins_active
group while also requesting them as GPIOs for the bit-banged MDIO
driver. Since Linux commit cc85cb96e2e4 ("pinctrl: qcom: make the
pinmuxing strict") the pinctrl core rejects a GPIO claim on pins
already claimed by a non-GPIO mux function:
ipq8064-pinctrl 800000.pinmux: pin GPIO_1 already requested by soc:mdio;
cannot claim for 800000.pinmux:513
so mdio_gpio_probe() fails, the MDIO bus is never registered and no
PHYs get attached to the ethernet interfaces.
Mux the pins to the "gpio" function in a board-local mdio_gpio0_pins
group instead, matching the onhub pattern; the GPIO request is allowed
because the gpio function is marked as a GPIO pin function.
Assisted-by: opencode:big-pickle
Signed-off-by: Rafal Boni <rafal.boni@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25886
Signed-off-by: Robert Marko <robimarko@gmail.com>
The two SFP cages of the Netgear GS750E (front panel ports 49 and 50)
are wired to the RTL8393M GPIOs: each cage has its own bit-banged I2C
bus plus mod-def0, LOS and tx-disable lines. Describe them so the sfp
driver can read the module EEPROM, detect insertion and removal, and
let phylink manage the link.
The pin map was recovered from the vendor firmware (V1.0.1.10):
cage SCL SDA mod-def0 LOS tx-disable
49 17 18 16 21 19
50 12 13 2 22 14
Tested on hardware with two GLC-SX-MMD-C 1000BASE-SX modules and the
stock "boota" bootcmd after a cold power cycle: both modules are
detected, EEPROM and DDM (hwmon) are read, and both links come up at
1 Gbps and pass traffic. Unplugging the fibre drops the link and it
comes back on reconnect. Pulling a module reports its removal, and on
reinsertion it is probed again and the link recovers (hotplug tested
with a backport to 25.12.5). The reset key and gpio-restart still work.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Bertrand d'Hérouville <bertrand.dherouville@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25898
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
On RTL839x the fiber PCS of the SerDes stays powered down (BMCR_PDOWN
set in the FIB page) unless the vendor bootloader ran "rtk network on"
before booting. Since the 1000base-x setup is not implemented yet and
relies on the bootloader, SFP ports never get a link when booting with
a plain "boota" bootcmd, which is the default on e.g. the Netgear
GS750E.
Clear BMCR_PDOWN on SerDes activation and set it again on deactivation,
like the RTL838x code already does.
Comparing SerDes 12/13 register dumps of a cold boot with and without
"rtk network on", the only configuration differences are FIB BMCR
(0x1940 vs 0x1140, i.e. BMCR_PDOWN) and SDS_EXT 0x1d/0x1e. The other
differing registers (BMSR, LPA, FIB_EXT 0x15) are link status. Clearing
BMCR_PDOWN alone is enough to get the link up.
Tested on a Netgear GS750E with two GLC-SX-MMD-C 1000BASE-SX modules,
bootcmd "boota" and a cold power cycle: both links come up at 1 Gbps.
Only 1000base-x was tested.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Bertrand d'Hérouville <bertrand.dherouville@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25898
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
legacy_sdcard_do_upgrade needs partx after a full image write, but only
some targets listed it in DEFAULT_PACKAGES, where it could be deselected.
Select it from the feature and add it to DEFAULT_PACKAGES for the
ImageBuilder, which also covers qoriq, sifiveu and mvebu/cortexa9.
Signed-off-by: John Audia <therealgraysky@proton.me>
Share the partition layout check and disk write with the other
whole-disk image targets, which keeps user partitions from being erased.
Signed-off-by: John Audia <therealgraysky@proton.me>
Share the partition layout check and full-image decision with the other
whole-disk image targets, which keeps user partitions from being erased.
Signed-off-by: John Audia <therealgraysky@proton.me>
Share the partition layout check and disk write with the other
whole-disk image targets, which keeps user partitions from being erased.
The bootloader write is dropped; it lacked /dev/ and never hit the disk.
Signed-off-by: John Audia <therealgraysky@proton.me>
Share the partition layout check and disk write with the other
whole-disk image targets, which keeps user partitions from being erased.
The bootloader write is dropped; it lacked /dev/ and never hit the disk.
Signed-off-by: John Audia <therealgraysky@proton.me>
Share the partition layout check and disk write with the other
whole-disk image targets, which keeps user partitions from being erased.
The bootloader write is dropped; it lacked /dev/ and never hit the disk.
Signed-off-by: John Audia <therealgraysky@proton.me>
Share the partition layout check and disk write with the other
whole-disk image targets, which keeps user partitions from being erased.
Signed-off-by: John Audia <therealgraysky@proton.me>
Share the partition layout check and disk write with the other
whole-disk image targets, which keeps user partitions from being erased.
Signed-off-by: John Audia <therealgraysky@proton.me>
Share the partition layout check and disk write with the other
whole-disk image targets, which keeps user partitions from being erased.
Signed-off-by: John Audia <therealgraysky@proton.me>
Share the partition layout check and disk write with the other
whole-disk image targets, which keeps user partitions from being erased.
Signed-off-by: John Audia <therealgraysky@proton.me>
Writing the full image erases partitions the image lacks. Refuse that at
upgrade time unless sysupgrade -p is given, so --force and failsafe
cannot bypass it, and read MBR and GPT tables the same way everywhere.
sysupgrade now exports SAVE_PARTITIONS to the image check and the -p help
text mentions the erase.
Signed-off-by: John Audia <therealgraysky@proton.me>
It writes to "$diskdev" without /dev/, so it creates a file in the
working directory and has never reached the disk.
Signed-off-by: John Audia <therealgraysky@proton.me>