Hi. I have a TL-WR740N v5(China) which comes with 2MB Flash(MX25L1606E) and 32MB RAM(Zentel A3S28D40FTP). I received it in a condition that I couldn't access the web interface. I got access to the router through serial port but the router would not stop autoboot. It said to press Ctrl-C. I tried it many times and it didn't work.
I de-soldered the flash chip from the router. Copied the contents to a bin file for backup using CH341a programmer. Bought a new 16MB Flash(W25Q128FV) and copied the breed bootloader to it with Neo. I also changed the RAM to 64MB(Hynix HY5DU121622DTP).
I turned on the router and all the lights turn on. No blinking at all. Pressing reset or turning on while holding reset doesn't change anything. No ethernet access and no wifi. I have checked my soldering if there was any mistake in pin layout etc but nothing there. I didn't try serial yet.
I have a feeling that I didn't write the bootloader properly. I am using a windows machine. I just grabbed the 'breed-ar9331.bin' and flashed it with Neo software with CH341a. I believe it flashed it to the first 128KB as the bootloader file itself is 92KB.
So what did I do wrong. Any suggestions will be really appreciated . Should I try Das-uboot instead? Is there a better way to flash this bootloader. Thanks
There is no way to answer this, it could be anything - from hardware failure (especially on the RAM side), to bootloader issues (and it doesn't help that your hardware is no longer 'normal'), to compatibility issues with the flash chip or RAM module.
You'll at least have to reach a state of getting 'some kind' of (serial-) log messages.
It would have been much better to work in stages
stock device, just flashed with your new bootloader to confirm that the (new) bootloader itself works
replace the flash chip alone (as this is the easiest hardware modification), check that you get bootloader and OpenWrt working
finally replace the RAM, as this is the hardest thing to solder (but doesn't need any changes to bootloader/ OpenWrt to 'work', not give you access to the newly expanded RAM, but at least boot, limited to 32 MB).
Especially with 16 MB chips (and larger), you are prone to compatibility issues (3-byte mode vs 4-byte mode).
At this point, the only way forward is to do hands-on debugging, lots of it.
Start trying to revert to a 'known good' position, by writing back the original OEM image (it won't really succeed, but you should at least get some kind of serial output) to the new flash.
Expect failure, both with selecting the 'wrong' chips as replacements, damaged (or fake-) chips, (fatal-) problems with the soldering, fringe issues (in the sense of aged capacitors no longer coping with the larger RAM, the new flash running too fast for the PCB to get a clean signal, etc.), up to software issues of all kinds.
If you aren't very fluent with the scope and have gained extensive experience with tasks like these, come up with an exit strategy, a point beyond which sticking to this device is no longer feasible…
Flashed the original chip with the breed bootloader it didn't work. Flashed the original chip with complete backup dump, it didn't work. De-soldered the RAM and soldered back the original RAM didn't work either!!
So What is going on. I am back to original configuration which at least had a serial output and now I don't have that either. All the lights turn on when powered on and then all go out. No output whatsoever.
At this stage I believe the problem is more related to the CPU itself than RAM or ROM.
Either I used the hot air gun for too long and damaged something or there was some hardware issue already there when I got the router.
Before hanging up my gloves I wanted to bring some certainties to my efforts. I have two more exact same routers with 8MB Flash and 64MB RAM modifications. They are working fine. So I soldered my 16MB Flash with just the breed bootloader to one of those routers and I get web interface. So my Flash is good. RAM is also the exact same model as I had tried on the failed router.
Do you know any other failure modes besides CPU which might cause this problem? I do have an oscilloscope at hand.
A lot of of problems. Lifted pads. Missing resistors. And the revelation that the Zentel A3S28D40FTP is not 32MB but 16MB.
After a lot of hard work, botched wires and jumper cables, I have a running WR740N with 16MB flash and 64MB RAM. Having an identical router at hand was the key to pinpoint misplaced or missing components.
In the u-boot based OEM bootloader, ubootenv (second 64 KB of mtd0) contains the (wired-) base MAC address (you will have to set that in breed differently and hope that OpenWrt can find it) - and ART as you mentioned (I would still backup the old flash backup for a couple of weeks).
The Wifi mac address shown in Lede is the same as the one I put in. I think this option in breed bootloader is for ones who can't get an ART file.
In the Network interface for lan in Lede, the mac address given has just a different last number than the one I put in. Is this suppose to be this way?
Another issue I am facing is that I cannot get access to the Lede web interface from Lan1. Lan2, Lan3 and Lan4 have no problem. I can access the bootloader interface from Lan1 just fine.
When Lan1 is connected, it uses eth1. When other Lan ports are used, it uses eth0. If I connect to the WAN port, it still uses eth0. Basically, what has happened is that Lan2, Lan3, Lan4 and WAN ports are being used as LAN and Lan1 is being used as WAN.
This is from system log when connected with Lan1 and then with Lan2:
Mon Jun 26 22:07:55 2023 daemon.notice netifd: Network device 'eth1' link is up
Mon Jun 26 22:07:55 2023 daemon.notice netifd: Interface 'wan' has link connectivity
Mon Jun 26 22:07:55 2023 daemon.notice netifd: Interface 'wan' is setting up now
Mon Jun 26 22:07:55 2023 daemon.notice netifd: Interface 'wan6' has link connectivity
Mon Jun 26 22:07:55 2023 daemon.notice netifd: Interface 'wan6' is setting up now
Mon Jun 26 22:07:55 2023 daemon.notice netifd: wan (6766): udhcpc: started, v1.25.1
Mon Jun 26 22:07:55 2023 daemon.notice netifd: wan (6766): udhcpc: sending discover
Mon Jun 26 22:07:58 2023 daemon.notice netifd: wan (6766): udhcpc: sending discover
Mon Jun 26 22:08:01 2023 daemon.notice netifd: wan (6766): udhcpc: sending discover
Mon Jun 26 22:08:49 2023 daemon.notice netifd: Network device 'eth1' link is down
Mon Jun 26 22:08:49 2023 daemon.notice netifd: Interface 'wan' has link connectivity loss
Mon Jun 26 22:08:49 2023 daemon.notice netifd: Interface 'wan6' has link connectivity loss
Mon Jun 26 22:08:49 2023 daemon.notice netifd: wan (6766): udhcpc: received SIGTERM
Mon Jun 26 22:08:51 2023 daemon.notice netifd: Network device 'eth0' link is up
Mon Jun 26 22:08:51 2023 daemon.info dnsmasq-dhcp[1341]: DHCPDISCOVER(br-lan) 18:60:24:42:4d:6e
Mon Jun 26 22:08:51 2023 daemon.info dnsmasq-dhcp[1341]: DHCPOFFER(br-lan) 192.168.1.151 18:60:24:42:4d:6e
Mon Jun 26 22:08:51 2023 daemon.info dnsmasq-dhcp[1341]: DHCPREQUEST(br-lan) 192.168.1.151 18:60:24:42:4d:6e
Mon Jun 26 22:08:51 2023 daemon.info dnsmasq-dhcp[1341]: DHCPACK(br-lan) 192.168.1.151 18:60:24:42:4d:6e DESKTOP-P5U1Q18
Mon Jun 26 22:08:51 2023 daemon.notice odhcpd[753]: Got DHCPv6 request
Mon Jun 26 22:08:51 2023 daemon.warn odhcpd[753]: DHCPV6 SOLICIT IA_NA from 000100012441c58c186024424d6e on br-lan: ok fd23:458c:4258::714/128
Mon Jun 26 22:08:51 2023 daemon.info dnsmasq[1341]: read /etc/hosts - 4 addresses
Mon Jun 26 22:08:51 2023 daemon.info dnsmasq[1341]: read /tmp/hosts/odhcpd - 0 addresses
Mon Jun 26 22:08:51 2023 daemon.info dnsmasq[1341]: read /tmp/hosts/dhcp.cfg02411c - 2 addresses
Mon Jun 26 22:08:51 2023 daemon.info dnsmasq-dhcp[1341]: read /etc/ethers - 0 addresses
Mon Jun 26 22:08:51 2023 daemon.notice odhcpd[753]: Got DHCPv6 request
Mon Jun 26 22:08:51 2023 daemon.warn odhcpd[753]: DHCPV6 SOLICIT IA_NA from 000100012441c58c186024424d6e on br-lan: ok fd23:458c:4258::714/128
Mon Jun 26 22:08:51 2023 daemon.info odhcpd[753]: Using a RA lifetime of 0 seconds on br-lan
Mon Jun 26 22:08:52 2023 daemon.notice odhcpd[753]: Got DHCPv6 request
Mon Jun 26 22:08:52 2023 daemon.warn odhcpd[753]: DHCPV6 REQUEST IA_NA from 000100012441c58c186024424d6e on br-lan: ok fd23:458c:4258::714/128
Mon Jun 26 22:08:52 2023 daemon.info dnsmasq[1341]: read /etc/hosts - 4 addresses
Mon Jun 26 22:08:52 2023 daemon.info dnsmasq[1341]: read /tmp/hosts/odhcpd - 1 addresses
Mon Jun 26 22:08:52 2023 daemon.info dnsmasq[1341]: read /tmp/hosts/dhcp.cfg02411c - 2 addresses
Mon Jun 26 22:08:52 2023 daemon.info dnsmasq-dhcp[1341]: read /etc/ethers - 0 addresses
Mon Jun 26 22:08:55 2023 daemon.info odhcpd[753]: Using a RA lifetime of 0 seconds on br-lan
Mon Jun 26 22:08:59 2023 daemon.info odhcpd[753]: Using a RA lifetime of 0 seconds on br-lan
Mon Jun 26 22:09:13 2023 daemon.err uhttpd[996]: dmesg: klogctl: Function not implemented
Mon Jun 26 22:10:09 2023 daemon.notice netifd: Network device 'eth0' link is down
There's a register in the chip to configure whether the first or the last physical port will be the direct eth1 bypassing the switch. I think this is expected to be set by the bootloader and OpenWrt does not change it. Right now you are running lan1 as eth1 and the blue WAN port will be switched to the LAN.
Nearly all TP-Link stores the factory Ethernet MAC, factory wifi password, and WPS PIN in unused space near the end of the bootloader partition, after the bootloader code. OpenWrt does not use the last two. This is different from the wifi MAC which is stored in the ART partition.
If you look at the picture of WR740N v4.23 and v5.1, on the openwrt main router page, they have the blue WAN port to the left. If you look at the picture I gave above, the blue WAN port is on the right. I think bootloaders are made for the traditional configuration and that is why my Chinese domestic market router has LAN ports in opposite.
WR740n v3 has the same port configuration as my router but the CPU is AR7240 instead of AR9331. I don't think I can use v3 bootloader.
Is there anyway to extract that Ethernet MAC address? Also, is there anyway to change the order of Lan ports by modifying something in the bootloader? If I was using this myself then I would leave it at what I have got but if I give it to some friend then I have to make sure WAN port is working as expected.
Look from offset 0x01f000 up to 0x01ffff in your dump of the original chip. The numbers should match the sticker on the bottom but I think they are in binary.
Look from offset 0x01f000 up to 0x01ffff in your dump of the original chip. The numbers should match the sticker on the bottom but I think they are in binary.
I cannot make sense of the numbers in that hex file. If you can look it up for me than I can pm you the file. Ethernet is working so I am not that worried about the MAC address.
Just trying to find a way to reassign LAN and WAN ports in the bootloader.
