OpenWrt support for Linksys MX4200

gameinn · June 2, 2025, 11:37am

Another thing I was wondering. In regards to flashing to another partition via wiki.

Now forgive me as I don't know much about this but does it not make more sense to do all this in ssh and never even touch SCP? i.e.

cd /tmp

wget "https://downloads.openwrt.org/releases/24.10.1/targets/qualcommax/ipq807x/openwrt-24.10.1-qualcommax-ipq807x-linksys_mx4200v2-squashfs-factory.bin"

mv "openwrt-24.10.1-qualcommax-ipq807x-linksys_mx4200v2-squashfs-factory.bin" "mx4200.bin"

[ "$(sha256sum mx4200.bin | awk '{print $1}')" == "54f61ec90aa0fe2d61b6d40230b7cc9f35965b6ef64c390ac548fd39fa4a48d4" ] && echo "Firmware check passed!" || echo "Firmware is corrupted, download it again!"

Then do the normal write as per wiki e.g:

mtd -r -e alt_kernel -n write mx4200.bin alt_kernel

The main advantage of this method is you get to make sure the checksum passed before flashing and a simple rename before you attempt flashing. I also guess you could just do sha256sum mx4200.bin and compare to the value on OpenWRT site but thought I would mention it.

RainGater · June 4, 2025, 7:06pm

I am NOT sure where you got that this will NOT boot. This is what I am doing ever since I owned MX4300. Whenever you flash sysupgrade, it updates the other partition and boots from it. If you retain the settings, then the settings are copied over to the other partition as well.

RainGater · June 4, 2025, 7:07pm

I used to build but gave up on it and rely on arix00's build now. So, I use his binaries and works very well.

jmandawg · June 5, 2025, 6:41pm

If anyone is interested, here is a clean build for MX4300 from Qosimos latest changes to the 24.10-nss branch using his seeded config (which includes nss accelerated SQM) use at your own risk:

RainGater · June 10, 2025, 5:12pm

I see that arix00 has abandoned the builds as it hasn't been updated for a while now. Is it possible to do a sysupgrade from the official SNAPSHOT build without a RESET? Anyone tried it without a RESET?

FanOfOpenWRT · June 11, 2025, 12:29am

Pretty sure I did this exact thing before (going from arix or another custom build straight to SNAPSHOT). It will most likely work but you'll have leftover, unused files on the device.

Someone please correct me if wrong.

abqjln · June 11, 2025, 12:26pm

Very new here, hope I am following correctly. I just upgraded 2 MX4200 and 5 MX4300 from snapshots this weekend to 24.10 and had to use factory.bin, not sysupgrade (failed), from snapshots. Either from Linksys-CA or ssh. All worked nicely.

moh1t · June 11, 2025, 12:55pm

I ended up compiling NSS version from Qosmio directly. It's fairly easy. I had to take this route since I wanted to build in a few kmod packages that the other pre-compiled versions lack.

Can also flash pre-compiled NSS builds from here Qualcommax NSS Build - #4859 by AgustinLorenzo

RainGater · June 11, 2025, 1:59pm

I flashed the latest snapshot and luci interface isn't coming up. "luci" is already there in the package list. Any other package for luci?

frollic · June 11, 2025, 2:05pm

need to click the "Request build" button, the links below it will get you files without luci.

RainGater · June 11, 2025, 2:06pm

It says Installed Packages and that's why I didn't request the build. Now, I have to flash it from shell. For those who didn't include luci and flashed the snapshot build, ssh to router and run:

apk update

apk add luci

frollic · June 11, 2025, 2:08pm

https://openwrt.org/docs/guide-user/installation/sysupgrade.cli, or simply flash a stable release - https://firmware-selector.openwrt.org/?version=24.10.1, then you don't need to build anything.

RainGater · June 11, 2025, 2:10pm

Never mind. I added the luci package and all good now.

root@MX4300:~# apk update

root@MX4300:~# apk add luci

frollic · June 11, 2025, 2:11pm

great!

just keep in mind: https://openwrt.org/faq/cannot_satisfy_dependencies.

dalant · June 12, 2025, 8:23am

Notice that the initial "total" available memory on the OEM firmware is much smaller (436224K) vs OpenWrt (524288K), which means that on the OEM kernel, 88064K is reserved in advance. This makes the difference in reserved memory usage between the two firmwares closer to 49MiB, which might be typical for the more advanced kernel/OS requirements of OpenWrt. 4MiB of that can be directly tied to kernel requirements.

So going on the dmesg output alone, and not really knowing the internals of how the kernel allocates memory, I think the best base scenario is 45MiB freed up.

That being said, it is possible that the memory being reserved for qualcomm special functions is overallocating on 512MiB ram devices. I think it should be adjusting the following:

github.com/openwrt/openwrt

target/linux/qualcommax/files/arch/arm64/boot/dts/qcom/ipq8074-512m.dtsi

openwrt-24.10

// SPDX-License-Identifier: GPL-2.0-only

#include "ipq8074.dtsi"

&tzapp_region {
	reg = <0x0 0x4a400000 0x0 0x100000>;
};

&q6_region {
	reg = <0x0 0x4b000000 0x0 0x3700000>;
};

&q6_etr_region {
	reg = <0x0 0x4e700000 0x0 0x100000>;
};

&m3_dump_region {
	reg = <0x0 0x4e800000 0x0 0x100000>;
};

Best I can tell, that is not happening, and it is using the defaults from:

github.com/openwrt/openwrt

target/linux/qualcommax/patches-6.6/0102-arm64-dts-ipq8074-add-reserved-memory-nodes.patch

openwrt-24.10

From ad2d07f71739351eeea1d8a120c0918e2c4b265f Mon Sep 17 00:00:00 2001
From: Robert Marko <robimarko@gmail.com>
Date: Wed, 22 Dec 2021 12:23:34 +0100
Subject: [PATCH] arm64: dts: ipq8074: add reserved memory nodes

IPQ8074 has multiple reserved memory ranges, if they are not defined
then weird things tend to happen, board hangs and resets when PCI or
WLAN is used etc.

So, to avoid all of that add the reserved memory nodes from the downstream
5.4 kernel from QCA.
This is their default layout meant for devices with 1GB of RAM, but
devices with lower ammounts can override the Q6 node.

Signed-off-by: Robert Marko <robimarko@gmail.com>
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 35 +++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi

This file has been truncated. show original

If my math is correct, that could free up another 41MiB of memory. If anyone else can provide insights, that would be helpful.

FanOfOpenWRT · June 12, 2025, 9:48am

Sorry for not mentioning that in advance... it's in the online docs and elsewhere that pre-built SNAPSHOT images don't include Luci. If you use the firmware selector/image builder convenience site, you can see it will be built with Luci. Custom builds generally include it because everyone uses it.

dalant · June 12, 2025, 10:51am

Okay I think I know what is going on. Specifically in the Linksys MX4x00 support, there is a double #include that ends up overwriting the special parameters for 512M ram devices.

github.com/openwrt/openwrt

target/linux/qualcommax/files/arch/arm64/boot/dts/qcom/ipq8174-mx4200v1.dts

openwrt-24.10

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/* Copyright (c) 2023, Mohammad Sayful Islam <Sayf.mohammad01@gmail.com> */

/dts-v1/;

#include "ipq8074-512m.dtsi"
#include "ipq8174-mx4200.dtsi"

/ {
	model = "Linksys MX4200v1";
	compatible = "linksys,mx4200v1", "qcom,ipq8074";
};

&wifi {
	status = "okay";

	qcom,ath11k-calibration-variant = "Linksys-MX4200v1";
	qcom,ath11k-fw-memory-mode = <1>;
};

Both "ipq8074-512m.dtsi" and "ipq8174-mx4200.dtsi" ultimately include "ipq8074.dtsi", so "ipq8074-512m.dtsi" is effectively nullified. I'll have to spend a little more time testing though.

RainGater · June 12, 2025, 1:43pm

I used the firmware builder openwrt website ONLY and see that luci was included in the build but it is NOT. You have to click the "Request Build" to include luci as the "Included Packages" fooled me. lol

dalant · June 13, 2025, 11:31am

@Snuupy @eginnc @sppmaster

Here is a MX4200v1 24.10.1-release build with a single line device-tree fix:

This brings the Qualcomm reserved memory ranges from 128,000K down to 86,016K. Difference of 41,984K and just under the amount pre-reserved on OEM firmware.

Memory: 413568K/524288K available (8576K kernel code, 922K rwdata, 1660K rodata, 1600K init, 293K bss, 110720K reserved, 0K cma-reserved)

413,568K available at boot which is much closer to the 424,012K available in the OEM boot log. Difference of 10,444K, of which 5,259K is directly accountable to higher allocations. I think this is as good as it's going to get for this hardware.

First boot before:

First boot after:

I've tested this build on my hardware, and have had no issues so far. I will give it a few days for a soak test, and then I'll submit a patch.

eginnc · June 13, 2025, 10:18pm

Wonderful! I'll have some time this weekend to set it up as one of my dumb AP's. I'll let you know how it goes.