You don't need the script.
That is run at the sysupgrade.
The error is the extraneous variables.
You can just run those two fw_setenv commands from SSH console.
both commands executed but again no access. The boot part 2 error is still there.
I also tried to run the script via ssh, but I have no idea if I did it correctly. After the reboot it started again from the error partition and nothing worked.
Would it help if I order a USB to TTL cable?
Are all three lines still there?
boot-part=1
boot_part=1
boot_▒part=2
Did you get rid at least of boot-part=1 ????
If that got removed, but not boot_▒part,
you might try quotes that, as "boot_▒part"
You should see that by looking if the variable values shown by fw_printenv changed.
But again: you do not need that script. It is run automatically at the sysupgrade to toggle the booting. It does not fix anything for you. Running it manually once toggles the boot_part value, and then running a sysupgrade toggles it again back to the original value.
Hello, I admit the translation into my language is sometimes really damn difficult to understand. I have to translate every text here.
The funny sign is still there "▒".
I suspect that I don't know exactly what I have to do due to ignorance (I don't know openwrt).
would that bring something out of the video??? Then I order a cable and it's good.
A serial connection would be very helpful to watch the early messages and determine exactly why it is not booting. Also it gives you options to set environment and manipulate flash directly.
You can find the hex code of that unprintable character with something like:
fw_printenv | grep boot_ | hexdump -C
then craft a file to set that parameter to null and send it into fw_setenv.
1 Like
Unfortunately, I can’t really create or do something because I can’t. I’m afraid I don’t know enough about it.
If using the above command does not remove / change the env variables of concern I think you will need a ttl serial to try and achieve that at the uboot prompt.
1 Like
Hello, I received the cable today (the driver is also installed correctly) and tried to access it according to the video instructions, unfortunately without success.
If I have set the correct COM port in Putty and also the speed and then press open, only a black screen appears after switching on the router.
Does anyone have any ideas what I can do?
One could first verify correct operation of such adapter e.g. using an RPi or any other board.
Unfortunately I don't have either.
Shorting TX / RX as a start.
2 Likes
isn't there a short circuit??? I found 2 videos where nobody does that. But let me teach you that it must be different
Maybe a picture of your adapter and how you connected it?
The router has metric pins (2 mm header) and the cable you're using is for the larger 0.1 / 0.025 inch dimensional pins. It may not make good contact because the pin size is smaller. Find a 2mm plug on something such as a (very) old CD-ROM drive audio cable and make up an adapter.
This is a loopback test, to confirm that your adapter can send and receive data. Disconnect the adapter Rx and Tx wires from the router and connect them to each other instead. Then when you type in the terminal window it goes out the Tx wire, back into the Rx wire and should appear on the screen. If you open the connection, what you type should not appear.
Okay I did a short circuit but nothing happened.
I have network adapters on 192.168.1.5 and 255.255.255.0 and network cable directly on port 1
First I start tftpd and go to 192.168.1.5 and the corresponding diretory.
Then I start Putty and go to Serial and set it to Com4 as it says in the device manager. Speed to 115200 and then to open.
Windows 7 and windows 10 have been tested
Am I still doing something wrong?
You're probably using the wrong COM port number. Or you have one of the old or counterfeit PL2303 chips which Prolific has locked out of working with their Windows driver (they work fine on Linux). In that case I think the adapter does not set up a COM port at all.
The serial loopback test has to work before you even consider Ethernet and IP addresses, which is a completely separate situation.
Okay, while I would never ever use anything other than a properly trusted FTDI it should maybe work.
However, looking at your picture don't you have RX/TX swapped? Did you try swapping them green and white cables?
Good luck!
I have now also tried one of the driver fixes from this post but unfortunately without success. Is there anything else I could test?