No.
The first command that you just ran just serves to verify the partition structure.
You don't have "fip" there. (You have "ubootenv")
So, you are still with the old partition structure and this does not apply for you.
The same is actually seen from 23.05.3, as the new structure has only been implemented for main/master with ubi installer 1.1.0+
Thank you for clarifying this point. I am also unable to reboot my router normally since the 23.05.3 update and if for any reason - like power outage - it shutdown, I need to cool it down for 20~30 mins before be able to power it back on. So I start following in this post and purchased a USB-Serial cable but hesitated to open the router and was looking for easier solution like yours.
I am now more confused, what shall I do next?
Is the recommendation still stand to not re-flash the installer if you're already in OpenWRT and to wait for proper soultion?
Indeed, loose cables and my impatience are to blame. And I think I might have the root cause:
I am unable to successfully run owrt-ubi-installer due to that error message:
mac addresses not found anywhere in factory partition, aborting
Is there a way to fix it? I might have backup of original mtdblocks done from LuCI level.
Plus (not sure if that's the separate issue) boot process is hanging with the following:
F0: 102B 0000
F6: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0400 0041 [0000]
G0: 1190 0000
T0: 0000 02F1 [000F]
Jump to BL
NOTICE: BL2: v2.9.0(release):OpenWrt v2023.10.13~0ea67d76-1 (mt7622-snand-ubi-1ddr)
NOTICE: BL2: Built : 21:27:49, Apr 25 2024
NOTICE: WDT: [40000000] Software reset (reboot)
NOTICE: CPU: MT7622
NOTICE: SPI-NAND: FM35Q1GA (128MB)
NOTICE: UBI: scanning [0x80000 - 0x8000000] ...
NOTICE: UBI: scanning is finished
NOTICE: UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
NOTICE: UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
ERROR: UBI error: No volume named fip could be found
NOTICE: UBI: scanning [0x80000 - 0x8000000] ...
NOTICE: UBI: scanning is finished
NOTICE: UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
NOTICE: UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
ERROR: UBI error: No volume named fip could be found
ERROR: BL2: Failed to load image id 3 (-2)
Definitely good news, and hopefully good news. Having the serial console working makes things much easier. The missing MAC addresses warning is concerning, since it means the factory partition has most likely been at least partially overwritten. You'll definitely need that backup. However, with that factory partition backup, the mtk_uartboot tool and its files, a tftp server, and a few files from the OpenWRT firmware site, you should be able to recover the router completely.
The reason the boot process is hanging is because it's searching for the fip with BL31 U-Boot image in the UBI volume, but it can't find it. This usually means you've flashed something incompatible or something went extremely wrong in the process of flashing.
Experiencing a strange new issue with one of my RT3200's where it runs for a while then the power and networking light goes off as though it has no power. I have to switch the power off and back on again to get it working. Has happened numerous times over the past couple of days.
Any guesses at a cause or something I should do to try to fix it? Not sure if it is crashing and failing to reboot, maybe an OKD issue, but I am travelling and I don't have my serial cable on me.
My guess is either a bad power supply or that something is causing a kernel panic or is otherwise causing delays sufficient to prevent the router from updating a watchdog counter, and then this subsequently attempts a reset and fails.
One thing you can do is take a look to see if there is a ramoops log entry left behind. That might contain some hint as to what's going on. However, if it's not coming back up and therefore isn't able to permanently store the crash logs, you might not find anything without a console connected at the time it occurs.
Unfortunately, without seeing a crash log or error information (which would also be sent to the serial console), everything is going to be pure guesswork.
I will take a closer look when I get home. I really need to start taking my serial cable with me everywhere!
It could be power supply related as I appear to be having slightly better luck with the original power supply rather than using a 12V battery, but to be honest I have been powering this router with alternative 12V power sources for months without any trouble at all. It looks as though it now just falls over for no obvious reason. Perhaps a change to some configuration somewhere which has increased power consumption, but the battery should offer a lot more power than the power supply unit ever would and I really don't know what is happening.
Will be interesting to see what the error is on the serial cable, but having the power light go off and needing to disconnect the power for a period of time was also interesting. I will attempt to reproduce the scenario in a few days time and get back to you.
Also now seeing the situation somebody else previously reported where a "reboot" command doesn't result in a reboot even though I am using the original power supply. The lights just go off and it stops doing anything.
It definitely doesn't boot reliably at this stage, more details on this very fragile RT3200 will follow when I get my home to my serial cable on Tuesday.
I have four files: mtd0.bin up to mtd3.bin. How can I flash them from u-boot level assuming I am transferring them using loadx command? Would apprieciate help there.
If you're using loadx and you have the four mtd partitions from the stable OpenWRT, you first need to ensure that the .fip you use with mtk_uartboot is the version provided with the stable (23.05.x) version of OpenWRT.
Following the OKD recovery steps shown at https://openwrt.org/toh/linksys/e8450#recovery_from_openwrt_kiss_of_death_okd, use the instructions for 'did not run the v1.1.1 UBI installer' up until the point where you have access to the U-Boot console. Rather than rewriting the flash as listed in that document, you'll instead take the following steps one by one, stopping between each to ensure everything has happened as intended. If a step succeeds, the U-Boot console will show that it has erased the mtd partition and then written the data. If it does not, we will need to identify and correct the error before proceeding.
On the U-Boot console command line, enter the command:
loadx $loadaddr 115200 && mtd erase bl2 && mtd write spi-nand0 $loadaddr 0x0 0x80000
From your terminal application, you will now send mtd0.bin via xmodem.
--
On the U-Boot console command line, enter the command:
loadx $loadaddr 115200 && mtd erase fip && mtd write fip $loadaddr 0x0 $filesize
From your terminal application, you will now send mtd1.bin via xmodem.
--
On the U-Boot console command line, enter the command:
loadx $loadaddr 115200 && mtd erase factory && mtd write factory $loadaddr 0x0 $filesize
From your terminal application, you will now send mtd2.bin via xmodem.
--
On the U-Boot console command line, enter the command:
loadx $loadaddr 115200 && mtd erase ubi && mtd write ubi $loadaddr 0x0 $filesize
From your terminal application, you will now send mtd3.bin via xmodem.
If all four partitions have been written properly, you may now issue the reset command via the U-Boot console and the router will reboot into the firmware exactly as it was when you took the backups.
I followed the instructions on flashing the fip file from the command line after OpenWRT had booted, and all my problems with the RT3200 crashing and the lights going off appear to have vanished. Not entirely sure why the contents of the fip file would matter after the system appears to have booted normally, but happy the issue appears to have gone for me.
That was of great help. Thank you!
After reset it again came back to:
F0: 102B 0000
F1: 5000 1006
F3: 4000 0036
F5: 480A 0031
F5: 480A 0031
00: 1005 0000
F1: 5000 1006
F3: 4000 0036
F5: 480A 0031
F5: 480A 0031
01: 102A 0001
02: 1005 0000
BP: 0000 00C0 [0001]
T0: 0000 0351 [000F]
System halt!
Now I am trying to run OpenWrt UBI installer but:
preparing backup of relevant flash areas...
4+0 records in
4+0 records out
32+0 records in
32+0 records out
factory partition not found on raw flash offset
ip: SIOCGIFFLAGS: No such device
alternatively:
preparing backup of relevant flash areas...
4+0 records in
4+0 records out
10+0 records in
10+0 records out
8+0 records in
8+0 records out
16+0 records in
16+0 records out
mac addresses not found anywhere in factory partition, aborting
Any ideas?
I recovery my E8450 through the following steps.
Hoping This Helps.
# 0. prepared files: four backup MTD files, vendor firmware(FW_E8450_1.0.01.101415_prod.img), owrt installer
# 1. setup TFTP server
# 2. login the u-boot from serial
# 3. load the owrt installer use tftpboot, then I got a OpenWRT run on RAM
tftpboot openwrt-23.05.0-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery-installer.itb
# 4. copy the four backup MTD files to /tmp, then write to NAND
mtd write /tmp/mtd0 /dev/mtd0
mtd write /tmp/mtd1 /dev/mtd1
mtd write /tmp/mtd2 /dev/mtd2
mtd write /tmp/mtd3 /dev/mtd3
mtd -p 0x200000 write /tmp/FW_E8450_1.0.01.101415_prod.img /dev/mtd3
Those errors say that the writes didn't happen successfully. The System Halt at first says that it couldn't find the preloader. The error on the installer says that it couldn't find the factory partition. In other words, it went very wrong but you didn't spot and report any errors.
Let's try this once more, but this time without the variables that might have been corrupted and with using clean files where possible.
From the OpenWRT firmware selector, we need all four of the following files for the Linksys E8450 UBI version 23.05.3:
From your backups, we need the file:
Follow the initial steps as before, starting with mtk_uartboot to get into the U-Boot console. From there:
loadx 0x48000000 115200 && mtd erase bl2 && mtd write spi-nand0 0x48000000 0x0 0x20000 && mtd write spi-nand0 0x48000000 0x20000 0x20000 && mtd write spi-nand0 0x48000000 0x40000 0x20000 && mtd write spi-nand0 0x48000000 0x60000 0x20000
At this time, you will send the file you downloaded as the 'PRELOADER.BIN' file using the xmodem protocol. If you didn't change the filename, it should be called openwrt-23.05.3-mediatek-mt7622-linksys_e8450-ubi-preloader.bin.
When the upload completes and you return to the terminal, you should see that it has written the file to a total of four places. An example of what you should see is below.
Erasing 0x00000000 ... 0x0007ffff (4 eraseblock(s))
Writing 131072 byte(s) (64 page(s)) at offset 0x00000000
Writing 131072 byte(s) (64 page(s)) at offset 0x00020000
Writing 131072 byte(s) (64 page(s)) at offset 0x00040000
Writing 131072 byte(s) (64 page(s)) at offset 0x00060000
If you do not see confirmation, then something has probably gone wrong and it needs to be addressed.
--
With the preloader written, we can continue on with the fip. Issue the below command:
loadx $loadaddr 115200 && mtd erase fip && mtd write fip $loadaddr
Now, you will upload the 'BL31-UBOOT.FIP' file via xmodem. If you haven't changed the filename, it should be openwrt-23.05.3-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip
When the upload completes and you return to the terminal, you should see confirmation of the erasure and writing. The below is an example:
Erasing 0x00000000 ... 0x0013ffff (10 eraseblock(s))
Writing 1310720 byte(s) (640 page(s)) at offset 0x00000000
If you do not see this confirmation, then something has gone wrong and we need to see the error to identify the issue.
--
If the two above sets of commands succeeded, now we will write the factory partition. Here is where we need your backed up mtd2.bin file.
loadx $loadaddr 115200 && mtd erase factory && mtd write factory $loadaddr
Now, upload your backed up mtd2.bin file via xmodem. When it completes, you should again see similar confirmation lines indicating that it has erased a section of flash and then written the content.
--
For this next step, we will install the new OpenWRT recovery environment.
setenv replacevol 1; loadx $loadaddr 115200 && iminfo $loadaddr && ubi part ubi && run ubi_write_recovery; setenv replacevol;
Now, upload the 'KERNEL' file via xmodem. If you didn't change the filename, it should be openwrt-23.05.3-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb
Upon success, the router will boot into the newly installed recovery environment when reset. From there, all you need to do is install the sysupgrade file via your preferred method (luci, command line, etc.).
Another of mine just died. I had successfully flashed the v1.1 installer (and an imagebuilder snapshot build from the same time) back in February, and rebooted about 5 times since then (usually due to a power outage or similar). This morning, after a power failure, it failed to boot.
I have ordered the wires needed for the UART connection (my existing connectors were too large), and will attempt to recover that one tomorrow (I'll do the second one -- which bricked while flashing the v1.1 installer as mentioned earlier -- later, as I don't currently have physical access to it).
I'm wondering if I should maybe restore it to the pre-v1.1 layout given that the routers had been running and rebooting without issue for over a year before the v1.1 installer, and two have presumably OKD'd within a few months after.
Turns out the female connector on the wires I got was still too large. I ended up just taking the female end out of some breadboard wires and pressing it tighter with pliers, then wrapping it with tape. I used a RPi Pico with https://github.com/Noltari/pico-uart-bridge as the serial adapter.
So I disassembled it (the second one which died two days ago after running fine for a while with v1.1.0 and a snapshot build from Feb), and connected over serial, getting:
F0: 102B 0000
F6: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0400 0041 [0000]
G0: 1190 0000
T0: 0000 02F0 [000F]
Jump to BL
NOTICE: BL2: v2.9.0(release):OpenWrt v2023-10-13-0ea67d76-1 (mt7622-snand-ubi-1ddr)
NOTICE: BL2: Built : 11:23:19, Feb 18 2024
NOTICE: WDT: Cold boot
NOTICE: CPU: MT7622
NOTICE: WDT: disabled
NOTICE: SPI-NAND: FM35Q1GA (128MB)
NOTICE: UBI: scanning [0x80000 - 0x8000000] ...
ERROR: UBI error: bad CRC at record 11: NOTICE: UBI: Bad VID magic in block 738 00000000
NOTICE: UBI: Bad VID magic in block 909 00000000
NOTICE: UBI: Bad VID magic in block 917 00000000
NOTICE: UBI: scanning is finished
NOTICE: UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
NOTICE: UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
ERROR: BL2: Failed to load image id 3 (-2)
Note that when I tried mtk_uartboot, I still had issues until I tightened the connector even more (it basically had to wrap perfectly around the entire length of the pin -- I went through a LOT of wires).
I used mtk_uartboot --aarch64 --serial /dev/ttyACM0 --payload bl2-for-mtk_uartboot.bin --fip openwrt-4272ed0c5552-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip && screen /dev/ttyACM0 115200.
I ran ubi remove rootfs_data ; ubi read $loadaddr fip && ubi write $loadaddr fip $filesize in the u-boot console, then rebooted, and it booted successfully.
Hopefully OKD doesn't happen again, but if it does, I'll probably try reverting to the pre-v1.1 layout and seeing if it still happens.
Last set of commands (starting with setenv) didn't work. Anyway I've restored mtd2 and flashed other files from recovery image. For the kernel I've just did sysupgrade.
While I am able to boot the device it is still not passing through UBI upgrade:
OpenWrt UBI installer
preparing backup of relevant flash areas...
4+0 records in
4+0 records out
32+0 records in
32+0 records out
factory partition not found on raw flash offset
OpenWrt UBI installer
preparing backup of relevant flash areas...
mkdir: can't create directory '/tmp/backup': File exists
4+0 records in
4+0 records out
10+0 records in
10+0 records out
8+0 records in
8+0 records out
16+0 records in
16+0 records out
mac addresses not found anywhere in factory partition, aborting
I guess that might mean mtd2 backup broken as well? Is it possible to use somebodys else mtd2?
Yes, this suggests that your mtd2 is most likely corrupt. It's certainly possible to use one from a donor device, but there will be complications. First of all, the data needs to be updated so it contains the correct MAC addresses for your router. The offsets for those addresses are present in this topic, and this can be done with any hex editor. However, the calibration data is something that cannot at this point be recovered by any means of which I am aware. Running with another router's calibration data can result in abnormal behavior. Although this could very well be so minor as to be unnoticeable, it's also possible that it could severely degrade performance or cause unexpected and unpredictable issues.
Today the WiFi on my RT3200 running OpenWrt 23.05.3 crashed, it had around 2 weeks uptime and it’s behind an UPS.
5GHz was gone and I was unable to connect over 2.4GHz, the leds were all ON so I had to do a manual power cycle to get it back online.
It had HW offloading and WED enabled, disabled them and stay with SW offloading only as a 500mbps line over WiFi consumes a lot of CPU.
I rebooted it again so I’m unable to grab any log from the crash 