Upstream DTS uses 0x40300000 as the base while QSDK uses 0x48000000
So we are talking about a rather big difference
We should check if that space is used by something else
But I have no idea how?
PCI controller seems to be the only thing in 0x40000000 range
QSDK DTS doesn't have anything in the 0x5x* range at all so its maybe possible that is 256M.
Cause the memory ends at 0x58000000 and there is nothing in between in the DTS
root@AX6:~# cat /etc/fw_env.config
/dev/mtd6 0x0 0x10000 0x20000
1 Like
I mean the only reason could be that
- They want to leave some space for I/O and they offset everything to 0x48000000 (on the linux version the mem part starts right after i/o
- They found some hardware bug and it's required tons of space between the 2 space
- They use some hack / proprietary driver that use that space and skip any memory check
Considering only 16M is needed we can also consider increasing the space to something like 32M and keep that way. Don't honestly know the disadvantage of enlarging the bar. Probably more reserved ram for the mapping?
The thing is that it's not in the RAM range at all, RAM starts at 0x80000000 on IPQ40xx.
But they had to move the base as the counter is at 0x004a1000
uhm...
I just flashed with firmware build from latest IPQ-backports checkout, and found there is no wifi interfaces.
I looked in dmesg and found this:
root@OpenWrt:~# dmesg | grep ath
[ 12.858763] ath11k c000000.wifi: ipq8074 hw2.0
[ 14.059296] ath11k c000000.wifi: qmi ignore invalid mem req type 3
[ 14.065025] ath11k c000000.wifi: chip_id 0x0 chip_family 0x0 board_id 0x292 soc_id 0xffffffff
[ 14.077294] ath11k c000000.wifi: fw_version 0x250704a5 fw_build_timestamp 2021-09-14 06:19 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HK.2.5.0.1-01192-QCAHKSWPL_SILICONZ-1
[ 14.107538] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=658,variant=Xiaomi-AX3600 from ath11k/IPQ8074/hw2.0/board-2.bin
[ 14.148781] ath11k c000000.wifi: failed to fetch board-2.bin or board.bin from IPQ8074/hw2.0
[ 14.148825] ath11k c000000.wifi: failed to load board file: -12
[ 14.156452] ath11k c000000.wifi: failed to load board data file: -12
Then I looked in /lib/firmware/IPQ8074/ and there was really no hw2.0 directory.
Instead I found it laying inside /lib/firmware/ath11k/IPQ8074/.
Okay, I symlinked it, and performed rmmod ath11k_ahb && rmmod ath11k && modprobe ath11k && modprobe ath11k_ahb. And...
Still no wifi...
I looked in dmesg again and found this:
[ 499.729489] ath11k c000000.wifi: ipq8074 hw2.0
[ 505.059530] ath11k c000000.wifi: failed to boot the remote processor Q6
[ 505.066555] ath11k c000000.wifi: failed to power up :-110
[ 505.090374] ath11k c000000.wifi: failed to create soc core: -110
[ 505.090401] ath11k c000000.wifi: failed to init core: -110
[ 505.095653] ath11k: probe of c000000.wifi failed with error -110
Now, it is over my competention to understand what's wrong...
I really don't understand how are you building the images at all as you are missing most of the packages etc.
Actually, I'm not sure that it is something like missing package.
ath11k-firmware is really installing files to /lib/firmware/IPQ8074/. and ath11k-board to /lib/firmware/ath11k/IPQ8074.
And both of them are installed in the image.
And I have no idea, why on the earth module tries to load from the path that miss /ath11k/
And anyway, I think, that is not a main problem (at least, content of second backtrace doesn't look like related to missing packages).
I'm probably forgetting things but... I thought those rangers where mapped to the HW (DMA or pre defined buffer where pcie HW is knows to write to ?) And are unchangeable without FW / BL changes ?
except when they are not allocated fully. In that case someone can simply extend the range
Oh, I searched the topic, and found messages, that it doesn't want to load FW after fails.
EDIT1: Although, anyway, even reboot doesn't make it to load
EDIT2: Looks like it tries to load firmware before overlay is mounted, that's why symlinking/copying it at proper path doesn't help on reboot.
Although, I still can't understand, how it is working for, say, @dchard, as he reported that he tested the wifi on fresh FW
EDIT3: and I looked in the rootfs of FW from /releases, and it also has fw files lying on the same paths as here... Why don't ath11k driver fails to load board2.bin then?...
Ahh, have you included the ipq-wifi-* for ax3600?
I assume not since it cant find that variant as it doesn't exist in the generic BDF
If it's backed just by some kind of memory then you can pretty much do whatever you want.
@Ansuel Somehow the stupid card works now after more shit getting backported.
Though it did throw a nice ASPM error:
[ 24.816626] ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0xb board_id 0xff soc_id 0xffffffff
[ 24.816691] ath11k_pci 0000:01:00.0: fw_version 0x101c06cc fw_build_timestamp 2020-06-24 19:50 fw_build_id
[ 24.996377] ath11k_pci 0000:01:00.0: leaving PCI ASPM disabled to avoid MHI M2 problems
[ 25.167189] pcieport 0000:00:00.0: AER: Multiple Corrected error received: 0000:00:00.0
[ 25.167275] pcieport 0000:00:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
[ 25.174126] pcieport 0000:00:00.0: device [17cb:1001] error status/mask=00000001/00006000
[ 25.183826] pcieport 0000:00:00.0: [ 0] RxErr (First)
finally some progress
Yeah, trust me PCI has been harder then the AHB version which makes no sense.
@dchard IPQ4019 is really CPU bottlenecked in AP mode with ath11k, it hits core at 90+% during iperf3, so its a good example to see if TX/RX decap offloading works.
2 Likes
btw, is it worth to select ath10k-firmware-qca9887-ct-full-htt (instead of "default" non-htt) in not-so-busy[1] network (about 7-10 WiFi-devices at max)?
[1] as it's decription says "improves stability in busy networks" 
Also, I confirm bug someone reported above: after doing sysupgrade FW starts using tmpfs in /tmp/root as overlay (and don't even mount ubi partition to /overlay), so every changes (configuration, installation, whatever) became not persistent (disappears after reboot).
I tried to investigate it a bit (by lurking over sources, starting in package/base-files), but not yet found a source of the problem.
To be continued tomorrow.
Well, looks like sysupgrade by itself may even be not guilty.
Here is the actual problem:
[ 7.990347] kmodloader: done loading kernel modules from //etc/modules-boot.d/*
[ 8.330078] UBIFS error (ubi0:2 pid 790): ubifs_mount: too few LEBs (12), min. is 17
[ 8.331437] UBIFS error (ubi0:2 pid 788): ubifs_mount: too few LEBs (12), min. is 17
[ 8.337179] mount_root: failed to mount -t ubifs /dev/ubi0_2 /tmp/overlay: Invalid argument
[ 8.562726] UBIFS error (ubi0:2 pid 795): ubifs_mount: too few LEBs (12), min. is 17
[ 8.563534] mount_root: unable to set filesystem state
[ 8.569603] mount_root: switching to ubifs overlay
[ 8.574538] mount_root: switching to ubifs failed - fallback to ramoverlay
As per ubifs faq, this error (too few LEBs) means that "mounting volume is too small".
But it shouln't be
Somewhy there is not even /dev/ubiblock0_2 getting created (while ..._1, which is used for mounting /rom perfectly there)...
My though was that rootfs partition somehow overlapped with overlay one, but
- I really not sure that it is possible at all,
- it's size was <30M, while there is 35M reserved for rootfs partition, so that also make it unlikely.
EDIT: Oh, I got it!
Looks like default behaviour is that /overlay is getting created from remaining space on the same rootfs MTD partition, and special MTD partition named overlay is not used at all...
1 Like
It works as I can manage to build my own images, like most of the guys here. And the ones who dont, can always use the pre-built images. 
@robimarko soon I will get the 160MHz AX card, lets see what can we squeeze out then.
Well, actually "build own images" is not a nuclear physics nor quantum mechanics.
Just I fell victim of my own laziness (but thanks to Robi, I managed to make it work [almost] as expected).
Now, it remains to deal with broken overlay issue 