Adding OpenWrt support for Xiaomi "Redmi Router AX6S"/"Xiaomi Router AX3200"

dsouza · 2022-04-11T01:54:06.369Z

Not really. The ports are capped at 100Mbps only if you connect a 100Mbps device. If all devices you connect to the Ethernet ports are Gigabit, all ports will work at full speed.

namidairo · 2022-04-11T01:57:33.006Z

I could have sworn it was reverted last week. I don't have any 100FE stuff connected to mine, so I wouldn't really see it anyway.

xabolcs · 2022-04-11T07:57:06.168Z

Yes, it was reported:

github.com/openwrt/openwrt

MT7621, MT7622: FDB learning bugs when VLAN filtering is enabled causes performance loss

opened 09:22PM - 07 Mar 22 UTC

closed 04:28PM - 03 Apr 22 UTC

dietcoke73

kernel target/mediatek bug

Fix FDB learning bugs when VLAN filtering is enabled was merged in ee6ba216d8ba1…b02154c287e64d709a8bc7b0054 but causes a performance drop on LAN ports. Multiple users discussing this issue in Forum topic https://forum.openwrt.org/t/belkin-rt3200-linksys-e8450-wifi-ax-discussion/94302/1785 TL;DR summary - when mulitple devices are connected to the switch, the performance of the switch drops to the lowest speed of the connected devices. So for example a 1000mbps capable device receives data only at the 10mbps data rate. Reverting this commit ee6ba216d8ba1b02154c287e64d709a8bc7b0054 tested by multiple users corrects the problem as the cost of reintroducing the original issue.

And it was fixed for master as @namidairo wrote: https://github.com/openwrt/openwrt/commit/3e0daca6447c3d5b9eb6d24ecb8e52f256f385cc

quarky · 2022-04-11T08:46:46.381Z

xabolcs:

Yes, it was reported:

This was reported for the mt7530 switch driver tho. Should only affect the AX6S as AX3600 uses QCA switch? Btw, when I studied the mt7530 driver I find that the VLANs configuration code is not ideal, but it shouldn't cause thruput throttling. The one that I found causes issue for the mt7530 switch is the disabling of the source address learning capability of the switch. When I disabled the 'disabling of SA learning' the mt7530 router (in my case the Linksys E8450) goes back to full speed even when 10/100mbps clients connected. The entire patch that was reverted to 'fix' the issue can be retained.

Edit: I mistakenly thought that this is also a thread for the Xiami AX3600, but it was for the AX3200, which is mt7622 based, using the mt7531 switch. In any case, the above point still stands tho.

Interestingly in the R7800 thread it was also reported that if there's a 100mbps client connected to it and there's active data transfer between that client and other LAN clients, WAN thruput will be affected. I did a quick test with my R7800 and I also see the behaviour as reported. It doesn't look like it could be caused by the switch driver, but I do not have enough knowledge to determine the cause. My suspicion lies in the way data frames are passed between the GMAC and the CPU. Likely the same issue is affecting the AX6S and AX3600 and likely all routers?

Gilgamesh · 2022-04-11T09:13:30.076Z

I sent a mail to a shop who sells the AX3200 International version and asked about the date on the package and he answered 09/2021, is it guaranteed that they come with Telnet enabled with that date? if so I should have waited before buying the AX6S from Aliexpress as the shop with the AX3200 is the same country I live in...lol.

arch_pilot · 2022-04-11T12:02:26.213Z

I am trying to reproduce johnd2's method.
During booting of the router I see regular U-Boot and kernel messages on my UART console.
But I can't type anything or get the boot process to halt, so it is not clear to me what the step "Start recovery/debrick procedure" means.

I have a BR01 (international) model from 11/2021 with fw 1.0.35 and according to routers fac_info page uart, telnet and ssh are disabled.

Gilgamesh · 2022-04-11T12:04:12.992Z

I just took a chance and bought two AX3200 International version with 09/2021 date, hopefully they have Telnet enabled.

kekesed97 · 2022-04-11T13:24:00.307Z

By "Start recovery/debrick procedure", he might mean the procedure for unbricking, not via console, but pressing the reset button and plugging the power in (you hold the reset botton in power off). Then halt the process by unplugging. Then follow the rest of guide.

arch_pilot · 2022-04-12T13:25:12.815Z

I successful managed to flash my AX3200 BR01 (international model) using UART and a BOOTP/TFTP server. Here is an explanation of what I did:

I discovered (by watching the UART console) that if you hold the reset button on start, the U-Boot with halt and check again in 5 seconds if the button is still pressed. If this is true it starts looking for a BOOTP server to obtain an IP address and a TFTP location for an image. So I set up a server and served the image xiaomi_redmi-router-ax6s-initramfs-recovery.itb, which was rejected by U-Boot. There is probably a RSA public key on one of the later partitions that gets sometimes updated with the official firmware updates, which is used by U-Boot even in this recovery mode. Next I served the official 1.0.71 BR01 firmware image http://cdn.awsde0-fusion.fds.api.mi-img.com/xiaoqiang/rom/rb01/miwifi_rb01_firmware_bbc77_1.0.71_INT.bin that was found by @remittor. U-Boot started the flashing process by erasing and rewriting two partitions. So I was not sure, if a bootloader update was performed. I repeated this procedure and this time only one partition was erased and rewritten. Feeling more confident now, I repeated the process again this time unplugging the power during the erase process. After booting the router normally (without reset button pressed) U-Boot failed to boot (as intended) and offered me a prompt starting with "MT7622>". So I changed my BOOTP/TFTP server to serve the xiaomi_redmi-router-ax6s-initramfs-recovery.itb image and executed MT7622> tftpboot on the UART console. U-Boot obtained the necessary information via the BOOTP protocol and booted directly into OpenWRT . From this I assume that either some kind of RSA public key was erased by the previous procedure, or the U-Boot prompt after a failed boot attempt (indicating a bricked device) never performs signature checks on images.

arch_pilot · 2022-04-12T13:56:45.659Z

Based on my previous longer post here is a short step-by-step flashing instruction for those who want to try flashing a BR01 model.

Setup a UART console with RX and TX working (115200 Baud 8N1)
Setup a BOOTP and TFTP server
2.1 I used bootp tftpd-hpa under Debian
2.2 Use the official 1.0.71 BR01 firmware image
2.3 The client mac address is set in step 4
Start the router while pressing the RESET button for at least 5 seconds
When the console shows that BOOTP broadcasts are sent, discover the MAC of the router in recovery mode using a tool like wireshark (this MAC is different to the one on the bottom of the device)
Ensure by looking at the output on the UART console, that the the flashing process only touches one partition, otherwise if you cut the power while the bootloader is updated you need a NAND programmer (and an image of the right U-Boot image )
5.1 If two partitions were flashed in the first run the second run should result in only one partition being flashed (my router from 11/2021 went from FW 1.0.35 --> 1.0.71)
Cut the power right after the erasing messages appear on the serial console
Change the BOOTP/TFTP server to serve the xiaomi_redmi-router-ax6s-initramfs-recovery.itb image
7.1 I used the one from 22.03-SNAPSHOTS
Boot up the router without pressing the reset button and you should end up with a console like this MT7622> where you can enter MT7622>tftpboot
Once you are in OpenWRT use scp to copy over the image xiaomi_redmi-router-ax6s-squashfs-sysupgrade.bin and execute sysupgrade image.bin
The router should automatically reboot into a persistent OpenWRT .

Remarks:

The BOOTP server can potentially be committed if using the official recovery tool from Xiaomi in step 2 and specifying the TFTP IP and location in step 8 explicitly.
Most important is step 5 where you check that only the firmware (kernel+ramfs+rootfs) partition and not the bootloader partition is touched during the recovery flashing

namidairo · 2022-04-12T14:39:24.135Z

arch_pilot:

otherwise if you cut the power while the bootloader is updated you need a NAND programmer (and an image of the right U-Boot image )

There's no uboot.bin in that image, to my knowledge, so that shouldn't be an issue...

arch_pilot · 2022-04-12T15:24:51.729Z

I saved the output of the serial console during booting using a logic analyzer with sigrok.

U-Boot output before flashing, i.e. running stock firmware 1.0.35 RB01

F0: 102B 0000
F6: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0000 0041 [0000]
G0: 0190 0000
T0: 0000 036F [000F]
Jump to BL

UNIVPLL_CON0 = 0xFE000000!!!
mt_pll_init: Set pll frequency for 25M crystal
[PMIC_WRAP]wrap_init pass,the return value=0.
[pmic_init] Preloader Start..................
[pmic_init] MT6380 CHIP Code, reg_val = 0, 1:E2  0:E3
[pmic_init] Done...................
Chip part number:7622B
MT7622 Version: 1.2.8, (iPA) 
SSC OFF
mt_pll_post_init: mt_get_cpu_freq = 1350000Khz
mt_pll_post_init: mt_get_mem_freq = 1600000Khz
mt_pll_post_init: mt_get_bus_freq = 279980Khz
[PLFM] Init I2C: OK(0)

[BLDR] Build Time: 20210316-161525
==== Dump RGU Reg ========
RGU MODE:     4D
RGU LENGTH:   FFE0
RGU STA:      0
RGU INTERVAL: FFF
RGU SWSYSRST: 8000
==== Dump RGU Reg End ====
RGU: g_rgu_satus:0
 mtk_wdt_mode_config  mode value=10, tmp:22000010
PL P ON
WDT does not trigger reboot
WDT NONRST=0x20000000
WDT IRQ_EN=0x340003
RGU mtk_wdt_init:MTK_WDT_DEBUG_CTL(590200F3)
[EMI] MDL number = 2
[EMI] DRAMC calibration start

[EMI] DRAMC calibration end

[EMI]rank size auto detect
[EMI]start_addr[0x40000000]=0x12345678, test_addr[0x48000000]= 0xEDCBA987
[EMI]start_addr[0x40000000]=0xEDCBA987, test_addr[0x50000000]= 0xEDCBA987
[EMI]rank0 size: 0x10000000
[MEM] complex R/W mem test pass
RAM_CONSOLE wdt status (0x0)=0x0
mtk_snand_get_device_info 
2-Recognize NAND: ID [C8 51 ], Device Name [GD5F1GQ5UEYIG], Page Size [2048]B Spare Size [128]B Total Size [128]MB
[BBT] BMT.v2 is found at 0x3FF
[PLFM] Init Boot Device: OK(0)

[PART] blksz: 2048B
[PART] [0x0000000000000000-0x000000000007FFFF] "PRELOADER" (256 blocks) 
[PART] [0x0000000000080000-0x00000000000BFFFF] "tee1" (128 blocks) 
[PART] [0x00000000000C0000-0x000000000013FFFF] "lk" (256 blocks) 

Device APC domain init setup:

Domain Setup (0x0)
Domain Setup (0x0)
Device APC domain after setup:
Domain Setup (0x0)
Domain Setup (0x0)
[PART] Image with part header
[PART] name : U-Boot
[PART] addr : 41E00000h mode : -1
[PART] size : 356560
[PART] magic: 58881688h

[PART] load "lk" from 0x00000000000C0200 (dev) to 0x41E00000 (mem) [SUCCESS]
[PART] load speed: 15827KB/s, 356560 bytes, 22ms
load lk (ret=0)
[PART] Image with part header
[PART] name : atf
[PART] addr : FFFFFFFFh mode : -1
[PART] size : 57936
[PART] magic: 58881688h

[PART] load "tee1" from 0x0000000000080200 (dev) to 0x43000DC0 (mem) [SUCCESS]
[PART] load speed: 14144KB/s, 57936 bytes, 4ms
load tee1 (ret=0)
[BLDR] bldr load tee part ret=0x0, addr=0x43001000
[BLDR] boot part. not found
[BLDR] part_load_images ret=0x0
[BLDR] Others, jump to ATF

[BLDR] jump to 0x41E00000
[BLDR] <0x41E00000>=0xEA00000F
[BLDR] <0x41E00004>=0xE59FF014


U-Boot 2014.04-rc1 (Aug 07 2021 - 08:08:31)

auto detection g_total_rank_size = 0x F000000
DRAM:  240 MiB
Turn on power orange!
NAND:  Recognize SNAND: ID [c8 51 ], Device Name [GD5F1GQ5UEYIG], Page Size [2048]B Spare Size [128]B Total Size [128]MB
[mtk_snand] probe successfully!
Not found in UBOOT NAND flash list
[BBT] BMT.v2 is found at 0x3ff
128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   mtk_eth
Uip activated


  *** U-Boot SPI NAND ***

     1. Load firmware 0 and bootup.
     2. Load firmware 1 and bootup.
     3. Load firmware selected by Xiaoqiang and bootup.
     U-Boot console trigger button release!


  Press UP/DOWN to move or Press 1~3 to choose, ENTER to select



Erasing NAND...
[mtk_nand_erase_hw] mtk_nand_erase_hw @4249, ret:0x40. page:0x280 
Erasing at 0x140000 -- 100% complete.
Writing to NAND... OK
Booting System 0

NAND read: device 0 offset 0x2c0000, size 0x2000
 8192 bytes read: OK
[do_read_image_blks] This is a FIT image,img_size = 0x285814
[do_read_image_blks] img_blks = 0x50c
[do_read_image_blks] img_align_size = 0x286000

NAND read: device 0 offset 0x2c0000, size 0x286000
 2646016 bytes read: OK
bootm flag=0, states=70f
## Loading kernel from FIT Image at 4007ff28 ...
   Using 'config@1' configuration
   Trying 'kernel@1' kernel subimage
     Description:  ARM64 OpenWrt Linux-4.4.198
     Type:         Kernel Image
     Compression:  lzma compressed
     Data Start:   0x40080010
     Data Size:    2610147 Bytes = 2.5 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x41080000
     Entry Point:  0x41080000
     Hash algo:    crc32
     Hash value:   df9c069c
     Hash algo:    sha1
     Hash value:   2676efab45128ee3677aaffe49b6ac05e048fc99
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 4007ff28 ...
   Using 'config@1' configuration
   Trying 'fdt@1' fdt subimage
     Description:  ARM64 OpenWrt mtk3200-RB01 device tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x402fd530
     Data Size:    31959 Bytes = 31.2 KiB
     Architecture: AArch64
     Hash algo:    crc32
     Hash value:   05344f9c
     Hash algo:    sha1
     Hash value:   5bb7038947f23d28abc8b9bd41cb821040cd8a4d
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x402fd530
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 4cf38000, end 4cf42cd6 ... OK

Starting kernel ...

U-Boot output after flashing OpenWRT 22.03-SNAPSHOT

F0: 102B 0000
F6: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0000 0041 [0000]
G0: 0190 0000
T0: 0000 036F [000F]
Jump to BL

UNIVPLL_CON0 = 0xFE000000!!!
mt_pll_init: Set pll frequency for 25M crystal
[PMIC_WRAP]wrap_init pass,the return value=0.
[pmic_init] Preloader Start..................
[pmic_init] MT6380 CHIP Code, reg_val = 0, 1:E2  0:E3
[pmic_init] Done...................
Chip part number:7622B
MT7622 Version: 1.2.8, (iPA) 
SSC OFF
mt_pll_post_init: mt_get_cpu_freq = 1350000Khz
mt_pll_post_init: mt_get_mem_freq = 1600096Khz
mt_pll_post_init: mt_get_bus_freq = 279980Khz
[PLFM] Init I2C: OK(0)

[BLDR] Build Time: 20210316-161525
==== Dump RGU Reg ========
RGU MODE:     4D
RGU LENGTH:   FFE0
RGU STA:      0
RGU INTERVAL: FFF
RGU SWSYSRST: 8000
==== Dump RGU Reg End ====
RGU: g_rgu_satus:0
 mtk_wdt_mode_config  mode value=10, tmp:22000010
PL P ON
WDT does not trigger reboot
WDT NONRST=0x20000000
WDT IRQ_EN=0x340003
RGU mtk_wdt_init:MTK_WDT_DEBUG_CTL(590200F3)
[EMI] MDL number = 2
[EMI] DRAMC calibration start

[EMI] DRAMC calibration end

[EMI]rank size auto detect
[EMI]start_addr[0x40000000]=0x12345678, test_addr[0x48000000]= 0xEDCBA987
[EMI]start_addr[0x40000000]=0xEDCBA987, test_addr[0x50000000]= 0xEDCBA987
[EMI]rank0 size: 0x10000000
[MEM] complex R/W mem test pass
RAM_CONSOLE wdt status (0x0)=0x0
mtk_snand_get_device_info 
2-Recognize NAND: ID [C8 51 ], Device Name [GD5F1GQ5UEYIG], Page Size [2048]B Spare Size [128]B Total Size [128]MB
[BBT] BMT.v2 is found at 0x3FF
[PLFM] Init Boot Device: OK(0)

[PART] blksz: 2048B
[PART] [0x0000000000000000-0x000000000007FFFF] "PRELOADER" (256 blocks) 
[PART] [0x0000000000080000-0x00000000000BFFFF] "tee1" (128 blocks) 
[PART] [0x00000000000C0000-0x000000000013FFFF] "lk" (256 blocks) 

Device APC domain init setup:

Domain Setup (0x0)
Domain Setup (0x0)
Device APC domain after setup:
Domain Setup (0x0)
Domain Setup (0x0)
[PART] Image with part header
[PART] name : U-Boot
[PART] addr : 41E00000h mode : -1
[PART] size : 356560
[PART] magic: 58881688h

[PART] load "lk" from 0x00000000000C0200 (dev) to 0x41E00000 (mem) [SUCCESS]
[PART] load speed: 16581KB/s, 356560 bytes, 21ms
load lk (ret=0)
[PART] Image with part header
[PART] name : atf
[PART] addr : FFFFFFFFh mode : -1
[PART] size : 57936
[PART] magic: 58881688h

[PART] load "tee1" from 0x0000000000080200 (dev) to 0x43000DC0 (mem) [SUCCESS]
[PART] load speed: 14144KB/s, 57936 bytes, 4ms
load tee1 (ret=0)
[BLDR] bldr load tee part ret=0x0, addr=0x43001000
[BLDR] boot part. not found
[BLDR] part_load_images ret=0x0
[BLDR] Others, jump to ATF

[BLDR] jump to 0x41E00000
[BLDR] <0x41E00000>=0xEA00000F
[BLDR] <0x41E00004>=0xE59FF014


U-Boot 2014.04-rc1 (Aug 07 2021 - 08:08:31)

auto detection g_total_rank_size = 0x F000000
DRAM:  240 MiB
Turn on power orange!
NAND:  Recognize SNAND: ID [c8 51 ], Device Name [GD5F1GQ5UEYIG], Page Size [2048]B Spare Size [128]B Total Size [128]MB
[mtk_snand] probe successfully!
Not found in UBOOT NAND flash list
[BBT] BMT.v2 is found at 0x3ff
128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   mtk_eth
Uip activated


  *** U-Boot SPI NAND ***

     1. Load firmware 0 and bootup.
     2. Load firmware 1 and bootup.
     3. Load firmware selected by Xiaoqiang and bootup.
     U-Boot console

 restore_defaults is set, enlarge xqup detect time 
 trigger button release!or Press 1~3 to choose, ENTER to select



Erasing NAND...
[mtk_nand_erase_hw] mtk_nand_erase_hw @4249, ret:0x40. page:0x280 
Erasing at 0x140000 -- 100% complete.
Writing to NAND... OK
Booting System 0

NAND read: device 0 offset 0x2c0000, size 0x2000
 8192 bytes read: OK
[do_read_image_blks] This is a FIT image,img_size = 0x3916a8
[do_read_image_blks] img_blks = 0x723
[do_read_image_blks] img_align_size = 0x391800

NAND read: device 0 offset 0x2c0000, size 0x391800
 3741696 bytes read: OK
bootm flag=0, states=70f
## Loading kernel from FIT Image at 4007ff28 ...
   Using 'config-1' configuration
   Trying 'kernel-1' kernel subimage
     Description:  ARM64 OpenWrt Linux-5.10.110
     Type:         Kernel Image
     Compression:  lzma compressed
     Data Start:   0x40080014
     Data Size:    3711254 Bytes = 3.5 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x44000000
     Entry Point:  0x44000000
     Hash algo:    crc32
     Hash value:   0ce3869b
     Hash algo:    sha1
     Hash value:   a3f64d0d011d42d98a990d8630057d76432926e0
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 4007ff28 ...
   Using 'config-1' configuration
   Trying 'fdt-1' fdt subimage
     Description:  ARM64 OpenWrt xiaomi_redmi-router-ax6s device tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x4040a274
     Data Size:    28171 Bytes = 27.5 KiB
     Architecture: AArch64
     Hash algo:    crc32
     Hash value:   9760fe11
     Hash algo:    sha1
     Hash value:   de430ae388f338ec99ec660fd095148655fdd052
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x4040a274
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 4cf39000, end 4cf42e0a ... OK

Starting kernel ...

According to these logs the bootloader was in fact not changed, but maybe the recovery flashing procedure updated two mtds (kernel+ubi) in the first run (which corresponded to an update from 1.0.35 --> 1.0.71) and only flashed the mtd containing the ubi in the second run (which is the only thing the user could possibly corrupt via the WebIF).

In this case the risk involved in this flashing method is potentially smaller than I assumed it to be.

dekomote · 2022-04-12T15:37:19.773Z

There's also the possibility of two separate firmware partitions being written the first time around.

arch_pilot · 2022-04-12T15:52:35.572Z

Some information about the NAND chip and layout on my device that might be interesting for the wiki page:

chip: GD5F1GQ5UEYIG (GD/ESMT SNAND 128MiB 3.3V 8-bit)

layout under 1.0.35 BR01 official FW (output from kernel)

Recognize NAND: ID [c8 51], [GD5F1GQ5UEYIG], Page[2048]B, Spare [128]B Total [128]MB
nand: device found, Manufacturer ID: 0xc8, Chip ID: 0x51
nand: GD/ESMT SNAND 128MiB 3.3V 8-bit
nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128
[NAND]select ecc bit:12, sparesize :112
[BBT] BMT.v2 is found at 0x3ff
13 ofpart partitions found on MTD device MTK-SNAND
Creating 13 MTD partitions on "MTK-SNAND":
0x000000000000-0x000000020000 : "PL_Header"
0x000000020000-0x000000080000 : "Preloader"
0x000000080000-0x0000000c0000 : "ATF"
0x0000000c0000-0x000000140000 : "uboot"
0x000000140000-0x000000180000 : "Nvram"
0x000000180000-0x0000001c0000 : "Bdata"
0x0000001c0000-0x000000240000 : "Factory"
0x000000240000-0x000000280000 : "crash"
0x000000280000-0x0000002c0000 : "crash_syslog"
0x0000002c0000-0x0000020c0000 : "firmware"
2 fit-fw partitions found on MTD device firmware
0x0000002c0000-0x000000560000 : "kernel"
0x000000560000-0x0000020c0000 : "rootfs"
mtd: device 11 (rootfs) set to be root filesystem
0x0000020c0000-0x000003ec0000 : "firmware1"
0x000003ec0000-0x0000070c0000 : "overlay"
0x0000070c0000-0x000008000000 : "obr"
mtd: partition "obr" extends beyond the end of device "MTK-SNAND" -- size truncated to 0x500000
mtk-snand 1100d000.snfi: [mtk_snand] probe successfully!

layout under OpenWRT 22.03-SNAPSHOT (output from kernel)

mtk-snand 1100d000.snfi: chip is GD5F1GQ5xExxG, size 128MB, page size 2048, oob size 128
[BBT] BMT.v2 is found at 0x3ff
10 fixed-partitions partitions found on MTD device 1100d000.snfi
Creating 10 MTD partitions on "1100d000.snfi":
0x000000000000-0x000000080000 : "Preloader"
0x000000080000-0x0000000c0000 : "ATF"
0x0000000c0000-0x000000140000 : "u-boot"
0x000000140000-0x000000180000 : "u-boot-env"
0x000000180000-0x0000001c0000 : "bdata"
0x0000001c0000-0x000000240000 : "factory"
0x000000240000-0x000000280000 : "crash"
0x000000280000-0x0000002c0000 : "crash_log"
0x0000002c0000-0x0000006c0000 : "kernel"
no rootfs found after FIT image in "kernel"
0x0000006c0000-0x0000075c0000 : "ubi"

However I only have ~50MB as an overlayfs despite the ubi region in the mtd is 111MiB≈116MB in size.

luzik · 2022-04-12T16:26:47.790Z

Wiki have no information what to do next, after successful openwrt installation.

Should we just install luci and stick with firmware version from wiki (because it is especially crafted for this device) ? Or after flash - is it safe to upgrade to latest snapshot (is there any Flash Layout issue?)
Can we upgrade to latest stable release ? or should we wait for next one ?

wepee · 2022-04-12T16:31:28.392Z

If not mistaken, @dsouza bought 1 unit of AX3200 RB01 model, production date = 9/2021 which
has Telnet enabled. Mine one is 8/2021, which also has Telnet enabled.

Another forum user bought one that has a production date: 11/2021 but it has Telnet disabled.Adding OpenWrt support for Xiaomi "Redmi Router AX6S"/"Xiaomi Router AX3200" - #507 by arch_pilot

So I guess, most likely 10/2021 is the cut off point- it could be Telnet enabled or disabled.

dekomote · 2022-04-12T16:49:43.816Z

I got 5 units 9/2021 all had telnet on.

Gilgamesh · 2022-04-12T16:50:45.579Z

yeah I went through the whole thread before I ordered the 09/2021 ones to see if more users who bought the International model with Telnet enabled told about the production date but like you say only 2-3 users so maybe it's no guarantee but I get them tomorrow, so hopefully Telnet is enabled so I can return or sell the AX6S I bought from Aliexpress.

Gilgamesh · 2022-04-12T16:53:00.166Z

oh great, the shop I bought from had only 3 left, all of them 09/2021, so I bought two, only needing one but one for backup instead of the R7800 that I can sell.

Wham_Donny · 2022-04-13T09:19:12.873Z

My MT7621 device with the latest 22.03 snapshot is getting around 300 Mbps with SQM + Software Offloading, has anyone tested the throughput with these MT7622 devices like the AX6S?