Skip to content
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

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

Closed
openwrt-bot opened this issue Aug 5, 2019 · 8 comments
Closed
Labels

Comments

@openwrt-bot
Copy link

tmn505:

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

@openwrt-bot
Copy link
Author

danielg4:

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.

@openwrt-bot
Copy link
Author

tmn505:

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"

@openwrt-bot
Copy link
Author

tmn505:

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"

@openwrt-bot
Copy link
Author

weedy:

Ping

@openwrt-bot
Copy link
Author

f00b4r0:

partial erase block no longer works on 4.19

As far as I can tell, this bug was introduced here: http://git.openwrt.org/9261e7447

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

@openwrt-bot
Copy link
Author

tmn505:

For anyone involved, this patch fixes the bug:
[[https://patchwork.ozlabs.org/project/openwrt/patch/20200805211354.3922-1-git@johnthomson.fastmail.com.au|kernel: fix mtd partition erase<parent_erasesize writing to wrong address]]

@openwrt-bot
Copy link
Author

acoul:

Tested-by: Tomasz Maciej Nowak <tomek_n AT o2.pl>
Fixes: FS#2428

@tmn505 so you think it's safe to use [[https://patchwork.ozlabs.org/project/openwrt/patch/20200805211354.3922-1-git@johnthomson.fastmail.com.au/|this patch]] against current trunk/linux-5.4.65, revert the [[https://github.com/openwrt/openwrt/commit/0cc87b3baceedd05208464f7fc7b5157bd618505|sysupgrade removal]] & use sysupgrade safely again on RouterStations ?

@openwrt-bot
Copy link
Author

tmn505:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant