firmware-utils: mkfwimage: fix firmware_max_length for XM layout
authornbd <nbd@3c298f89-4303-0410-b956-a3cf2f4a3e73>
Mon, 29 Feb 2016 20:11:33 +0000 (20:11 +0000)
committernbd <nbd@3c298f89-4303-0410-b956-a3cf2f4a3e73>
Mon, 29 Feb 2016 20:11:33 +0000 (20:11 +0000)
commit02bd3a267ed5b8b870de6c233dda5ce6bf87c969
tree7f485183ecbfd0b1c8fe2441585ea99e5b139627
parentfc5e8ed5e73b5c80426ac582f267f674cdebed64
firmware-utils: mkfwimage: fix firmware_max_length for XM layout

The new u-boot version bundled with the 5.6.x firmwares from Ubiquiti gets
confused by the smaller rootfs partition size; this can lead to various
issues:

1. We've gotten reports that flashing from the 5.6.x stock firmware to
   OpenWrt will brick devices; I wasn't able to reproduce this myself
2. Flashing from 5.5.x stock firmware to OpenWrt and back to stock (via
   TFTP recovery), following by an update to 5.6.x via web interface can
   yield a bricked device with the following properties:
   - It can't be booted without entering commands over a serial console, as
     u-boot supplies the wrong MTD layout
   - The web interface won't accept any image with the original flash
     layout, so stock firmware upgrades are impossible
   - As the TFTP recovery doesn't update u-boot, returning to the old
     u-boot from firmware 5.5.x is impossible

To recover from 2., creating an OpenWrt image which doesn't set u-boot as
read-only and flashing a backup of the old u-boot from there is the only
way known to me. (Fixing the mtdparts variable in u-boot-env from OpenWrt
might also work; settings this from u-boot over serial didn't have
any permanent effect.)

Fix all of this by setting the correct flash layout also used by the stock
firmware. Flashing has been tested from both firmware 5.5.x and 5.6.x. The
fixed layout also matches the mtdparts defined by OpenWrt.

Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@48829 3c298f89-4303-0410-b956-a3cf2f4a3e73
tools/firmware-utils/src/mkfwimage.c