Initramfs and sysupgrade.tar files here as well in case you want to do the tftp boot (option 1 in the uboot menu):
openwrt-ramips-mt7621-mir3g-initramfs-kernel.bin
openwrt-ramips-mt7621-mir3g-squashfs-sysupgrade.tar
(limit of two links per post)
@Andy_x If you're interested as well
(limit of two linked users per post)
@tanonn
Thanks a ton!
I'm gonna try it today and share with results.
Unfortunately link to 'rootfs0.bin' not working (show 0 byte file). Please check
Thanks!
Does this method work with latest version of Padavan? And the kernel1 file is the one in http://downloads.lede-project.org/snapshots/targets/ramips/mt7621/openwrt-ramips-mt7621-mir3g-squashfs-kernel1.bin ?
Yesterday was still working.
wget.exe https://downloads.lede-project.org/releases/18.06.0-rc1/targets/ramips/mt7621/openwrt-18.06.0-rc1-ramips-mt7621-mir3g-squashfs-kernel1.bin -O openwrt-ramips-mt7621-mir3g-squashfs-kernel1.bin
wget.exe https://downloads.lede-project.org/releases/18.06.0-rc1/targets/ramips/mt7621/openwrt-18.06.0-rc1-ramips-mt7621-mir3g-squashfs-rootfs0.bin -O openwrt-ramips-mt7621-mir3g-squashfs-rootfs0.bin
for /f %%i in ("openwrt-ramips-mt7621-mir3g-squashfs-kernel1.bin") do ( set /a size = 4194304 - %%~zi >nul )
fsutil file createnew dummy2.bin %size% >nul
copy /y /b openwrt-ramips-mt7621-mir3g-squashfs-kernel1.bin + /b dummy2.bin + /b openwrt-ramips-mt7621-mir3g-squashfs-rootfs0.bin firmware.bin >nul
del dummy2.bin
pause
You should be able to hit much higher than that, as seen here https://wiki.openwrt.org/doc/howto/benchmark.openssl someone got the MT7621 to hit 1.2GHz. But just like juppin said, the mir3g does indeed heat and you can feel that to the touch.
If OCing and worried about heating too much, consider active cooling with a silent 120mm fan, should be plenty. As far as actually OCing the mir3g, until a month ago the BREED bootloader missed the clocking options completely and I don't know if it's been updated to sort that.
Thanks a lot @tanonn for your work, I'll test that asap (same case bad PEB 939 !)
Did you make your image based on 18rc1 ?
@Ultraboss @tanonn @Andy_x @pablos891
Has anyone reported a bug on https://bug.openwrt.org about this issue?
Probably anyone of the dev´s could take a look into this nand issue...
Sounds a bit that bad block handling does not work as expected in the mt7621 nand driver.
I think it was based on 17.04.1, as I was having problems with 18rc1 when trying to install packages due to missing dependencies for libc...
How can you actually tell? "/etc/os-release", "/etc/openwrt-version", "/etc/openwrt-release" and "/proc/version" all helpfully give the same information, "OpenWrt SNAPSHOT r7452-7e82418372". Don't know if that helps?
It works fine ! Thanks a lot again. I'm just leaning how to use OpenWRT...
Thank you for your answer. Once I flash it, in order to update I need to run the same commands or can I do it from the upgrade option (cli sysupgrade or using luci sysupgrade)?
Is there a recommended stable version of this firmware available anywhere? I tried 18rc1 and it goes out to lunch every now and then and not very useful. The latest snapshots and the 18rc1 both seem to be quite unusable.
The only semi-stable version I have ever used on this is OpenWrt SNAPSHOT r5740-012d20e which I had put onto the very first one of these I ever purchased. If I knew how to get that a copy of that version I would probably run it on my new ones too.
Does anyone know of a place to get a stable version?
Hey guys. I have a little problem, after installation I wrote this into my network file:
# Configure pppoe connection
uci set network.wan.proto=pppoe
uci set network.wan.username='yougotthisfromyour@isp.su'
uci set network.wan.password='yourpassword'
# Configure atm bridge
uci set network.atm.encaps='llc'
uci set network.atm.payload='bridged'
uci set network.atm.vpi='8'
uci set network.atm.vci='32'
# Configure adsl settings
uci set network.adsl.fwannex='a'
uci set network.adsl.annex='a2p'
# Save changes
uci commit network
# Restart network service to reflect changes
/etc/init.d/network restart
# Bring up the atm bridge and start it automatically on boot
/etc/init.d/br2684ctl start
/etc/init.d/br2684ctl enable
After that I did reboot and now I can't access router anymore. NetworkManager won't connect through lan and running ssh command says that network is unreachable. Did I bricked my router somehow?
Did you do factory reset? Anyway you can't broke a router with wrong openwrt configuration files.
Did anybody try to install dnscrypt v2 on mr3g? I tried this guide this https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-on-OpenWRT but i have a error "syntax error: unexpected word (expecting ")")". Did i choose right mips (Not mipsle. mips64, mips64le) architecture?
First of all, big thanks to all the devs for the great work on OpenWrt! Especially @nbd, for recent changes fixing ethernet hangs issue (I guess that it is related to issue with "NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out" messages) and unaligned writes to flash.
I can confirm that with r7493-b123921 I no longer see messages "Data buffer not 16 bytes aligned". And I'll have to wait and see whether mtk_soc_eth is also fixed in my case.
My current concern is related to issues recently mentioned by @tanonn, @pablos891 and @Andy_x - bad erase blocks. I had no issue yet, however since the first boot to OpenWrt I see messages mentioning a single bad erase block (in the range of "ubi" partition). It looked to me that the bad block is handled properly, but with the recent reports I began to wonder.
My situation is:
kern.info kernel: [ 2.532940] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
kern.info kernel: [ 2.540500] Scanning device for bad blocks
kern.warn kernel: [ 2.685110] Bad eraseblock 987 at 0x000007b60000
kern.notice kernel: [ 2.694913] 10 fixed-partitions partitions found on MTD device MT7621-NAND
kern.notice kernel: [ 2.701753] Creating 10 MTD partitions on "MT7621-NAND":
kern.notice kernel: [ 2.707061] 0x000000000000-0x000000080000 : "Bootloader"
kern.notice kernel: [ 2.713429] 0x000000080000-0x0000000c0000 : "Config"
kern.notice kernel: [ 2.719382] 0x0000000c0000-0x000000100000 : "Bdata"
kern.notice kernel: [ 2.725270] 0x000000100000-0x000000140000 : "Factory"
kern.notice kernel: [ 2.731293] 0x000000140000-0x000000180000 : "crash"
kern.notice kernel: [ 2.737155] 0x000000180000-0x0000001c0000 : "crash_syslog"
kern.notice kernel: [ 2.743579] 0x0000001c0000-0x000000200000 : "reserved0"
kern.notice kernel: [ 2.749815] 0x000000200000-0x000000600000 : "kernel_stock"
kern.notice kernel: [ 2.756311] 0x000000600000-0x000000a00000 : "kernel"
kern.notice kernel: [ 2.762264] 0x000000a00000-0x000007f80000 : "ubi"
kern.warn kernel: [ 2.768916] [mtk_nand] probe successfully!
kern.warn kernel: [ 2.773730] Signature matched and data read!
kern.warn kernel: [ 2.777997] load_fact_bbt success 1023
kern.info kernel: [ 2.782493] libphy: Fixed MDIO Bus: probed
kern.info kernel: [ 2.857298] libphy: mdio: probed
(...)
kern.notice kernel: [ 4.312772] UBI: auto-attach mtd9
kern.notice kernel: [ 4.316160] ubi0: attaching mtd9
kern.notice kernel: [ 5.425390] ubi0: scanning is finished
kern.notice kernel: [ 5.445342] ubi0: attached mtd9 (name "ubi", size 117 MiB)
kern.notice kernel: [ 5.450818] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
kern.notice kernel: [ 5.457702] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
kern.notice kernel: [ 5.464461] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
kern.notice kernel: [ 5.471406] ubi0: good PEBs: 939, bad PEBs: 1, corrupted PEBs: 0
kern.notice kernel: [ 5.477401] ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128
kern.notice kernel: [ 5.484590] ubi0: max/mean erase counter: 4/2, WL threshold: 4096, image sequence number: 1653724481
kern.notice kernel: [ 5.493689] ubi0: available PEBs: 0, total reserved PEBs: 939, PEBs reserved for bad PEB handling: 19
kern.notice kernel: [ 5.502902] ubi0: background thread "ubi_bgt0d" started, PID 394
kern.info kernel: [ 5.504948] block ubiblock0_0: created from ubi0:0(rootfs)
kern.notice kernel: [ 5.504960] ubiblock: device ubiblock0_0 (rootfs) set to be root filesystem
Now I wonder where is the difference in my case. Do they have just too many bad blocks? Or maybe there are different class of errors and mine is detected at boot time and reserve block is being used, but in the other cases some blocks are supposed to be fine (scan does not detect them as bad) however an error is thrown upon their usage?
The device is using NAND flash, so it's normal for it to accumulate some bad blocks over its lifetime. This is handled properly by UBI, and the code handling the kernel also contains some logic to skip over bad blocks.
Any way to rename DHCP hostnames to be easy to identify?
Something like:
android-3966338e17f7a375 192.168.0.243 89:7C:FF:1F:A5:4E
to
John_phone 192.168.0.243 89:7C:FF:1F:A5:4E
Add something like this to your /etc/config/dhcp
config host
option ip '192.168.1.2'
option mac '00:11:22:33:44:55'
option name 'mypc'
For more details:
https://openwrt.org/docs/guide-user/base-system/dhcp#static_leases