The global firmware will fail going from a CN firmware due to verifcation error on attempt of upgrade via the oem web page.
I will attempt a new u-boot bootloader in the future for this device, on my to do list
1 Like
Hey just thought you might want to know, it appears your most recent zip has a stale kmod-tun kernel module built for some previous kernel/build. When I try to install it, it complains about the kernel version, when I force it, the module won't load. And, indeed, your latest config doesn't have kmod-tun enabled, so I assume it's an old package from a previous build that accidentally made its way into the zip.
The image works great otherwise, thank you! I've been trying to build my own from the master branch of the OpenWrt repository, but I have a weird problem with the WAN interface, it just keeps resetting:
Sun Oct 18 13:47:47 2020 daemon.notice netifd: Network device 'wan' link is up
Sun Oct 18 13:47:47 2020 daemon.notice netifd: Interface 'wan' has link connectivity
Sun Oct 18 13:47:47 2020 daemon.notice netifd: Interface 'wan' is setting up now
Sun Oct 18 13:47:47 2020 daemon.notice netifd: Interface 'wan6' has link connectivity
Sun Oct 18 13:47:47 2020 daemon.notice netifd: Interface 'wan6' is setting up now
Sun Oct 18 13:47:47 2020 kern.info kernel: [ 75.105466] mt7530 mdio-bus:1f wan: Link is Up - 100Mbps/Full - flow control rx/tx
Sun Oct 18 13:47:47 2020 daemon.notice netifd: wan (2733): udhcpc: started, v1.31.1
Sun Oct 18 13:47:47 2020 daemon.notice netifd: wan (2733): udhcpc: sending discover
Sun Oct 18 13:47:48 2020 daemon.notice netifd: Network device 'wan' link is down
Sun Oct 18 13:47:48 2020 daemon.notice netifd: Interface 'wan' has link connectivity loss
Sun Oct 18 13:47:48 2020 daemon.notice netifd: Interface 'wan6' has link connectivity loss
Sun Oct 18 13:47:48 2020 kern.info kernel: [ 76.129401] mt7530 mdio-bus:1f wan: Link is Down
Sun Oct 18 13:47:48 2020 daemon.notice netifd: wan (2733): udhcpc: received SIGTERM
Sun Oct 18 13:47:48 2020 daemon.notice netifd: wan (2733): udhcpc: entering released state
Sun Oct 18 13:47:48 2020 daemon.notice netifd: wan (2733): Command failed: Permission denied
Sun Oct 18 13:47:49 2020 daemon.notice netifd: Interface 'wan' is now down
Sun Oct 18 13:47:49 2020 daemon.notice netifd: Interface 'wan6' is now down
### And then it repeats, over and over again
Sun Oct 18 13:48:00 2020 daemon.notice netifd: Network device 'wan' link is up
Sun Oct 18 13:48:00 2020 daemon.notice netifd: Interface 'wan' has link connectivity
### and so on...
Anyone else experiencing this problem? @araujorm's build works fine, so I'm trying to reconfigure that per my own needs, so far I haven't been able to get it to compile, but it's a work in progress. Still, even if I get the stable build working, I'm really interested in what could be happening here.
Hi.
Been checking... something looks fishy indeed with that module. Will try to rebuild properly later.
As for the instability of the master version, that's a problem inherent to it... if you try tomorrow maybe they've fixed it... or try to see the latest commits and rollback to before a suspicious one. That's why I prefer using something based on the stable version, sometimes performance may not be the best of the best, but there are less surprises.
1 Like
I wouldnt use the master snapshot, its always a moving target.
Try my new commit - https://gitlab.com/db260179/xiaomi-m4a/-/commit/4dd052bebdcaf48bd89e2ed2f54a13ead96e4fc5
I've noticed interfaces going up and down and traffic issues. Let me know if you have a good result no a build from my repo.
I have a quick build.sh script to make life easier.
Also the way openwrt builds kernel modules and links to the current kernel, then symbols from the openwrt master build repo will not work - reason for forcing the module insert.
@araujorm Best supply a imagebuilder so people can add kernel modules and create a custom image.
1 Like
Nice, thank you @araujorm and @db260179, all you say makes sense. And yeah master really isn't the optimal choice, but I didn't know what else to use before digging through this thread and finding these stable builds. I'll give it a shot @db260179, thanks!
Made a new build.
Using an online repo now, most annoyances with kmod packages should be fixed I hope. No need to copy anything manually any more. If you were using the previous release that was made available in a big zip file, please update to this one.
Other than that, it includes a tweak suggested by @db260179 to define the image block size. May help to install it on some devices that had squashfs errors before (please provide feedback).
As an alternative, I strongly suggest to look at the thread @db260179 opened to share his work, check his work and provide him the most useful feedback, as some of his discoveries are looking very promising IMO.
4 Likes
Damn, now I'm not sure which repo to use... 
Wonderful, thank you!
how do i add the tgz config?
It's only if you want to build the image yourself just as I did. For normal usage just flash the sysupgrade image.
tell me sir. How to add config
If you want to build your own firmware, clone the git repository, switch to the same tag as the build and untar the file there.
If you didn't understand, then you don't need it Just flash the sysimage file.
Note: if your router is not yet using openwrt, please search the thread for @hoddy video tutorials. You'll have to use a hack to be able to flash on the first time, or a flasher device (as described in the first thread posts). After being on openwrt you can flash other builds without hacks.
1 Like
hemm I've used your latest firmware but I don't know how to enter the config
Hi everyone,
I received a Mi Router 4A Gigabit (global edition) a couple of days ago and first thing I tried was to put OpenWRT in it. By using the OpenWRTInvasion exploit I managed to gain shell access, but after flashing the firmware the router was bricked. I then unbricked it via bootp/tftp and installed the original firmware (in Chinese), and tried to reflash it again with the same result (I tried a few different releases). Following the @araujorm notes I was able to flash the initramfs version of the firmware successfully, however after booting up the router I see no kernel partition on the mtd device.
Below is a portion of dmesg with the relevant info:
[ 7.081689] MediaTek Nand driver init, version v2.1 Fix AHB virt2phys error
[ 7.089085] spi-mt7621 1e000b00.spi: sys_freq: 220000000
[ 7.104118] m25p80 spi0.0: w25q128 (16384 Kbytes)
[ 7.109003] 8 fixed-partitions partitions found on MTD device spi0.0
[ 7.115326] Creating 8 MTD partitions on "spi0.0":
[ 7.120118] 0x000000000000-0x000000030000 : "u-boot"
[ 7.126259] 0x000000030000-0x000000040000 : "u-boot-env"
[ 7.132564] 0x000000040000-0x000000050000 : "Bdata"
[ 7.138390] 0x000000050000-0x000000060000 : "factory"
[ 7.144314] 0x000000060000-0x000000070000 : "crash"
[ 7.150177] 0x000000070000-0x000000080000 : "cfg_bak"
[ 7.156130] 0x000000080000-0x000000180000 : "overlay"
[ 7.162168] 0x000000180000-0x000001000000 : "firmware"
The output from cat /proc/mtd:
root@OpenWrt:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "Bdata"
mtd3: 00010000 00010000 "factory"
mtd4: 00010000 00010000 "crash"
mtd5: 00010000 00010000 "cfg_bak"
mtd6: 00100000 00010000 "overlay"
mtd7: 00e80000 00010000 "firmware"
It's worth noting that, when accessing the original firmware via the exploit the mtd device lists 11 different partitions, with the one labeled OS1 being mtd8, which is not listed when booting into OpenWRT initramfs (I don't have the output in a text format but I can post a picture if needed).
Any help would be greatly appreciated.
1 Like
Looks like some flash chips are picky with the alignments, and that should be your router's situation. Or it could be something on certain devices bootloader, I'm not sure.
Please revert to the original firmware and try my latest build, the one that was released a few hours ago. It has a new setting that should hopefully solve the issue. I never had that issue, but a few have had and I really hope this finally solves it...
If it doesn't, try going to @db260179 thread see a few posts above and see if his builds work with you. He's been working on a solution and he was the one that suggested that the blocksize parameter I applied on the build released tonight can be the solution, and since he could reproduce the problem on his hardware, he has been working on it. His insight on this matter is better than mine.
Worst case, try a snapshot build, is not as stable but many people say it works for them...
Edit: meanwhile I'm going to add a warning on those notes you mentioned that it was an experimental solution, but at this point it doesn't seem to be of much help
Hi @araujorm, thank you for your quick response. I did try your latest build a few hours ago and the same thing happened. I will try the one you mention from @db260179 and will keep you updated.
Best,
Carlos.
I took a look at my router's mtd table and I think I may have been misunderstanding it.
dev: size erasesize name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "Bdata"
mtd3: 00010000 00010000 "factory"
mtd4: 00010000 00010000 "crash"
mtd5: 00010000 00010000 "cfg_bak"
mtd6: 00100000 00010000 "overlay"
mtd7: 00e80000 00010000 "firmware"
mtd8: 001de405 00010000 "kernel"
mtd9: 00ca1bfb 00010000 "rootfs"
mtd10: 00950000 00010000 "rootfs_data"
Someone correct me if I'm wrong, but the kernel, rootfs and rootfs_data are contained in the firmware (mtd7) partition, being the kernel at offset 0 of it. I copied to my machine and ran binwalk, looks like so:
[rod@zoo tmp]$ ls -l mtd*
-rw-r--r-- 1 rod rod 15204352 Oct 23 02:27 mtd7
-rw-r--r-- 1 rod rod 1958917 Oct 23 02:27 mtd8
-rw-r--r-- 1 rod rod 13245435 Oct 23 02:27 mtd9
[rod@zoo tmp]$ binwalk mtd7
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0x445AAE3E, created: 2020-09-06 16:19:39, image size: 1958853 bytes, Data Address: 0x80001000, Entry Point: 0x80001000, data CRC: 0x17A6FC50, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-4.14.195"
64 0x40 LZMA compressed data, properties: 0x6D, dictionary size: 2097152 bytes, uncompressed size: 6270088 bytes
1958917 0x1DE405 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 3425314 bytes, 1643 inodes, blocksize: 262144 bytes, created: 2020-09-06 16:19:39
5439488 0x530000 JFFS2 filesystem, little endian
[rod@zoo tmp]$ binwalk mtd8
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0x445AAE3E, created: 2020-09-06 16:19:39, image size: 1958853 bytes, Data Address: 0x80001000, Entry Point: 0x80001000, data CRC: 0x17A6FC50, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-4.14.195"
64 0x40 LZMA compressed data, properties: 0x6D, dictionary size: 2097152 bytes, uncompressed size: 6270088 bytes
[rod@zoo tmp]$ binwalk mtd9
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 3425314 bytes, 1643 inodes, blocksize: 262144 bytes, created: 2020-09-06 16:19:39
3480571 0x351BFB JFFS2 filesystem, little endian
Also, take a look at when the router boots, taken from dmesg:
[ 2.504973] Creating 8 MTD partitions on "spi0.0":
[ 2.509749] 0x000000000000-0x000000030000 : "u-boot"
[ 2.515688] 0x000000030000-0x000000040000 : "u-boot-env"
[ 2.521789] 0x000000040000-0x000000050000 : "Bdata"
[ 2.527561] 0x000000050000-0x000000060000 : "factory"
[ 2.533478] 0x000000060000-0x000000070000 : "crash"
[ 2.539278] 0x000000070000-0x000000080000 : "cfg_bak"
[ 2.545309] 0x000000080000-0x000000180000 : "overlay"
[ 2.551212] 0x000000180000-0x000001000000 : "firmware"
[ 2.557481] 2 uimage-fw partitions found on MTD device firmware
[ 2.563384] Creating 2 MTD partitions on "firmware":
[ 2.568404] 0x000000000000-0x0000001de405 : "kernel"
[ 2.574298] 0x0000001de405-0x000000e80000 : "rootfs"
[ 2.580117] mtd: device 9 (rootfs) set to be root filesystem
[ 2.585898] 1 squashfs-split partitions found on MTD device rootfs
[ 2.592072] 0x000000530000-0x000000e80000 : "rootfs_data"
So if I'm interpreting this correctly, the notes on my mir4ag-19.07-20200722 release were almost correct... except that since it doesn't identify the flashed initramfs image on the "firmware" partition as a "multiple sub-partition" one (since it is not a squashfs sysupgrade image yet), we should flash the sysupgrade image on that "firmware" mtd partition. I now think that the correct command on the last part of the notes should be:
mtd -e firmware -r write openwrt-ramips-mt7621-xiaomi_mir3g-v2-squashfs-sysupgrade.bin firmware
However I don't want to brick your router permanently, so I won't really ask you to try it without a big fat warning: although I think you'll still be able to reflash original firmware with TFTP method if it doesn't work, I can't be 100% sure so be warned 
I currently don't have my flasher (a friend borrowed it some months ago and it may take some days to ask it back) or I would try it myself knowing I would be able to recover...
Is anyone here with a flasher able to try this in the meanwhile (having made a backup of the full flash first of course)? Or if someone can confirm that what I wrote above is harmless and will work...
Edit: corrected the mtd command, it's getting late and I should be sleeping now
1 Like
Thank you @araujorm. I tried your suggestion of writing your latest image to the firmware partition and it bricked the router. But good news: the build from @db260179's thread worked when flashing it from stock (Chinese).
1 Like
Hi @boliva,
Is this the text version you are referring to?
root@XiaoQiang:/tmp/mtd_backup# bootinfo ROM ver: config core 'version' # ROM ver option ROM '3.0.9' # channel option CHANNEL 'release' # hardware platform R1AC or R1N etc. option HARDWARE 'R4A' # CFE ver option UBOOT '1.0.2' # Linux Kernel ver option LINUX '0.0.1' # RAMFS ver option RAMFS '0.0.1' # SQUASHFS ver option SQAFS '0.0.1' # ROOTFS ver option ROOTFS '0.0.1' #build time option BUILDTIME 'Mon, 11 May 2020 10:39:54 +0000' #build timestamp option BUILDTS '1589193594' #build git tag option GTAG 'commit 85beb510fa8e9350b41c1cdef4f2083488887348' Hardware : Ver. A ROM sum: System : Dual - 1 KERNEL : console=ttyS1,115200n8 uart_en=0 factory_mode=0 mem=128m root=/dev/mtdblock9 MTD table: dev: size erasesize name mtd0: 01000000 00010000 "ALL" mtd1: 00030000 00010000 "Bootloader" mtd2: 00010000 00010000 "Config" mtd3: 00010000 00010000 "Bdata" mtd4: 00010000 00010000 "Factory" mtd5: 00010000 00010000 "crash" mtd6: 00010000 00010000 "cfg_bak" mtd7: 00100000 00010000 "overlay" mtd8: 00e80000 00010000 "OS1" mtd9: 00cb0000 00010000 "rootfs" root@XiaoQiang:/tmp/mtd_backup#
If so, after flashing OpenWrt the MTD layout is expected to be different, detailed below:
root@OpenWrt:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "Bdata"
mtd3: 00010000 00010000 "factory"
mtd4: 00010000 00010000 "crash"
mtd5: 00010000 00010000 "cfg_bak"
mtd6: 00100000 00010000 "overlay"
mtd7: 00e80000 00010000 "firmware"
mtd8: 001de405 00010000 "kernel"
mtd9: 00ca1bfb 00010000 "rootfs"
mtd10: 00970000 00010000 "rootfs_data"
root@OpenWrt:~#
Have just installed this build on the device that was previous running your v19.07.4-xiaomi-miwifi-3gv2-mt76updated-2020-09-18-fix_mtk_eth_timeout-generic_config firmware release