[23.05] ath79: generic: disable SPI-NOR write protect unconditionally #14361
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
kernel
|
@blocktrron, did you have any chance to hit upstream with your patches containing proper fix? |
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> (cherry picked from commit f024f4b) Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
PolynomialDivision
force-pushed
the
ath79_ubnt_macronix_flash_write_fix_23.05
branch
from
83151c4
to
c55aaa7
Compare
fblaese
added a commit
to FreifunkFranken/firmware
that referenced
this pull request
Mar 22, 2024
OpenWrt v23.05 releases up to and including v23.05.2 contain a bug which causes some SPI flashes to be partially or fully unwriteable [1]. A workaround for this bug has already been added to the v23.05 branch, but no new version has been released since. Bump OpenWrt and corresponding feeds to the most recent commit on the v23.05 branch. [1] openwrt/openwrt#14361 Signed-off-by: Fabian Bläse <fabian@blaese.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: #12882
Fixes: #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
(cherry picked from commit f024f4b)