Hi @FieryEagle954 - which version of OEM firmware did you flash? Is it 1.1.0.78 or earlier? I'm wondering if different versions of OEM firmware have different factory partition layout??
Hi there, sorry to hear you're having the same issue as me. Since this was a little bit ago I have absolutely no memory of what version of the OEM firmware I used. All I did was nmrp flash the newest OEM firmware and then the then newest OpenWRT build and it has been working fine ever since
Hi @FieryEagle954 - thanks, based on the timing of your posts, I tried to nmrpflash factory img 1.1.0.78 (Dec'20) and then flash 21.02rc1 (Jan'20) but still no luck.
Would you be able to share a copy of your mtd5 factory file? I think mine is corrupted and not getting updated at all because every time the hexdump shows "15 76 00 ..." starting at 00048000 instead of 28000 or 8000.
Thanks!
I see you already installed the R6850 build, it's been a while and I don't have either R6850 or R6350, so I can't tell the exact differences. You've been lucky, since e.g. flash layout might differ and flashing builds for another device might easily wipe your radio calibration data altogether, rendering wireless completely unusable. So please don't do that again in the future.
And yes, reverting to vanilla OpenWrt images will make the problem show up again. The patches used in my build parse the bad block table of the device, which vanilla OpenWrt doesn't.
The bug's been reported and patches have been sent in by someone, but they're not in a state to be merged. That being said, you can build an image with them and they should work, or you build an image with a modified DTS. The latter is the easier approach: check the address of your calibration data (like you already did for one radio), and adapt the DTS accordingly, then build an image. You have two radios, so you have two addresses in your DTS. You need to modify both, usually by the same offset (I haven't seen it otherwise yet).
Thanks @Borromini a lot for your comments, guess I was lucky!
I tested my "new R6850" and wifi seems to be working fine.
I noticed the mtd partitioning is different now. Factory used to be on mtd5 on the R6350, but now it's on mtd16 on the R6850.
P.S. I also opened a bug referencing this post and said I tested your fix. Thanks a lot for building it!
Question: should I stick with R6850 builds from now on and never go back to R6350 builds to be safe? The funny thing is when my device was the "R6350" the DTS info was at 0x48000 on mtd5, and now with the "new R6850", it's at 0x08000 on mtd16. How does this work?
One more question: what's the best tutorial for setting up openwrt build environment? Is it better on Ubuntu or Macbook Pro? I'll look into that during Christmas break.
Hi @Borromini , I'm using your r6850 builds with sercomm parser from here
https://volatilesystems.org/dl/lede/targets/r6850/
on my R6350 with bad eraseblocks that forces the DTS info to be at 0x48000.
so far it works great, but I cannot install or update any packages, always comes back with:
The installed version of package kernel is not compatible, require 5.4.162-1-58214f1a… while 5.4.105-1-7684bdfb… is installed.
when I try to install kmod-mtd-rw, or sqm
it seems upgrading kernel is not allowed, but if I go to a newer snapshot, my wifi 5Ghz goes back to too low power.
Any suggestions? I know I should try to learn to build it myself... Thanks!
It's an old personal build, so vanilla OpenWrt kernel packages won't work. You need a vanilla OpenWrt build for that (or one you roll your own with the extra packages compiled along).
Hi @Borromini - I got it work as follows:
- sysupgrade from your build to latest stable release
- Install kmod-mtd-rw and make mtd writable, e.g.
insmod mtd-rw.ko i_want_a_brick=1 - overwrite mtd5 with a saved factory bin with 5Ghz DTS starting at 08000, that I saved when I was using your build, i.e.
mtd write openwrt.factory8000.bin /dev/mtd5
Now I'm on the latest stable with working wifi!
Couldn't have done it without your build, thanks!
1 Like
Clever! Great to hear you found a workaround!
Thanks! It was your idea to save and apply the mtd. I just put the two together 
Is this fixed on 22.03.0?
I just installed 21.02.3 on two r6350s.
One works correctly and the other is limited to 6dbm
I tried reverting to stock and the power was correct.
I then reinstalled 21.02.3 and it still has the problem.
Do they have different bad blocks?
I don’t know if they have different bad blocks (or how to check)
I set up one 6350 with 21.02.3 and it works correctly.
When I set up the second 6350, I discovered it had speed and power issues on 5Ghz.
When I found it was missing some of the power settings, I tried reinstalling Openwrt.
I searched for r6350 and found this thread that appears to be the same problem.
Borromini indicates in one post that patches were under development.
This was over six months ago so I am hoping that they are in 22.03.0.
The required patch was merged into master but not into 22.03. So the basic support is there in master. You can adapt the DTS for your hardware in the same way I have adapted it in this patch for the Netgear R6800 e.g..
1 Like
Does that patch actually work, especially for the factory partition? It looks to me like the partition IDs would be wrong, as the two reserved partitions actually correspond to multiple ones in the partition map on flash. In my patch from February 2021 (which I created based on the GPL source from Netgear) the factory partition had ID 16.
I have no bad blocks, so I can't confirm nor deny. If you could test with the patch that was merged in master, feel free to send in an improved patch. I already forgot where I got the index count from exactly.
Thanks for the quick reply even though it isn’t what I was hoping for.
I have a third 6350 with stock firmware to try before learning how to make a patch.
My guess is that most 6350s don’t have the problem.
The R6350 has factory partition on mtd16
The R6850 has factory partition on mtd5
Borromini's patch turns the R6350 into a R6850, and worked fine for me. I'm still running it until the official release has the fix.
I can also upgrade from the patch to a stable release and then overwrite the factory mtd, even survives a reboot.
That does not make sense. Both are essentially the same device with a different label, and use the same partition table (together with other CHJ devices, and as it looks BZV as well). In the GPL sources from Netgear, the factory partition is at index 16 (but that does not mean it has to be at mtd16 in Linux).
I think I remembered where I got the numbering from - from that very patch you sent earlier and just linked to. The mt7621_netgear_sercomm_bzv.dtsi modifications (which apply to the R6800) just show numbering starting from zero.