I can confirm this: Yellow port 4 does not work with the latest snapshot, however if you connect your laptop to port 1 and boot the router connecting to it at 192.168.1.1 should work, no need to unplug/plug the cable.
Sadly I'm getting 'no route to host'. Just to be sure, by port 1 you mean the one closest to the USB port?
Yes, port 1 is the one closest to the USB port. Ports 2 and 3 also work. Port 4 does not, it is somewhat special on the MT7620 chip and probably the settings are not correct. When it boots I see on the serial:
[ 1.237760] libphy: Fixed MDIO Bus: probed
[ 1.255601] gsw: setting port4 to ephy mode <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[ 1.279938] libphy: mdio: probed
[ 1.286418] mtk_soc_eth 10100000.ethernet: using fixed link parameters
[ 1.299548] mtk_soc_eth 10100000.ethernet: loaded mt7620 driver
[ 1.312004] mtk_soc_eth 10100000.ethernet eth0: mediatek frame engine at 0xb0100000, irq 5
[ 1.329036] rt2880_wdt 10000120.watchdog: Initialized
Can you check whether the ethernet comes up at all, i.e. what is the link status of the ethernet connection between the router and your laptop?
It's detecting the link and auto-negotiating to 1000/Full.
I'll install tcpdump on this laptop and see if there's ARP (or any other) traffic now.
What you can also try is to install the openwrt sysupgrade image via the OEM recovery procedure. I just tested that and it works. When you put the image in your tftp client, just select the openwrt sysupgrade file and it will work. However, you need to wait at least 10 minutes for the first boot, because I can see that OpenWRT needs to clean the jffs2 file-system which takes some time. On the console I see during this:
<3 minutes of the following messages>
[ 172.149411] jffs2: Further such events for this erase block will not be printed
[ 172.172352] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00271000: 0x73eb instead
[ 172.191282] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00271004: 0xa50f instead
[ 172.210464] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00271008: 0x5c71 instead
[ 172.229547] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0027100c: 0xe1c8 instead
[ 172.248629] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00271010: 0xcb83 instead
[ 172.267753] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00271014: 0x87a1 instead
[ 172.286883] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00271018: 0xb1c2 instead
[ 172.305976] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0027101c: 0x567d instead
[ 172.325057] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00271020: 0x97f2 instead
[ 172.344138] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00271024: 0x82d7 instead
[ 172.363059] jffs2: Further such events for this erase block will not be printed
[ 172.602335] jffs2: notice: (1226) jffs2_build_xattr_subsystem: complete building xattr subsystem, 13 of xdatum (2 unchecked, 11 orphan) and 20 of xref (11 dead, 0 orphan) found.
[ 172.916799] overlayfs: upper fs does not support tmpfile.
[ 176.556388] random: crng init done
BusyBox v1.31.1 () built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r13600-9a477b833a
-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:/# ifconfig
br-lan Link encap:Ethernet HWaddr 74:DA:38:A7:CF:93
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fdba:8501:55e5::1/60 Scope:Global
inet6 addr: fe80::76da:38ff:fea7:cf93/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:2306 (2.2 KiB)
eth0 Link encap:Ethernet HWaddr 74:DA:38:A7:CF:93
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:4908 (4.7 KiB)
Interrupt:5
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:96 errors:0 dropped:0 overruns:0 frame:0
TX packets:96 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6528 (6.3 KiB) TX bytes:6528 (6.3 KiB)
OK Yeh I'm still seeing no ethernet traffic at all, but thanks to you, we know it's not the image, it's something wrong with how I've flashed it.... I've previously only waited about 5 minutes since it seemed (based on the LEDs which seemed to be indicating a boot sequence) to be responsive so I'll try uploading by tftp and give it a little while before I touch it this time, and let you know. Wish me luck 
Best of luck 
The thing is that it takes at least 3 minutes after the reboot for OpenWRT to come up, because it cleans the jff2 partition the first time it boots.
No signs of life I'm afraid. Still no ethernet traffic at all. I can see arp requests leaving the laptop and no reply. I've tested the laptop into the main router to ensure the NIC is actually working and it's all good there.
I'm really curious what's different between our process. Clearly, I'm doing something wrong.
Just throwing ideas out there:
I did a factory reset through the OEM GUI, then loaded into the GUI directly (using the IP, not the DNS name to the wizard) and loaded it in... Is that correct? I've noticed that some settings (such as the admin account/password) are retained throughout thsi whole process so I wonder if perhaps the NIC status is, too - and since the NICs are not active when it's factory-reset, perhaps that's 'sticking' through the owrt install?
Another: When I use TFTP, Some instructions say to put the file in my laptop's /var/lib/tftp directory - but since that doesn't exist, I'm sending it from the user's home dir. I did set mode 666 and set the owner to tftp as per the instructions, but I thought perhaps the source path might be a factor.
One more: Some guides suggest using atftp rather than tftp, is that worth trying?
I cannot comment much on the procedure for going from the OEM firmware to OpenWRT. The only times I did this was originally from the original installation without any custom settings to OpenWRT using the web-interface. The second time just now. The problem is that you can only test this really once with a device, because OpenWRT might leave settings behind that are picked up the second time you try this after re-installing the OEM image in the mean time again. This might be the problem why we get different results, although what I see appears to be a pristine installation of OpenWRT with all the right default settings.
With regards to tftp everything you do is correct. The different instructions stem from the fact that some routers provide a tftp client for recovery, others like this edimax a tftp server. When it is a tftp server, then you need to connect with a tftp client, and there is no difference whether which one you use. The differences are more for the tftp servers. Also different directories should not make any differences.
I will redo the installation of openwrt via the recovery procedure using a tftp client and post what I see on the command line and with regards to the leds later.
One possibility is that the hardware is subtly different, sometimes this gets changed without notice.
What would help you at this point is a serial cable between your laptop and the router. You would need a USB-UART cable (5 $/€) and a pin-header to solder onto the board (some cents), plus a friendly neighbour with a soldering iron.
See if the initramfs-kernel image will boot and give access. That image runs from RAM, so it doesn't try to format a jffs on the flash chip(*). The intended process is to use it to install the sysupgrade image.
(*) a common reason for OpenWrt working in one case but not another one with the same version of hardware is that the manufacturer changed production to a different flash chip, one which is not yet supported.
1 Like
That is a very good idea. Try doing the recovery procedure with an initramfs. You can also open the device and check the flash chip, it should be:
Sorry for the delay, the forum said I was at my maximum replies for the day 
Hmm. Before trying OpenWRT on this device, I had hoped that I could get it to work with the OEM firmware, and had set it up fairly extensively (changed a lot of settings) so I wonder if perhaps the reverse is occurring - the changes I've made to the OEM firmware are interfering with OpenWRT.
Although, you're quite right, it's entirely common for OEMs to make minor alterations to the components over time, so I'd like to check that out. I have a nice old Weller and some spare header strips, but no UART - I do have a teensy 4.0 here though, which I'm fairly sure could do the UART work. Are the pins at 3v3? Or do I need 12v conversion or something?
I had the idea to use the initramfs image as a kind of bootstrap to load the sysupgrade, but I read that the initramfs images required a UART to use. Perhaps this is false, I'm sorry I'm not entirely clear on what to expect since that thing is not really documented - which is fine, it's for dev work, so it's 'if you have to ask, then it is not for you'... but here I am, asking, lol. Sorry. Dumb questions incoming:
What communication should I expect from the image? IP? The usual address 192.168.1.1, or maybe .1.6? Will there be a TFTP server running to upload the sysupgrade image? Any use of the USB port? Can I get a boot log from the image?
Edit after the forum let me post:
So I tried the initramfs image. The image sent during the OEM recovery just as the sysupgrade one did, however there was no indication of an automatic reboot as with the sysupgrade image. The TFTP server does disappear after this point, though - subsequent attempts to put the image timed out. I tried both 192.168.1.1 and .1.6, no joy. I power cycled the box and the LEDs indicated the boot sequence as if it were running the sysupgraded image, and tried both again, to no avail.
The initramfs image will behave just like a normal flashed OpenWRT image after initial boot, i.e. expect a connection at 192.168.1.1. It clould be that it does not work when run from the flash, I have never tried that. Normally they are run in combination with a serial console which allows to load them from the bootloader.
The teensy should work. The levels of the UART of the router are at 3.3V. Once you have the initramfs image running, you can ssh to the router, scp the image into a ramdisk at /tmp and use mtd to write the image to flash.
Well, long story short: You're right, the RAM has changed. Inside is a winbond w9751g6kb-25
What to do? Is there a chance it can be made to work without too much drama? Building from source I can maybe fit in my schedule, but writing a driver is a bit much right now. As far as I can tell, it's the same chip as in several other supported devices, so I have a glimmer of hope.
Slightly offtopic (maybe) I found a video to help with opening it without damaging the clamshell (I failed, lol) and it shows a different chip again. Apparently Edimax like to get around if you know what I'm sayin'
TL;DR sorry, it's a MX25L6406E
I've just realised - you asked about the flash, not the DRAM, which the above chip is. You said "flash", my brain went "memory" and I found the DRAM, haha derp, sorry!
I've been reading source code trying to figure out how the openwrt system does its magic and realised that the SoCs here have memory controller ICs that autodetect the DRAM and provide a layer of abstraction so that's why I couldn't find anything in the source about pinouts and timing and such So if I'm not looking for the DRAM and it's automagically supported via the SoC and the kernel, then I'm definitely looking at the wrong memory IC here.
Trick is, I can't seem to find the flash. As far as IC's on this board, there are the two mediatek IC's, plus one with a heatsink glued to it which I can only assume is the MT switch IC, that dram IC, three identical DC converters, and a bunch of 3-pin ICs that look like some kind of transistor....... and the moment I typed that, it hit me: Is it underneath the board?
Sure enough, there is ONE IC on the underside of the board, and it's the one I'm searching for. Image attached (pardon the odd angle, it was necessary to make the text readable and I didn't want to make lossy edits by rotating it)
So what's the next step? Is this a matter of running the stock image with the serial monitor, obtaining the correct partitioning of the flash, and then replicating that in the OpenWRT build?
Since this is not so much of a specific question regarding the EW-7478APC and is now more of a generic OpenWRT flash IC configuration question, I've decided to make a new thread over in the developers forum.
Thanks again to you @anon13997276 and @pwned and @mk24 , really appreciate your help!
I am not sure the different flash chip is the issue, here. According to
the 2 chips have the same ID and are mostly compatible. So there is a good chance OpenWRT does not even notice something changed. It would be great to see the output of the serial console.
The only thing I can really see that could be an issue (given that I've seen other devices using the same lower clock rate with the '06) is the difference in transfer commands, perhaps the '05 driver is making use of those commands not supported on the '06, but yeh, I'll get on the serial stuff ASAP.
Our city is back on covid lockdowns so it's going to be tricky to get components.... I may end up taping bare wires to the serial pads 
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.