I don't see this problem (read errors from mtdblock2) on BPi-R64 booting off SPI-NAND as well. There it just works. It also got no calibration data in flash, so less partitions, no NVMEM stuff defined, ...
Only the Linksys E8450 seems to be affected so far.
Quite possibly - I also have a bunch of those MTD errors in kernel log.
Would it be possible to revert to the old SPI-NAND driver for this target only, at least until the MTD issues are fixed?
I updated the installer to re-write the existing data to flash and thereby fix the ECC problems we were seeing. No further changes are required, after re-running the installer everything should be fine again also when using the new SPI-NAND drvier.
That's great buddy, my RT3200 should arrive by the next week.
Awesome work!
By any chance, would it be possible to re-run that part of the installer, in the form of a snippet, without re-flashing the devices? At the moment I have three units running the release from this morning, and I won't have physical access to two of them till later this week.
I have two belkin rt3200 but I don't have update again with the new snapshot,
I have installed with dangowrt recovery installed the first time 0.5.2, I don't really understand which version will do use for the future of my two router also flashed with 0.5.2
I'm use which file recorevy installed? Or sys upgrade thanks for clarification
The problem is that in the final installation mtd0...2 are read-only. Only the installer patches DTS to have write-access there. If you do the same (ie. make a build with the read-only attributes removed from MTD partitions) then you can just read and write back /dev/mtd2 and that will fix it:
dd if=/dev/mtd2 of=/tmp/factory.bin
mtd write /tmp/factory.bin /dev/mtd2
sorry for my more than limited english, but if i understand correctly if i update the last snapshot i would have a problem on my router ??
Do I have to put the sys upgrade as usual or I can recreate by putting a flash firmware back up and put directly in luci recovery installer.itb? thank you
Yes, you understand correctly. Updating to latest snapshot will render wifi unusable as calibration data will be unreadable.
You need to flash openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery-installer.itb in LuCI (do NOT keep configuration) or using sysupgrade -n in shell. Once the new recovery comes up, you use it to flash new openwrt-mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade.itb and be done.
ok thanks a lot for your help, i really appreciate it,
can I still make a backup of my cofniguration to retransfer it afterwards?
in "generate archive"
Yes, the configuration is the same, ie. you can create a backup archive using your currently running firmware and then restore that backup in the newly flashed firmware.
I don't suppose it would be possible to build a recovery-initramfs+sysupgrade AIO image that would automate the manual flashing process?
Something like baking in the sysupgrade image into the squashfs of the recovery image, and running sysupgrade once the installer settles.
My problem is that two of the units are unreachable right now (both roommates are out of town, doors locked), and I only have access to the WAN port - sadly even the recovery comes with the "default" network config that blocks access from WAN, and since I can't keep my config (which puts the WAN port on the LAN bridge to make it a wireless AP), I can't flash the sysupgrade image afterwards.
What you describe is possible to some degree, but would require a quite customized installer containing a customized sysupgrade image which would already ship your configuration. As you are already running OpenWrt with UBI, the space constraints of the vendor loader do not apply, which would allow to embed both, recovery and sysupgrade image into the installer.
However, I suggest you wait for your flatmates to return as that sounds much easier 
Well, they're not going to be happy about me tinkering again 
for most people, home network is usually a "fire and forget" thing that they expect to work if untouched. Then they wonder why their router became compromised, running a 2012 model with a firmware from 2016 that was already considerably old (kernel and software additions vise)...
Ah, all this headache just makes me want to get back to my little pet project that would allow almost Unifi-style local provisioning, but that would require a considerable change of how OpenWrt handles initial configuration of the network interfaces - which is partly why I made that post a few weeks back about moving said configurations out into external packages (that would still be added into the firmware during compile time, but would allow replacement via e.g. Image Builder or ASU).
After flash an updated recovery, dont forget to set again "bootcmd" in case you changed it
I'm assuming this is a Luci bug, but just wanted to double check that it's not related to the calibration data problem before making a bug report, flashing your new installer brought the 5ghz radio back (thanks btw), but after installing the latest snapshot there's no wireless tab in Luci, wireless is all there in cli though.
edit - well never mind, right after I wrote that it occurred to me to generate a new wireless config and that brought up the wireless tab in Luci
So, the reason was the ECC thing as I thought ? 
I compiled your installer myself, and after reflashing the router with it, both radios work again and there aren't that many logged errors.
Curiously, there seems to an error regarding mtdblock2 "sector 256" or "logical block 32" that gets to the kernel log a dozen times at boot.
[ 13.857812] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 13.868862] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 13.879390] Buffer I/O error on dev mtdblock2, logical block 32, async page read
Looking at the install.sh code, the sectors in mtd2 after the wifi calibration data are left unwritten, right?
0x020000, the 128 kB rewritten and ECC fixed, while0x100000 and MACs are visible at 0x07fff4Apparently the mtdblock parser throws error at the end of the ECC fixed part, and determines that the mtdblock2 ends there, while the partition actually goes until 1 MB, with MACs at the middle.
Accessing mtdblock2 e.g. with hexdump causes errors to surface regarding the remaining sectors.
Sun Aug 29 09:54:32 2021 kern.warn kernel: [40943.627391] print_req_error: 54 callbacks suppressed
Sun Aug 29 09:54:32 2021 kern.err kernel: [40943.627399] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x84700 phys_seg 28 prio class 0
Sun Aug 29 09:54:32 2021 kern.err kernel: [40943.643487] blk_update_request: I/O error, dev mtdblock2, sector 264 op 0x0:(READ) flags 0x84700 phys_seg 27 prio class 0
Sun Aug 29 09:54:32 2021 kern.err kernel: [40943.654621] blk_update_request: I/O error, dev mtdblock2, sector 272 op 0x0:(READ) flags 0x84700 phys_seg 26 prio class 0
Sun Aug 29 09:54:32 2021 kern.err kernel: [40943.665712] blk_update_request: I/O error, dev mtdblock2, sector 280 op 0x0:(READ) flags 0x84700 phys_seg 25 prio class 0
Probably harmless, but strange that the new driver is so picky.
I wonder if it might make sense to rewrite also the remaining mtd2 (after the first 128 kB).
Yes it was ECC -- just not only what was written by the vendor but also all writes done using the old driver...
And yes, the installer only writes back the EEPROM data and MAC addresses inside mtd2, writing the whole partition didn't seem to be needed (and would also be slightly more tricky as there may be bad blocks between EEPROM data in the beginning and MAC addresses in the middle, so that the offset of the MACs would change ...).
As @981213 explained well in https://github.com/openwrt/openwrt/pull/4179 , the root-cause is a mix of API misuse by mt76 and mtdblock (not handling EUCLEAN) and apparently broken ECC data for things which had been written using the old driver.
I seem to be having a similar issue with snapshot where the 5ghz driver isn’t loaded. When I rolled back to commit 7119fd32d397567931e63dbbf72014e95624018f everything works fine again.
I’m running my own build without ubifs.
Hi @daniel , would you know if the old (snfi) nand driver work with the mtd2 ECC data that's re-written with the new v0.5.3 installer? Or would it be the case that once we use the new v0.5.3 installer, we must use the new snand driver?