Search the Community

Description Moving use of dbeinder's repo to fifteenhex repo for xradio driver as fifteenhex seems to give more consistent speeds. This also allows us to drop all of our xradio patches as we can now build right from fifteenhex code. How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [X] Test wifi on Orange Pi Zero Checklist: [X] My code follows the style guidelines of this project [X] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [X] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description Bumped legacy, current and edge kernel. Legacy - 5.15.127 -> 5.15.130 Current - 6.1.47 -> 6.1.51 Edge - 6.5 -> 6.5.1 Fixed compilation of xradio and as its working fine, disabled cw1200 driver that I added for edge last week. Refreshed kernel configs. Also uwe5622 patches needed for orange pi 3 lts were not being applied as least kernel version was set to 6.0. Moved it back to 5.15. Not sure if it works though will test next week once I receive my orangepi 3 lts. Also for edge kernel, enabled rtw88 based drivers and disabled their corresponding legacy counterparts. How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [X] Tested all images on NanoPi Duo2 (sun8i H3) [X] Tested all images on Orange Pi Prime (sun50i H5) [X] Tested xradio drivers on Orange Pi Zero Checklist: [ ] My code follows the style guidelines of this project [X] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [X] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description Enabling wireless driver found on many Orange Pi boards. Jira reference number AR-1486 How Has This Been Tested? [ ] Test wireless connection Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Description The current xradio patch causes the wifi mac address to randomize after every reboot on kernel 5.13+ Modified it to use the updated of_get_mac_address function on kernel 5.13+ and get a stable mac address How Has This Been Tested? Tested patch with 5.15.85 kernel on 3 aw-h6-tv boards. The wifi mac address is now stable/unique and not randomized after every reboot Checklist: [X] My code follows the style guidelines of this project [X] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [X] My changes generate no new warnings [X] Any dependent changes have been merged and published in downstream modules View the full article

Description switched to most recent upstream source fixed wrong header location For 5.19.y and up there is a lot more work, so this will wait for someone else. Jira reference number AR-1316 How Has This Been Tested? [x] Build sunxi and sunxi64 CURRENT Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Hi all, I have a few orange pi zero's and recently on 2 I had an issue with wifi AP that I am trying to properly understand. I have read some of the discussion regarding the wifi chip on the opi0 and that's not a great chip. I thoroughly agree with people that say that if you pay bottom dollar for a board, don't expect top dollar performance. And especially don't come complaining on a public FOSS forum. The only thing I am trying to do is understand the error and see if there is anything I can do to improve it. I use my orange pi zero's with a basic (custom) armbian image that starts up with a wifi AP briefly, so I can ssh in and do some config. Afterwards I reboot it and either turn wifi off altogether, or just connect as a wifi client using wpa_supplicant/ `/etc/network/interfaces.d`. So no heavy wifi AP usage. This has been working fine so far, but with 2 recent boards I couldn't connect to the wifi, and upon inspection of the logs, it showed these errors: [ 21.667120] random: crng init done [ 21.667157] random: 7 urandom warning(s) missed due to ratelimiting [ 21.692073] xradio AP-WRN: ap restarting! [ 21.731438] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 33.782692] vcc3v0: disabling [ 33.782721] vcc5v0: disabling [ 56.852083] xradio TXRX-WRN: received frame has no key status [ 56.852107] xradio TXRX-WRN: dropped received frame [ 56.852208] xradio TXRX-WRN: received frame has no key status [ 56.852218] xradio TXRX-WRN: dropped received frame [ 56.855392] xradio TXRX-WRN: received frame has no key status [ 56.855413] xradio TXRX-WRN: dropped received frame [ 56.861510] xradio TXRX-WRN: ***skb_queue_tail [ 56.973724] xradio TXRX-WRN: ***skb_queue_tail [ 57.028068] xradio TXRX-WRN: ***skb_queue_tail [ 57.040336] xradio TXRX-WRN: ***skb_queue_tail [ 57.042775] xradio TXRX-WRN: received frame has no key status [ 57.042789] xradio TXRX-WRN: dropped received frame [ 57.198022] xradio TXRX-WRN: ***skb_queue_tail [ 57.198644] xradio TXRX-WRN: received frame has no key status [ 57.198669] xradio TXRX-WRN: dropped received frame [ 57.198740] xradio TXRX-WRN: received frame has no key status [ 57.198752] xradio TXRX-WRN: dropped received frame [ 57.199236] xradio TXRX-WRN: received frame has no key status [ 57.199249] xradio TXRX-WRN: dropped received frame [ 57.199662] xradio TXRX-WRN: received frame has no key status [ 57.199672] xradio TXRX-WRN: dropped received frame [ 57.273269] xradio TXRX-WRN: ***skb_queue_tail [ 57.398636] xradio TXRX-WRN: ***skb_queue_tail Can anybody explain what these errors actually mean? Is this indicative of an actual hardware error on the board? Or could it be caused by something else? I did update my base image recently (using the same `customize_image.sh`), or could it be something locally on my wifi that can cause these errors? ---- EDIT ---- After diving into the driver source (well, at least one of the versions), I found this piece of code that seems to trigger the message: void xradio_rx_cb(struct xradio_vif *priv, struct wsm_rx *arg, struct sk_buff **skb_p) { . . . . . . . if (unlikely(early_data)) { spin_lock_bh(&priv->ps_state_lock); /* Double-check status with lock held */ if (entry->status == XRADIO_LINK_SOFT) { skb_queue_tail(&entry->rx_queue, skb); dev_warn(priv->hw_priv->pdev, "***skb_queue_tail\n"); } else ieee80211_rx_irqsafe(priv->hw, skb); spin_unlock_bh(&priv->ps_state_lock); } else { ieee80211_rx_irqsafe(priv->hw, skb); } *skb_p = NULL; I am not very familiar with the linux networking drivers/stack, but from what I understand, a wifi frame comes in over a socket, causing the rx callback to be called, which does a bunch of stuff, ending with checking some status (on the wifi chip? or on the frame?) concludes that the status is XRADIO_LINK_SOFT, which I guess means it isn't able to do something, and queues the frame back on the receive socket buffer/queue (and warns about it)? So does anyone know what that status means? And if there is anything that could cause it? Cheers, Dolf.

If somebody has a chance to test new firmware blob for XR819 feedback would be appreciated Simply grab the code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } fw_xr819.bin from the PR below, replace your current one and reboot. Check if Wi-Fi still works as expected or ideally even better. The file is located here: code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } /usr/lib/firmware/xr819/ https://github.com/armbian/firmware/commit/aff348fa9eef0fcc97d4f2bb7304f0862baffc20 If in doubt create a backup of your current firmware bin.

Hi everyone, I was doing speed tests on the XR819 and started looking at the driver code. My this looks very similar to the cw1200 driver already in mainline Linux. I started modifying the cw1200 driver to try and get it to work with the XR819. Apart from someone renaming functions and adding a bunch of important junk for XR819, the drivers are quite similar. I've modified the cw1200 driver up to the point that it's loading the boot_cw1x60.bin ( boot_xr819.bin ) file, but for some reason the bootloader is returning an error instead of success. I don't think it's possible to diagnose this without the datasheet from ST. Clearly this exists, because people were able to write the cw1200 driver for mainline. Does anyone have a clue where I might find the datasheet for the CW1100? I also haven't been able to find the firmware files from ST for this chip. They don't exist in the linux-firmware tree! Here's my progress thus far: Try to load cw1200_wlan_sdio first time. Timeout waiting for bootloader to respond (I think XR819 has the same bug, no?) Unload the module and load it again: Here's my diff to the mainline driver.