I'll take it apart, do the eMMC glitch thing from your video, to see if I can get it to talk to me that way, but I suspect you're right, it's probably broken.
oh no, you are right! what was i thinking? this device requires stock openwrt to allow logins via serial, they could have closed that.
this router has dual firmware. in the uboot bootlog you can see which firmware is active and which kernel partition is being loaded. before you take it apart, try resetting the device right after linux starts many times in a row. it might be the case that you can force the active firmware slot to switch to the older version that way (do tell us), and the the older system might allow serial login. worth a try!
Major upgrade to the U-Boot configuration script
The old version kept track of boot attempts and triggered recovery after a number of consecutive interrupted boots were detected.
The new version instead uses the state of the RESET button to choose a boot path. It also supports A/B dual firmware sysupgrades.
Upgrade when possible, info here:
i'm curious about your case. what happened in the end? did you have time to look? please post when you do.
No, not yet.
It's on my to-do list.
sorry, late update.
I had two units I thought were bricked, turns out one of them was OK, I must have gotten the password wrong in some way.
I used your new script, worked just fine.
just two things, seems run boot_write_recovery_from_tftp can't be executed multiple times.
if I Ctrl-C the TFTP because whatever transfer issue, and run it again, the script runs, but won't do anything, need to reset 1st.
perhaps it should be mentioned somewhere ?
the ipaddr and serverip could be picked up from the u-boot env variables ?
then the user would be able to change them before executing run boot_write_recovery_from_tftp.
currently they're hardcoded -
fw_setenv boot_set_ip 'setenv ipaddr 192.168.1.1; setenv netmask 255.255.255.0; setenv serverip 192.168.1.2'
fw_setenv boot_write_recovery_from_tftp 'run boot_set_type_initramfs; run boot_set_ip;....
I'll get back to you about the 2nd device, the one I just flashed was the one I thought was boot looping at the "press space" count down 
regarding our previous discussion about the fan, I'm convinced it isn't used, at all.
if you check the arrows showing the direction of the air flow, you'll notice it's blowing towards the base of the device, which is completely pointless ...
i bought 2 more of these. i got scared about the new law that forbids foreign made routers in the US, and found them on the cheap, so i got them. i'll get them in a month or two from the states. hopefully i won't have issues with hackability.
tftp is very finicky on this router. i don't quite remember, i'd need to fire up ghidra and take a look, but i think tftp needs to be patched to work at all, and one of the patches does that. what you describe might happen in some fw versions and not other, and might be the result of incorrect/incomplete patching.
more of the same. yes, the script is not the way i wanted it to be. at first it did get the vars from the environment (contrary to how the original scripts did). turned out, and it made no sense to me, that unless i set the vars in the script itself, tftp doesn't work reliably. i remember this happening specifically when the device booted straight to tftp (ie, what the script does when the main and recovery partitions are wiped), but not necessarily when playing with uboot's command line.
well it's not that hardcoded. it is set in boot_set_ip precisely so that you can easily change it. you don't need to saveenv, just change it in ram and do what you need.
you can even set boot_set_ip to the empty string and set your variables manually before invoking tftp stuff. in fact, you can do this and saveenv, wipe both systems and test that indeed this does not work when rebooting. or at least that's what i remember.
before any tftp calls, and again after changing IPs, the network stack needs to be initialized. this is done manually with the go call that is part of the hack. this seems to be finicky as well.
in my tests, not setting the variables in code made tftp boot fail during straight-to-tftp boot, i don't know why. but it is of note that the original hacking script also set these vars in code, possibly because of the same issue.
if you test and prove me wrong (ie, straight-to-tftp boot works without setting the vars in code), i'll see if i can revisit. but please provide logs.
i'm thinking of your ctrl-c and retry issue. maybe it is caused by the additional go command? maybe go can be called only once?
or maybe go can be called only after really changing the settings and causes tftp failure if called unnecessarily? this would be really weird, but given that uboot calls it during normal boot before any scripts (you can see it the logs), the repeated call from the script would make tftp fail unless the values were actually changed... which would cause the need to set the vars from code. so straight-to-tftp boot could work without setting the vars in code only if you also remove the go call from the tftp boot path. who knows...
absolutely not, never. my reply here:
at any time the OEM could push an update that bricks the device if you roll back.
just post the bootloader partition(s) here for analysis when needed.
although i can't just step over the active bootloader, i could find which is active and upgrade the inactive slot to the active slot contents. this would solve one of the issues.
the problem is detecting which one of the partitions is the active one. one could try and guess that the highest versioned number is the active one, but this is not guaranteed. the device could have a broken newer copy from a failed upgrade, and stepping over the older one would brick the device. also, the device has different BL binaries with the same version number (yes, believe me) but different build dates, complicating matters.
i could do the upgrade only if the chosen or even both versions are known, but still this is a guess.
more likely, i could be able to infer which copy is running by the same method that the OEM software does when upgrading. this is possible though subject to change.
problem is, i don't have a router with OEM software to develop and test that.
no worries, I was flashing one, and couldn't understand why my ipaddr and serverip didn't have any effect.
I looked and your script after I had finished the flashing, next time I'll know what to do
I've finally set up the last of my units, the one failing to load u-boot, I'll try the glitch next.
Hit space key to stop autoboot: 0
## Starting application at 0x4A9647CC ...
data abort
pc : [<4a9647f4>] lr : [<4a964e80>]
reloc pc : [<4a9647f4>] lr : [<4a964e80>]
sp : 4a77f3c8 ip : 05926111 fp : 4a91153c
r10: 00000002 r9 : 4a77fea0 r8 : 4a77f86a
r7 : 4a98d190 r6 : 4a96dd4d r5 : 4a77f450 r4 : 0000041a
r3 : 00000073 r2 : 4a77f884 r1 : 0000041a r0 : 4a77f450
Flags: nzcv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
or... you could have read the docs 
what is this? did you do anything to this router or this is the way it arrived in your hands?
it looks like the system is corrupt... both copies? wouldn't ipqboot switch to the older one if the current one fails?
but "Hit space..." means uboot loaded. and since it is secure boot, uboot must be intact; which means that if you can glitch and interrupt it we should be able to recover the device.
if you ever interrupt boot do this:
- printenv and record the output.
- clear the
bootcmdvar andsaveenv.
dont forget saveenv! this will make future boots drop you to the uboot command line. try it: reboot and check that you no longer need to glitch. from there you can continue the standard boot (which fails) with a bootipq.
ask chatgpt if it can guide you to easily switch the active system image, then bootipq and follow the usual install.
if not...
install my tools https://github.com/Lanchon/ubtools and use them to dump a copy of both uboot partitions. you will have to read them from emmc to memory and use my tool to transfer them from ram to the PC. ask an LLM for help. next get the md5sums and see if they are known images (see the code inside my script). use strings -n10 on them to get the version numbers. post.
EDIT:
transfer them from router memory to the PC twice and check that the copies match MD5. if not, something is up with your serial port corrupting data.
when transferring in the other direction (PC to device) you don't need to check anything, as the device echoes every "keystroke" over serial and my tool verifies this and detects any errors.
if BLs are known...
use my toolls to upload a known good initramfs image (please not bleeding edge!) to ram.
now you can manually patch the BL and bootm. (see my script for exact commands.)
(or you can write it to the recovery partition. (see my usual install script docs for which reserved partition is used), and then patch the BL and bootm. an LLM is your friend again.)
with openwrt booted, install using my script and flash the recovery partition (docs on my script). next reboot should get you to recovery, and do a standard sysupgrade from there.
NOTE: transfers to/from my tool will take a very, very long time. be patient, and try not making mistakes so you save time
I came back home with several units, so I'm not 100% sure, but I believe I ran your script, and this was the result, post reboot.
it was an older version on your script though.
haven't gotten that far yet.
this was the kind of info I was looking for
I've pretty much set it up for glitching, but I need another pair of hands to actually do it.
I'll keep you posted.
if you already ran my script -no matter what version- there is no need to glitch. it will always give you the chance of interrupting with Ctrl-C