OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Critical
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by tmn505 - 05.08.2019
Last edited by Adrian Schmutzler - 08.12.2020

FS#2428 - ath79: sysupgrade will brick devices with RedBoot bootloader

The current code responsible for upgrading devices with sysupgrade image, doesn’t take in to the account that “FIS” partition and “RedBoot config” partition can be on the same erase block. This can cause erasing the “RedBoot config” partition and make the device inoperable. The recovery would involve external SPI programmer or usage of JTAG.

The cause is still assumption so it will need confirmation. Flashing devices with factory image should be safe.

- Device problem occurs on:

   Ubiquiti RouterStation and RouterStation Pro
   jjPlus JA76PF2
   Adtran BSAP1880, BSAP1800 V2 and BSAP1840

- Software versions of OpenWrt release, packages, etc.:

   master and possibly 19.07

- Steps to reproduce

   syupgrade the device
Closed by  Adrian Schmutzler
08.12.2020 14:47
Reason for closing:  Fixed
Additional comments about closing:  

Working again since 5

Daniel Gimpelevich commented on 05.08.2019 19:28

On the Adtran devices, the "RedBoot config" partition has its own dedicated erase block, so they will not be affected in this way. However, related problems may still apply.

tmn505 commented on 13.08.2019 15:28

After further investigating on jjPlus JA76PF2:
a) sysupgrade works on current master for ath79 with 4.14 kernel meaning that:

 4.14 -> 4.14 works
 4.14 -> 4.19 works
 4.19 -> any other fails

b) when sysupgrading on 4.19, mtd will wipe "RedBoot config" if it's on the same erase block as "FIS directory" and also corrupt area between 0xF000 and 0x10000 where usually bootloader resides, which makes the board inoperable

c) this issue probably stems from kernel bump from 4.14 to 4.19 in which mtd driver can't handle partial erase blocks, the culprits could be either upstream changes or 'target/linux/generic/pending-4.19/411-mtd-partial_eraseblock_write.patch' which had bigger modification on the bump

d) affects only master

For reference the flash map of the tested board

dev:    size   erasesize  name
mtd0: 00040000 00010000 "RedBoot"
mtd1: 00120000 00010000 "linux"
mtd2: 00e80000 00010000 "rootfs"
mtd3: 00c60000 00010000 "rootfs_data"
mtd4: 0000f000 0000f000 "FIS directory"
mtd5: 00001000 00001000 "RedBoot config"
tmn505 commented on 20.08.2019 13:20

Finally I found backup of Ubiquiti RouterStation flash, and it behaves same as in previous comment:
a) corrupted area between 0xF000 and 0x10000

b) wiped "RedBoot config" partition which is on the same erase block as "FIS directory"

Weedy commented on 08.10.2019 21:27


f00b4r0 commented on 28.03.2020 12:11

partial erase block no longer works on 4.19

As far as I can tell, this bug was introduced here:

The above commit completely reworks 411-mtd-partial_eraseblock_write.patch in a way that apparently breaks it. Still investigating

tmn505 commented on 14.08.2020 11:08
Alexandros C. Couloumbis commented on 13.09.2020 19:12
Tested-by: Tomasz Maciej Nowak <tomek_n AT>
Fixes: FS#2428
@tmn505 so you think it's safe to use this patch against current trunk/linux-5.4.65, revert the sysupgrade removal & use sysupgrade safely again on RouterStations ?
tmn505 commented on 15.09.2020 15:03

Yes if You have kernel ≤ 4.14. If You somehow ended up with kernel 4.19 or later, the only safe option is to use TFTP recovery. After recovery any subsequent sysupgrade will be safe (TM) if kernel is patched with mentioned patch. I tested this on RouterStation.


Available keyboard shortcuts


Task Details

Task Editing