You can use this patch in 19.07.8:
This patch is for master, but can be applied to the 19 branch....
Basically, the problem is with the Realtek Giga Switch driver that is not supported by Openwrt yet. We are working with Openwrt to include support for this chip.
Not really "working" but actually "waiting" for someone to review/reject/accept the PR
Hi guys, some information about firmware 21.02 for archer c5v4?? Thank’s.
We are still waiting for the someone to review/reject/accept the PR.
The Realtek Chip for the gigabit switch driver is not supported by Openwrt yet , all of us are waiting on it too.
If you want to install it now , the 2.4ghz radio wont work and only 5ghz is usable.
I'm a newbie here using Archer C5 v4 provided by Act Fibernet.. can you pls share the full guide?
update: successfully updated openwrt using TFTP recovery mode.
@gaspare I tried compiling the firmware using this patch; but the firmware doesn't seems to work.
can you help me if i am missing something.
Steps followed:
installed dependencies from here
git clone https://git.openwrt.org/openwrt/openwrt.git/
cd openwrt
./scripts/feeds update -a
./scripts/feeds install -a
downloaded this patch then
git apply 4327.patch
make defconfig
make menuconfig
set Target System: MediaTek Ralink MIPS
set Subtarget: MT7620..
set Target Profile: TP-Link Archer C5 v4
saved as archerc5v4.config
then
make -j4 V=s
This patch worked for building a current firmware, based on v21.02.1, really awesome.
can you share the binary files to update?
The files and instructions you provided work just fine, the only adjustment required is that the patch complains about the permission of two files not being 644.
I fixed this by issuing something like this before applying the patch:
chmod 644 target/linux/ramips/mt7620/base-files/etc/board.d/01_leds
chmod 644 target/linux/ramips/mt7620/base-files/etc/board.d/02_network
When doing git apply 4327.patch is is silent and returns nothing.
So I do not have the permission errors?
Update 2:
Basically, the current config from 19.07 do not work fully.
For the first boot up, there is switch0, with no ports active. Switch 1, which is the active switch.
After install of luci, any change of Interface config will result in failed when apply. Need to manually remove switch0 entries in /etc/config/network, reboot, then edits in luci will work.
Update: I proceeded to force upgrade. And it works so far.
I can generate the rom file after cp archerc5v4.config .config .
When flash the file with sysupgrade, I got:
Should I force upgrade?
Glad that worked for you. I don't know it didn't work how many times I tried building / flashing; not sure it is because the router is provided by my ISP (Act Fibernet from India).
After flashing the firmware using tftp the router reboots and doesn't connect to LAN. So, no way for me to access it.
I remember when I do the first sysupgrade after build, I opt to keep existing configuration.
Then I can use the previous IP and Admin/password to access the router.
Only when I find the extra switch0 / switch1 issue, then I proceed to manually do a reset to factory vi ssh .
And, I think I build with the latest development snapshot, as I don't know how to select a tagged version using git, yet.
I have no idea.
Hello Mythili,
Please share your solution for serial flash. I am having the same problem. The router fails to respond to '4' and 't' during power up.
Your help is appreciated.
Sorry all. I discovered the problem. Please ignore my request.
Thank you all.
Thank you for the images. I am using 19.07.02. I received kernel version mismatch error after openvpn-openssl package installation attempt. Please update the images to match kernel versions for this package. Thank you for your help.
FYI, the DSA driver for the Realtek rtl8367s got merged upstream today. It might arrive with kernel 5.18. Once that switch driver is available, it might not be too difficult to have C5v4 support merged.
This driver does not offload forwarding and all traffic between LAN ports still goes through the CPU. Maybe we can add the offload support before OpenWrt really uses it.
I have a branch with 5.15.17 kernel and dozens of backported patches that can generate a working image. There is a hack to disable all mediatek resets that prevented to boot the image. Mediatek Ethernet also have some trouble with checksum offload and incompatible dsa tag. I'll test changing the Realtek CPU tag position to the end of the packet. Maybe Mediatek will be happy with it. For now, it is disabling checksum offload.
If someone wants to take a look: