Yes, it was working with the shady, shitty, f**king QSDK chinese version.
My guess is that you messed up the partition table and now it cant find the overlay partition.
But without UART its just a guess
1 Like
It's a very likely possibility, I just ordered the TTL a while ago so when it arrives I can dig around.
In the meantime ye olde netgear R7000 will have to take over.
@Apache14 I got really annoyed and frustrated with ath11k so I tried getting the NSS crypto engine working.
Got the DTS node added, nss-crypto package with the patches required, enabled NSS-DRV crypto stuff and added a heper package to install the EIP FW.
Unfortunately, when I try to benchmark it with the benchmark kernel module that comes with nss-crypto it will cause the NSS FW to crash.
Only good thing out of that was that I fixed NSS-DRV to actually print the coredump and not crash the kernel with NULL pointer exceptions.
So, I pushed everything to nss-crypto branch of nss-packages.
Could be NSS firmware version mishmatch issues
2 Likes
@hugomon and @1715173329 I actually ended up bricking mine once as well after flashing the Chinese QSDK and then flashing the stock firmware with MiRepairTool. The router bootlooped, I managed to fix it with serial access. I think it had to do with uboot not finding a valid kernel to load. I fixed it by using uboot's memory write command to write a original firmware packaged as a .ubi to rootfs
And btw you did mess up the partition table if you used the chinese firmware... It does change the layout.
5 Likes
why use the uboot memory write when you can simply load a initramfs image and fix from there? (that should actually be the advised method to install the image with serial access)
also a brick is when you need advanced tool... A simple serial should fix the problem (if you enabled serial access with the vulnerability)
1 Like
This is a must for anyone wanting to test this device out 
I wouldn't do anything without validating you have TTY TX & RX until things are more stable
You used 11.4 branches along with the 11.4 FW ?
Im having a rest from ath11k for a day or so, its too much to read and understand 
Still think we are missing some responses from WMI so free doesnt get called. I was looking at the copy engine pipe clear down tasklet, so that may be where we see the clean up under load.
You know that the solution will be rework the code and convert it to a tasklet logic with some timeout so that after some time if the wmi response will be freed anyway if the firmware never actually respond ?
just telling you how messy it will be at the end... for now that is the only way practical way to fix this
Considering every command will have their own cleanup process, we can drop the cleanup part on the copyengine
1 Like
Yeah i was looking at wait_for_completion_timeout, issue is you dont 100% know what WMI responses your looking for
but i honestly think that we should really track what wmi response are failing and actually add the logic only for them... (or the other way... add a list of wmi that are always handled) but again putting a cleanup function in the copyengine that are triggered on load seems fundamentally wrong... can't understand why they designed it that way
again would love to work on that but NO TIME 
hope next week i will have some so i can have some fun with many ath11k kernel panic
Because when I tried the initramfs image approach I had 2 problems, 1 there wasn't sufficient disk space for me to scp the image I wanted to flash and 2 I then scp'ed it to /tmp but the router would reboot as soon as the transfer ended for some reason... This was before we started with the "reboot" branches, so the images were not nearly as usable as they're now
This is what im looking at now, the ath11k_ce_per_engine_service looks to clear down things on send callback
@Apache14 Yeah, I tried 11.4 FW as well, unfortunatelly core 1 which is the crypto one will panic anyway.
just to make sure, the nss core have the required flags enabled correct?
Yes, I enabled the crypto feature as without it, nss-crypto cant be compiled at all.
@quarky Was CFI also required for this?
@hugomon @1715173329 Did that brick happen after flashing one of the *.ubi files (as expected) or did you attempt to revert to stock using the regular *.bin from Xiaomi? (you have both types in this folder)
I am currently running one of those QSDK builds (with surprisingly nice wireless performance), but I am eagerly awaiting the day I can run OpenWRT. It's not so nice to know that I may face an imminent brick the day I try to move out of that QSDK build.
My guess is that it was when I try to revert it to the original Xiaomi firmware with MiRepairTool; this happened also to @felipejfc1 as he wrote on Adding OpenWrt support for Xiaomi AX3600 - #3450 by felipejfc1, and it seems the same case.
Right now I can only wait for the arrival of a 1.8v TTL.
2 Likes
It wont break if you ubiformat mtd12 or 13 with openwrt image if you're running the QSDK version already. You will be just fine. Still, I won't do it (for now) without serial access, just in case.
But it will break for sure if you use MiRepairTool after using QSDK version, so don't do it!
3 Likes
I don't know if I have the correct partition, but I simply booted into the Xiaomi partition, updated the firmware from UI to latest version, this replaced the QSDK partition and booted ok. After that I upgraded from the UI again, in theory this updated the Xiaomi partition to latest version too.
As I say I don't know if all is ok, but I'm on official without problem.
1 Like