Thanks, I successfully flashed my mir3g, so far so good.
Cheers!
How to flash back stock kernel0 if I erased kernel0 according to instruction in this post: Xiaomi WiFi Router 3G ?
Hi Andy,
Did you find a solution to your problem? I'm experiencing the same issue with bad eraseblocks in mtd9 where it tries to set up the ubi partition.
As an alternative, I tried loading the combined initramfs+kernel image directly to SDRAM via TFTP (option 1 in the uboot process), which successfully allowed me to access the console, from which I attempted to perform the sysupgrade command with a sysupgrade tarball transferred from laptop via scp. Unfortunately, the issue with the flash caused sysupgrade to fail, yielding a little more detail now:
[ 106.401215] ubi0 error: ubi_read_volume_table: the layout volume was not found
[ 106.408671] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd9, error -22
ubiattach: error!: cannot attach mtd9
error 22 (Invalid argument)
And another error after trying to format all of the eraseblocks:
libmtd: error!: MEMERASE64 ioctl faile
ubiformat: error!: failed to erase eraseblock 934
error 11 (Resource temporarily unavailable)
After which the device just goes into a boot loop at this error:
[ 4.351986] UBI error: no valid UBI magic found inside mtd9
[ 4.357626] hctosys: unable to open rtc device (rtc0)
[ 4.362879] usb_vbus: disabling
[ 4.366568] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[ 4.382353] 1f00 512 mtdblock0
[ 4.382359] (driver?)
...
[ 4.447504] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 4.457695] Rebooting in 1 seconds..
The weirdest thing is that when I revert to the stock xiaomi firmware, the same bad blocks get reported, but it seemingly has no problem in erasing them, as I discovered upon restoring the original firmware via the usb method. Additionally, the position of the blocks that are reported as bad are shifted down by a value of 80 after the error occurs:
libscan: scanning eraseblock 938 -- 99 % complete
libscan: scanning eraseblock 939 -- 100 % complete
ubiformat: 918 eraseblocks have valid erase counter, mean value is 4
ubiformat: 2 eraseblocks are supposedly empty
ubiformat: 10 bad eraseblocks found, numbers: 561, 562, 571, 583, 587, 596, 644, 743, 769, 851
ubiformat: warning!:
ubiformat: formatting eraseblock 0 -- 0 % complete
ubiformat: formatting eraseblock 1 -- 0 % complete
and yet:
[ 3.290000] NAND device: Manufacturer ID: 0xc8, Chip ID: 0xd1 (ESMT NAND 128MiB 3,3V 8-bit), 128MiB, page size: 2048, OOB size: 64
[ 3.310000] [NAND]select ecc bit:4, sparesize :64 spare_per_sector=16
[ 3.310000] Scanning device for bad blocks
[ 3.410000] Bad eraseblock 641 at 0x000005020000
[ 3.410000] Bad eraseblock 642 at 0x000005040000
[ 3.420000] Bad eraseblock 651 at 0x000005160000
[ 3.420000] Bad eraseblock 663 at 0x0000052e0000
[ 3.430000] Bad eraseblock 667 at 0x000005360000
[ 3.430000] Bad eraseblock 676 at 0x000005480000
[ 3.450000] Bad eraseblock 724 at 0x000005a80000
[ 3.460000] Bad eraseblock 823 at 0x0000066e0000
[ 3.470000] Bad eraseblock 849 at 0x000006a20000
[ 3.490000] Bad eraseblock 931 at 0x000007460000
[ 3.510000] Signature matched and data read!
[ 3.510000] load_fact_bbt success 1023
I'm just wondering if anyone here has a better understanding of linux flash filesystems than me (knowing basically nothing at all, apart from what I've been able to gleam from the OpenWRT pages) and might be able to help?
I've uploaded the logs for the sysupgrade attempt and the reversion to stock firmware on pastebin at the links below:
Thanks!
1 Like
May i know the safest step by step to flash from stock to lede firmware for xiaomi wifi router 3G ?
@tanonn
I'm another who have this issue. Unfortunately no much answer in the web. You did a little more research than I do (I have only seen this error on UART):
[ 4.596314] ubi0 error: __erase_worker: failed to erase PEB 939, error -5
[ 4.603070] ubi0: mark PEB 939 as bad
Funny thing is that the three of us (you, me and @Andy_x) have exactly the same block marked as bad.
I can back to Stock Firmware and also I have seen "Bad erase Block info" as you.
Assume we have exactly the same issue, but have no idea how to solve it.
I hope that someone with more knowledge will help.
Do you also have the version with the China Telecom branding on? ((image)
This is actually the 2nd Mi 3G router I've bought, my other one doesn't have the same branding and that flashed with no problems at all, so I'm wondering if there's anything different with the China Telecom ones?
It is possible to run LEDE simply on the SRAM, by booting from an image served over tftp, as I described above. While this means that the filesystem won't persist between power cycles, if I can't find a way to fix the flash memory problem, I may just try to get around this by automating backups of the configuration files with cron jobs and hooking up the serial interface to a raspberry pi to automate the boot procedure via tftp.
It ain't pretty, but at least it's better than having a $40 (plus shipping) paperweight sitting on my desk....
@tanonn
My R3G have no China Telecom branding.
Actually it is also my second R3G and with the first one I have no problems, but both looks identically.
If you prepare this kind of solution please share details. I also have the Raspberry Pi and it would be much easier for me not to invent the wheel again 
BTW: is there any chance to have good working LEDE if we go to e.g Padavan firstly (Stock Firmware -> Padavan -> LEDE)? Or we expect that Padavan also wont't work?
On SRAM is impossible... This has only a few kb...
You mean DRAM?
If you have a serial console you could boot the build initram image over tftp or flash it also on flash...
But the Ralink Uboot does always boot from flash by default, this means you have to choose on every boot the tftp ram boot option.
If you flash the initram image your bl will always load the kernel with the appended initram rootfs and you have an always ram booted system...
Check out the Ralink Uboot options 1 and 2 at boot up...
Hi Juppin,
Yes, I meant DRAM, sorry, in the U-boot menu it's confusingly referred to as SDRAM...
I've already tried those, as in my post above, there's no problem getting the image onto the volatile memory via tftp boot (option 1), but writing it to flash isn't working due to the issue with the bad blocks, which it isn't able to erase for some reason, yielding the following error:
ubiformat: formatting eraseblock 933 -- 99 % complete
ubiformat: formatting eraseblock 934 -- 99 % complete libmtd: error!: MEMERASE64 ioctl faile
ubiformat: error!: failed to erase eraseblock 934
error 11 (Resource temporarily unavailable)
Now it only reports 10 bad PEBs, with 418 good PEBs (when reverting to stock firmware):
[ 14.980000] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[ 14.980000] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[ 14.990000] UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
[ 15.000000] UBI: good PEBs: 418, bad PEBs: 10, corrupted PEBs: 0
[ 15.000000] UBI: user volume: 0, internal volumes: 1, max. volumes count: 128
[ 15.010000] UBI: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 1124940026
[ 15.020000] UBI: available PEBs: 404, total reserved PEBs: 14, PEBs reserved for bad PEB handling: 10
[ 15.030000] UBI: background thread "ubi_bgt1d" started, PID 696
which - not knowing the exact details of how linux filesystems are implemented on flash - doesn't sound to me to be significant enough to prevent the flash memory from being useable, given that these things are meant to be pretty massively over-provisioned in the first place. The fact that it's able to erase the bad blocks successfully when reverting to the stock firmware (see my original post and linked logs) seem to validate this, although it seems when formatting the blocks for the stock firmware, it only use 428 PEBs, as opposed to the much greater number of >900 PEBs with the OpenWRT firmware, which leads to the error at block 939. Given that this is for the UBI partition, is it possible to limit the blocks assigned to this partition so that it doesn't go up to block 939, where the error occurs?
Thanks very much for helping us on this by the way!
Sorry, i've read only the last two postings...
You have to compile the image yourself.
Take a look at the partition nodes in the nand node...
OpenWRT does use all available space after the second kernel partition for the rootfs and data (ubi).
The stock fw does split the ubi partition in two separate partitions, one for kernel0(kernel_stock) and one for kernel1(kernel).
Try to reduce the partition with the label ubi to the half of its current size and try your self compiled image...
1 Like
Thanks a lot man, I will give this a try!
You could also play with the start of the partition and don't use the sections with bad blocks...
Probably the nand driver for mt7621 could not handle bad blocks correctly, but it should...
To which partition numer is your image flashed for stock and for openwrt? Could you choose that in the uboot menu? If not this will be always the partition that isn't selected as current working partition...
If i had time i will check this on my secondary mir3g...
Edit: Forgot to mention, if you change the start of the ubi partition, you have to boot the initram image with changed ubi start address and flash with that the sysupgrade image with the changed start address of ubi partition.
Someone know how to flash stock from padavan? I want flash this new snapshot from stock but i can't make padavan to let me install miwifi.bin.
From prometheus i tryied "recovery mode" but now router flashing yellow light when i connect power plug and then is blinking red...
Okay. Nevermind... I swiched usb drives and i have stock back again...
How did you manage to flash OpenWRT from Padavan? Did you use SSH from Padavan or had to use the Breed firmware?
Or @ anyone else, is it possible to flash OpenWRT from Padavan? What should be the steps?
Please check link: https://goo.gl/HikS9u or using padavan script restore backup firmware
http://s1.fotowrzut.pl/WK7SZGBPKB/1.jpg
Hello there.
I saw several guides about overclocking xmr3g. But they for padavan firmware. Does have one for LEDE?
Don´t think this depends on firmware... I think you have to modify the bootloader... Some guys here have installed breed bootloader and as i know with this it is possible to overclock your mt7621.
But don´t think it is worth the performance gain...
My mir3g gets without oc hot under load and i dont´t think you can get more than 100 mhz oc on mt7621 without a better cooling solution.
I read about 1100 mhz on processor w\o any troubles. Anyway, just want to test how will work xmr3g with p2p, vpn server and large amount iptable rules.
Slightly more than 24 hours later and I have a working Mi 3G router running OpenWRT, thanks to @juppin!
I spent most of the day messing around trying to set up the build environment on my mac, then on Windows Subsystem for Linux, then finally realised the sensible thing to do would be to just set up a docker container and it compiled perfectly first time!
I experimented a bit with the size of the UBI partition and I've settled on leaving it at 85% of the original size, which I'm pretty comfortable with, as it's reporting 75MB free and that's with lede-ssl and some other useful packages that I wanted already installed.
@pablos891 I've uploaded the images I've used, so you can try them to see if they work for you too:
openwrt-ramips-mt7621-mir3g-squashfs-kernel1.bin
openwrt-ramips-mt7621-mir3g-squashfs-rootfs0.bin
Those files should be available for the next 30 days.
Thanks again @juppin!