@pepermint @darkjrtk75 I have figured out why you are bricking your MR5500 and MR7350 devices when doing an OpenWrt sysupgrade. I have tested and confirmed my observations several times on my MR5500 and I assume this also applies to MR7350 - please feel free to double check my findings. The MR5500 thread can be found here: Adding support for Linksys MR5500 - #235 by KrypteX
So these are dual-boot firmware Linksys devices, meaning they have a failsafe mechanism in case of a bad firmware flash and allow us to easily go back to the previously working/functional firmware. This is done at the bootloader level and works like this: the router has 2 boot partitions (called 1 and 2) and when a new firmware is flashed from the currently booted partition, it will get written to the OTHER (also called alternative) partition. This is important to always keep in mind.
The current and alternative partitions are not to be confused with 1 and 2. The current boot partition can be 1 and alternative is 2, or current can be 2 and alternative is then 1. Which one (1 or 2) is current is specified in a round-robin fashion, depending which one is flashed when doing the upgrade.
So let’s assume current is 1 and we perform a firmware upgrade. The new firmware will be written to the alternative partition, which is now partition 2, and it will be booted in the next boot cycle. If the router can’t boot from it 3 times in a row, it will set the boot partition back to the previous working partition, which is partition 1 in this case. This is the fail-safe mechanism.
The fail-safe can also be controlled manually by physically power-cycling the device 3 times (on/off), so it will then boot from the other partition. Or there’s a very useful openwrt package called luci-app-advanced-reboot which can be used to reboot easily into any partition with a click, here’s a screenshot (at the moment my Current is partition 2 and the Alternative is the other one, partition 1):
The reason for bricking is that the two boot partitions have different brands of firmwares: e.g. OpenWrt and Linksys stock/factory, or OpenWrt and DD-WRT, or DD-WRT and Linksys, etc.
Let’s take an example: Current partition has OpenWrt and Alternative partition has Linksys stock on it. If we sysupgrade from OpenWrt, it will write it to the Alternative partition, so it overwrites the stock Linksys with the sysupgrade OpenWrt and then tries to boot from it. This procedure obviously bricks the Alternative partition because we should flash an openwrt-factory file over the Linksys firmware, not an openwrt-sysupgrade. The sysupgrade is only good for upgrading from openwrt to openwrt. The same bricking scenario occurs when trying to sysupgrade a DD-WRT partition.
The solution to this whole ordeal is to have the same brand of firmware on both boot partitions so OpenWrt on both and then the fail-safe mechanism would work as intended.
The easiest way to do that is to use the mtd method to flash an openwrt-factory from OpenWrt SSH over the other partition running the Linksys stock firmware. So if Current partition is OpenWrt and Alternative is Linksys, then do a SSH under the current OpenWrt and flash an openwrt-factory file over the other partition that is still running Linksys stock. This is explained nicely in the original adding support commit on github for the devices in question, e.g. for MR5500 here: https://github.com/openwrt/openwrt/pull/17958 and for MR7350 here: https://github.com/openwrt/openwrt/pull/14807
So basically the following steps:
- copy the openwrt-factory file to the currently running openwrt /tmp directory
- SSH into openwrt and run
cd /tmp - from SSH find out the currently booted partition with
fw_printenv -n boot_part - if the result is 1, execute
mtd -r -e alt_kernel -n write openwrt-qualcommax-ipq60xx-linksys_mr7350-squashfs-factory.bin alt_kernel - if the result is 2, execute
mtd -r -e kernel -n write openwrt-qualcommax-ipq60xx-linksys_mr7350-squashfs-factory.bin kernel - in the above commands it’s important to use the openwrt factory.bin file, not the sysupgrade.bin file. Also note that
kernelstands, in fact, for partition 1 andalt_kernelstands for partition 2.
Hope this helps, if you have questions, feel free to ask!