Jump to content

Search the Community

Showing results for 'xradio'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Armbian
    • Armbian project administration
  • Community
    • Announcements
    • SBC News
    • Framework and userspace feature requests
    • Off-topic
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Standard support
    • Amlogic meson
    • Allwinner sunxi
    • Rockchip
    • Other families
  • Community maintained / Staging
    • TV boxes
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Support

Categories

  • Official giveaways
  • Community giveaways

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP/Jabber


Skype


Github


Discord


Location


Interests

  1. Same NanoPi M1, RTL8152 attached to usb1, only the USB-Ethernet connected to network, our OPi Zero image booting flawlessly (no need for udev rules IMO): http://sprunge.us/eLJP The xradio driver fails as expected and with Zero's default /etc/network/interfaces contents (none) it should be also easy to bring up RTL8189ETV if present on the board (to be confirmed). Since I don't have any devices with RTL8189ETV maybe someone else (@Igor?) can give it a try booting our Zero image on an OPi Plus and check whether nmtui just works? If that's ok, all further development efforts are two lines adding to documentation / download page.
  2. Wifi on this device is done by XR819, module name is xradio, like on Orangepi Zero. Changing link to right board config might help /boot/script.bin -> bin/orangepione.bin to bin/orangepizero.bin Performance of this chip is bad, so don't expect too much.
  3. Rev. 1.4 problems are related only to the first Zero (one with the Ethernet and Xradio wireless), Zero Plus 2 has better wireless and shouldn't have any serious overheating issues. This applies to all H2+ and H3 devices - quality of the legacy kernel is not the best, and mainline will be much more stable.
  4. Just bumped this one: Orange Pi Zero, stable version, legacy kernel Trying to insert Realtek WiFi dongle (8188eu in my case). Module cannot load - with this error: Peeked solution on 4pda - http://4pda.ru/forum/lofiversion/index.php?t750921-1740.html - decompiled script bin and set wifi_usbc_id = 1 - before it was set to none. Original solution has value "2", but it was just a guess, so I used "1". Module worked in parallel with original xradio. According to original poster on 4pda, this issue was seen on Orange Pi PC. Not sure, is it correct solution, but, well - it may help. Issues seen - when I try to unload realtek module, then modprobe back with some other parameters for powersaving or mac changing wia rtw_xxx options - original xradio gets also resetted. Issue with wifi_usbc_id does not show up, if i use ralink 2800 dongle for example. Hope it is not a duplicate topic and may help others somehow.
  5. start here... https://forum.armbian.com/index.php?/topic/3243-orange-pi-zero-wireless-module-status-xradio-st-cw1200/ the zero works fine in IoT projects, thing is some folks think a cheap 7.00 board can replace 200.00 of x86 gear. ap limit of 5 connections, weak wi-fi signal, crappy stock antenna, weak psu = failure before they start Igor did build a 4.1x image with wi-fi it is linked here
  6. Repository README: https://github.com/fifteenhex/xradio/blob/master/README.md Discussion: https://forum.armbian.com/index.php?/topic/3243-orange-pi-zero-wireless-module-status-xradio-st-cw1200/
  7. Some test result using iperf. Distance to AP ca. 5m line of sight. Zero as client: [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 17.4 MBytes 14.6 Mbits/sec [ 3] 10.0-20.0 sec 17.6 MBytes 14.8 Mbits/sec [ 3] 20.0-30.0 sec 17.4 MBytes 14.6 Mbits/sec [ 3] 30.0-40.0 sec 17.9 MBytes 15.0 Mbits/sec [ 3] 40.0-50.0 sec 16.6 MBytes 13.9 Mbits/sec [ 3] 50.0-60.0 sec 17.2 MBytes 14.5 Mbits/sec [ 3] 0.0-60.1 sec 104 MBytes 14.5 Mbits/sec Zero as server: [ 4] 0.0-61.3 sec 96.9 MBytes 13.3 Mbits/sec dmesg reports no xradio related drops/errors.
  8. Oh ! You're right ! Back in May, when I've done the job, and when we decided to remove that support, I've never committed the patch fix, it is sitting on my tree : diff lib/patch/kernel/sun8i-dev/add-xradio-wireless-driver.patch.disabled lib/patch/kernel/sun8i-dev/add-xradio-wireless-driver.patch 1902c1902 < @@ -0,0 +1,880 @@ --- > @@ -0,0 +1,884 @@ 1922a1923,1926 > +struct sched_param { > + int sched_priority; > +}; > + 1948d1951 < + struct sched_param param = { .sched_priority = 1 }; 1963a1967 > + struct sched_param param = { .sched_priority = 1 }; 12076c12080 < @@ -0,0 +1,266 @@ --- > @@ -0,0 +1,267 @@ 12092a12097 > +#include <linux/module.h> 13601c13606 < + ieee80211_cqm_rssi_notify(priv->vif, cqm_evt, --- > + ieee80211_cqm_rssi_notify(priv->vif, cqm_evt, rcpiRssi, I will probably commit it soon, but leaving it disabled ...
  9. Thank you, @martinayotte. Hmm, if I rename add-xradio-wireless-driver.patch.disabled to -xradio-wireless-driver.patch (and move it to userpatches/kernel/sun8i-dev/) I get fatal compiler errors: drivers/net/wireless/xradio/bh.c: In function ‘xradio_register_bh’: drivers/net/wireless/xradio/bh.c:46:9: error: variable ‘param’ has initializer but incomplete type struct sched_param param = { .sched_priority = 1 }; ^~~~~~~~~~~ drivers/net/wireless/xradio/bh.c:46:32: error: ‘struct sched_param’ has no member named ‘sched_priority’ struct sched_param param = { .sched_priority = 1 }; ^~~~~~~~~~~~~~ drivers/net/wireless/xradio/bh.c:46:49: warning: excess elements in struct initializer struct sched_param param = { .sched_priority = 1 }; ^ drivers/net/wireless/xradio/bh.c:46:49: note: (near initialization for ‘param’) drivers/net/wireless/xradio/bh.c:46:21: error: storage size of ‘param’ isn’t known struct sched_param param = { .sched_priority = 1 }; ^~~~~ drivers/net/wireless/xradio/bh.c:46:21: warning: unused variable ‘param’ [-Wunused-variable] scripts/Makefile.build:294: recipe for target 'drivers/net/wireless/xradio/bh.o' failed make[4]: *** [drivers/net/wireless/xradio/bh.o] Error 1 scripts/Makefile.build:553: recipe for target 'drivers/net/wireless/xradio' failed make[3]: *** [drivers/net/wireless/xradio] Error 2 scripts/Makefile.build:553: recipe for target 'drivers/net/wireless' failed make[2]: *** [drivers/net/wireless] Error 2 scripts/Makefile.build:553: recipe for target 'drivers/net' failed make[1]: *** [drivers/net] Error 2 make[1]: *** Waiting for unfinished jobs.... The diff used by the above patch appears pre 4.11. Am I missing something here?
  10. just a note, if you do a ping test to lets say 8.8.8.8, it will be VERY erratic, like 300ms, 200ms, 600ms,200ms etc. but if u do a ping test after sudo ping -s 1 -i 0.2 <orangePiWifiIp> you will see 1ms 1ms 2ms 3ms 1ms... etc. the xradio needs 'constant' connectivity to have a 'smooth' output i realize.
  11. @martinayotte Would you update the actual driver code to your build as well? It seems the driver code in the current add-xradio-wireless-driver.patch.disabled is still pre 4.11.
  12. For the changes to DTS, maybe I can look to append them directly into the add-xradio-wireless-driver.patch.disabled when I will get chance.
  13. I hope so. You could try my userpatch until he does: https://drive.google.com/file/d/0B47UwibE8mfvRXYzR0p4SGJ4Vnc/view?usp=sharing Copy it to userpatches/kernel/sun8i-dev/ Don't forget to set KERNEL_CONFIGURE="yes" and set XRADIO to manual (m).
  14. And this is possible already using the userpatches functionality. @martinayotte or anybody else can update existing xradio patch while leaving it disabled, and developers who build their own kernels will have a relatively easy way to activate it by copying or symlinking this patch and using KERNEL_CONFIGURE=yes to change the kernel config.
  15. That's great news at least this solution will be a solution from some users. The driver is crapy but at least permit transmitting wireless which is a must in some applications. I understand to not include the solution in standard images. There is , however, the option to include as an option in the build tool for those that assume the risk of this crashy driver. As far as I understood to make it work it is needed to do following steps: build with newest patches that solve (aes-arm) crashes. Use correct fifteenhex' driver compatible with 4.11. I think this can be done changing the current add-xradio-wireless-driver.patch.disabled with the correct version. Still if it is remain as disabled it could be enabled manually by the user and compile the correct version. Use XRADIO_* kernel settings to activate the configuration and compilation. By default they can be commented (unset) but the user can remove the contents and get the driver compiled installed in custom builds. Provide a suitable DTS that inform the kernel that the xr819 is present with valid params. Current build system do not do configure it. Can this be done with an overlay? If yes then it can be included in the overlay section of the build script so it get compiled and can be activated by the user in armbianEnv.txt. If this approach is possible we can find a compromise between not supporting the driver in standard images but easy for custom compilation activation. What do you think? Regards,
  16. It just fixes it barely enough to work without crashing (and fix is not related to the xradio driver, it's a kernel-wide fix) My opinion here would be "definitely no", we had enough crap about this driver and none of that was fixed (packet losses, open AP connection, virtual interfaces, P2P mode, etc.)
  17. Yes, thanks Zador to have figured out ! I've tested it on my side too, and right, it fix the xradio perfectly ! Maybe we should re-enabled it in the nightlies ?
  18. @raschid, @martinayotte I was able to compile the driver under 4.11 using this version: https://github.com/fifteenhex/xradio/commit/3f80a7c69a4d00b93bb187edc6beef2b4c38bada. Also I mokypatched the current patch in armbian/build to align the driver compiled during image build process including the XRADIO_* settings. The build is correct and the driver is loaded when booted: Linux orangepizero 4.11.5-sun8i #2 SMP Fri Jun 23 14:44:29 CEST 2017 armv7l GNU/Linux root@orangepizero:~# lsmod Module Size Used by sunxi_cir 16384 0 xradio_wlan 102400 1 sun8i_codec_analog 24576 0 mac80211 335872 1 xradio_wlan cfg80211 204800 2 mac80211,xradio_wlan still no wlan0 is available. It is possible that it has to be with associated DTS files that have been changed also. I'm trying with an overlay to properly configure it but still no success. I'm not an expert on Device-tree but it seems to be in-line with the needs to make the driver work. When loading the overlay there a msg showing that there are duplicate entries and lots of warnings in the compilation. /dts-v1/ /plugin/; / { compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus", "allwinner,sun8i-h3"; fragment@0 { target = "/aliases"; __overlay__ { ethernet1 = &xr819wifi; }; }; fragment@1 { target = "/reg_vcc_wifi"; __overlay__ { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; startup-delay-us = <70000>; }; }; fragment@2 { target = "/wifi_pwrseq"; __overlay__ { pinctrl-names = "default"; pinctrl-0 = <&wifi_rst>; }; }; fragment@3 { target = <&mmc1>; __overlay__ { vmmc-supply = <&reg_vcc3v3>; vqmmc-supply = <&reg_vcc_wifi>; /*max-frequency = <16000000>; */ /delete-node/ xr819; xr819wifi: sdio_wifi@1 { reg= <1>; compatible = "xradio,xr819"; pinctrl-names = "default"; pinctrl-0 = <&wifi_wake>; interrupt-parent = <&pio>; interrupts = <6 10 1>; interrupt-names = "host-wake"; local-mac-address = [dc 44 6d c0 ff ee]; }; }; }; fragment@4 { target = <&pio>; __overlay__ { wifi_wake: wifi_wake@0 { allwinner,pins = "PG10"; allwinner,function = "irq"; allwinner,pull= <0>; }; }; }; fragment@5 { target = <&r_pio>; __overlay__ { wifi_rst: wifi_rst@0 { allwinner,pins = "PL7"; allwinner,function = "gpio_out"; allwinner,drive = <0>; allwinner,pull = <0>; }; }; }; }; Any Idea?
  19. Thanks for the links. But i normally build my own images using lib build tools. I tried to build version 4.10 with xradio support but I cant do it with current master branch. any idea how to get the last version of build tools that will enable that. regards,
  20. I did a big mistake updating to 4.11. So called crappy Xradio has been working great for me with 4.10. Is there any possibility to undo the update?
  21. exquisitus, I don't see how jhpadjustable's reply was patronizing, prejudiced, or full of attitude. He politely said that if you want to know the history of the module (and why it's not well supported) there are other threads talking about it. I really don't see how his reply is "less useful than no reply at all" since he told you where you can find more information (something you can also do with the forum's search feature). When people here provide information to users, and then get replies like yours, it's no wonder the driver situation doesn't improve. Anyone who is working to make it better just gets people coming and being offended by their answers. If you're unhappy with the state of the XR819 driver, I have the perfect place for you to go to solve your problems: https://github.com/fifteenhex/xradio/pulls I hate to say it, I really do, but I think you need to see this: https://www.youtube.com/watch?v=F-mju_gW3c8
  22. @raschid They didn't add the latest fix https://github.com/fifteenhex/xradio/commit/3f80a7c69a4d00b93bb187edc6beef2b4c38bada
  23. I would also like to get the wireless of the Orange Pi Zero working fully. Limited bandwidth is not a problem for my use case. I'm a competent programmer, but normally try to stay away from kernel code. If this isn't too much work, I'm willing to make an exception. To know that, and also to get started, I need to know what needs to be done though. My observations so far: When the xradio module is loaded, the load average is at least 1.0. It seems to be busy waiting whenever it's not doing anything useful. Unloading the module makes the system load reasonable (near 0). The wifi interface works, but when creating other virtual interfaces (iw dev wlan0 interface add), they show up as if they're working, but no communication is possible with them (they also don't find any networks when scanning). Please let me know where I should start if I want to fix things, so I can see if it's worth my time. Thanks!
  24. OK, somewhat obvious: forgot to set CONFIG_WLAN_VENDOR_XRADIO in the kernel config-file. This time compiling the kernel failed, partly due to the face, that the current "add-xradio-wireless-driver"-patch has not been updated to the 4.11 version. Nope, I do not think it is ... (e.g. missing parameter for ieee80211_cqm_rssi_notify function etc.)
  25. Like the thread-starter I was happy with the xradio-implementation in 4.10 and would like wifi-support in 4.11. Taking the advice of jhpadjustable and tkaiser and attempted to built a 4.11 kernel enabling the xradio-related patch. The kernel works alright but there still is no wlan0. Syslog shows a failed attempt to modprobe xradio-wlan during boot and there is no xradio-module in /lib/modules/4.11.1-sun8i/net/wireless/. I am probably missing something ultra-obvious here ... can anyone help?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines