Its the normal "use thing plastic knife / phone opening tool" and open slowly around the edge (in this case this is a line above the Ethernet ports). but i was VERY cautious with mine but still broke 2 tabs. But the screws hold everything together fine regardless.
2 Likes
Has anyone succeeded in compiling this link?
If you succeed please tell me what Linux version and the development packages versions that you use?
I appreciate it.
Hi @Apache14, How dose you enter into u-boot?
After I type any key when the numbers count down, I can't execute any command in u-boot.
After connecting the serial TX / RX and GND you have to set the nvram to enable boot wait and the RX pin. So from the stock rom with ssh access
nvram set uart_en=1
nvram set boot_wait=on
nvram commit
After setting boot_wait=on, will the system boot after X seconds without any key interaction?
I'm asking because it could make sense to enable this from SSH even when one did not connect the serial-pins.
Yeah with boot_wait=on it waits for 5 seconds, if no keys are pressed it will boot to system. It is part of the install guide for the QSDK image here Xiaomi AX3600 install guide
But you can only interact with the UBOOT shell with a working serial connection.
1 Like
Soldered a w25q128fwsig to the spi-nor flash footprint but the command sf probe doesn't detect it.
On the bottom side below the spi-nor footprint there are two labeled resistor and one capacitor footprints that are not assembled. One resistor and one capacitor are for sure related to the vcc pin of our spi-nor flash footprint. But it was to late to figure out if the second resistor is also related to it. Probably this is a persitent "cs" or "write enable" pull up/down resistor.
Are these R88 R87 and C77 ? If so (from the images I have) they all seem to be off the same trace. The resistors could well just be 0 Ohm links, unsure about the capacitor tho.
But it should be east to check if those unpopulated pads are connected to the SPI pads and if so the VCC voltage.
I'm not at home, but if they are below the spi-nor footprint, then yes.
The resistor related to vcc is for sure a dummy 0 ohm resistor.
The other one is most likely a pull up resistor with high impedance.
This one is for sure to keep the vcc line clean and the power stable.
Humm, I have cropped some of the images I have and marked up what how i think the through holes match up to the SPI chip
C77 = Cap between VCC and GND
R87 = Resistor between RESET and VCC
R88 = Resistor between DI and VCC
Could well be wrong tho
1 Like
Very helpful images 
Your labeling and thoughts seems right to me.
Seems I have to solder at least a pull up resistor in R87 to keep the reset/hold line disabled (pulled up) as the W25Q128FWSIG SOIC-8 package hasn't an internal pull up resistor.
The cap's usage is almost clear to me, but i think it should work without too.
I'm a bit confused about R88. This can actually only be a pull up resistor, which get's pulled down by the soc's MOSI pin.
I think R87,88 can be use 8-10k ohm, the capacitor can be about 1uf. I'm measured from another router.
Did anyone manage to upgrade the firmware from 1.0.17 to 1.0.67 while preserving SSH access?
I hope that the mesh-support in 1.0.67 is being realized by a newer hostapd-version and hope for hostapd-full which would allow 802.11K/R/V.
Using the webinterface there is no chance to stop it before rebooting and one will lose SSH 
I hoped that sysupgrade could be a feasible method, but the .bin-file is not being recognized as an valid image.
sysupgrade -i -T miwifi_r3600_firmware_f7f3e_1.0.67.bin
Image metadata not found
/tmp/miwifi_r3600_firmware_f7f3e_1.0.67.bin is not a valid FIT image
The .bin-file cannot be anlyzed with binwalk or at least I don't know how to do that:
binwalk miwifi_r3600_firmware_f7f3e_1.0.67.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
684 0x2AC UBI erase count header, version: 1, EC: 0x0, VID header offset: 0x800, data offset: 0x1000
Interesting that mtdinfo is reporting errors. I hoped this could be a way to manually upgarde.
mtdinfo
Count of MTD devices: 19
libmtd: error!: ECCGETLAYOUT ioctl request failed
error 95 (Not supported)
libmtd: error!: ECCGETLAYOUT ioctl request failed
error 95 (Not supported)
libmtd: error!: cannot open "/dev/mtd18"
error 16 (Resource busy)
Present MTD devices: mtd0, mtd1, mtd2, mtd3, mtd4, mtd5, mtd6, mtd7, mtd8, mtd9, mtd10, mtd11, mtd12, mtd13, mtd14, mtd15, mtd16, mtd17, mtd18
Sysfs interface supported: yes
The capacitor will just be for filtering on VCC, you could probably run without it, but anything 1uf - 10uf should work.
Also as @leeandy stated anything around 10k should work for the pull up resistors.
Should be some thing wrong with my UART connect, I can execute command in U-BOOT now, thanks.
Started throwing the DTS together for this, 1st issue is a panic when probing the nand chip
[ 0.820673] Hardware name: AX3600 (DT)
[ 0.820675] pstate: 60400005 (nZCv daif +PAN -UAO)
[ 0.820677] pc : qcom_nandc_probe+0x3d4/0x888
[ 0.820679] lr : qcom_nandc_probe+0x360/0x888
[ 0.820681] sp : ffffffc01002bb70
[ 0.820683] x29: ffffffc01002bb70 x28: 0000000000000000
[ 0.820688] x27: 0000000000000000 x26: ffffffc01096047c
[ 0.820693] x25: ffffff801e243800 x24: ffffff801e152ea8
[ 0.820697] x23: ffffff801ea19700 x22: ffffff801e9a9c00
[ 0.820702] x21: ffffff801e9a9c10 x20: ffffff801e152e80
[ 0.820706] x19: 0000000000000000 x18: 0000000000000014
[ 0.820710] x17: 000000003af8daf9 x16: 000000000db8d26c
[ 0.820715] x15: 00000000cb9ed508 x14: ffffffffffffffff
[ 0.820719] x13: 0000000000000008 x12: 0101010101010101
[ 0.820724] x11: 0000000000000010 x10: 0000000000000cc0
[ 0.820728] x9 : 0000000000000000 x8 : ffffff801e20c000
[ 0.820733] x7 : 0000000000000000 x6 : 0000000000000000
[ 0.820737] x5 : 0000000000000000 x4 : 0000000000000000
[ 0.820741] x3 : 0000000000000000 x2 : 0000000000000000
[ 0.820746] x1 : ffffffc012500000 x0 : 00000000f00f3000
[ 0.820751] Kernel panic - not syncing: Asynchronous SError Interrupt
[ 0.820753] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.48 #0
[ 0.820755] Hardware name: AX3600 (DT)
[ 0.820757] Call trace:
[ 0.820759] dump_backtrace+0x0/0x120
[ 0.820760] show_stack+0x14/0x20
[ 0.820762] dump_stack+0xb4/0xe0
[ 0.820764] panic+0x144/0x2f8
[ 0.820765] nmi_panic+0x6c/0x70
[ 0.820768] arm64_serror_panic+0x7c/0x88
[ 0.820769] do_serror+0x80/0x138
[ 0.820771] el1_error+0xbc/0x160
[ 0.820773] qcom_nandc_probe+0x3d4/0x888
[ 0.820775] platform_drv_probe+0x50/0xa0
[ 0.820776] really_probe+0xd8/0x2f8
[ 0.820778] driver_probe_device+0x54/0xe8
[ 0.820780] device_driver_attach+0x6c/0x78
[ 0.820782] __driver_attach+0x54/0xd0
[ 0.820784] bus_for_each_dev+0x60/0x98
[ 0.820786] driver_attach+0x20/0x28
[ 0.820788] bus_add_driver+0x178/0x1d8
[ 0.820790] driver_register+0x60/0x110
[ 0.820792] __platform_driver_register+0x44/0x50
[ 0.820794] qcom_nandc_driver_init+0x18/0x20
[ 0.820796] do_one_initcall+0x74/0x1b0
[ 0.820798] kernel_init_freeable+0x190/0x224
[ 0.820799] kernel_init+0x10/0xfc
[ 0.820801] ret_from_fork+0x10/0x18
[ 0.822513] SMP: stopping secondary CPUs
[ 0.822515] Kernel Offset: disabled
[ 0.822517] CPU features: 0x0002,20002004
[ 0.822519] Memory Limit: none
Edit so apparently adding some printk's masked the panic 
[ 0.820073] qcom_nandc_probe 1
[ 0.820882] qcom_nandc_probe 2
[ 0.823952] qcom_nandc_probe 3
[ 0.826981] qcom_nandc_probe 4
[ 0.830014] qcom_nandc_probe 5
[ 0.833035] qcom_nandc_probe 6
[ 0.836203] qcom_nandc_probe 7
[ 0.839224] qcom_nandc_probe 8
[ 0.842183] qcom_nandc_probe 9
[ 0.845192] qcom_nandc_probe 10
[ 0.845194] qcom_nandc_setup 1
[ 0.848255] qcom_nandc_setup 2
[ 0.853232] qcom_nandc_setup 3
[ 0.854400] qcom_nandc_setup 5
[ 0.857427] qcom_nandc_probe 11
[ 0.863852] nand: device found, Manufacturer ID: 0xef, Chip ID: 0xaa
[ 0.866569] nand: Winbond W29N02GZ
[ 0.873159] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 0.877031] qcom_nandc_probe 12
1 Like
I have mapped the NAND out in the device tree and it seems like we have nand working OK in the fallback shell (read rootfs and validated strings)
[ 0.863028] nand: device found, Manufacturer ID: 0xef, Chip ID: 0xaa
[ 0.865713] nand: Winbond W29N02GZ
[ 0.872322] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 0.875621] 17 fixed-partitions partitions found on MTD device qcom_nand.0
[ 0.883088] Creating 17 MTD partitions on "qcom_nand.0":
[ 0.889945] 0x000000000000-0x000000100000 : "0:SBL1"
[ 0.896925] 0x000000100000-0x000000200000 : "0:MIBIB"
[ 0.901779] 0x000000200000-0x000000500000 : "0:QSEE"
[ 0.908492] 0x000000500000-0x000000580000 : "0:DEVCFG"
[ 0.911325] 0x000000580000-0x000000600000 : "0:RPM"
[ 0.916266] 0x000000600000-0x000000680000 : "0:CDT"
[ 0.921066] 0x000000680000-0x000000700000 : "0:APPSBLENV"
[ 0.925907] 0x000000700000-0x000000800000 : "0:APPSBL"
[ 0.931890] 0x000000800000-0x000000880000 : "0:ART"
[ 0.936551] 0x000000880000-0x000000900000 : "bdata"
[ 0.941289] 0x000000900000-0x000000980000 : "crash"
[ 0.946201] 0x000000980000-0x000000a00000 : "crash_syslog"
[ 0.951019] 0x000000a00000-0x000002dc0000 : "rootfs"
[ 0.960313] random: fast init done
[ 0.986598] mtd: device 12 (rootfs) set to be root filesystem
[ 0.986880] mtdsplit: no squashfs found in "rootfs"
[ 0.991342] 0x000002dc0000-0x00000adc0000 : "rootfs_1"
[ 1.104152] 0x00000adc0000-0x00000cc80000 : "overlay"
[ 1.130607] 0x00000cc80000-0x00000cd00000 : "rsvd0"
[ 1.131624] 0x00000cd00000-0x00000d600000 : "0:WIFIFW"
[ 1.142464] qcom_nandc_probe 12
root@(none):/# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "0:SBL1"
mtd1: 00100000 00020000 "0:MIBIB"
mtd2: 00300000 00020000 "0:QSEE"
mtd3: 00080000 00020000 "0:DEVCFG"
mtd4: 00080000 00020000 "0:RPM"
mtd5: 00080000 00020000 "0:CDT"
mtd6: 00080000 00020000 "0:APPSBLENV"
mtd7: 00100000 00020000 "0:APPSBL"
mtd8: 00080000 00020000 "0:ART"
mtd9: 00080000 00020000 "bdata"
mtd10: 00080000 00020000 "crash"
mtd11: 00080000 00020000 "crash_syslog"
mtd12: 023c0000 00020000 "rootfs"
mtd13: 08000000 00020000 "rootfs_1"
mtd14: 01ec0000 00020000 "overlay"
mtd15: 00080000 00020000 "rsvd0"
mtd16: 00900000 00020000 "0:WIFIFW"
Still unsure why those printk's stopped the qcom nand driver falling over
If anyone wants me to push what I have i can do tomorrow. No networking at all at the moment tho, having to run all of this over the serial
4 Likes
Hello,
I found this information in the UBI file of the firmware (miwifi_r3600_firmware_5da25_1.0.17):
UBI File
UBI File
Min I/O: 2048
LEB Size: 126976
PEB Size: 131072
Total Block Count: 216
Data Block Count: 214
Layout Block Count: 2
Internal Volume Block Count: 0
Unknown Block Count: 0
First UBI PEB Number: 0
Image: 1696626347
---------------------
Image Sequence Num: 1696626347
Volume Name:kernel
Volume Name:ubi_rootfs
PEB Range: 0 - 215
Volume: kernel
---------------------
Vol ID: 0
Name: kernel
Block Count: 34
Volume Record
---------------------
alignment: 1
crc: '0xe136f135'
data_pad: 0
errors: ''
flags: 0
name: 'kernel'
name_len: 6
padding: '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
rec_index: 0
reserved_pebs: 34
upd_marker: 0
vol_type: 'dynamic'
Volume: ubi_rootfs
---------------------
Vol ID: 1
Name: ubi_rootfs
Block Count: 180
Volume Record
---------------------
alignment: 1
crc: '0xbbdc8fe3'
data_pad: 0
errors: ''
flags: 0
name: 'ubi_rootfs'
name_len: 10
padding: '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
rec_index: 1
reserved_pebs: 180
upd_marker: 0
vol_type: 'dynamic'
Extracted files:
nunoxyz@DESKTOP-9U8GI13:~/ubifs-root/ubi1.ubi$ binwalk img-1696626347_vol-ubi_rootfs.ubifs
DECIMAL HEXADECIMAL DESCRIPTION
0 0x0 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 22760870 bytes, 4138 inodes, blocksize: 262144 bytes, created: 2020-02-19 11:13:53
nunoxyz@DESKTOP-9U8GI13:~/ubifs-root/ubi1.ubi$ binwalk img-1696626347_vol-
img-1696626347_vol-kernel.ubifs img-1696626347_vol-ubi_rootfs.ubifs
nunoxyz@DESKTOP-9U8GI13:~/ubifs-root/ubi1.ubi$ binwalk img-1696626347_vol-kernel.ubifs
DECIMAL HEXADECIMAL DESCRIPTION
0 0x0 device tree image (dtb)
232 0xE8 gzip compressed data, maximum compression, has original file name: "Image", from Unix, last modified: 2020-02-19 11:13:17
3962192 0x3C7550 device tree image (dtb)
4042472 0x3DAEE8 device tree image (dtb)
4122692 0x3EE844 device tree image (dtb)
2 Likes
Yeah, so the rootfs and kernel ubi partitions are contained within the rootfs / rootfs_1 mtd block partition.
This should make this device very flexible in terms of kernel size.