jimg

Yes, that appears to be correct. I couldn't figure out why the UART on the p26 pin header wasn't working. Found your post and tried ttyS1 instead. Working beautifully now. Thanks 🙂.

It looks that way to me. It has 'orangepi-config' and 'orangepimonitor' commands that look and behave exactly like the Armbian equivalents. I'd feel a little more comfortable downloading the images from Armbian's torrents, though, than a server in China....

I installed Orange Pi's version of Ubuntu Bionic server with kernel 5.34.27 mentioned in the tweet refered to by @gounthar above on a Orange Pi Zero LTS V1.5 board, and it has indeed fixed the temperature reporting problem. The onboard wifi is working flawlessly, too.

I haven't tried setting up AP mode using the unmodified driver, but I was able to get a hotspot set up on Orange Pi PC Plus and Orange Pi Plus 2E by enabling concurrent mode in the wifi driver and recompiling it. This will give you two wifi interfaces, one of which can be used as an AP. The advantage of doing this is it allows you to use the board as a wifi repeater if you want, or to make it easier to set it up as an IoT device. However, it also cuts the transmission rate in half, since the wifi module is concurrently switching between STA and AP modes. Let me know if you're interested and I'll write up how I did it.

Bluetooth works for me, but only if I completely power off and do a cold boot. It doesn't work on a warm restart. Note that firmware updates currently will overwrite these changes, so be careful when doing an apt-get update && apt-get upgrade.

This got wifi working for me (but broke bluetooth ): $ cd /lib/firmware/brcm $ sudo mv brcmfmac4356-sdio.bin brcmfmac4356-sdio.bin.old $ sudo mv brcmfmac4356-sdio.txt brcmfmac4356-sdio.txt.old copy drivers from this post to ~/Downloads: $ sudo cp ~/Downloads/brcmfmac4356-sdio.* . $ sudo chmod g+w brcmfmac4356-sdio.bin $ sudo chmod g+w brcmfmac4356-sdio.txt then reboot

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...

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?

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. :-)

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

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!

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.

@TonyMac32. Have you been able to apply Neil's patch? If so, what do I need to do to start using it?

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

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.

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"

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.

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.

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.

Yes, that will work, but going from 61 -> 45 is a big version downgrade :( .

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?

I'm using an Odroid C2 and need some newer software packages than those found in the Ubuntu 16.04 repositories, so I installed the legacy (3.14.79) version of the Debian server edition of Armbian, then upgraded it to Debian 9. I've installed xorg, lightdm, etc and now have a very functional desktop. However, I want to install a 3D CAD program that **I think** would perform better if I had 3D accelerated graphics installed. I'm a complete noob when it comes to 3D graphics drivers. I assume they're not installed, as I see this on my Orange Pi PC 2 running the desktop version of Ubuntu: $ lsmod | grep mali mali_drm 2732 1 drm 178255 2 mali_drm mali 123146 0 ump 29379 3 mali but nothing on my Odroid C2. I can't find the drivers in any directory on my system, either. How would I go about installing them? -Jim

This is a known problem that appears to be compiler-related: https://bugzilla.mozilla.org/show_bug.cgi?id=1391802 https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1711337 A fix appears to have been released for Ubuntu 17.04, but that version won't install due to unmet dependencies that can't be satisfied with Armbian (libstdc++6 (>= 6)). The last stable build I could find for armhf is Firefox 52. You can download it from here via FTP: ftp://ports.ubuntu.com/ubuntu-ports/pool/main/f/firefox/firefox_52.0.2+build1-0ubuntu0.12.04.1_armhf.deb These are the steps I took to remove the broken version, install the unmet dependencies, install the older, working version, and prevent it from being automatically upgraded back to the new, broken version. sudo apt remove firefox sudo apt-get install libpango1.0-0 sudo dpkg -i ~/Downloads/firefox_52.0.2+build1-0ubuntu0.12.04.1_armhf.deb sudo apt-mark hold firefox (TIL: gdebi is a very useful tool for seeing the dependencies of a package before you install it. You can use it from the command line like so: sudo gdebi <name of deb package> to see the dependencies you might need to install before installing a package.)

Firefox (not Chromium this time) is now crashing on me when I attempt to launch it on an Orange Pi PC+. Seems to be related to a new security update I think I got (55.0.1+build2-0ubuntu0.16.04.2). Anyone else having this problem?

I can format it, but when I attempt to mount it by hand using the method in the create_armbian function of nand-sata-install , it fails: $ sudo mkdir -p /mnt/rootfs /mnt/bootfs $ sudo mount /dev/mmcblk1p1 /mnt/rootfs mount: wrong fs type, bad option, bad superblock on /dev/mmcblk1p1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. FWIW, I can confirm what Da Alchemist experienced--ext3 works, but not ext4.