[openwrt/openwrt] ramips: fix TP-Link mr600 radio partition offset

LEDE Commits lede-commits at lists.infradead.org
Sat Aug 23 09:15:29 PDT 2025


hauke pushed a commit to openwrt/openwrt.git, branch main:
https://git.openwrt.org/e7ed87b83b62cc3920cf1f25abbf6f06c96fee66

commit e7ed87b83b62cc3920cf1f25abbf6f06c96fee66
Author: Stefan Dösinger <stefandoesinger at gmail.com>
AuthorDate: Sat Aug 9 17:29:38 2025 +0300

    ramips: fix TP-Link mr600 radio partition offset
    
    This makes 5ghz WiFi work out of the box on these devices, eliminating
    the need to flash a magic blob to the radio partition.
    
    This was found by user BulldozerBSG on the OpenWRT Forums:
    https://forum.openwrt.org/t/tp-link-archer-mr600-exploration/65489/20
    All credit belongs to them. I can confirm the correctness of the
    findings. At least one other user (Iggy87100) confirmed them too.
    
    Signed-off-by: Stefan Dösinger <stefandoesinger at gmail.com>
    Link: https://github.com/openwrt/openwrt/pull/19790
    Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
---
 target/linux/ramips/dts/mt7621_tplink_mr600-v2-eu.dts | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/target/linux/ramips/dts/mt7621_tplink_mr600-v2-eu.dts b/target/linux/ramips/dts/mt7621_tplink_mr600-v2-eu.dts
index be68471b44..246fd16a72 100644
--- a/target/linux/ramips/dts/mt7621_tplink_mr600-v2-eu.dts
+++ b/target/linux/ramips/dts/mt7621_tplink_mr600-v2-eu.dts
@@ -136,9 +136,26 @@
 				read-only;
 			};
 
+			/* The boot log of the stock kernel suggests the radio partition is at
+			 * 0xfe0000, but this is wrong. The U-Boot log lists it at 0xff0000. The
+			 * WiFi driver's log output indicates the calibration data is read from a
+			 * hardcoded 0xff0000, ignoring mtd partitions:
+			 *
+			 * 0x000000fe0000-0x000000ff0000 : "radio" <- WRONG
+			 * ...
+			 * MT7603E--> ####  read 2.4G cal from flash !! ####
+			 * spiflash_ioctl_read, Read from 0x00ff0000 length 0x10000, ...
+			 *
+			 * Manual inspection shows 0xfe0000 is empty (0xff) bytes. 0xff0000 contains
+			 * the data we want. */
 			partition at fe0000 {
-				label = "radio";
+				label = "filler";
 				reg = <0xfe0000 0x10000>;
+			};
+
+			partition at ff0000 {
+				label = "radio";
+				reg = <0xff0000 0x10000>;
 				read-only;
 
 				nvmem-layout {




More information about the lede-commits mailing list