Glad to hear, thank you.
About flashing the second partition, if your [fw_printenv -n boot_part]=[2], shouldn’t it be:
fw_setenv boot_part 1
to set it boot to the newly flashed partition?
no issues factory –> openwrt
I have had issues with some snapshot builds upgrading
scp -O -rp fw.img root@192.168.1.1:/tmp/fw.img
sysupgrade -v /tmp/firmware_image.bin
or
mtd -r write /tmp/firmware_image.bin firmware
scp -O -rp fw.img root@192.168.1.1:/tmp/fw.img
fw_printenv boot_part
in case of 1:
mtd -e alt_kernel -n write /tmp/fw.img alt_kernel
fw_setenv boot_part 2 && reboot
else in case of 2:
mtd -e kernel -n write /tmp/fw.img kernel
fw_setenv boot_part 1 && reboot
I only modified the image filename
added how to use scp to upload the image from this post below
this is to flash back to factory
https://forum.openwrt.org/t/adding-support-for-linksys-mr5500/159826/48
yes, as long as you are flashing boot part one. “kernel”, where boot part 2 is “alt_kernel”. Remember i
These are snapshots, so things may break as expected. At this time there is no stable release for MR7350, or the MR5500.
OK, to conclude on this post. My educated guess (for now) is just to flash the primary partition until more development is done and wait for a more estable build.
Guys, I still don’t understand what the problem really is. I have an MR5500, flashed openwrt-factory from Linksys UI, I assume on 1st partition. Since then, I’m running OpenWrt without issues. So if I now upgrade from OpenWrt’s LuCI to a newer sysupgrade, will it brick or not?
Hello, that is what I am experiencing with the MR7350. If any testing is needed please let me know.
Going to setup the router in the AM and flash it with the latest SNAPSHOT, if more testing is needed - please let me know.
Just to clarify, my issue is from SNAPSHOT doing 30641 trying to flash the latest SNAPSHOT sysupgrade, via Luci, bricks the router.
I have experience bricking on both MR5500 and MR7350 with openwrt. for the time being I have backed off. Some builds I was able to flash, others brick and I have had to use serial to unbrick. If asked I will test a build. Until then I am just on stand by. I do have soldered connections on both routers hanging out of the casing… lol
1 Like
I am on the same boat as Peppermint but with the MR7350. Today installed the stock firmware, then flash the latest SNAPSHOT (r31419-297057f0f2) (from the firmware selector,) I was able to install the sysupgrade file from Luci for the first time, without bricking the router. That means progress is being made, I will keep testing it as an Access Point on a non production network. I figure to share the update here for others to see and to say Thank You to the developers for all the hard work.
@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!
1 Like
@KrypteX this is a great write up putting everything together. Thanks for doing the tests as I put these linksys routers down for a while. Once I used the image builder on my (at the time debian 12) system I flashed both sides. I read in the forums about advanced boot loader and baked in the Advanced reboot which is awesome! your combined instructions should help others. I have not tried to flash anything recently. for anyone curious here is a screenshot of the advanced reboot menu. This is now an older snapshot. Some reason why I still bricked the MR7350, so that is currently on DDWRT both partitions. My MR5500 is on openwrt.
1 Like
It might have been that you had OpenWrt on one partition and DD-WRT on the other one and sysupgraded OpenWrt over DD-WRT, which bricked it. If that was indeed the situation,the easiest way of flashing OpenWrt over DD-WRT would have been to use the mtd method from OpenWrt SSH to flash the openwrt-factory (NOT the sysupgrade) file as I described above.
I have the MR7350 back on DDWRT both partitions. My MR5500 is on openwrt snapshot. I have no idea anymore. It seems MR7350 development slowed down and more in favor of the MX4300/4300/8500
@pepermint I edited my comment above, sorry if there was any confusion. I rephrased it:
`…flashing OpenWrt over DD-WRT would have been to use the mtd method from OpenWrt SSH to flash the openwrt-factory (NOT the sysupgrade)`.
no big deal. If a wiki ever gets created I believe it should be default to flash both partitions. If the USB key ever works, storage could be expanded on that. i have not tested.
Well, my hope is that development continues, and we get something stable, pretty sad the development for this model has slow down, but I do see some advances as of today the latest SNAPSHOT (r31588-8103b79776) things are moving but, one can only wait.
What do you mean?
Maybe, I did not explain myself properly, what I mean to say is - It feels like the development for this model, has slow down. If that is not the case, my apologies.
I have the same feeling. the other models have more ram (mx models) in general. like the mx4300, and they are cheap on ebay. I dove to mediatek chipsets and very stable. I will keep an eye out. However I am not a developer.
1 Like