@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!
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.
@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?
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?
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.
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.