Yeah, its already on the todo.
Only downside is that you must use fixed-partitions for it, but most devices already have partitions dedicated for it.
It would make life much easier.
right the smem partition problem... i assume pstore search for an of node connected with the mtd name right? (totally random didn't check the implementation)
Anyway ideally the correct solution would be to use all the logic used by the SoC to store kernel panics... part of the reserved memory is also about storing kernel panics and other debug stuff
but too much effort currently to make it work... (aka not a priority)
Wonder if for the current debug purpose we should consider converting the device to fixed partition
No idea how it works, but it requires to be under an MTD partition node.
I mean, AX6,3600 and 9000 kind of require to be converted to fixed-partition anyway to enlarge the rootfs drastically so its not bad.
RAMoops can be used to store debug logs in RAM, since its reserved memory I presume it somehow doesn't get flushed on reboot?
No idea... We should test... AFAIK that reserved part is also used by rpm but should be used by the watchdog to store all sort of debug stuff on a kernel panic. We should test if using it doesn't cause problems... Easy to test in theory as we can trigger fake kernel panic.
(code about that reserved memory is in the watchdog source)
I doubt it will cause a panic as QCA uses it for debug as well, something to test for sure.
Do you know the range maybe?
I know that they have a TZ log and RPM log, both of which are not RAM at all and are used to see messages from TZ and RPM, not to store crash logs there
How to get back to STOCK partition layout on AX3600 without serial cable
Files required: https://drive.google.com/drive/folders/1r_SomeN7epfbYEf6qkzqMDIn971DCdHK?usp=sharing
I would like to describe how I reverted into stock partition layout in my case
My configuration: mtd12 - stock firmware, mtd13 -robimarko firmware, partition layout broken (mtd13 - 128MB(only 48mb usable), extra 0:WIFIFW part) after play with QSDK stuff..
short instruction: replace mtd1(0:mibib) with stock_mibib.bin
-
Booted into mtd13 by: (I'm not sure if it's mandatory)
nvram set flag_last_success=1
nvram set flag_boot_rootfs=1 -
after boot into openwrt I've placed mibib_stock.bin into /tmp and issued commands:
mtd write /tmp/mibib_stock.bin /dev/mtd1
reboot
-> unplugged power cable for 30secs -
device boot takes about 3-5mins (device reboot few times, sys orange light may blink)
-
After reboot -> stock image with cleared out configuration but with stock partition layout - like new one.
Thanks for @cjom and @McGiverGim for providing files to compare across routers.
8 Likes
How much free space after you back to stock partition? Is it enough for install Agguard home? Thank you
I got the stock partition back, thank you for your guide. But with this partition, I don't have enough freespace to install AdguardHome (only have 13.5MB free after flash) 
I want to test your method to return to stock in the layout. In my case, I think I have stock firmware in both partitions (possibly INT version in mtd12 and Chinese in mtd13). I suppose is not a problem, right? I have seen the mtd command exists.
few comments from myself:
- Currently only stock partition layout gives you opportunity to use tftp unbrick method that came with vendor uboot.
- Both partition will have around 12MB of free space after flash openwrt. Even with that huge second partition if you start to put data there if you pass 48MB router starting to crash, and you cannot use tftp recovery....
- In future it might be good idea to create new uboot (with breed, that will provide you anti-brick recovery) together with new partition layout to utilize space better on nand flash. Until this is not done - it's safer to stay with stock one, with price to have smaller amount of free space.
1 Like
A little typo... the file is mibib_stock.img not bin... I tried and I get this error:
root@XiaoQiang:~# mtd write /tmp/mibib_stock.img /dev/mtd1
Could not open mtd device: /dev/mtd1
Can't open device for writing!
As I say I'm on stock in both partitions. Maybe I need to install OpenWRT first?
that might be good idea, seems that vendor blocked flash of this part somehow. Boot router from mtd12, flash openwrt on mtd13 - same as here then follow my instructions.
It seems OpenWRT unlocks it first:
root@OpenWrt:~# mtd write /tmp/mibib_stock.img /dev/mtd1
Unlocking /dev/mtd1 ...
Writing from /tmp/mibib_stock.img to /dev/mtd1 ...
Layout ready:
root@XiaoQiang:~# 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: 023c0000 00020000 "rootfs_1"
mtd14: 01ec0000 00020000 "overlay"
mtd15: 00080000 00020000 "rsvd0"
mtd16: 0041e000 0001f000 "kernel"
mtd17: 015cc000 0001f000 "ubi_rootfs"
mtd18: 01876000 0001f000 "data"
1 Like
has anyone been able to build the kmod-qca-nss-crypto together with nss_eip_firmware?
it is failing with not finding the ifpp.bin however it is under the linux-firmware folder
"ifpp.bin" should be in /lib/firmware/ otherwise the driver can't find it. Just copy it to the right location.
No, the nss-eip-firmware package is there to ensure that you cant build the nss-crypto without FW.
FW must be extracted from the stock FW(All 4 bins) and you should place it in package/feeds/nss_packages/nss-eip-firmware/src
Also, note that NSS-CRYPTO wont work currently, NSS-DRV still needs to be fixed up.
2 Likes
yes ... but the makefile should be doing it as part of the build
thx... that was my next question about the nss-drv ...
when you say that the FW must be extracted ... do you mean manually or is already covered as part of the makefile?
Its obviusly not automatic, you can either pull it from a running system or just unpack the stock firmware image
oh wow we are in the idea of making the crypto firmware work. Nice!