Any chance you can give 6.6 a go and see if it "fixed" itself magically?
I'm on 6.6 now and will check this issue.
IPQ8074 5G radio support channels 169, 173 and 177. I'm able to start radio using HE80 htmode on 149 and 165 channel.
But HE160 htmode on channel 149 is not working:
Thu Jan 1 00:02:57 1970 daemon.notice netifd: radio0 (2864): WARNING: Variable 'data' does not exist or is not an array/object
Thu Jan 1 00:02:57 1970 daemon.notice hostapd: Set new config for phy phy0:
Thu Jan 1 00:02:57 1970 daemon.notice wpa_supplicant[2095]: Set new config for phy phy0
Thu Jan 1 00:02:58 1970 daemon.notice wpa_supplicant[2095]: Set new config for phy phy0
Thu Jan 1 00:02:58 1970 daemon.notice hostapd: Set new config for phy phy0: /var/run/hostapd-phy0.conf
Thu Jan 1 00:02:58 1970 daemon.notice hostapd: Restart interface for phy phy0
Thu Jan 1 00:02:58 1970 daemon.notice hostapd: Configuration file: data: driver=nl80211 logger_syslog=127 logger_syslog_level=2 logger_stdout=127 logger_stdout_level=2 country_code=US ieee80211d=1 ieee80211h=1 hw_mode=a beacon_int=100 chanlist=149 tx_queue_data2_burst=2.0 #num_global_macaddr=1 ieee80211n=1 ht_coex=0 ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40] ieee80211ac=1 vht_oper_chwidth=2 vht_oper_centr_freq_seg0_idx=149 vht_capab=[RXLDPC][SHORT-GI-80][SHORT-GI-160][TX-STBC-2BY1][SU-BEAMFORMER][SU-BEAMFORMEE][MU-BEAMFORMER][MU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC-1][SOUNDING-DIMENSION-4][BF-ANTENNA-4][VHT160][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7] ieee80211ax=1 he_oper_chwidth=2 he_oper_centr_freq_seg0_idx=149 he_su_beamformer=1 he_su_beamformee=1 he_mu_beamformer=1 he_bss_color=128 he_spr_sr_control=3 he_default_pe_duration=4 he_rts_threshold=1023 he_mu_edca_qos_info_param_count=0 he_mu_edca_qos_info_q_ack=0 he_mu_edca_qos_info_queue_request=0 he_mu
Thu Jan 1 00:02:58 1970 daemon.notice netifd: Wireless device 'radio0' is now up
Thu Jan 1 00:02:58 1970 kern.info kernel: [ 178.239040] br-lan: port 5(phy0-ap0) entered blocking state
Thu Jan 1 00:02:58 1970 kern.info kernel: [ 178.239083] br-lan: port 5(phy0-ap0) entered disabled state
Thu Jan 1 00:02:58 1970 kern.info kernel: [ 178.243507] ath11k c000000.wifi phy0-ap0: entered allmulticast mode
Thu Jan 1 00:02:58 1970 kern.info kernel: [ 178.249178] ath11k c000000.wifi phy0-ap0: entered promiscuous mode
Thu Jan 1 00:02:58 1970 daemon.warn hostapd: nl80211: Failed to add interface phy0-ap0 into bridge br-lan: Resource busy
Thu Jan 1 00:02:58 1970 daemon.notice hostapd: phy0-ap0: interface state UNINITIALIZED->COUNTRY_UPDATE
Thu Jan 1 00:02:58 1970 daemon.notice hostapd: phy0-ap0: interface state COUNTRY_UPDATE->HT_SCAN
Thu Jan 1 00:02:58 1970 daemon.err hostapd: Interface initialization failed
Thu Jan 1 00:02:58 1970 daemon.notice hostapd: phy0-ap0: interface state HT_SCAN->DISABLED
Thu Jan 1 00:02:58 1970 daemon.notice hostapd: phy0-ap0: AP-DISABLED
root@OpenWrt:/# iwinfo phy0 freqlist
5.180 GHz (Band: 5 GHz, Channel 36) [NO_HT40-]
5.200 GHz (Band: 5 GHz, Channel 40)
5.220 GHz (Band: 5 GHz, Channel 44)
5.240 GHz (Band: 5 GHz, Channel 48)
5.260 GHz (Band: 5 GHz, Channel 52)
5.280 GHz (Band: 5 GHz, Channel 56)
5.300 GHz (Band: 5 GHz, Channel 60)
5.320 GHz (Band: 5 GHz, Channel 64) [NO_HT40+]
5.500 GHz (Band: 5 GHz, Channel 100) [NO_HT40-]
5.520 GHz (Band: 5 GHz, Channel 104)
5.540 GHz (Band: 5 GHz, Channel 108)
5.560 GHz (Band: 5 GHz, Channel 112)
5.580 GHz (Band: 5 GHz, Channel 116)
5.600 GHz (Band: 5 GHz, Channel 120)
5.620 GHz (Band: 5 GHz, Channel 124)
5.640 GHz (Band: 5 GHz, Channel 128)
5.660 GHz (Band: 5 GHz, Channel 132)
5.680 GHz (Band: 5 GHz, Channel 136)
5.700 GHz (Band: 5 GHz, Channel 140)
5.720 GHz (Band: 5 GHz, Channel 144) [NO_HT40+]
5.745 GHz (Band: 5 GHz, Channel 149) [NO_HT40-]
5.765 GHz (Band: 5 GHz, Channel 153)
5.785 GHz (Band: 5 GHz, Channel 157)
5.805 GHz (Band: 5 GHz, Channel 161)
5.825 GHz (Band: 5 GHz, Channel 165)
5.845 GHz (Band: 5 GHz, Channel 169)
5.865 GHz (Band: 5 GHz, Channel 173)
5.885 GHz (Band: 5 GHz, Channel 177) [NO_HT40+]
Could it be something hardware related?
That error seems weird, its failling to add the interface and not even trying to bringup the AP itself
HT160 htmode is working on channels 36 and 100:
Thu Jan 1 00:19:36 1970 daemon.notice netifd: radio0 (3038): WARNING: Variable 'data' does not exist or is not an array/object
Thu Jan 1 00:19:36 1970 daemon.notice hostapd: Set new config for phy phy0:
Thu Jan 1 00:19:36 1970 daemon.notice wpa_supplicant[2095]: Set new config for phy phy0
Thu Jan 1 00:19:36 1970 daemon.notice wpa_supplicant[2095]: Set new config for phy phy0
Thu Jan 1 00:19:36 1970 daemon.notice hostapd: Set new config for phy phy0: /var/run/hostapd-phy0.conf
Thu Jan 1 00:19:36 1970 daemon.notice hostapd: Restart interface for phy phy0
Thu Jan 1 00:19:36 1970 daemon.notice hostapd: Configuration file: data: driver=nl80211 logger_syslog=127 logger_syslog_level=2 logger_stdout=127 logger_stdout_level=2 country_code=US ieee80211d=1 ieee80211h=1 hw_mode=a beacon_int=100 chanlist=100 tx_queue_data2_burst=2.0 #num_global_macaddr=1 ieee80211n=1 ht_coex=0 ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40] ieee80211ac=1 vht_oper_chwidth=2 vht_oper_centr_freq_seg0_idx=114 vht_capab=[RXLDPC][SHORT-GI-80][SHORT-GI-160][TX-STBC-2BY1][SU-BEAMFORMER][SU-BEAMFORMEE][MU-BEAMFORMER][MU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC-1][SOUNDING-DIMENSION-4][BF-ANTENNA-4][VHT160][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7] ieee80211ax=1 he_oper_chwidth=2 he_oper_centr_freq_seg0_idx=114 he_su_beamformer=1 he_su_beamformee=1 he_mu_beamformer=1 he_bss_color=128 he_spr_sr_control=3 he_default_pe_duration=4 he_rts_threshold=1023 he_mu_edca_qos_info_param_count=0 he_mu_edca_qos_info_q_ack=0 he_mu_edca_qos_info_queue_request=0 he_mu
Thu Jan 1 00:19:36 1970 kern.info kernel: [ 1176.656659] br-lan: port 5(phy0-ap0) entered blocking state
Thu Jan 1 00:19:36 1970 kern.info kernel: [ 1176.656697] br-lan: port 5(phy0-ap0) entered disabled state
Thu Jan 1 00:19:36 1970 kern.info kernel: [ 1176.661074] ath11k c000000.wifi phy0-ap0: entered allmulticast mode
Thu Jan 1 00:19:36 1970 kern.info kernel: [ 1176.666817] ath11k c000000.wifi phy0-ap0: entered promiscuous mode
Thu Jan 1 00:19:36 1970 daemon.warn hostapd: nl80211: Failed to add interface phy0-ap0 into bridge br-lan: Resource busy
Thu Jan 1 00:19:36 1970 daemon.notice hostapd: phy0-ap0: interface state UNINITIALIZED->COUNTRY_UPDATE
Thu Jan 1 00:19:36 1970 daemon.notice hostapd: phy0-ap0: interface state COUNTRY_UPDATE->HT_SCAN
Thu Jan 1 00:19:36 1970 daemon.notice netifd: Wireless device 'radio0' is now up
Thu Jan 1 00:19:37 1970 daemon.notice hostapd: phy0-ap0: interface state HT_SCAN->DFS
Thu Jan 1 00:19:37 1970 daemon.notice hostapd: phy0-ap0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
Thu Jan 1 00:20:42 1970 daemon.notice hostapd: phy0-ap0: DFS-CAC-COMPLETED success=1 freq=5500 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5570 cf2=0
Thu Jan 1 00:20:42 1970 kern.info kernel: [ 1242.162306] br-lan: port 5(phy0-ap0) entered blocking state
Thu Jan 1 00:20:42 1970 kern.info kernel: [ 1242.162356] br-lan: port 5(phy0-ap0) entered forwarding state
Thu Jan 1 00:20:42 1970 daemon.notice netifd: Network device 'phy0-ap0' link is up
Thu Jan 1 00:20:42 1970 daemon.notice netifd: bridge 'br-lan' link is up
Thu Jan 1 00:20:42 1970 daemon.notice netifd: Interface 'lan' has link connectivity
Thu Jan 1 00:20:42 1970 daemon.notice hostapd: phy0-ap0: interface state DFS->ENABLED
Thu Jan 1 00:20:42 1970 daemon.notice hostapd: phy0-ap0: AP-ENABLED
I get that, I am just pointing out that hostapd did not fail on regulatory or DFS but it failed as it was unable to add the interface to the bridge for your case with channel 149
Are you able to do the same "magic" that @Ansuel did for the CR1000A QCN9074 BDF?
Sadly no, but he just updated the regulatory info in it, you are doing the same by using the external regulatory info as it wasnt available at that time
Not really, BDF is hardly modified:
OFFSET CR1000A.bin CR1000A_mod.bin
--------------------------------------------------------------------------------
0x00000000 01 00 04 04 00 00 00 00 00 80 51 4E 18 04 00 03 |..........QN....| \ 01 00 04 04 00 00 00 00 00 80 DC BA 18 04 00 03 |................|
*
0x00000040 FE FF FF FF 00 01 00 00 00 00 00 00 00 00 00 00 |................| / 14 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 |................|
*
0x00000070 00 00 00 00 00 00 00 00 00 60 00 00 00 00 00 00 |.........`......| \ 00 00 00 00 00 00 00 00 02 60 00 00 00 00 00 00 |.........`......|
*
0x00000220 06 00 00 00 00 00 00 00 00 00 00 02 02 01 00 00 |................| / 06 00 00 00 00 00 00 00 00 00 00 04 00 02 00 00 |................|
*
0x00012DE0 00 00 00 00 00 00 00 00 13 00 04 1C 00 00 00 00 |................| \ 00 00 00 00 00 00 00 00 13 00 04 28 00 00 00 00 |...........(....|
...
These are just a few differences at the beginning of the file.
Oh, did not know that
So far I haven't noticed any reboots on kernel 6.6.
Does the bluetooth serial port need some special configuration:
root@OpenWrt:/# hciattach -s 115200 /dev/ttyMSM1 any 115200
Device setup complete
[ 609.592133] Bluetooth: hci0: command 0x1003 tx timeout
[ 609.592133] Bluetooth: hci0: Opcode 0x1003 failed: -110
?
irq and iomem_base are different:
- OEM
~ # cat /sys/class/tty/ttyMSM1/irq
24
~ # cat /sys/class/tty/ttyMSM1/iomem_base
0x78B1000
- OpenWrt
root@OpenWrt:/# cat /sys/class/tty/ttyMSM1/irq
22
root@OpenWrt:/# cat /sys/class/tty/ttyMSM1/iomem_base
0x78B4000
AQR114C is not detected on 6.6 kernel:
[ 2.673753] Aquantia AQR114C 90000.mdio-1:08: bad firmware CRC: file 0x8080 calculated 0x170e
[ 2.673804] Aquantia AQR114C 90000.mdio-1:08: firmware loading failed: -22
[ 2.685349] Aquantia AQR114C 90000.mdio-1:08: loading firmware version 'v9.9.5 WNC SAQA-L2 082721 12:00:46' from 'FS'
[ 14.024498] ssdk_phy_driver_init[372]:INFO:dev_id = 0, phy_adress = 8, phy_id = 0x0 phytype doesn't match
root@OpenWrt:/# mdio 9* mmd 8:1 3
0x1c22
Log clearly shows it is detected
Should some delay be added for the sskd driver to detect the PHY?
Oh you mean that phytype doesn't match, I have had that on Qnap 301W forever, never bothered to look into it as everything still works just fine
In my case I have:
[ 3633.133214] uniphy autoneg time out!
Can you read the MMD4 register 0xC441?
root@OpenWrt:/# mdio 9* mmd 8:4
DEVID(0x02/0x03): 0x31c31c22
DEVS(0x06/0x05): 0xe000009a
devices: +vendor2 +vendor1 +c22-ext -power-unit -ofdm -pma4 -pma3 -pma2 -pma1
+aneg -tc -dte-xs +phy-xs +pcs -wis +pma/pmd -c22
PKGID(0x0E/0x0F): 0x31c31c22
It's 0x0000 (I previously set before checking):
root@OpenWrt:/# mdio 9* mmd 8:4 0xC441
0x0000
On 6.1.81 kernel I have this log:
[ 2.868399] aquantia_phy_api_ops_init[2241]:INFO:qca probe aquantia phy driver succeeded!
[ 4.046062] regi_init[3603]:INFO:Initializing HPPE Done!!
[ 4.046186] regi_init[3662]:INFO:qca-ssdk module init succeeded!
and
root@OpenWrt:/# mdio 9* mmd 8:4 0xC441
0x0008
Yeah, it seems that SSDK is racing with the kernel since it is what is setting the USXGMII autoneg bit in 0xC441.
Honestly, its probably time for me to respin the series to add support for that in the upstream driver so we can get rid of SSDK support.
1 Like
On kernel 6.6 QCA8075 ports are working even without loading AQR firmware in u-boot. Is it because of this race condition?
There is problem with loading AQR firmware using nvmem-cells. The firmware size is not fixed. After changing the firmware to one of a different size, you need to modify the dts.
Firmware size can be read from the MBN header at positions 0x10 and 0x14:
header = [
img_type, # Type: APPSBL
0x3, # Version: 3
0x0, # Image source pointer
base, # Image destination pointer
size, # Code Size + Cert Size + Signature Size
size, # Code Size
base + size, # Destination + Code Size
0x0, # Signature Size
base + size, # Destination + Code Size + Signature Size
0x0, # Cert Size
]
Reboots also happen on kernel 6.6, but not as often.