Hi there ... I think I made a serious mistake by flashing the wrong *.bin file in the process of flashing OpenWrt with OpenWrtInvasion into my router (Xiaomi 4A Gigabit Edition). Not exaclty sure what file I took, but now I have the following situation showing in Luci:
Well, I took the file that was on my Desktop because I (successfully) flashed another Xiaomi 4A Gigabit Edition some weeks ago but I renamed it openwrt.bin at that time so maybe there was my fault. From the filesize I recon it was not the squashfs file and then the trouble began. (trying to fix it the whole day)
The good thing is, whatever I tried for the last 12h it didn't get worse at least. OpenWrt starts every time but in recovery mode only. The device connects properly to the internet as soon as I connect the WAN cable. Sure it has forgotten all the settings I made after a boot.
I tried via WebUI-Flash-image and via sysupgrade when connected via ssh without any visible effect, so I am stuck on OpenWrt 22.03.2 (initramfs) I just have no idea what else I could try ...
An initramfs implies booting from RAM, that needs to be fed to the device in some way. It sounds like your device is just getting stuck in cold boot, which would suggest it's not finding the rootfs?
Can you pastebin dmesg output? If you can SSH in you can copy things over.
[ 4.307592] spi-mt7621 1e000b00.spi: sys_freq: 220000000
[ 4.314423] spi-nor spi0.0: unrecognized JEDEC id bytes: 1c 71 18 1c 71 18
[ 4.321311] spi-nor: probe of spi0.0 failed with error -2
You should thank yourself that you flashed the initramfs version of OpenWrt, so you can login after boot instead a bootloop!
By the way, you are hit by issue 9442:
Which was fixed on master then backported to 22.03 (released as 22.03.3) and to 21.02 but the latter isn't released yet, so you have to use 21.02-SNAPSHOT builds if you need to stick to that oldstable release!
boot an OpenWrt SNAPSHOT or 22.03.03 of initramfs.bin through TFTP
do a simple sysupgrade with the same version of OpenWrt but now with a sysupgrade.bin
changing bootloader to a third party bootloader (at least for temporary)
flashing the correct version of OpenWrt
(optional) rollback to current bootloader
(if you mess up something you only way is #2)
reprogramming your flash with an SPI programmer
Ok, there could be a third solution, but it depends on the bootloader your device has: If it does support your CF EON flash chip you could use it's recovery function:
OEM booloader (an U-Boot) supports TFTP recovery, but accepts only stock firmwares
I have no access to a stock firmware which contains an U-Boot which supports this new chip and it's TFTP recovery isn't bugged!
BREED bootloader (third party BL, use the breed-mt7621-pbr-m1.bin edition) has nice HTTP GUI for recovery
newer versions support your flash chip
updated U-Boot by @db260179 (you should self-build it for now), it also has a nice HTTP GUI for recovery
the support was committed to the repository but no new release was made
Oh no ... I was hoping not to climb down so deep into the rabbit hole, but what the heck, it's fun right? So I have a serial adapter at hand, but no spi programmer. (which I am willing to order if neccessary)
Even though the device is brand new and I could just send it back, but nope thats not me ... I won't give up that easy! Btw. thanks everbody for all your help, really apprecite it.
Given my USB zu TTL Seriell Adapter is there anything usefull I could try before ordering an spi programmer? How do I convince my device to boot the initramfs.bin you mentioned? Usefull tools (Linux/Windows doen't matter) for that task? Does the present bootloader give me an option to do that? Sorry for asking basic stuff, but I do consider myself in the group of beginners ...
Before attempting the flashing bootloader, connect the serial adaptor to your router board.
Get a serial program running like putty, then connect up, turn on router and if u can capture the putty output to a log file for us to see.
If you did the openwrt invasion part correctly, u should be able to hit enter to set u-boot commands, if not - 1. reflash the oem firmware back or 2. spi programmer read the flash chip (sometimes works, sometimes doesnt without removing the chip from the board)
My gitlab https://gitlab.com/db260179/openwrt-base/-/tree/openwrt-22.03-mt7621 has folder called docker, in there is a docker container that can boot images as its a TFTP,dhcp and dns all in one server. You will need to get your own oem firmware as your board has the new EON chips my example firmware has only support for the GIGA flash chips.
Did you do this part when doing the openwrtinvasion part?
nvram set uart_en=1
nvram set boot_wait=on
nvram set boot_delay=5
nvram commit
if not, you will need reflash to oem firmware and do the hack again, making sure you do the above part so you can enter the u-boot command line from the serial console aka putty
Press (and hold) 4 when / before the menu shows up:
Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.
If you are able to enter the U-Boot prompt, then help or ? to get help.
If you are unable to enter the U-Boot prompt, then you missed the serial access parameters setup, see below:
You could set those params from OpenWrt too with fw_setenv. Ahhh!!! fw_setenv won't work as the flash is unkown currently.
