That is so sad, bad news for people who bought the global version of this 
lets hope for the best😁
Yep. I stand corrected. Th test s/w only applies to RB03.
I think I'm missing something...
It seems like I can only run panton's images.
I can't get dekomote, nor mikeeq, nor original namidairo images to work. It doesn't seem to be able to bring up all the mtd partitions correctly.
The bootlog around the mtd partition creation...
2.979156] mtk-snand 1100d000.snfi: chip is GD5F1GQ5xExxG, size 128MB, page size 2048, oob size 128
[ 2.990312] [BBT] BMT.v2 is found at 0x3ff
[ 3.005797] 10 fixed-partitions partitions found on MTD device 1100d000.snfi
[ 3.012896] Creating 10 MTD partitions on "1100d000.snfi":
[ 3.018381] 0x000000000000-0x000000080000 : "Preloader"
[ 3.024825] 0x000000080000-0x0000000c0000 : "ATF"
[ 3.030208] 0x0000000c0000-0x000000140000 : "u-boot"
[ 3.036258] 0x000000140000-0x000000180000 : "u-boot-env"
[ 3.042213] 0x000000180000-0x0000001c0000 : "bdata"
[ 3.047759] 0x0000001c0000-0x000000240000 : "factory"
[ 3.053906] 0x000000240000-0x000000280000 : "crash"
[ 3.059510] 0x000000280000-0x0000002c0000 : "crash_log"
[ 3.065381] 0x0000002c0000-0x0000006c0000 : "kernel"
[ 3.078264] no rootfs found after FIT image in "kernel"
[ 3.083488] 0x0000006c0000-0x0000075c0000 : "ubi"
[ 3.295720] mtk-snand 1100d000.snfi: ECC: Uncorrectable bitflips in page 3456 sect 0
[ 3.303485] mtk-snand 1100d000.snfi: ECC: Uncorrectable bitflips in page 3456 sect 1
[ 3.311234] mtk-snand 1100d000.snfi: ECC: Uncorrectable bitflips in page 3456 sect 2
[ 3.318981] mtk-snand 1100d000.snfi: ECC: Uncorrectable bitflips in page 3456 sect 3
[ 3.326723] nand: FATAL ERR: BMT pool is run out!
And if I tftpboot to initramfs I don't see a firmware partition...
root@OpenWrt:/tmp# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00020000 "Preloader"
mtd1: 00040000 00020000 "ATF"
mtd2: 00080000 00020000 "u-boot"
mtd3: 00040000 00020000 "u-boot-env"
mtd4: 00040000 00020000 "bdata"
mtd5: 00080000 00020000 "factory"
mtd6: 00040000 00020000 "crash"
mtd7: 00040000 00020000 "crash_log"
mtd8: 00400000 00020000 "kernel"
mtd9: 06f00000 00020000 "ubi"
Any ideas?
I'm sure I'm just missing something that affects the layout, or more likely I did some a while back that affected the partition layout.
This looks like it's the latest layout. So, you won't be able to make a mtd write factory.bin firmware since there is no firmware partition, here the kernel partition is at the offset where firmware was. You'd use mtd write -r factory.bin kernel
I am totally stumped on getting the latest image onto my RB03. Any other ideas?
Using mtd -r write factory.bin kernel did not work. (I am assuming the key there is to ensure we are writing to offset 0x0000002c0000 since that is where uboot points to for boot.)
mtd -r write factory.bin firmware on stock gives the following at boot... https://pastebin.com/jeRdvrtg
mtd -r write factory.bin kernel on an initramfs gives [e]Failed to get erase block status. If I try to do it without erasing using -n, I get error [e]Error writing image. https://pastebin.com/ygVb8g83
Did you write the nvram vars before writing the factory.bin? Any change the bootloader is set to load from firmware1 and that's why it's failing? Maybe try this as well:
nvram set "boot_fw1=run boot_rd_img;bootm" && nvram commit
Yep. All nvram vars are being set & committed.
I'm interrupting the boot menu on every boot to ensure it's booting from firmware/0x2C0000, so that is not it.
I'm trying to think if I did anything that screwed up the mtd partitions or if the flash was bad, but I suspect if both of those were the case, then stock would not work, nor the old layout.
1 Like
Could it be that you need to fix these ECC - bitflips errors in the NAND? In the AX3600 thread there are some posts about one corrupted NAND issue.
*EDIT: Be careful, it is just a possible related problem.
Thanks for the tip.. I'll take a look.
I'm not sure if the bitflip errors are a cause or a symptom, but I have a feeling I'm about to dive into a world of flash, that I didn't care to dive into.
@namidairo anything we could do to help with merging this? I have 4 separate routers running this latest build, so far so good, no hangups, no need for reboots, everything looking fine.
2 Likes
Hi All, I'm still having issues with the latest image builds, but I am narrowing it down...
The kernel in those images does not not seem to be able to access anything past 4M on the kernel mtd partition. Accessing less than 4096k works, accessing more than 4096k does not work. This was tested by booting the initramfs versions of the images, creating test files using dd if=/dev/urandom and doing mtd write to see where it failed.
This does not happen from stock, nor the image created by panton. I can create test files, mtd write, mtd verify and all is good.
My next step is to get familiar with the openwrt build system to create some minimal "kernel only" images for further testing; along with reviewing the latest commits/merges for anything that might cause the issue.
EDIT: Up and running. Somewhere, somehow, I got the flash into a very strange state. To the point where most of the initramfs images wouldn't tftpboot because they would either panic or error-out from the flash errors. However, after writing my test files (/dev/random & /dev/zero), the nand errors went away, initramfs images were now happy to boot.
This morning, breaking out of my mtd tunnel vision, I finally clued in that mtd write factory.bin kernel from initramfs is never going to work since the kernel partition is only 4M big. As mentioned all over the place, from initramfs we do sysupgrade -u.
This was such a fringe case, and I'm still somewhat perplexed why reverting to stock did not fix the issue and allow for mtd -r write factory.bin firmware to work from stock. My best guess is there were some areas towards the end of the nand that were not erased/reset by stock, but were used by the openwrt image.
1 Like
Great to see you got it working at the end man!
The mediatek BBT/BMT resides at the end of the flash.
Ideally you shouldn't run into BMT exhaustion, but also erasing it may be ??? depending on how many actual bad blocks you have.
Hence the
[ 3.326723] nand: FATAL ERR: BMT pool is run out!
Occurring on your system.
hello everyone. Before 10 days i received a ax6s (rb03 model) which replaced my "old" xiaomi r3g.
I haven't tried it with stock firmware and flashed openwrt after unboxing. I have a feeling that the "old" one has better wifi coverage. Defective device or it is true?
r3g 5ghz wifi coverage is better than ax6s for me
been trying to force enable telnet on my telnet disable rb01 but with no luck whatsoever.methods tht i used up until now such as openwrtinvasion,redmi/mi ac2100 exploit,debrick to rb03 beta fw(no luck).usb programmer will be my last resort:sweat_smile:
To get telnet access, you may try this version
https://share.qust.me/路由器/红米%20AX6S
https://share.qust.me/d/路由器/红米%20AX6S/miwifi_rb03_firmware_stable_1.2.7（内测版）.bin
Try with 1.0.50 global firmware https://we.tl/t-A9rcZU7b6T