Cool. I won't be able to test until in the new year but I saw your message in the AX3600 topic that future initramfs will not have wireless to make sure the ethernet works correctly. I guess that is a nice solution since the image is only needed for the install.
Thing is that this was masked before by overriding the board-id to the "correct" one, so WLAN kind of worked but not properly.
This is a limitation of OpenWrt buildsystem as per target rootfs does not work for initramfs images.
with FW 2.7
i have an issue if i change something on the wifi config...
Fri Dec 23 21:42:24 2022 daemon.notice netifd: Network device 'phy1-ap0' link is down
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] qcom-q6v5-wcss-pil cd00000.q6v5_wcss: fatal error received:
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] QC Image Version: QC_IMAGE_VERSION_STRING=WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] Image Variant : IMAGE_VARIANT_STRING=8074.wlanfw.eval_v2Q
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160]
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] :Excep :0 Exception detectedparam0 :zero, param1 :zero, param2 :zero.
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] Thread ID : 0x00000060 Thread name : WLAN RT1 Process ID : 0
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] Register:
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] SP : 0x4bfc94c0
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] FP : 0x4bfc94d0
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] PC : 0x4b15be0c
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] SSR : 0x00000001
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] BADVA : 0x00a4973b
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] LR : 0x4b15be14
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160]
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] Stack Dump
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] from : 0x4bfc94c0
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160] to : 0x4bfc9a20
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.223160]
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.269786] remoteproc remoteproc0: crash detected in cd00000.q6v5_wcss: type fatal error
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.292008] remoteproc remoteproc0: handling crash #1 in cd00000.q6v5_wcss
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.300086] remoteproc remoteproc0: recovering cd00000.q6v5_wcss
Fri Dec 23 21:42:25 2022 kern.info kernel: [ 214.332897] remoteproc remoteproc0: stopped remote processor cd00000.q6v5_wcss
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 214.333167] ath11k c000000.wifi: failed to clear rx_filter for monitor status ring: (-108)
Fri Dec 23 21:42:25 2022 daemon.notice netifd: Wireless device 'radio1' is now down
Fri Dec 23 21:42:25 2022 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy1.conf (phy phy1-ap0) --> new PHY
Fri Dec 23 21:42:25 2022 daemon.err hostapd: Could not set interface phy1-ap0 flags (UP): Cannot send after socket shutdown
Fri Dec 23 21:42:25 2022 daemon.err hostapd: nl80211: Could not set interface 'phy1-ap0' UP
Fri Dec 23 21:42:25 2022 daemon.notice hostapd: nl80211: deinit ifname=phy1-ap0 disabled_11b_rates=0
Fri Dec 23 21:42:25 2022 daemon.err hostapd: nl80211 driver initialization failed.
Fri Dec 23 21:42:25 2022 daemon.notice hostapd: phy1-ap0: CTRL-EVENT-TERMINATING
Fri Dec 23 21:42:25 2022 daemon.err hostapd: hostapd_free_hapd_data: Interface phy1-ap0 wasn't started
Fri Dec 23 21:42:25 2022 daemon.notice hostapd: phy1-ap1: CTRL-EVENT-TERMINATING
Fri Dec 23 21:42:25 2022 daemon.err hostapd: hostapd_free_hapd_data: Interface phy1-ap1 wasn't started
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): Command failed: ubus call hostapd config_add {"iface":"phy1-ap0", "config":"/var/run/hostapd-phy1.conf"} (Invalid argument)
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): Usage: ubus [<options>] <command> [arguments...]
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): Options:
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): -s <socket>: Set the unix domain socket to connect to
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): -t <timeout>: Set the timeout (in seconds) for a command to complete
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): -S: Use simplified output (for scripts)
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): -v: More verbose output
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): -m <type>: (for monitor): include a specific message type
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): (can be used more than once)
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): -M <r|t> (for monitor): only capture received or transmitted traffic
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177):
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): Commands:
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): - list [<path>] List objects
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): - call <path> <method> [<message>] Call an object method
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): - subscribe <path> [<path>...] Subscribe to object(s) notifications
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): - listen [<path>...] Listen for events
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): - send <type> [<message>] Send an event
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): - wait_for <object> [<object>...] Wait for multiple objects to appear on ubus
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): - monitor Monitor ubus traffic
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177):
Fri Dec 23 21:42:25 2022 daemon.notice netifd: radio1 (3177): Device setup failed: HOSTAPD_START_FAILED
Fri Dec 23 21:42:25 2022 kern.warn kernel: [ 215.097881] ath11k c000000.wifi: failed to send WMI_PDEV_SET_PARAM cmd
Fri Dec 23 21:42:25 2022 kern.err kernel: [ 215.097925] ath11k c000000.wifi: failed to enable PMF QOS: (-108
Fri Dec 23 21:42:25 2022 daemon.notice netifd: Wireless device 'radio1' set retry=0
Fri Dec 23 21:42:25 2022 daemon.crit netifd: Wireless device 'radio1' setup failed, retry=0
Fri Dec 23 21:42:25 2022 daemon.notice netifd: Wireless device 'radio1' is now down
Fri Dec 23 21:42:26 2022 daemon.info dnsmasq[1]: read /etc/hosts - 4 addresses
Fri Dec 23 21:42:26 2022 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 1 addresses
Fri Dec 23 21:42:26 2022 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Fri Dec 23 21:42:27 2022 kern.warn kernel: [ 216.990768] ath11k c000000.wifi: failed to send WMI_PDEV_BSS_CHAN_INFO_REQUEST cmd
Fri Dec 23 21:42:27 2022 kern.warn kernel: [ 216.990818] ath11k c000000.wifi: failed to send pdev bss chan info request
Fri Dec 23 21:42:27 2022 kern.warn kernel: [ 216.997533] ath11k c000000.wifi: failed to send WMI_PDEV_SET_PARAM cmd
Fri Dec 23 21:42:27 2022 kern.warn kernel: [ 217.004100] ath11k c000000.wifi: Failed to set beacon mode for VDEV: 1
Fri Dec 23 21:42:27 2022 kern.warn kernel: [ 217.010644] ath11k c000000.wifi: failed to send WMI_BCN_TMPL_CMDID
Fri Dec 23 21:42:27 2022 kern.warn kernel: [ 217.017134] ath11k c000000.wifi: failed to submit beacon template command: -108
Fri Dec 23 21:42:27 2022 kern.warn kernel: [ 217.023285] ath11k c000000.wifi: failed to update bcn template: -108
Fri Dec 23 21:42:27 2022 kern.warn kernel: [ 217.030513] ath11k c000000.wifi: failed to send WMI_VDEV_SET_PARAM_CMDID
Fri Dec 23 21:42:27 2022 kern.warn kernel: [ 217.037101] ath11k c000000.wifi: failed to set BA BUFFER SIZE 256 for vdev: 1
Fri Dec 23 21:42:30 2022 kern.err kernel: [ 219.606254] qcom-q6v5-wcss-pil cd00000.q6v5_wcss: start timed out
Fri Dec 23 21:42:30 2022 kern.err kernel: [ 219.606304] remoteproc remoteproc0: can't start rproc cd00000.q6v5_wcss: -110
Fri Dec 23 21:42:33 2022 kern.warn kernel: [ 223.046111] ath11k_warn: 86 callbacks suppressed
Fri Dec 23 21:42:33 2022 kern.warn kernel: [ 223.046129] ath11k c000000.wifi: failed to send WMI_PDEV_BSS_CHAN_INFO_REQUEST cmd
Fri Dec 23 21:42:33 2022 kern.warn kernel: [ 223.049859] ath11k c000000.wifi: failed to send pdev bss chan info request
Fri Dec 23 21:42:33 2022 kern.warn kernel: [ 223.057484] ath11k c000000.wifi: failed to send WMI_PDEV_SET_PARAM cmd
Fri Dec 23 21:42:33 2022 kern.warn kernel: [ 223.064054] ath11k c000000.wifi: Failed to set beacon mode for VDEV: 1
but if i reboot
it works again...
So we can have per device rootfs, but only a single initramfs for the target (or subtarget)?
Yes, if building for multiple devices then DEVICE_PACKAGES are not respected.
Cause, in order to respect them you would have to regenerate the CPIO archive per board and rebuild the kernel per board.
1 Like
How to properly modify @clayface script to load uImage from flash drive, instead of tftp boot attempt? (As it's seems like tftp boot is not reliable).
During my tests I was only able to run TFTP after getting into the U-Boot shell because without it the network is not initialized.
Getting into the U-Boot shell requires serial access, which I don't consider a user-friendly solution.
A simple solution would be to modify the "setup" variable on @clayface script so it runs something different than "tftprecover".
Here is an alternative that loads the initramfs image from USB.
The "tftprecover" variable is directly flashing a factory image to flash, whether this simple modification just loads an initramfs image and then you would have set the appropriated variables from OpenWrt for the next boot.
Please note that:
- I have not tested it, so you better have a way to get serial access if you want to try it.
- If I understand @clayface script correctly, it's only considering one out of the two scenarios related to current OEM slots
Original:
fw_setenv setup 'if test $active = 0; then ubi part fs;' \
'elif test $active = 1; then ubi part fs_1;' \
'else run tftprecover; fi'
Modified:
fw_setenv usbinitramfs 'usb start && fatload usb 0:1 0x44000000 openwrt-ipq807x-generic-dynalink_dl-wrx36-initramfs-uImage.itb && bootm 0x44000000'
fw_setenv setup 'if test $active = 0; then ubi part fs;' \
'elif test $active = 1; then ubi part fs_1;' \
'else run usbinitramfs; fi'
Just to make sure - but I have to run sysupgrade (or flash image to nand some other way?) before setting variables, right? Besides that, which specific variables I have to set?
I probably will order hardware next week, so I can not brick it just yet 
Sorry for probably stupid questions above - although I am not afraid to use serial console (if it's will be necessary to proceed) I just hope to get it done without opening up the case.
If you have serial access, I think the current safest way it to follow the instructions from the commit on @robimarko repo, which supports single-slot for the time being.
That should enable sysupgrade to the same slot until something else is developed and tested.
Opening the case is not hard at all, just 4 screws.
The challenging part is probably the connector.
I have not tested the script from @clayface to support multi-slot and recovery from TFTP (it might miss some scenarios).
I'm not fully sure what are the steps to flash OpenWrt with this approach, and they might change with the "usbinitramfs" I gave as an example on my previous post.
I'm trying to develop something similar, that ideally won't require serial access, but it needs review, changes, and more testing before recommending it.
Oh, it's seems like I missed that @clayface script not only flash OpenWRT but also implement additional features, so for simple loading uImage from flash drive something much simpler should be sufficient?
If loading uImage from flash drive works out, following sequence should flash OpenWRT (and enable sysupgrade for future updates) even without serial access, right? Theoretically speaking, at least.
cat /proc/mtd
ubiformat /dev/mtdXY -y -f /path_to/factory_image
fw_setenv bootcmd "setenv bootargs console=ttyMSM0,115200n8 ubi.mtd=rootfs root=mtd:rootfs rootfstype=squashfs rootwait; ubi part fs; ubi read 0x44000000 kernel; bootm 0x44000000#config@rt5010w-d350-rev0"
(I replaced partition number with XY intentionally.)
Yes, that script has more features.
You also need to set mtdids and mtdparts.
Give me a couple of days to test a method that should install to a single-partition (same as current commit).
Note: I'm also working on multi-partition support with recovery, but that requires more developent.
2 Likes
I wanted to share some simple tests I just run out of curiosity.
Everything looks good.
I have 500/100 Mbits and I'm also running these:
https-dns-proxy
addblock
statistics with additional cpufreq and thermal (5 sec. collection)
htop
There is also one wifi user that I didn't disconnect to run the tests.
Also I enabled this:
But not this:
Running speedtest-netperf.sh -H netperf-eu.bufferbloat.net:
root@D1:~# speedtest-netperf.sh -H netperf-eu.bufferbloat.net
2022-12-28 15:20:09 Starting speedtest for 60 seconds per transfer session.
Measure speed to netperf-eu.bufferbloat.net (IPv4) while pinging gstatic.com.
Download and upload sessions are sequential, each with 5 simultaneous streams.
.............................................................
Download: 484.38 Mbps
Latency: [in msec, 61 pings, 0.00% packet loss]
Min: 13.712
10pct: 14.079
Median: 14.560
Avg: 16.239
90pct: 19.908
Max: 22.943
CPU Load: [in % busy (avg +/- std dev) @ avg frequency, 57 samples]
cpu0: 43.5 +/- 1.7 @ 1410 MHz
cpu1: 13.8 +/- 2.3 @ 1552 MHz
cpu2: 13.7 +/- 2.4 @ 1467 MHz
cpu3: 12.9 +/- 2.8 @ 1509 MHz
Overhead: [in % used of total CPU available]
netperf: 11.9
...............................................................
Upload: 102.52 Mbps
Latency: [in msec, 62 pings, 0.00% packet loss]
Min: 13.626
10pct: 13.843
Median: 14.877
Avg: 16.379
90pct: 20.144
Max: 21.683
CPU Load: [in % busy (avg +/- std dev) @ avg frequency, 59 samples]
cpu0: 10.3 +/- 3.1 @ 1422 MHz
cpu1: 1.7 +/- 1.2 @ 1538 MHz
cpu2: 1.4 +/- 1.1 @ 1422 MHz
cpu3: 2.0 +/- 1.2 @ 1498 MHz
Overhead: [in % used of total CPU available]
netperf: 0.9
root@D1:~# ping gstatic.com
PING gstatic.com (142.250.178.163): 56 data bytes
64 bytes from 142.250.178.163: seq=0 ttl=61 time=14.253 ms
64 bytes from 142.250.178.163: seq=1 ttl=61 time=14.657 ms
64 bytes from 142.250.178.163: seq=2 ttl=61 time=14.734 ms
64 bytes from 142.250.178.163: seq=3 ttl=61 time=14.835 ms
64 bytes from 142.250.178.163: seq=4 ttl=61 time=14.676 ms
64 bytes from 142.250.178.163: seq=5 ttl=61 time=14.796 ms
64 bytes from 142.250.178.163: seq=6 ttl=61 time=15.126 ms
^C
--- gstatic.com ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 14.253/14.725/15.126 ms
root@D1:~#
Load observed during test:
Max spike observed:
Latency results are specif to my ISP and location, but CPU load is related to my max 500/100 speed and to the router CPU and configuration. Max router freq. is 2.2Ghz, but it was running at 1Ghz with only 2 or 3 occasional spikes at 1.3Ghz and 1.6Ghz.
There's also the load from netperf running inside the router.
Max. cpu load and freq. observed during test:
-> How Packet Steering and Software flow offloading affects CPU load (during a 520Mbits speedtest):
-
Packet Steering: OFF; Software flow offloading: OFF
(also 3 spikes to 1.3Ghz) -
Packet Steering: ON; Software flow offloading: OFF
(In a few other runs, there was a worst load distribution, with one core upto 70%, but same freq.) -
Packet Steering: OFF; Software flow offloading: ON
(In a few other runs, one core went upto 63%, but same freq.) -
Packet Steering: ON; Software flow offloading: ON
2 Likes
After several tests I was able to come up with a process to install OpenWrt from OEM SSH (without serial access).
I split the instructions into booting initramfs (serial or OEM SSH), and installing from initramfs.
@RussianNeuroMancer, please try it once your device arrives. I tested it with both OEM slots, so it should be safe.
@robimarko, can the instructions on commit "ipq807x: add Dynalink DL-WRX36" from your repo include this instead?
They are just instructions (no code change required).
I still plan to work on multi-partition support, but we can review that part later.
Instructions are:
[rest of the commit message]
...
Notes:
- Serial is completely deactivated in the stock firmware image.
- This commit adds only single partition support, that means
sysupgrade is upgrading the current rootfs partition.
- Installation can be done by serial connection or
SSH access on OEM firmware
Installation Instructions:
Most part of the installation is performed from an initramfs image
running OpenWrt, and there are two options to boot it.
Boot initramfs option 1: Using serial connection (3.3V)
1. Stop auto boot to get to U-boot shell
2. Transfer initramfs image to device
(openwrt-ipq807x-generic-dynalink_dl-wrx36-initramfs-uImage.itb)
Tested using TFTP and a FAT-formatted USB flash drive.
3. Boot the initramfs image
# bootm
Boot initramfs option 2: From SSH access on OEM firmware
1. Copy the initramfs image to a FAT-formatted flash drive
(tested on single-partition drive) and connect it to device USB port.
2. Change boot command so it loads the initramfs image on next boot
Fallback to OEM firmware is provided.
# fw_setenv bootcmd 'usb start && fatload usb 0:1 0x44000000 openwrt-ipq807x-generic-dynalink_dl-wrx36-initramfs-uImage.itb && bootm 0x44000000; bootipq'
3. Reboot the device to boot the initramfs
# reboot
Install OpenWrt from initramfs image:
1. Use SCP (or other way) to transfer OpenWrt factory image
2. Connect to device using SSH (on a LAN port)
3. Check MTD partition table.
rootfs and rootfs_1 should be mtd18 and mtd20
depending on current OEM slot.
# cat /proc/mtd
4. Do a ubiformat to both rootfs partitions:
# ubiformat /dev/mtd18 -y -f /path_to/factory_image
# ubiformat /dev/mtd20 -y -f /path_to/factory_image
5. Set U-boot env variable: mtdids
# fw_setenv mtdids 'nand0=nand0'
6. Get offset of mtd18 to determine current OEM slot
- If current OEM slot is 1, offset is 16777216 (0x1000000)
- If current OEM slot is 2, offset is 127926272 (0x7a00000)
# cat /sys/class/mtd/mtd18/offset
7. Set U-boot env variable: mtdparts
If current OEM slot is 1, run:
# fw_setenv mtdparts 'mtdparts=nand0:0x6100000@0x1000000(fs),0x6100000@0x7a00000(fs_1)'
If current OEM slot is 2, run:
# fw_setenv mtdparts 'mtdparts=nand0:0x6100000@0x7a00000(fs),0x6100000@0x1000000(fs_1)'
8. Set U-boot env variable: bootcmd
# fw_setenv bootcmd 'setenv bootargs console=ttyMSM0,115200n8 ubi.mtd=rootfs rootfstype=squashfs rootwait; ubi part fs; ubi read 0x44000000 kernel; bootm 0x44000000#config@rt5010w-d350-rev0'
9. Reboot the device
# reboot
12 Likes
Sure, it looks like you put in quite a lot of work, so why not add non UART ones as well
I got OpenWrt installed following these instructions (+ following Dynalink DL-WRX36 Askey RT5010W IPQ8074 OpenWrt support - #365 by luaraneda first to enable SSH). Thanks a lot to you, @robimarko, @lmore377 and others who spent time to get it working. Hoping to see it mainline at some point.
1 Like
Finally remembered to replace the Dynalink instructions with yours.
1 Like
@luaraneda
Thank you so much for the ssh (stock firmware) and openwrt install instructions. There were some minor issues I faced that I was able to overcome.
- SSH in the stock firmware seems to use some older algorithm. The ssh utility in my Arch Linux x86_64 system initially refused to connect to it.
% pacman -Qi openssh
Name : openssh
Version : 9.1p1-3
% pacman -Qi openssl
Name : openssl
Version : 3.0.7-4
% ssh -V
OpenSSH_9.1p1, OpenSSL 3.0.7 1 Nov 2022
I had to add the following to ~/.ssh/config to connect to the DL-WRX36.
Host 192.168.216.1
User admin
PubkeyAcceptedAlgorithms +ssh-rsa
HostkeyAlgorithms +ssh-rsa
- After loading OpenWrt Initramfs image, I again faced some issue trying to scp the factory.ubi image. SCP man page has the following text "Since OpenSSH 9.0, scp has used the SFTP protocol for transfers by default". I had to pass the "-O" parameter to scp to make it use the older SCP protocol.
scp -O openwrt-ipq807x-generic-dynalink_dl-wrx36-squashfs-factory.ubi root@192.168.1.1:/tmp/
1 Like
@robimarko Thank you for providing the OpenWrt images for DL-WRX36. I followed @luaraneda's instructions and I was able to flash (tag https://github.com/robimarko/openwrt/releases/tag/ipq807x-2022-12-28-2350)
and then
Everything seemed to work fine. I later replaced the IPQ8074 firmware in the image with the latest from kvalo's ath11k-firmware github repo
and
and then rebooted. Now, the DL-WRX36 turns ON but neither LAN ports nor WiFI SSID seem to work. WiFi, I can understand, may be the IPQ8074 firmware 2.7.0.1 might have issues. But why do the LAN ports not work?
I am back to using my Belkin RT3200 for now.
Because you replaced the board-2.bin, dont replace it and it will work
1 Like
Will pressing "reset" button for 30 seconds clear the changes (basically resetting back to factory.ubi squashfs) and bring back the DL-WRX36?