I was getting garbled output on my stock firmware. I tried everything: changing baud rates, resoldering, tried programs like screen, minicom, tried enabling utf-8, but nothing worked - I was still getting garbled output.
Friend suggested me that i should flash openwrt, and then try UART on openwrt because it sets standard 115200 baud rate. So I flashed openwrt factory and sysupgrade. Now, for the first 10 seconds of booting I get garbled output and after that it gets completely normal. Following screenshot shows my problem.
If you want to access uboot, it appears the connection settings are not what the uboot is expecting. If you have uboot tools installed you can use fw_printenv to see what the uboot console settings are
I tried all possible values for fw_env.config and it still does not work. If you have any suggestions that I could try I would be grateful. Thanks in advance.
Thanks, in Minicom you can set the parity bits and flow control. Try changing settings and seeing if uboot responds better. No flow control may work better.
I tried setting 115200 7E1 as serial parameters and it worked. The only problem is that in 7E1 my input does not work correctly but i can switch to 8N1 and it will work. Thank you for help.
I successfully entered some kind of shell when i quickly entered "tpl" while still in uboot. Unfortunately it seems like this shell only gets my input correctly if I am in 8N1 mode but it only displays information in 7E1/7N1 mode. Things like CTRL+L work for screen clearing, and I can see that it outputs more garbage if I type commands like printenv. I tried almost all modes but can not find one where I can both receive and send data correctly.
Is there a way to send data in 8N1 and receive it in 7N1?
It seems like my assumptions were correct. I was indeed receiving data in 7E1 and my input was accepted in 8N1. I set up 2 UARTs: one with TX wire and other with RX wire, and now I can access uboot shell. Thanks to everyone who joined to help me.
I am trying to de-brick a 740N v4.21. I soldered on the wires (and checked the connection with a multimeter from the other side of the PCB) including the extra wire from the header to the CPU (I can't double-check this one but it seems fine optically).
With 115200 8N1 I see things like this:
But the real problem is that I can break the bootloop by sending the tpl command (I tried sending it right after applying power and during the bootloop), neither in 8N1, nor in 7E1 mode.
I tried powering it on with the Reset button pressed. If I release Reset shortly after applying power then I get the same bootlop I get without touching the Reset button. If I hold Reset for until the LEDs stop flashing there is zero text in the terminal (garbage or otherwise) and it does not respond to commands (no echo, no response, nothing).
I think I just "soft-bricked" it because the bootloop started after I flashed my custom OpenWRT build (the build config resulted in a working 23.05.0-rc3 build but not after I compiled the 23.05.2 sources).