Jump to content

raschid

Members
  • Posts

    116
  • Joined

  • Last visited

Everything posted by raschid

  1. @Igor quick fix (fix-xradio-interrupt.patch): diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts index 454408b..df356b5 100644 --- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts @@ -49,6 +49,7 @@ #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h> +#include <dt-bindings/pinctrl/sun4i-a10.h> / { model = "Xunlong Orange Pi Zero"; @@ -157,6 +158,10 @@ */ xr819: sdio_wifi@1 { reg = <1>; + compatible = "xradio,xr819"; + interrupt-parent = <&pio>; + interrupts = <6 10 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "host-wake"; }; }; performance is back up to around 10 mbit/s ... (PCB rev 1.1).
  2. @IgorThe for the performance drop seems to be a missing interrupt definition in the device tree. @geotravelI am getting the same dmesg warnings, but frequency scaling (and thermals!) work.
  3. Compiling a NEXT kernel now will give you CPU frequency scaling for the Opi Zero - up to 1200 MHz. I upgraded an existing 4.11.12 install via freshly compiled kernel-debs (dtb,header,image). Tested overlays: spi, analog-codec, ubhost2, usbhost3. Issues: the already poor WLAN performance seems to have suffered some more => RX: 3mbit/s, TX: 9mbit/s (down from 10/13 mbit/s)
  4. Thx @tkaiser, I am quite aware of DVFS/THS entries in device trees - good analysis in that separate post. BTW, any progress on DVFS for H3-boards (OPi-One/-Lite) in mainline?
  5. The H2+/H3 SoCs have tendency to reach such temperatures at prologed max loads. As simple test with sysbench at an ambient temp of 20c sees my duo reach 65c after about 8 minutes. Throttling occurs lowering cpu freq to 816k and quite effectivly reducing temp below throttling point quickly. I am currently using the nanpi provided image btw.
  6. Some iperf results A.: 1.5m from AP internal Antenna - server 20.8 Mbit/s - client 21.7 MBit/s external Antenne - server 21.5 MBit/s - client 21.8 MBit/s B.: 5m from AP internal Antenna - server 20.7 Mbit/s - client 20.3 MBit/s external Antenne - server 21.2 MBit/s - client 21.9 MBit/s The xradio_wlan driver seems to be loaded as an out-of-tree module: [ 6.402364] xradio_wlan: loading out-of-tree module taints kernel. I cannot find the out-of-tree driver code at friendlyarms github ... any ideas where to look?
  7. I received a NanoPi Duo today. Since I did not order the shield I set up for Wifi. A preliminary network performance test using speedtest-cli shows about 18 MBit/s with the on-board antenna, and 20 MBit/s with an OPiZ-Antenna (ca. 1,5 m from AP). Though not impressive, this is significantly better the OPiZ WLAN performance - despite the identical driver(and close to the numbers reported by @TarableCode). Nice little board, though ...
  8. @mikeymikeTo avoid loosing wlan0 with update/upgrade you have to freeze the kernel using the "freeze kernel" option in armbian-config. My OpiZ idles at about 35°C (in a case) with WLAN active. I assume you have version 1.4 board, right? Sorry, can't help you with the webcams.
  9. @mikeymikeTry this build ... IIRC it contains the wifi driver. https://dl.armbian.com/orangepizero/archive/Armbian_5.32_Orangepizero_Ubuntu_xenial_dev_4.11.7.7z Don't expect data rates substantially exceeding 10mbit/s.
  10. @Igor, sorry, I misspelled "patch" in my original post and I think you copy&pasted that typo when uploading the patch.
  11. the following patch fixes cpufreq for the Orange Pi Zero, Mainline 4.11.12. @mbee, to give it a try save it as e.g. "orangepi-zero-add-cpufreqscaling.patch" and place it in build/userpatches. Don't forget to freeze the kernel version in armbian-config to avoid loosing this functionality when running apdate/upgrade. This patch also fixes some temperature issues since the CPU is not fed 1.3V all the time. My OPiZ is right now idling happily at 30 deg (21 deg ambient temp). Armbianmonitor now reports the current cpu-freq. @igor, please consider to include this patch. diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts index 69b4a35..506c462 100644 --- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts @@ -50,10 +50,11 @@ #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h> #include <dt-bindings/pinctrl/sun4i-a10.h> +#include <dt-bindings/thermal/thermal.h> / { model = "Xunlong Orange Pi Zero"; - compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2-plus"; + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h3"; aliases { serial0 = &uart0; @@ -94,6 +95,77 @@ reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>; post-power-on-delay-ms = <200>; }; + + vdd_cpux: gpio-regulator { + compatible = "regulator-gpio"; + regulator-name = "vdd-cpux"; + regulator-type = "voltage"; + regulator-boot-on; + regulator-always-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1300000>; + regulator-ramp-delay = <50>; /* 4ms */ + gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>; + gpios-states = <0x1>; + states = <1100000 0x0 + 1300000 0x1>; + }; +}; + +&cpu0 { + operating-points = < + 1008000 1300000 + 816000 1100000 + 624000 1100000 + 480000 1100000 + 312000 1100000 + 240000 1100000 + 120000 1100000 + >; + #cooling-cells = <2>; + cooling-min-level = <0>; + cooling-max-level = <6>; + cpu0-supply = <&vdd_cpux>; +}; + +&cpu_thermal { + trips { + cpu_warm: cpu_warm { + temperature = <65000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu_hot: cpu_hot { + temperature = <75000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu_very_hot: cpu_very_hot { + temperature = <90000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu_crit: cpu_crit { + temperature = <105000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + + cooling-maps { + cpu_warm_limit_cpu { + trip = <&cpu_warm>; + cooling-device = <&cpu0 THERMAL_NO_LIMIT 1>; + }; + cpu_hot_limit_cpu { + trip = <&cpu_hot>; + cooling-device = <&cpu0 2 3>; + }; + cpu_very_hot_limit_cpu { + trip = <&cpu_very_hot>; + cooling-device = <&cpu0 5 THERMAL_NO_LIMIT>; + }; + }; }; &ehci0 {
  12. @mbee, mainline cpufreq scaling is still broken for the orange pi zero. Currently there is no support for DVFS in the zeros DTS (no operating points, no cpu voltage regulator def, no thermal stuff). U-boot sets cpu freq to 480MHz and that's it.
  13. Yep, driver and chip are crap and have no future - no-one argues that. Nobody - literally nobody - in this thread made any development demands: The thread starter @hpapagaj noted the absence of wlan0. @exquisitus very kindly asked a valid question about dev-status. Both got told off (and never posted again as of today - and they're not the only ones). Other users, me included, noted that the disabled driver did not compile and finally patched up a working version - before you guys did. Now the only "demand" there is, is to re-enable the driver for users uncomfortable with or unable to compile their own kernel. Of course, you can do whatever you like - but be aware that the way you guys communicate does not promote a "vibrant community". Cheers, Raschid
  14. Thank you @zador.blood.stained for clearing this up. I had been genuinly under the impression that you thought about reactivating the driver when you were asking folks to test stuff : Bit of a waste of time, right? One last request to @Igor: please update the armbian hompage regarding folks "becoming a part of our vibrant community, contribute ideas and have fun" - because it isn't, you can't and you won't. Just read this thread from top to bottom and you will see what I mean. Whoops, my stop - this is where I get of ... bye
  15. Same here. Also tested the fifteenhex-version of the driver. No luck either. This is no deal breaker for me - I fail to see significant use cases for open wifi with this device.
  16. @Bubbadid you update/upgrade before the reboot? That seems to kill wlan0 (by "upgrading" dtb and kernel) ...
  17. quick check ... iperf - as client: [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 13.4 MBytes 11.2 Mbits/sec [ 3] 10.0-20.0 sec 15.4 MBytes 12.9 Mbits/sec [ 3] 20.0-30.0 sec 15.6 MBytes 13.1 Mbits/sec [ 3] 30.0-40.0 sec 16.0 MBytes 13.4 Mbits/sec [ 3] 40.0-50.0 sec 15.2 MBytes 12.8 Mbits/sec [ 3] 50.0-60.0 sec 15.9 MBytes 13.3 Mbits/sec [ 3] 0.0-60.0 sec 91.6 MBytes 12.8 Mbits/sec ... as server: [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 10.1 MBytes 8.49 Mbits/sec [ 3] 10.0-20.0 sec 10.0 MBytes 8.39 Mbits/sec [ 3] 20.0-30.0 sec 12.1 MBytes 10.2 Mbits/sec [ 3] 30.0-40.0 sec 9.12 MBytes 7.65 Mbits/sec [ 3] 40.0-50.0 sec 11.9 MBytes 9.96 Mbits/sec [ 3] 50.0-60.0 sec 11.1 MBytes 9.33 Mbits/sec [ 3] 0.0-60.3 sec 64.5 MBytes 8.98 Mbits/sec very few "missed interrupt" errors (1 per measurement).
  18. 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.
  19. Thank you. That will certainly help people willing (and able) to compile their own kernels. I wish the rest could have access to the driver though ...
  20. 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?
  21. Sorry @kutysam, but I not think that this is possible ... unfortunately
  22. Repeated this test with a sligtly different position (still ca. 8m, 1 Wall): Testing download speed........................................ Download: 8.67 Mbit/s Testing upload speed.................................................. Upload: 5.49 Mbit/s much better and probably more realistic ... one more Test: EDIT: removed third test due to errors in the test setup, sorry.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines