Djfe
July 10, 2024, 1:13pm
41
it's not a bug anymore, it's a feature now that Linux handles write protects on flash correctly. you can either restore legacy behavior or set the correct values in the dts to allow disabling write protection.
though OpenWrt should run on legacy behavior currently
committed 11:42AM - 24 Dec 23 UTC
Kernel 5.15 introduced a significant change to spi-nor subsystem [1],
which woul… d 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: 579703f38c14 ("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>
I'm able to boot the nanostation loco m5 23.05 image as @bmork mentioned.
I've created a dts with the correct mtd partition layout, and built OpenWRT 24.10, however can't successfully boot into this. The last little bit of the serial output:
[ 1.364668] Mem-Info:
[ 1.366991] active_anon:0 inactive_anon:0 isolated_anon:0
[ 1.366991] active_file:0 inactive_file:0 isolated_file:0
[ 1.366991] unevictable:5253 dirty:0 writeback:0
[ 1.366991] slab_reclaimable:213 slab_unreclaimable:942
[ 1.366991] mapped:0 shmem:0 pagetables:0
[ 1.366991] sec_pagetables:0 bounce:0
[ 1.366991] kernel_misc_reclaimable:0
[ 1.366991] free:2229 free_pcp:0 free_cma:0
[ 1.404211] Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:21012kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB kernel_stack:2016kB pagetables:0kB sec_pagetables:0kB all_unreclaimable? yes
[ 1.429705] Normal free:8916kB boost:8192kB min:8960kB low:9152kB high:9344kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:21012kB writepending:0kB present:65536kB managed:37204kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[ 1.456711] lowmem_reserve[]: 0 0
[ 1.460088] Normal: 5*4kB (UM) 2*8kB (UM) 3*16kB (UM) 2*32kB (UM) 1*64kB (U) 2*128kB (M) 1*256kB (U) 0*512kB 0*1024kB 0*2048kB 2*4096kB (UM) 0*8192kB = 8916kB
[ 1.474607] 5253 total pagecache pages
[ 1.478421] 0 pages in swap cache
[ 1.481788] Free swap = 0kB
[ 1.484709] Total swap = 0kB
[ 1.487641] 16384 pages RAM
[ 1.490473] 0 pages HighMem/MovableOnly
[ 1.494362] 7083 pages reserved
[ 1.497558] Tasks state (memory values in pages):
[ 1.502327] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
[ 1.511360] Out of memory and no killable processes...
[ 1.516577] Kernel panic - not syncing: System is deadlocked on memory
[ 1.523205] Rebooting in 1 seconds..
Not sure why this is as my device tree should be identical to that of the nanostation m5 image, but with the correct mtd partition layout.
bachi
June 9, 2026, 10:58am
43
Any news about UAP v2 devices? I have 6 of them, and i tried mtd method from https://openwrt.org/toh/ubiquiti/unifi_ap
*As of 2026: The following procedure worked to install OpenWrt 25.12.2 on the UAP with 64 MB RAM running factory firmware v4.3.28 *
scp the sysupgrade package to /tmp/openwrt.bin
build a *static* mtd binary and scp that to /tmp/mtd
verify you have the kernel partition as mtd2 and the size is correct:
# cat /proc/mtd
...
mtd2: 00760000 00010000 "kernel"
...
/tmp/mtd write /tmp/openwrt.bin kernel && reboot
After a moment the green led will blink showing the startup sequence is executing, then solid to show it is ready to ssh in.
after last command it says it's writing to partition, but after reboot, openwrt is not there, it loads default unifi os.
Firmware is v4.3.28
Wiki page should have the 8/64 warning added .
Try an older release.
bachi
June 9, 2026, 11:37am
45
OpenWRT v22.03.07, same result.
mk24
June 9, 2026, 2:23pm
46
I think you can use TFTP recovery to flash a factory OpenWrt because the bootloaders of those days did not look for firmware signatures during TFTP recovery.
Using serial will definitely work. In the bootloader, TFTP load and boot the intramfs OpenWrt then use it to flash the sysupgrade. I don't recommend what the wiki says to write directly to flash since if you make a mistake you can end up with a hard brick.