jimg

Members
  • Content Count

    35
  • Joined

  • Last visited

About jimg

  • Rank
    Advanced Member

Recent Profile Visitors

840 profile views
  1. Thanks for your help. 1. I would be happy to submit a patch, but I'm not sure you want it--concurrent mode cuts wifi transfer speed in half, because the radio is continually switching between two modes. Would that be acceptable to the project? 2. Thanks for the tip. I'll look into dkms. 3. Not my prefered choice, but that's always a fallback...
  2. I apologize for asking such a basic question. I have recompiled the wifi module on an Orange Pi PC+ to operate in concurrent mode so it can act in both station and AP mode at the same time, allowing it to be a wifi repeater. The problem is, this feature is lost on every kernel upgrade, requiring me to recompile the module each time I upgrade the kernel. The kernel module driver often changes slightly between kernel versions, and I have to track down and fix new bugs in the source code that prevent it from compiling when concurrent mode is enabled. I'm happy with how the wifi module performs now, but don't want to lose the ability to get needed kernel updates in the future. Is there any way I can keep the wifi module I have now without losing the ability to upgrade the rest of the kernel?
  3. Thanks for the advice. I just updated the kernel, and am in the process of installing the new (dev) source and header files. I also did an `apt update`, and see that now the linux image for the "next" branch is back to 4.19.57! $ apt-cache search linux-image | grep next-sunxi linux-image-next-sunxi - Linux kernel, version 4.19.57-sunxi So the problem has apparently been fixed. :-)
  4. I'm trying to add concurrent mode to the wifi driver on an Orange Pi PC Plus running the latest stable distribution of Armbian, but running into an "invalid module format" error due to the kernel version not matching the source version I'm using to recompile the wifi driver. I installed both the source and header files from armbian-config. The kernel version is 4.19.59 according to uname -r. This apparently is the linux-image-next-sunxi image, according to `apt-cache search linux-image | grep 4.19.59`. However, the source for the next-sunxi branch in the repository is 4.19.57, not 4.19.59, as `apt-cache search linux-source | grep next-sunxi` gives: linux-source-4.19.57-next-sunxi - This package provides the source code for the Linux kernel 4.19.57 `apt-cache search linux-source | grep 4.19.59` returns no results. How do I get the 4.19.59 source version? Would it be safe to upgrade to the dev branch (v 5.1.0), since both the kernel and source there are the same version? FWIW, here's my sources.list: deb http://httpredir.debian.org/debian buster main contrib non-free #deb-src http://httpredir.debian.org/debian buster main contrib non-free deb http://httpredir.debian.org/debian buster-updates main contrib non-free #deb-src http://httpredir.debian.org/debian buster-updates main contrib non-free deb http://httpredir.debian.org/debian buster-backports main contrib non-free #deb-src http://httpredir.debian.org/debian buster-backports main contrib non-free deb http://security.debian.org/ buster/updates main contrib non-free #deb-src http://security.debian.org/ buster/updates main contrib non-free
  5. Thanks, everyone, for all your work. I installed the 4.19 Beta image, added the following line to /boot/armbianEnv.txt: overlays=uartC rebooted, and now the UART works!
  6. Thanks for following up on this! Glad to hear it's finally going to be fixed. I'm excited to see work going forward on the 4.19 kernel, too.
  7. @TonyMac32. Have you been able to apply Neil's patch? If so, what do I need to do to start using it?
  8. Sorry, attached is the output from armbian-hardware-monitor.log. The first half is with the SD card in the board's card slot, the second half is with it in a USB adapter. It's a Samsung EVO 16 GB card. I checked htop but did not see anything unusual. The processes consuming the most CPU were the same in both cases. I had a PNY 32 GB card I wasn't using, so today I reformatted it and tried using it instead. This card worked normally, so apparently the problem is related to this particular SD card. armbian-hardware-monitor.log
  9. I have an Orange Pi Plus 2E I'm using as a cheap desktop computer/kiosk. I want to run Armbian on eMMC but use an SD card for file storage. If I boot off the eMMC, then insert an SD card (formatted as ext4) after boot, the system works well. But if I boot off the eMMC with the SD storage card in the card slot at boot, the CPU load increases and performance lags. Here's the output of armbianmonitor without an SD card, with two Firefox windows and a terminal window open while streaming audio using Audacious: Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 06:18:26: 1296MHz 1.10 25% 3% 21% 0% 0% 0% 54.1°C 0/9 06:18:31: 1296MHz 1.01 22% 2% 19% 0% 0% 0% 53.8°C 0/9 06:18:36: 1296MHz 0.93 21% 1% 19% 0% 0% 0% 53.8°C 0/9 06:18:41: 1296MHz 0.86 21% 2% 18% 0% 0% 0% 54.7°C 0/9 06:18:46: 1296MHz 0.79 24% 2% 21% 0% 0% 0% 53.6°C 0/9 06:18:51: 1296MHz 0.80 26% 1% 23% 0% 0% 0% 57.8°C 0/9 06:18:56: 1296MHz 0.74 23% 2% 21% 0% 0% 0% 55.9°C 0/9 06:19:01: 1296MHz 0.68 22% 2% 19% 0% 0% 0% 54.8°C 0/9 Here's the results running on eMMC, with the data SD card installed at boot, running under identical conditions: Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 06:27:47: 1296MHz 2.33 87% 14% 72% 0% 0% 0% 64.3°C 0/9 06:27:52: 1296MHz 2.38 87% 10% 76% 0% 0% 0% 62.9°C 0/9 06:27:57: 1296MHz 2.35 79% 8% 70% 0% 0% 0% 63.2°C 0/9 06:28:03: 1296MHz 2.41 80% 8% 71% 0% 0% 0% 64.5°C 0/9 06:28:08: 1296MHz 2.12 77% 7% 69% 0% 0% 0% 65.0°C 0/9 06:28:14: 1296MHz 2.03 77% 9% 67% 0% 0% 0% 61.3°C 0/9 06:28:19: 1296MHz 2.18 75% 7% 67% 0% 0% 0% 63.8°C 0/9 06:28:25: 1296MHz 2.17 75% 9% 65% 0% 0% 0% 65.5°C 1/9 The load and CPU usage is 3X higher and temperature is 10C higher. This is even without the SD card mounted! I get similar results using the eMMC on an Orange Pi PC+, too.
  10. I'm trying to configure the RTL8189FTV module on an Orange Pi+ 2E in SoftAP + STA mode so I can use it as wifi hotspot. According to this old document from Realtek (http://www.ofeixin.com/downloadRepository/8da8dda7-6721-4ac8-a7db-47cc4d9b218c.pdf), it's possible to do so using an RTL8189ETV, so I'm assuming it's possible on the RTL8189FTV, too. The default driver doesn't allow concurrent connections like this, tho, so it must be recompiled. I downloaded the source recommended on the sunxi wiki (http://linux-sunxi.org/Wifi#RTL8189FTV): git clone https://github.com/jwrdegoede/rtl8189ES_linux.git cd rtl8189ES_linux git checkout -B rtl8189fs origin/rtl8189fs I edited the file ./include/autoconf.h to turn on concurrent mode: #define CONFIG_CONCURRENT_MODE 1 then compiled the driver using the repository's Makefile: make -j4 ARCH=arm KSRC=/lib/modules/$(uname -r)/build I renamed the old module, copied the new one to the proper directory, removed the old module, and inserted the new one: cd /lib/modules/4.14.70-sunxi/kernel/drivers/net/wireless/realtek/rtl8189fs sudo mv 8189fs.ko 8189fs.ko.orig sudo cp ~/rtl8189ES_linux/8189fs.ko . sudo rmmod 8189fs.ko sudo insmod 8189fs.ko After doing so, I have two wifi interfaces, wlan0 and wlan1. The trouble I'm having is I cannot get wlan0 to authenticate when configured as a wifi client, nor accept clients when configured as a wifi hotspot. It attempts to make a connection but always fails, even when the hotspot is configured as open (no password). wlan1, however, works fine when configured either as a wifi client or hotspot. FWIW, I'm using the latest version of Armbian Bionic. UPDATE: The problem was both devices had the same mac address. I solved this by running the following script at boot: #!/bin/sh # Set up access point AP_IFACE=wlan0 AP_NAME="MyAP" AP_PASSWORD="abcd1234" CON_NAME=hotspot if [ ! $(nmcli -t con show | grep "$CON_NAME") ] then nmcli con add type wifi ifname "$AP_IFACE" con-name "$CON_NAME" autoconnect yes ssid "$AP_NAME" mode ap nmcli con modify "$CON_NAME" 802-11-wireless.cloned-mac-address 12:34:56:78:90:AB 802-11-wireless.mode ap 802-11-wireless-security.key-mgmt wpa-psk ipv4.method shared 802-11-wireless-security.psk "$AP_PASSWORD" fi nmcli connection up "$CON_NAME"
  11. Thanks for all your work. I really appreciate it. FWIW, I need uart C more than I need BT. I don't suppose using the newer 4.17 kernel instead of 4.14 would help, would it? I'm currently using the UART on an Odroid C2 (different board but same SoC), but that's using the legacy kernel. I really like the features and performance (and cost!) of the Nano Pi K2 better.
  12. Thanks! Would it have been possible to resolve this as a DT overlay? I found an overlay that enabled UART_C on the nano pi k2, so I tried: armbian-add-overlay uart_c_on.dts I first got the error"Overlays are supported only on A10, A20, H3, H5 and A64 based boards", so I commented out the test for the sunxi boards in the scirpt. I then got the error "Overlays are supported only on mainline kernel based images". I thought I had a mainline kernel, so I commenented that test out, too. The final error was "Error: dtc does not support compiling overlays". I don't know how to get an overlay-compatible device tree compiler, so I gave up.
  13. How do you enable the UART GPIO serial port (i.e., the one on pins 8 & 10) on a Nano Pi K2? The only active serial port I see from `dmesg | grep serial` is ttyAML0, which I'm assuming is the serial port on the debugging pins. FWIW, I'm using the 4.14.69-meson64 kernel on a Nano Pi K2.
  14. Yes, that will work, but going from 61 -> 45 is a big version downgrade :( .
  15. I have an Orange Pi PC Plus running the mainline Debian Stretch desktop version of Armbian, but lately I've been using it headless. When I'm logged in over ssh and shutdown it down using "sudo shutdown -h now", the ssh connection drops and the board's LED flashes then shuts off, giving every indication the board is off. However, power consumption doubles (increasing from ~1.2W to ~2.4 W)! The problem persists as long as the board is powered, so I presume the board is hung and never fully shutdown. Any thoughts as to what could be causing the board to hang when shutting down?