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).
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!
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.
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..
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.
You can confirm this by flashing a 6850 factory build on a 6350, and check the log files, factory mtd moves from mtd16 to /dev/mtd5.
just ran this on my R6350:
In your patch, the factory partition has an ID of 5 though, which doesn't seem right to me (in my patch it was 16 which seems to match the GPL source for both CHJ and BZV which I just checked again).
I'm currently building an image to test on my WAC124 (this is a CHJ device). It also doesn't have any bad blocks, but as long as there is a actually partition map on the flash, a wrong partition ID should still result in a broken partition table in Linux.
If you use unpatched OpenWrt images there should be no difference, as both use the same device tree (except for the different device name). As far as I can see, the 7-partition layout with the factory partition at mtd5 has been used since support for these devices was added to OpenWrt.
Okay maybe you are right that it's because Borrominis image has factory on mtd5, not related to 6530 or 6580, and his image was for the 6850 so I assumed it was difference between 6350 and 6380.
Thanks for clarifying.
