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.