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.
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:
root@OpenWrt:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00100000 00020000 "SC PART_MAP"
mtd2: 00400000 00020000 "kernel"
mtd3: 02800000 00020000 "ubi"
mtd4: 01800000 00020000 "reserved0"
mtd5: 00200000 00020000 "factory"
mtd6: 03800000 00020000 "reserved1"
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.
1 Like
I installed 21.02.3 on the third 6350 and I don’t see any problems.
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.
I just completed the test on my WAC124.
With my old patch (after replacing scpart-id by sercomm,scpart-id to make it compatible with the upstream driver), the partition table is correct (factory partition is where it should be).
Kernel log (factory partition with id 16)
[ 0.982259] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1
[ 0.994921] nand: Macronix MX30LF1G18AC
[ 1.002542] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 1.017628] mt7621-nand 1e003000.nand: ECC strength adjusted to 4 bits
[ 1.030685] mt7621-nand 1e003000.nand: Using programmed access timing: 21005134
[ 1.045246] mt7621-nand 1e003000.nand: Using programmed access timing: 21005134
[ 1.059801] Scanning device for bad blocks
[ 2.401576] scpart: Valid 'SC PART MAP' (29 partitions) found at 0x100000
[ 2.415242] 29 scpart partitions found on MTD device mt7621-nand
[ 2.427204] Creating 29 MTD partitions on "mt7621-nand":
[ 2.437792] 0x000000000000-0x000000100000 : "u-boot"
[ 2.448827] 0x000000100000-0x000000200000 : "SC PART_MAP"
[ 2.460936] 0x000000200000-0x000000600000 : "kernel"
[ 2.471891] 0x000000600000-0x000002e00000 : "ubi"
[ 2.482425] 0x000002e00000-0x000003000000 : "English UI"
[ 2.494082] 0x000003000000-0x000003200000 : "ML1"
[ 2.504473] 0x000003200000-0x000003400000 : "ML2"
[ 2.514842] 0x000003400000-0x000003600000 : "ML3"
[ 2.525224] 0x000003600000-0x000003800000 : "ML4"
[ 2.535581] 0x000003800000-0x000003a00000 : "ML5"
[ 2.546024] 0x000003a00000-0x000003c00000 : "ML6"
[ 2.556384] 0x000003c00000-0x000003e00000 : "ML7"
[ 2.566768] 0x000003e00000-0x000004000000 : "ML8"
[ 2.577253] 0x000004000000-0x000004200000 : "ML9"
[ 2.587678] 0x000004200000-0x000004400000 : "ML10"
[ 2.598239] 0x000004400000-0x000004600000 : "ML11"
[ 2.608809] 0x000004600000-0x000004800000 : "factory"
[ 2.619950] 0x000004800000-0x000004a00000 : "SC Private Data"
[ 2.632317] 0x000004a00000-0x000004c00000 : "POT"
[ 2.642763] 0x000004c00000-0x000004e00000 : "Traffic Meter"
[ 2.654859] 0x000004e00000-0x000005000000 : "SC PID"
[ 2.665826] 0x000005000000-0x000005200000 : "SC Nvram"
[ 2.677073] 0x000005200000-0x000005400000 : "Ralink Nvram"
[ 2.689039] 0x000005400000-0x000005600000 : "reserved0"
[ 2.700464] 0x000005600000-0x000005800000 : "reserved1"
[ 2.711900] 0x000005800000-0x000005a00000 : "reserved2"
[ 2.723388] 0x000005a00000-0x000005c00000 : "reserved3"
[ 2.734870] 0x000005c00000-0x000005e00000 : "reserved4"
[ 2.746427] 0x000005e00000-0x000007f80000 : "reserved5"
With your patch applied to mt7621_netgear_sercomm_chj.dtsi, the partition table is broken. In this case ML1 is used as factory partition (with the expected results). The two reserved partitions are also wrong (but of course that doesn't directly break anything as they aren't used).
Kernel log (factory partition with id 5)
[ 0.982495] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1
[ 0.995149] nand: Macronix MX30LF1G18AC
[ 1.002771] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 1.017854] mt7621-nand 1e003000.nand: ECC strength adjusted to 4 bits
[ 1.030895] mt7621-nand 1e003000.nand: Using programmed access timing: 21005134
[ 1.045456] mt7621-nand 1e003000.nand: Using programmed access timing: 21005134
[ 1.060005] Scanning device for bad blocks
[ 2.402340] scpart: Valid 'SC PART MAP' (29 partitions) found at 0x100000
[ 2.415909] 7 scpart partitions found on MTD device mt7621-nand
[ 2.427695] Creating 7 MTD partitions on "mt7621-nand":
[ 2.438103] 0x000000000000-0x000000100000 : "u-boot"
[ 2.449177] 0x000000100000-0x000000200000 : "SC PART_MAP"
[ 2.461104] 0x000000200000-0x000000600000 : "kernel"
[ 2.472036] 0x000000600000-0x000002e00000 : "ubi"
[ 2.482492] 0x000002e00000-0x000003000000 : "reserved0"
[ 2.493926] 0x000003000000-0x000003200000 : "factory"
[ 2.504999] 0x000003200000-0x000003400000 : "reserved1"
@Borromini: If it actually works for you with a partition ID of 5 for the factory partition, could you check if the kernel log contains any scpart messages on your device?
Here's the kernel log from my 6350 flashed with the 6850 patch, if it helps?
and does your build work for the R6350?
Sun Jun 5 21:48:09 2022 kern.info kernel: [ 1.004198] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1
Sun Jun 5 21:48:09 2022 kern.info kernel: [ 1.016852] nand: Macronix MX30LF1G18AC
Sun Jun 5 21:48:09 2022 kern.info kernel: [ 1.024494] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
Sun Jun 5 21:48:09 2022 kern.info kernel: [ 1.039585] mt7621-nand 1e003000.nand: ECC strength adjusted to 4 bits
Sun Jun 5 21:48:09 2022 kern.info kernel: [ 1.052630] mt7621-nand 1e003000.nand: Using programmed access timing: 21005134
Sun Jun 5 21:48:09 2022 kern.info kernel: [ 1.067188] mt7621-nand 1e003000.nand: Using programmed access timing: 21005134
Sun Jun 5 21:48:09 2022 kern.info kernel: [ 1.081757] Scanning device for bad blocks
Sun Jun 5 21:48:09 2022 kern.warn kernel: [ 1.362166] Bad eraseblock 216 at 0x000001b00000
Sun Jun 5 21:48:09 2022 kern.warn kernel: [ 1.778105] Bad eraseblock 540 at 0x000004380000
Sun Jun 5 21:48:09 2022 kern.notice kernel: [ 2.394678] 7 fixed-partitions partitions found on MTD device mt7621-nand
Sun Jun 5 21:48:09 2022 kern.notice kernel: [ 2.408195] Creating 7 MTD partitions on "mt7621-nand":
Sun Jun 5 21:48:09 2022 kern.notice kernel: [ 2.418631] 0x000000000000-0x000000100000 : "u-boot"
Sun Jun 5 21:48:09 2022 kern.notice kernel: [ 2.429554] 0x000000100000-0x000000200000 : "SC PART_MAP"
Sun Jun 5 21:48:09 2022 kern.notice kernel: [ 2.441682] 0x000000200000-0x000000600000 : "kernel"
Sun Jun 5 21:48:09 2022 kern.notice kernel: [ 2.452527] 0x000000600000-0x000002e00000 : "ubi"
Sun Jun 5 21:48:09 2022 kern.notice kernel: [ 2.463047] 0x000002e00000-0x000004600000 : "reserved0"
Sun Jun 5 21:48:09 2022 kern.notice kernel: [ 2.474491] 0x000004600000-0x000004800000 : "factory"
Sun Jun 5 21:48:09 2022 kern.notice kernel: [ 2.485516] 0x000004800000-0x000008000000 : "reserved1"
Sun Jun 5 21:48:09 2022 kern.info kernel: [ 2.540499] mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module
OK. I checked your original patch again and it adds a bunch of other partitions whereas OpenWrt master now just expands that reserved0 partition to a total of 0x1800000 bytes. And those extra partitions in your DTSI patch make factory indeed have ID 16. I overlooked that the first time 
. After the factory partition, the master DTSI does the same again: it it allocates the remainder of the flash to reserved1, whereas your patch divides it into multiple partitions (to reflect OEM partitioning I suppose). I will adapt my patch.
Any idea why those reserved ranges are treated as one big partition in OpenWrt? I suppose because they're irrelevant to OpenWrt operation and only needed by the OEM firmware.
Edit: revised patch for both the BZV and CHJ platforms here.
@janh I will test again on my R6800 and report back, if you could test on your WAC124 and if it's looking good provide your Acked-by/Suggested-by/Tested-by/... - whatever feels appropriate to you.
@tsuda @jea101 @Jawadbz Since I'm at it anyway I will be whipping up images based on 22.03 HEAD. If you could test and report back for your specific device, that would be great and we can include your Tested-by in the final patch that gets sent in.
1 Like
Nice! Thanks a lot!!
Update: flashed and working well so far
Note to others who want to try: Luci is gone after upgrade, you need to reinstall it if you still have ssh root access and internet access.
1 Like