mirror of
https://git.openwrt.org/openwrt/openwrt.git
synced 2026-03-14 14:59:45 +01:00
ramips: fix TP-Link mr600 radio partition offset
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
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@gmail.com> Link: https://github.com/openwrt/openwrt/pull/19790 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This commit is contained in:
parent
65ed5f8d6d
commit
e7ed87b83b
1 changed files with 18 additions and 1 deletions
|
|
@ -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@fe0000 {
|
||||
label = "radio";
|
||||
label = "filler";
|
||||
reg = <0xfe0000 0x10000>;
|
||||
};
|
||||
|
||||
partition@ff0000 {
|
||||
label = "radio";
|
||||
reg = <0xff0000 0x10000>;
|
||||
read-only;
|
||||
|
||||
nvmem-layout {
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue