• Content Count

  • Joined

  • Last visited

Everything posted by yoq

  1. I decompiled sun8i_thermal.ko, not sure what I was expecting... This is the entirety of their "fix" compared to stock armbian: https://gist.github.com/dbeinder/6c4dac8df91fb4b1b1537bafa8136065/revisions Yep, that's just a +30C offset shoved straight into the function, couldn't even be bothered with putting it into the struct for H2/H3, never mind chip detection... > "BREAKING: Our engineer has solved the incorrect temperature Report about Zero LTS boards" Good job, Xunlong, nice one
  2. Alright, I rebased my changes on karabek's repository: https://github.com/dbeinder/xradio/tree/karabek_rebase The powersave commit is now split, with the power-lowering fix in the first part, and enabling userspace control over powersave in the second. After some more direct comparison, I'm starting to think the part about removing driver-level TX rate selection doesn't make a measurable difference, in either throughput or dropped packets. But since my much simpler code doesn't seem to make it worse either, I think that was just hacks built around the CW11x0 and simply never removed.
  3. I repharsed that sentence, I was talking about WiFi powersave polling, check my github comments for more details. In the current version, it is active but somewhat broken, and in idle uses about 200mW more than it needs to. On the other hand if you switch powersave mode fully off, the XR819 uses 300mW more in idle than the current driver. My patches enable setting powersave mode from userspace with iwconfig, and so power consumption can go up quite a bit if powersave is not ON by default. OPZ idle at 816MHz, WiFi driver not loaded: 610mW Connected to WiFi network & idle/no traf
  4. I know most of you probably don't want to hear any more about this chip, but I recently fixed quite a few long standing issues. It's not perfect yet, but it improves scanning/reliable reconnect, incoming frames missed in powersave, ping times, and rate selection. Here's the patch set: https://github.com/fifteenhex/xradio/pull/12 Edit: rebased from karabek: https://github.com/dbeinder/xradio/commits/karabek_rebase And some important comments about powersave: https://github.com/fifteenhex/xradio/pull/11#issuecomment-616226880 In short, relative to the current version, with powersave
  5. On the H2 (the same is true for most modern ARM chips) there is almost no benefit to lowering the clock rate by itself if the CPU has idle periods. If the CPU is IDLE, it pretty much halts and will use the same amount of power, no matter the clock rate. The savings really come from changing the core voltage, which can be lower at low clock rates. With a proper power management controller, the voltage can be matched to the clock in many steps, but on the ZeroPi there are only 2 states: 1.1V and 1.3V. It switches to the higher voltage when the CPU is clocked higher than 816MHz, so on the OPZ
  6. Did you make sure there isn't also getty running on ttyS3?
  7. UART2 with TX/RX should work out of the box if you enable the "uart2" overlay in armbianEnv.txt. I see you also have uart3 activated, afaik this port is not routed out on a OPZ. RTS/CTS for UART2 is missing at the moment, but you can add it to the device tree manually. Create the file "uart2_rtscts_fix.dts" in your home folder: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { uart2_rts_cts: uart2_rts_cts { pins = "PA2", "PA3"; function = "uart2"; }; }; }; }; Then run this to compile and add the cu
  8. You can free up a core using isolcpus kernel parameter and then move your task on the unused core using taskset: simply set it by adding extraargs=isolcpus=1 to your /boot/armbianEnv.txt https://codywu2010.wordpress.com/2015/09/27/isolcpus-numactl-and-taskset/
  9. @nairn62 the solution in the post above yours is the easiest, and addresses the issue directly (xradio driver doesn't allow setting mac from user space) - iwd is still not quite ready
  10. I spent some time investigating this, I think it is a hardware/production issue. There is a calibration value in the eFuse, set during chip production. That value is currently not used in mainline, but in the affected hardware, it does not correct the offset anyway. In my good boards, it only caused a small change that looks reasonable. But the problematic boards are off by 20-30 degrees. I wrote a small python3 script to access the hardware directly, it will print a dump of the THS registers, interpret the raw value into a temperature with all the formulas that were published one time or
  11. I don't think I had to run anything else than the 3 lines I posted and reboot.
  12. Thanks, that turned out be a good place to look. On a hunch, I tried swapping out wpa_supplicant for iwd as the wifi daemon for NetworkManager, and that did the trick. apt install iwd systemctl disable wpa_supplicant echo -e "\n[device]\nwifi.backend=iwd\n" >> /etc/NetworkManager/NetworkManager.conf I may just stick with iwd, but the root cause is probably that the aging xradio driver is missing support for some ioctl and it may just be a matter of time until a future release of iwd will send that one too.
  13. I've done some work on kernel drivers and uboot in the past, that would not be a problem. My point is that the XR819 worked on Armbian as good as the chip allows two months ago, and now the driver doesn't even initialize properly. The fact that it stopped working on the old 4.19 kernel branch too, makes me think this is probably not a problem with kernel patches but with the system image. I'm happy to help, but I'm looking for some pointers.
  14. I did, and did not find anything relevant to this particular problem. Can you point me to it? I'm not complaining about the general unreliability of the XR819, I am well aware.
  15. Is it possible that there have been some image changes that broke the XR819 wifi completely? The available images for download on the Armbian page (5.3 server, and 5.4 minimal) as well as a custom built "legacy" branch linux-4.19 image all show the same behavior, The wlan0 interface is not active and it's not possible to bring it up. And dmesg shows that module has been initialized but not much more. Armbianmonitor support info: 5.3.9 official buster server image: http://ix.io/240Y 4.19.88 self-built, two days ago, legacy branch: http://ix.io/240U Everything below is from the offic
  16. Thanks, this turned out to be much more involved than I expected. To save the next person some time, here's what it took: Activate the uart(s) and change stdout-path in the device tree, then add CONFIG_CONS_INDEX=3 (starts from 1) in configs/orangepi_zero_defconfig: diff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts index d166ffc0..abcc1874 100644 --- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts +++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts @@ -56,13 +56,15 @@ aliases { serial0 = &uart0; + serial1 = &uart1; +
  17. I'm trying to recompile U-Boot to move the serial console on my OP Zero from uart0 to uart2. I didn't have any trouble to move the linux console, but I'm struggling with U-Boot. I tried creating a patch to change stdout-path in the device tree: https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts#L65 ff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts index d166ffc..0e2e48d 100644 --- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts +++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts @@ -55,7 +55,7 @@