Is it worth testing 2.9.0.1-01837 over 23.05.0-rc2 or is the new fw incompatible?
23.05.0-rc2 is running 2.9.0.1-01385.
There are two known flaws:
Hangs every once in a while with:
qcom-q6v5-wcss-pil cd00000.q6v5_wcss: fatal error received:
QC Image Version: QC_IMAGE_VERSION_STRING=WLAN.HK.2.9.0.1-01385-QCAHKSWPL_SILICONZ-1
Image Variant : IMAGE_VARIANT_STRING=8074.wlanfw.eval_v2Q
wal_peer_control.c:2870 Assertion is_graceful_to_handle failedparam0 :zero, param1 :zero, param2 :zero.
Thread ID : 0x00000069 Thread name : WLAN RT0 Process ID : 0
Register:
SP : 0x4bfb9230
FP : 0x4bfb9238
PC : 0x4b1080c4
SSR : 0x00000008
BADVA : 0x00020000
LR : 0x4b107860
Stack Dump
from : 0x4bfb9230
to : 0x4bfb9aa8
remoteproc remoteproc0: crash detected in cd00000.q6v5_wcss: type fatal error
remoteproc remoteproc0: handling crash #1 in cd00000.q6v5_wcss
remoteproc remoteproc0: recovering cd00000.q6v5_wcss
remoteproc remoteproc0: stopped remote processor cd00000.q6v5_wcss
At this point, WiFi is completely wedged and a reboot is needed (wifi restart fails, removing the ath11k module hangs).
(I have a service that listens to logd and issues a reboot whenever this situation occurs, ask me for it).
Sending a WoL (Wake-on-LAN) packet hangs the device for a couple of minutes (ether-wake <mac-address> issued from a Linux box connected to the device) but it eventually recovers. The radio over which the WoL was sent seems stuck.
I think so, from their text descriptions, it looks like the last 2.9.0.1-01837 is the release and the others were engineering drops.
Only testing it will tell if it works well.
Here I had no crashes with the previous 2.9.0.1-01385, neither with the latest 2.9.0.1-01837.
No issues so far, but I didn't had any before.
I'll try WoL from wifi to LAN, WoL works well here.
Wifi FW is inside /lib/firmware/IPQ8074, but take care, if you mess the wrong files or if the changed files makes the router restart into a boot loop, crash or lose eth connection, you'll need serial access to recover.
If you prefer wait until the devs. decide if it's worth releasing.
Anything you change/ replace in the filesystem (such as under /lib/firmware/) can be fixed by a factory reset (in other words, invoking firstboot or keeping the reset button pressed for >5s on the fully booted device), none of that will brick the device (serial access should not be required).
The original files are inside the read-only squashfs, replacing them at runtime will only modify the overlay (which gets removed during the reset) - the overlay only shadows them.
Yes, it's working well here, it's in my previous post.
The advise is generic, I had situations in the past where replacing files made a fatal error and somehow disabled eth, so I always rename the original files or folder, so I can use serial console and rename them back if things go wrong.
This router can easily be recovered if you have used hnymans instructions to set the bootcmd:
In that case just plug in the USB stick with the initramfs, my notes how I do that:
Power down
Insert USB stick with the fat/fat32 partition with the initramfs on it
IMPORTANT: older initramfs was named:
openwrt-ipq807x-generic-dynalink_dl-wrx36-initramfs-uImage.itb
Newer builds can be found in the qualcommax directory and are renamed to:
openwrt-qualcommax-ipq807x-dynalink_dl-wrx36-initramfs-uImage.itb
Make sure to rename the qualcommax initramfs file otherwise it will not be found by the old bootcmd.
Power Up and wait about two minutes
After the initramfs is loaded the router has an IP address of 192.168.1.1
There is no LuCi, SSH into the router. The default OpenWRT log in name is root and there is no password
If it crashes during a test I'm doing, I also want to see what went wrong.
I have put an outside of the box serial connector in some of my routers for this.
