New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ath79: generic: disable SPI-NOR write protect unconditionally to fix UBNT XW and WA devices #14237
ath79: generic: disable SPI-NOR write protect unconditionally to fix UBNT XW and WA devices #14237
Conversation
66ae651
to
b55f493
Compare
Related to #13750. |
Related to #12882. |
Kernel 5.15 introduced a significant change to spi-nor subsystem [1], which would the SPI-NOR core to no longer unprotect the Flash chips if their protection bits are non-volatile, which is the case for MX25L6405D and MX25L12805D, used in Ubiquiti XW and WA lines of devices [2]. However, their bootloader forcibly enables this protection before continuing to boot, making the kernel not unprotect the flash upon boot, causing JFFS2 to be unable write to the filesystem. Because sysupgrade seems to unlock the flash explicitly, the upgrade will work, but the system will be unable to save configrationm showing the following symptom in the kernel log: [ 86.168016] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0 [ 86.192344] jffs2_build_filesystem(): unlocking the mtd device... [ 86.192443] done. [ 86.200669] jffs2_build_filesystem(): erasing all blocks after the end marker... [ 86.220646] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001e0000 [ 86.292388] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001d0000 [ 86.324867] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001c0000 [ 86.355316] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001b0000 [ 86.402855] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001a0000 Disable the write protection unconditionally for ath79/generic subtarget, so the XW and WA devices can function again. However, this is only a stopgap solution - it probably should be investigated if there is a way to selectively unlock the area used by rootfs_data - but given the lock granularity, this seems unlikely. With this patch in place, rootfs_data partition on my Nanostation Loco M5 XW is writable again. Fixes: openwrt#12882 Fixes: openwrt#13750 Fixes: 579703f ("ath79: switch to 5.15 as default kernel") Link: http://www.infradead.org/pipermail/linux-mtd/2020-October/082805.html Link: https://forum.openwrt.org/t/powerbeam-m5-xw-configuration-loss-after-reboot/141925 Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
b55f493
to
f024f4b
Compare
Tested on Ubiquity Nanostation AC loco (WA). Context/results:
@chunkeey @hauke I'd like to echo the request to backport this to 23.05. Given the pain to recover (some of these devices are designed to be installed outdoor, and recovery sometimes require flashing back the Ubiquiti firmware over TFTP), I believe this should be listed in the known issues in the release notes as well. If there's anything missing for either of these two things to happen, please advise. |
IIRC this was a simple cherry-pick (I'm building my images from source) so +1 for the above. |
Kernel 5.15 introduced a significant change to spi-nor subsystem [1], which would the SPI-NOR core to no longer unprotect the Flash chips if their protection bits are non-volatile, which is the case for MX25L6405D and MX25L12805D, used in Ubiquiti XW and WA lines of devices [2].
However, their bootloader forcibly enables this protection before continuing to boot, making the kernel not unprotect the flash upon boot, causing JFFS2 to be unable write to the filesystem. Because sysupgrade seems to unlock the flash explicitly, the upgrade will work, but the system will be unable to save configrationm showing the following symptom in the kernel log:
[ 86.168016] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
[ 86.192344] jffs2_build_filesystem(): unlocking the mtd device...
[ 86.192443] done.
[ 86.200669] jffs2_build_filesystem(): erasing all blocks after the end marker...
[ 86.220646] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001e0000
[ 86.292388] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001d0000
[ 86.324867] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001c0000
[ 86.355316] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001b0000
[ 86.402855] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001a0000
Disable the write protection unconditionally for ath79/generic subtarget, so the XW and WA devices can function again. However, this is only a stopgap solution - it probably should be investigated if there is a way to selectively unlock the area used by rootfs_data - but given the lock granularity, this seems unlikely.
With this patch in place, rootfs_data partition on my Nanostation Loco M5 XW is writable again.
Fixes: 579703f ("ath79: switch to 5.15 as default kernel")
Link: http://www.infradead.org/pipermail/linux-mtd/2020-October/082805.html
Link: https://forum.openwrt.org/t/powerbeam-m5-xw-configuration-loss-after-reboot/141925
Closes #13750