Adding OpenWrt support for Xiaomi AX3600

@robimarko the 512MB patch does magic - thanks for adding it!

1 Like

"Note that the ath11k profile is a config option that must be manually selected."

Am I blind or I really cant find where the DTSI mods can be selected? :slight_smile:

It's a config option for kmod-ath11k.
kernel-modules - wireless-drivers - kmod-ath11k

Yep, that is selected. Yet the total memory is 376MB instead of 408MB.
To be clear: the driver mods do apply, the DTSI mods are the ones missing: link

It's not missing, the ipq8074-512m.dtsi is included in ipq8071-ax3600 and ipq8070-cax1800 (instead of the regular ipq8074.dtsi)

Thanks a lot.
I have done the steps and i have root access.I have searched the file openwrt-ipq807x-generic-xiaomi_ax3600-squashfs-nand-factory.ubi in, but i was not succesful. Can anyone explain, where in the tree I can find the file ?


Hm... So you see 408MB total memory? Then maybe my old config is causing issues.

No it's till 374MB.

As far as I can see, the ipq8074-512m.dtsi still contains the reserved memory from the 1G profile.

I think we need to wait for robimarko to bring light into the darkness.

That patch has been removed from robi's and hauke's branches:

Notice that when you uploaded mtd1.bin to the device, it'll tell you how many bytes have been transferred, which is the file size.

You need to use this hex value as the last parameter for both erase and write command, that tells the command what size you need to erase and write.

Don't get confused with the previous one parameter, it's the start address of the target partition you want to erase and write to, it's coincidentally also 0x100000 here, you can check all partition addresses with command smeminfo

nand erase 0x100000 0x100000
nand write 0x44000000 0x100000 0x100000

thank you for answer. After the previous command i have constant reboot...

Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
S - Boot Config, 0x000002e5
B -       201 - PBL, Start
B -      2735 - bootable_media_detect_entry, Start
B -      3443 - bootable_media_detect_success, Start
B -      3448 - elf_loader_entry, Start
B -      6116 - auth_hash_seg_entry, Start
B -      6361 - auth_hash_seg_exit, Start
B -     68596 - elf_segs_hash_verify_entry, Start
B -    131296 - PBL, End
B -    218532 - SBL1, Start
B -    299296 - GCC [RstStat:0x10, RstDbg:0x600000] WDog Stat : 0x4
B -         0 - Debug Log
B -         0 - GCC_RST=0:r2=D306D401:r3=91F0A33B:r4=410E27EA:r5=F80B0459:r6=C082000C:r7=BE014640:r8=AC7110D:r9=C66557FC:r10=9104C850:r11=2860092D:r12=43046440:r13=9887C306:r14=C8AB839C:r15=280F800:r16=0:r17=65071400:r18=C0100350:r19=E7DA5C79:r20=C0F0201:r21=69C7CCA1:r22=96A0A010:r23=41470000:r24=47A4331:r25=5DFC5442:r26=63200040:r27=C04C01C0:r28=57244300:r29=5275066C:r30=83065123:r31=5FF41FA4:r32=0:r33=0:r34=4D141DDC:r35=30D01801:r36=0:r37=0:r38=0:r39=0:r40=0:
B -    379603 - pm_device_init, Start
B -    561139 - PM_SET_VAL:Skip
D -    180895 - pm_device_init, Delta
B -    563426 - pm_driver_init, Start
D -      5337 - pm_driver_init, Delta
B -    569862 - clock_init, Start
D -      2135 - clock_init, Delta
B -    573918 - boot_flash_init, Start
B -    6

is it possible to do something or it's a brick now?

Are you still able to stop auto boot and type commands? Paste your printenv so we can see your environment variable. It might be selecting the wrong rootfs to boot from. Also if your are able to run smeminfo so we can see partitions.

@dchard I messed up the memory DTSI for 512MB, I used the 1GB values since I wanted to add a 1GB one first, then changed my mind to just overriding the nodes and left the 1GB values inside.

Anyway, I fixed up the DTSI for 512M now and confirmed with DTC that the values match ones from QSDK 512M layout.
Its pushed anyway


I think it's bricked, there should be some lower level recovery method like a nand programmer or jtag, but I'm not familiar with them

@uamarchuan That looks really weird, SBL seems to fail on booting from media, I would assume that whatever partition table you put in is corrupted and it fails to find the bootloader partition.
This really requires an HW programmer to reflash the NAND completely.
This is why you don't flash whole QSDK based builds as they change the partition table and then you need to fix it up, and using U-boot for writing can be really nasty as it doesn't have anything that will prevent you from overwriting parts you don't want and you really need to check the hash and size of loaded binary as you don't know if the transfer got corrupted

Thanks Robi!

Question: with the second NSS core, can we get at least some basic crypto acceleration like AES?

1 Like

Well, for that you need nss crypto package and fw for it which is not public but can be pulled from the stock image.
However, the last time I tried it starting the test would cause the NSS FW to crash

I have serial connection but I only can received but unable to send data, I try to disable flow control but didn’t work. Please help me

Have you tried with newer NSS firmware?