That early boot log with "BL2: Failed to load image id 3" sounds like major trouble. It is much too early in the boot process that anything from the full OpenWrt recovery etc. would be in play.
But as you have serial access, the situation is likely not hopeless.
The closest similar thing that I found, is the discussion from a few months ago, starting here:
(that discussion is about bad blocks affecting fip, but closely related to broken bl2 and/or fip images)
Compared to that discussion, your log ends before the "BL31 starts" line, which might mean that your boot process fails already before the full u-boot have even started...
(...so you might just have parts of the ARM trusted firmware loader to play with)
Yes, this looks like the fip image containing U-Boot and TF-A BL31 has been overwritten. That really shouldn't happen by chance as the fip MTD partition is read-only under Linux.
Hence it is crucial for us to know what you did exactly before that happened -- most likely you are dealing with a semi-broken flash chip, unless you deliberately removed the read-only attribute from the fip partition and wrote something there.
To rescue the device at this point you will need to setup JTAG with OpenOCD and load U-Boot to RAM using that. Then you need to re-write the bootchain, the easiest way is to re-run the installer loaded via TFTP.
So as you didn't remove the read-only attribute I understand you were flashing this file via TFTP using the U-Boot menu. Correct? If so, you should have also flashed the BL31+U-Boot (FIP) image at this point. Anyway. Both is very dangerous (hence the red background) and should never be needed once the device is running U-Boot 202x.xx.
This is a flash adapter, not JTAG. It will not help you in this situation, or at least it is very difficult as you would have to write the flash out-of-band area in such a way that it looks correct to MediaTek's hardware ECC/BCH engine. Better to write using JTAG, as then you are using that very same ECC/BCH engine for writing, so it will all be fine.
What was the motivation or reason for updating bl2 and U-Boot? I'm thinking that maybe it's needed to make a bigger warning message and also clarify that there is no advantage what-so-ever of updating the bootchain once it is working...
Now, to rescue the device with JTAG:
Maybe forum user @vasilii can give you a hand if needed, they went through the procedure most recently...
openocd -f tumpa-lite.cfg -f mt7622.cfg
Open On-Chip Debugger 0.12.0-rc3
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 500 kHz
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 500 kHz
Info : JTAG tap: mt7622.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)
Info : mt7622.cpu0: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for mt7622.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
^Cshutdown command invoked
I got jtag working and found this as well. Is this what I need to load uboot? I'm not sure what to use to move uboot.bin from my pc to the router. I'm still looking.
Chapter 5: OpenOCD Project Setup 18
proc ramboot { } {
# Reset, running the target’s "reset-init" scripts
# to initialize clocks and the DDR RAM controller.
# Leave the CPU halted.
reset init
# Load CONFIG_SKIP_LOWLEVEL_INIT version into DDR RAM.
load_image u-boot.bin 0x20000000
# Start running.
resume 0x20000000
}
proc newboot { } {
# Reset, leaving the CPU halted. The "reset-init" event
# proc gives faster access to the CPU and to NOR flash;
# "reset halt" would be slower.
reset init
# Write standard version of U-Boot into the first two
# sectors of NOR flash ... the standard version should
# do the same lowlevel init as "reset-init".
flash protect 0 0 1 off
flash erase_sector 0 0 1
flash write_bank 0 u-boot.bin 0x0
flash protect 0 0 1 on
# Reboot from scratch using that new boot loader.
reset run
}
git clone https://repo.or.cz/openocd.git
cd openocd
curl https://raw.githubusercontent.com/mtk-openwrt/openocd-scripts/main/patch/0001-armv8-do-not-read-ESR_EL3-in-AArch32-state.patch | git am
Make sure the pinout of the adapter is configured correctly to match your actual connection to nTRST and nSRST signals. In tumpa-lite.cfg you see the commands for assigning the pins, so make sure they are either really exactly the same or modify your configuration accordingly.
Edit: I've also been using FTDI chip, but using FT2232HL breakout board and some pull-up/pull-down resistors added.
Regarding 'halt' command failing, this is most likely due to nSRST not being setup properly, I've also struggled with this problem for a bit and realized I needed to properly setup the pins on my adapter for things to work.
Why are you entering all this stuff manually on the OpenOCD shell? I've just put it all into a .cfg fine loaded on start, then just issue
mt7622_reset
mt7622_ddrinit
mt7622_uboot
and you should find yourself in RAM-loaded U-Boot which allows you to write fixed bootloader to flash.
My reason for typing each command is due to crashing when I try to run:
./src/openocd -f tumpa-lite.cfg -f openocd.cfg
Open On-Chip Debugger 0.12.0+dev-00044-g4cb1fdb14 (2023-01-23-20:12)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 200 kHz
Info : linux os creation
Segmentation fault (core dumped)
What do you enable when you run make on openocd? This command fails and I think it's due to something I'm not running.
jtag_tdo_sample_edge falling
Also, I've been connecting to the JTAG pins on the Tumpa-Lite. Will this work or should I use GPIO?
