Break boot is not any key. It ignores all alphanumerics until fully booted, from there accepts commands such as ls.
Ctrl+C enters U-Boot 1.1.3 (Dec 30 2014 - 10:10:36) SERCOMM # command-line prompt easy to enter main loop.
TFTP DL mode is not standard, tried 192.168.1.10 .2 .123 (printenv), stock filename, short names, client or server.
OP ondanet also was not able to TFTP without first using nrmpflash's magic packets that is a totally different mode.
For what it's worth, I still can't get it to do a TFTP transfer when booting no matter what I do, and I have tried numerous different ways with all sorts of timing. For me, the only exception, as you stated, was to use nmrpflash, then either letting nmrpflash TFTP the firmware file, or using the -c command to drop out and then use a TFTP utility. It'll successfully send the file, but as we all now know, the router then rejects it (at least with the current betas).
As for my experience, once connected to the serial header, I didn't have any luck with using the spacebar (or any other key), to interrupt the boot. I was able to press Ctrl-C early on and it (soon thereafter) gives me a prompt. I have no idea what to do at that point, but did type 'help' and saw a list of commands.
The timing you posted is interesting, does that mean that after 7 seconds, I would have 1 second to attempt a TFTP file transfer? If so, that's probably why I could never get the timing correct, it would have to be deadly accurate!
I discovered a download mode (TFTP recovery) if you hold reset during power on, which can be cancelled Ctrl+C.
Occurs after 7 sec prompt to enter u-boot 1 sec, listens for NMRP server 3 sec then checks the reset button state.
However, did not have luck with download mode. nmrpflash works first try, be patient after upload 4-5 min flash.
BTW to enter u-boot CLI press Ctrl+C just once far in advance it still works without waiting for 1 second prompt.
The entire point is so others do not waste their time (with TFTP) and to show how easy it is to enter u-boot CLI.
My posts are direct test results from experience with WNDR3700v5 there are no generalizations or assumptions.
Power ON 7 sec: 1 second to Ctrl+C enter u-boot CLI, but I found you can press Ctrl+C one time far in advance.
After 8 seconds is a 3 second time window to listen for an NMRP server (nmrpflash) then checks for reset button.
Power ON 7 sec: 1 second to Ctrl+C enter u-boot CLI, but I found you can press Ctrl+C one time far in advance.
After 8 seconds is a 3 second time window to listen for an NMRP server (nmrpflash) then checks for reset button.
So, are you saying the reason that I was unable to use a TFTP client (via Ethernet) when booting is because this v5 won't do it?
I get doing the Ctrl-C far in advance, I was able to do that too, but that also means that one would need a serial connection for access to the u-boot CLI. Is there a way for the rest of us (who typically don't have a serial connection) to use a TFTP client via an Ethernet port when booting like the other versions?
Also, if one does have the serial connection on place (as I now do), and presses Ctrl-C to get the # prompt, what command would one use to send a firmware file to the router (or start a TFTP server)?
At this point I do not know what the requirements of download mode are (manually invoked with sc_dl) and also
there is a TFTP recovery mode (manually invoked with sc_tftp_rec), so this just adds more confusion to mystery.
NMRP listen for server upgrade mode is manually invoked sc_nmrp but this is not necessary just power ON 8 sec.
Also, nrmpflash increased timeouts so no longer necessary to adjust. Just run it and power on approx same time.
Again, just use nmrpflash it works. 05-22-2023-r52651 is the same boot loop, so do not bother with this release.
Joined: 08 May 2018 Posts: 13463 Location: Texas, USA
Posted: Mon May 22, 2023 16:04 Post subject:
k3067e3 wrote:
Can I contribute anything or do we still have to wait for the Kernel panic to be fixed?
I linked the latest results for 05-22-2023-r52651 with log file attached (as I'm sure that @blkt has already emailed the developer as well (?)). Developer has at least two OEM firmware serial logs, but no fullflash dump. Don't know if that is going to be required or not. But, to answer your question, the kernel panic boot loop is the primary thing that needs to be addressed before we can proceed.
Another update: Don't bother with 05-23-2023-r52656, either. Same kernel panic boot loop. Flashed directly via nmrpflash since I didn't feel like flashing back to stock. Doubt that has any bearing on the results. Sending this to BrainSlayer...
Thanks for the update and for contacting BrainSlayer. Looks like you two experts have got a good handle on this v5 problem. Thus, I'm hanging out in the background and following along, but if I may be of assistance, please let me know.
Joined: 08 May 2018 Posts: 13463 Location: Texas, USA
Posted: Wed May 24, 2023 17:26 Post subject:
52671 is a no-go, too. Same kernel panic boot loop.
Maybe this is the problem?
Code:
[ 7.356389] 2 uimage-fw partitions found on MTD device linux
[ 7.367657] Creating 2 MTD partitions on "linux":
[ 7.377032] 0x000000000000-0x0000001f0000 : "kernel"
[ 7.388014] 0x0000001f0000-0x000000ee0000 : "rootfs"
[ 7.398950] mtd: device 5 (rootfs) set to be root filesystem
[ 7.410358] mtdsplit: squashfs has invalid size in "rootfs"
Opening log file may be tricky. Connections got a little screwy during test.
This information has been forwarded already.
EDIT 05/25/23: The next public beta should be good to go. I have *NOT* tested 52671M or 52672 alphas, I presume "someone else" did and did not comment on this thread.
BrainSlayer wrote:
next version will be smaller and will fit to the constraints
kernel-panic69 wrote:
Ok. There were only two things I could see that were an issue after slowing down and examining everything again a little more clearly. The size of squashfs in the rootfs partition and the 3700.bin vs. WNDR3700v5.bin in the files vs stock and OpenWRT. Hopefully, the latter is negligible.
BrainSlayer wrote:
i already fixed it. and the flash layout of openwrt might be different. cannot be compared
Joined: 06 Jun 2006 Posts: 7389 Location: Dresden, Germany
Posted: Fri May 26, 2023 13:51 Post subject:
blkt wrote:
05-26-2023-r52703 is same loop, ignore this release.
no its a different loop. different message. according to the flash log i see that the image is still to big for flashing from factory fw. dont know if its going better with nrpmflash. i will try to make it smaller _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Edit: Hope nobody else flashed test image, nmrpflash 2x no stock firmware recovery, stuck in TFTP recovery mode.
Edit 2: Okay! Recovered with an old Windows 7 machine tftp.exe (tftpd64 4.64 will not put, however, R7800 works).
That test image certainly overwrote something was not supposed to, but at least so far it seems I am back to stock.
