Search the Community

Showing results for tags 'mainline'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Announcements & first aid
    • Announcements
    • Board doesn't start
  • Community forums
    • Common issues
    • Peer to peer technical support
    • Feature Requests
    • TV boxes
    • General chit chat
  • Bug tracker
    • Allwinner A20
    • Allwinner H2 & H3
    • Allwinner H5 & A64
    • Armada A388, A3700
    • Amlogic S905(x)
    • NXP (Freescale)
    • Rockchip 3288 & 3328
    • Other supported boards
  • Development
    • Allwinner H6
    • Rockchip 3399
    • Development

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 851 results

  1. Hi, I have two OrangePi Lite running side by side. After working fine for about 8 months both started to experience same issue with wireless: The board works randomly for few hours or few days and then looses wireless connection. When this happens reboot does not help as then issue occurs immediately after the boot. Unplugging and replugging power source resolves that for a while and then happens again I suspect it may not be related to a hardware issue or wireless hotspot, as I have at least 3 other clients that continue to work fine. Searching for it on the internet brought this issue with Raspberry Pi: https://github.com/raspberrypi/linux/issues/1988. Raspberry uses different wireless chipset either. All that makes me think this may be an issue in the kernel itself Any ideas or thoughts? Workaround also appreciated Thanks
  2. Hi Guys, After a long time after the release Linux kernel 4.x I want use the I2S on Lime2 (Armbian Stretch kernel 4.14.14), but I2S interface did not work. I was add activation of overlays i2s0 and i2s1 into/boot/armbianEnv.txt root@lime2:~# cat /boot/armbianEnv.txt verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun7i-a20 rootdev=UUID=dcf7af80-8026-4e99-870f-f0d35f926063 rootfstype=ext4 overlays=i2s0 i2s1 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u After reboot I can't see I2S interfaces... root@lime2:~# aplay -l aplay: device_list:270: no soundcards found... root@lime2:~# lsmod | grep snd snd_soc_core 118784 1 sun4i_i2s snd_pcm_dmaengine 16384 1 snd_soc_core snd_pcm 65536 3 sun4i_i2s,snd_pcm_dmaengine,snd_soc_core snd_timer 24576 1 snd_pcm snd 45056 3 snd_timer,snd_soc_core,snd_pcm soundcore 16384 1 snd I2S really supported in Mainline on A20?
  3. Greetings, After setting my tinkerboard pins 22 and 24 as an Inputs, they reverts to being an output pin on HIgh after around 30 seconds. What is the cause of this? Is this some kind of feature. I don't have this happen on any other pin other than these 2. iomari
  4. Hello, I have Banana Pi R2 with armbian bionic. Have two wlan cards both USB, both works. But earlier when I used openwrt on x86 my both wlan and lan were bridged and had one IP - which was router IP. Here with armbian wlan hotspot get other IP than armbian itself. Is there any way to change it to bridge? Or best practices is to leave it as is? regards, Maciek
  5. Hardware setup :: Olimex Lime 2 Rev.k + 7" LCD + 5V power supply through the power jack. No battery is connected to the lime 2 board. Problem :: when the board boots up, the xfce power manager shows that the Battery is connected and it's in charging mode. The current charge value of the battery changes randomly like 92%, 56% and etc. When it reaches 0% the board will shut down. It completes the shut down procedure. The following is the terminal output, to find the battery status. Even though the battery is not connected you can observe that it returns the Voltage and reports that the battery is present root@olinuxino:~# cat /sys/class/power_supply/axp20x-battery/voltage_now 2865000 root@olinuxino:~# cat /sys/class/power_supply/axp20x-battery/present 1 root@olinuxino:~# cat /sys/class/power_supply/axp20x-battery/online 1 root@olinuxino:~# cat /sys/class/power_supply/axp20x-battery/capacity 0 root@olinuxino:~# cat /sys/class/power_supply/axp20x-battery/capacity 0 root@olinuxino:~# cat /sys/class/power_supply/axp20x-battery/online 1 root@olinuxino:~# cat /sys/class/power_supply/axp20x-battery/voltage_now 2879000 root@olinuxino:~# [ OK ] Stopped Unattended Upgrades Shutdown. [ OK ] Stopped target Timers. [ OK ] Stopped target Sound Card. ..... ..... ..... The board shut down as soon as the capacity reached 0%. I have three Lime 2 Rev.K boards, the behaviour is seen in all. What could be the reason for this behavior? Should I disable xfce power manager? What are the other problems with disabling xfce power manager? Can you please tell me the steps to disable the xfce4-power-manager. Note : I am using the Armbian_Ubuntu_bionic_5.1.12 OS with Lime 2 rev.K. It doesn't happen with Armbian_5.72.1 Debian_stretch. Attachments:: AXP209 Charging LED is ON - Even though the battery is not connected to the board, the charging LED is ON. The LED is not continuously ON, it blinks in random order. xfce4 Power manger - Image of xfce4 Power manger which shows that battery is connected even though its not physically connected.
  6. I want to use my GPIO pins on my OPi lite. After much research and testing, I have done the following - Add user pi to group gpio - Changed /etc/udev/rules.d/99-gpio.rules to SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\ chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\ chown -R root:gpio /sys/devices/platform/soc/1c20800.pinctrl/gpiochip0/gpio && chmod -R 770 /sys/devices/platform/soc/1c20800.pinctrl/gpiochip0/gpio;?\ '"???? Now, accessing GPIO pins is working fine via bash: (env) pi@orangepilite:~$ echo 65 > /sys/class/gpio/export (env) pi@orangepilite:~$ echo out > /sys/class/gpio/gpio65/direction (env) pi@orangepilite:~$ echo 1 > /sys/class/gpio/gpio65/value The LED connected to the corresponding pin lights up nicely. The problem is using Python to control the pin. I'm using the python module OrangePi.GPIO (env) pi@orangepilite:~$ python >>> import OPi.GPIO as GPIO >>> GPIO.setboard (GPIO.PCPCPLUS) >>> GPIO.setmode (GPIO.BOARD) >>> GPIO.setup (21, GPIO.OUT) Traceback (most recent call last): File "<stdin>", line 1, in <module> RuntimeError: No access to /dev/mem. Try running as root! This error is only there when trying to run the script from user pi. On root it's working fine. How do I access gpio pins on a non root user in python?
  7. I've tried to compile libgpiod (my assumption is this is a user space lib) and it depends on gpio.h which is used by the kernel. According to https://github.com/brgl/libgpiod/issues/22 gpio.h should be installed with linux-libc-dev which is already installed and gpio.h is missing. I installed the kernel headers and tried (it ends up with typedef conflicts): ./autogen.sh --enable-tools=yes --prefix=/usr/local CFLAGS="-I/usr/src/linux-headers-4.14.14-sunxi/arch/arm/include -I/usr/src/linux-headers-4.14.14-sunxi/include" configure: error: linux/gpio.h header not found (needed to build the library) I've attached the config.log. Maybe I'm totally missing the boat, but there's not a lot of info out there build this for ARM and there are no deb packages for ARM I can find. config.log
  8. Greetings. I'm running a headless cluster of Odroid C2's (eMMC) using the latest Armbian buster minimal image with kernel 4.19.69-meson64. I'm encountering an issue where it takes a long time for SSH connection to be accepted (initially up to 30 min consistently). I get a connection refused. The issue seems to be due to the entropy pool becoming depleted during the early boot process which blocks SSH from starting while it refills the pool. The problem seems to be known and documented well here: https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html As suggested I have installed installed haveged which brings the SSH startup from 30 mins to 10 mins after boot, which is an improvement, but still not good. Has anyone else experienced this issue? Any ideas?
  9. Yesterday my 14" Pinebook arrived so I thought I'll collect some already available information. A lot of work still has to be done to get a decent laptop experience with this hardware so this is neither a review nor a stupid Un-Review but just a preview instead. To get the idea about dimensions I added a 13" and a 15" laptop to the picture. Pinebook is wedge-shaped and thickness matches both the 2011 15" MacBook Pro and the 13" from 2015: Display size closely matches the 13" MacBook Pro (but of course pixel density / resolution don't match as well as quality: TN vs. IPS and coating -- it should be obvious if you've the 'you get what you pay for' principle in mind but I'm sure we'll see reviews somewhere else where people are comparing Pinebook with Chrome/MacBooks and think they would get the same display quality for a fraction of costs) Last hardware detail: heat dissipation. I've been curious how well the Pinebook's thermal design is and it looks pretty good. This is the moronic sysbench pseudo benchmark calculating prime numbers endlessly and the Pinebook sitting on a pillow to prevent airflow below the case bottom. Throttling settings are rather conservative with 65°C defined as first trip point and only after a couple of minutes the internal A64 SoC temperature reached this value and slight throttling occured (1.15 GHz down to 1.1 GHz, that's a 'difference' you won't be able to notice). So it seems the combination of a thermal pad with a large metal plate inside the case is rather sufficient: What you see here is a graph drawn by RPi-Monitor, one of my favourite tools to get a clue what's going on with ARM devices (since it's not a heavy monitoring tool that changes the way the OS behaves but it's pretty lightweight sp you can run it in the background and let it monitor/record stuff like cpufreq scaling, consumption and so on). Pinebook currently ships with a rather clean Ubuntu Xenial on the eMMC with Mate desktop environment based on latest BSP u-boot and kernel. To get RPi-Monitor installed on this Ubuntu @pfeerickprovides a script (please follow progress over there). When I played around with Wi-Fi I noticed that Wi-Fi powermanagement seems to be enabled (makes working via SSH close to impossible) and that MAC address changes on every reboot. To disable Wi-Fi powermanagement I simply used the Armbian way: root@pinebook:~# cat /etc/NetworkManager/dispatcher.d/99disable-power-management #!/bin/sh case "$2" in up) /sbin/iwconfig $1 power off || true ;; down) /sbin/iwconfig $1 power on || true ;; esac Unless Wi-Fi driver gets a fix to use a MAC address based on the SoC's individual so called SID one way to assign a fixed MAC address for the Wi-Fi is to add a wifi.cloned-mac-address property to all NetworkManager profiles after establishing a Wi-Fi connection first: nmcli con show | grep wlan | while read ; do set ${REPLY}; nmcli con modify "$1" wifi.cloned-mac-address $(cat /sys/class/net/$4/address); done (I'm pretty sure some masochistic people prefer fiddling around in /etc/network/interfaces instead so if you're not using your laptop as a laptop being carried around and seeing a lot of Wi-Fis you can also use the usual tweaks for the interfaces file. Please also note that using a random MAC address can be considered a privacy feature on laptops since it makes tracking of you in public environments harder). While watching the Pinebook's charging/discharging behaviour I noticed that consumption drawn from wall while charging oscillates between 9W and 15W while being used and display active so it's really great that Pine Inc fixed Pine64's design flaw N° 1: Pinebook is NOT equipped with shitty Micro USB for DC-IN leading to all sorts of trouble but just like SoPine baseboard now uses a 3.5mm/1.35mm barrel jack combined with a 5V/3A PSU (for other hardware details please refer to linux-sunxi wiki page). Battery status (health, capacity, voltage and so on) is already available through sysfs but some values are wrong or need calibration. This needs to be fixed with further upgrades. Also interesting: charging seems to be under control of the ARISC core inside A64 SoC and works together with Pinebook's AXP803 PMIC (powermanagement IC) even when there's no OS running. This will be somewhat challenging to implement later with mainline I would believe... I'll stop here for now since Pinebook is still stuff for developers and not end users. Just some resources for interested parties: https://github.com/ayufan-pine64/boot-tools (Kamil implemented an u-boot based approach to flash directly to eMMC and there you find the necessary BLOBs to convert other BSP based Pine64 images for Pinebook since different DRAM and other settings require different SPL+u-boot) https://github.com/ayufan-pine64/linux-pine64 (based on longsleep's BSP kernel but with more fixes currently for Pinebook) $mainline resources (I lost track where to find most recent stuff but will add this later) Wrt Armbian running on Pinebook we could now simply exchange u-boot+SPL+DT of our Xenial Desktop image... but I hope we won't do that but wait until dust has settled while helping with development efforts in the meantime. In other words: no Armbian on Pinebook (right) now
  10. I am using Olimex Lime 2 Emmc Rev.k for a project. One of the Boards shuts down randomly. Its not a freeze or a sudden power down of the board. The board undergoes a complete shut down procedure. I checked the log entries in /var/log/syslog log file. There is a entry of board going to shut down but I couldn't find the reason for shut down. Is there a way to find out if the board got shut down because of the Power-button press, shutdown command from a SSH client, shutdown because of temperature or shutdown because of under voltage ? Is there a log file i can check to find the reason for shutdown?
  11. Hi, I know it's a waste of time to play with an old bananapi pro but I think I could do it so I want to do it ! I can't make working PCM5102a DAC. I read a lot of things through different website but noway ! I tried https://forum.armbian.com/topic/9009-info-friendlyarm-pcm5102a-hat-with-nanopi-neo-under-mainline-4xx/ . I've only obtain this next to the step "armbian-add-overlay ./sun8i-h3-I2S-out.dts": $lsmod|grep i2s sun4i_i2s 20480 0 snd_soc_core 114688 2 sun4i_codec,sun4i_i2s snd_pcm 69632 4 sun4i_codec,sun4i_i2s,snd_pcm_dmaengine,snd_soc_core I tried the next step but nothing more: dmesg|grep -i pcm keep empty. I tried to make a module with this tuto https://hackaday.io/project/162373/instructions with the make command and his model of pcm5102a.c file, nothing more. I tried too with https://github.com/torvalds/linux/blob/master/sound/soc/codecs/pcm5102a.c failed ! aplay -l **** List of PLAYBACK Hardware Devices **** card 0: sun4icodec [sun4i-codec], device 0: CDC PCM Codec-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 Anyway ! Where I am wrong ? Is there a step that I do well ?
  12. Hello, I am trying to communicate with a mcp2515 breakout (8Mhz oscillator) on an Orange Pi Pc+ I have modified the breakout following info on Raspberry Pi: HowTo/Quickstart MCP2515 to keep logic level @3v I have two other nodes composed by two Arduinos, with same (not modified) breakout, one that transmits the other receives. I have successfully tested the first breakout (used on OPi) with an Arduino (powered by 3.3v and 5v on TJA1050). It lets me think that hardware is OK. Below photos of wiring (nb: orange wire becomes red, is wired near TJA1050 = 5v): It seems I have the same results with (edited) user_overlay and the compiled one provided in zador.blood.stained's post dmesg| grep 'can\|mcp\|spi' [ 6.701431] mcp251x spi0.0 can0: MCP2515 successfully initialized. [ 28.455699] can: controller area network core (rev 20170425 abi 9) [ 28.471752] can: raw protocol (rev 20170425) The controller seems well seen, I can bring up the can0 interface: sudo ip link set can0 type can bitrate 125000 triple-sampling on sudo ifconfig can0 up ifconfig can0 can0: flags=193<UP,RUNNING,NOARP> mtu 16 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 but candump is mute although the Arduino receiver displays messages from Arduino transmitter. And cansend do not give error but I could not see this messages on Arduino receiver. Does someone would have an idea of what I am missing ?
  13. Hi, as many did, I've bought a (CSI) OV5647 camera from AliExpress and am struggling to get it to work. Been at it for a week now and am at a loss. So i'm trying to get some clarification via this thread on how to get this camera to work. What I've done so far is to compile a mainline kernel (Ubuntu Bionic) and edited the kernel config file to include sun6i_csi and ov5647 driver. Build finishes successfully and am able to boot and load the drivers Unfortunately the OV5647 isn't recognized and /dev/video0 isn't created. Second build included a userpatch I've found online which i applied to no avail to the kernel https://lore.kernel.org/patchwork/patch/743268/ So my question is, what am i missing here ? Do i need an overlay, or patch the kernel/driver in some way ? Any help will be appreciated. Regards. Wim
  14. I have been experiencing sporadic unresponsiveness from my H3 boards (5 of them). The ping on them still worked but ssh did not. Logs showed that system experienced a time jumping backward somewhere in 1978. Today another such glitch happened but I was able to ssh-in and saw this: I got chrony instead of ntpd and it has a line "makestep 1 -1" in it's config allowing infinite number of big time corrections. For some reason it did not helped. There are relevant topis on the forum for A64: The only difference is that A64 jumps forward. I found no related issues on github or forum for H3 specifically. Does any one else experience this issue?
  15. The Volumio team is currently investigating whether our sopine64 based motivo board (https://volumio.org/epic-journey-called-volumio-motivo/) could boot from usb using SPI flash. I'm aware of the sunxi SPI developments in u-boot and mainline kernel, and that we theoretically should be able to flash the SPI-NOR chip with the correct u-boot version using FEL mode. I also read that armbian has been prepared for booting from usb (as @martinayotte mentioned in other places). My question is, did anyone actually do anything in this direction, is there something I could help testing with? I know how to compile u-boot as I've done this with armbian's u-boot version 2019-04 which works fine with our motivo board. I must admit i'm not skilled enough to get this done on my own, any help or pointer in the right direction would be very much appreciated. Cheers - Gé
  16. Hi Team I have two brand new Orange PI Zero LTS. Is this supported with the normal Zero download? Thanks
  17. Hi all, I got my hotspot working via armbian-config but I can't seem to edit the rules using ufw. Trying to block port xyz, any ideas how?
  18. root@orangepizero:/boot# iptables -nL modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.14.14-sunxi/modules.dep.bin' modprobe: FATAL: Module ip_tables not found in directory /lib/modules/4.14.14-sunxi iptables v1.6.0: can't initialize iptables table `filter': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. root@orangepizero:/boot# uname -a Linux orangepizero 4.14.14-sunxi #1 SMP Thu Jan 25 12:20:57 CET 2018 armv7l armv7l armv7l GNU/Linux root@orangepizero:/boot# Can someone help me how to fix this issue on Orange Pi Zero - 512 MB board ? I am running Armbian Ubuntu server image. Thank you in advance.
  19. The newest revision does not boot from current SD images. I'm working to debug why. If anyone else has a board and can test it out, let me know. The eMMC will boot, no problem, so it's just the SD itself. Model: Pine64 Rock64 DRAM: 1022 MiB MMC: rksdmmc@ff520000: 0, rksdmmc@ff500000: 1 SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In: serial@ff130000 Out: serial@ff130000 Err: serial@ff130000 Model: Pine64 Rock64 misc_init_r cpuid=55524b50303930343200000000051f1a serial=f55c6806c317581 Net: eth0: ethernet@ff540000 Hit any key to stop autoboot: 0 Card did not respond to voltage select! mmc_init: -95, time 9 switch to partitions #0, OK mmc1 is current device ** No partition table - mmc 1 ** starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: Core Release: 3.10a USB3: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 2 USB Device(s) found scanning bus 2 for devices... 2 USB Device(s) found scanning bus 3 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: unknown device ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT Ideally getting old an new to boot would be ideal, @Igor this might mean a fragmentation for this board though, like having a V2 and older and a V3 and newer build if we can't make them all play nice with one bootloader.
  20. Hi i have a problem trying to load the drivers of this camera, could you help me? Issue: mobprobe: FATAL: Module ov5647 not found in directory /lib/modules/4.14.84-sunix Board: Orange Pi Lite Camera sensor: OV5647 fisheye OS: Ubuntu - Armbian 5.65
  21. Today I swapped my old Neo2 against a Neo2 LTS 1GB in my NAS case - so I had a old Neo2 512MB free for the black Aluminum-OLED-case which I got in a drawer. Now I did try to activate the OLED in ARMBIAN 5.67 user-built Debian GNU/Linux 9 (stretch) 4.19.4-sunxi64 Linux npi-neo2-27 4.19.4-sunxi64 #6 SMP Fri Nov 30 14:02:43 +03 2018 aarch64 GNU/Linux First (like on a i2c-clock" I activated i2c0 in armbian-config: root@npi-neo2-27(192.168.6.27):~# armbian-config System --> Hardware --> [*] i2c0 After the reboot I checked for the i2c-OLED-device and got: root@npi-neo2-27(192.168.6.27):~# apt install i2c-tools root@npi-neo2-27(192.168.6.27):~# i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- After some trial and error(-messages) I did found the following dependencies for compiling/installing the software for the OLED-Board: apt-get install python-setuptools libjpeg-dev After that I did the normal "5 Enable NanoHat-OLED manually" from http://wiki.friendlyarm.com/wiki/index.php/NanoHat_OLED with root@npi-neo2-27(192.168.6.27):~# cd /home/guido root@npi-neo2-27(192.168.6.27):~# git clone https://github.com/friendlyarm/NanoHatOLED.git root@npi-neo2-27(192.168.6.27):~# cd NanoHatOLED root@npi-neo2-27(192.168.6.27):~# ./install.sh And after the next reboot the OLED-Display did work
  22. Well it took me longer than i hoped but i have managed to forward port icenowys code for TVE on the H2+/H3 to mainline armbian. It seems to work totally fine, with a few caveats. First: Sample images of it in action -> https://imgur.com/a/vXQEM Second: the patch itself -> https://github.com/stevenj/h3-tve/tree/v0.0.11 Third a prebuilt image for Orange Pi Zero: -> https://github.com/stevenj/h3-tve/releases/tag/v0.0.11 Howto: just put the patch into userpatches for the sunxi-next kernel, and build. it should apply cleanly. Its for H2+/H3. I have only tried it on a orange pi zero, but it should work on all H2+/H3 boards. You then need to edit /boot/armbianEnv.txt add tve to overlays to enable it. the driver will only run and enable tv out when the tv out devices are specifically enabled, so i created an overlay which does this. If you want to turn TV out off, just remove tve from the overlays line. My armbianEnv.txt overlays looks like this: overlays=usbhost2 usbhost3 tve If you want copious amounts of DRM debug info in your logs, add this as well: extraargs=drm.debug=0xF Its not needed, unless you really want the debug info. Notes: 1. The default mode is PAL, with 720x576 resolution. Thats outside of normal PAL displayable area, and so the screen overscans. I dont know how to correct this, although its mostly just annoying with terminals. I also don't know how to change the video mode to NTSC. 2. The standard font is a bit thin for composite video, and causes slight strobing and color impurity. Its because PAL needs pixels to be a certain MINIMUM width or color information can not be properly encoded. A way to resolve this is use : # apt-get install fbterm ... $ fbterm -s 20 This will run a terminal which is easy to change the font, and pick a bigger one. its much easier to read. Look at the help for fbterm to work out everything it can do. 3. I used the program "fim" to display the test images. there are others for doing stuff on the terminal. 4. I haven't tried X. I am not interested in running an X terminal on a TV, but it should probably work fine. Other than that it all seems good. I originally tested my hardware with the legacy kernel, and the image quality from this patch seems superior to what the legacy kernel produces. (legacy was noisy) The only other thing you need to know is Orange Pi Zero is missing filter circuity from its Composite Output, the most important thing you need to do is put a 50 ohm resistor between the signal and GND. i soldered one inside my RCA connector, it fits fine and isn't too difficult. IF you don't do this the image will bloom and look like total crap, so you have been warned. As this patch allows TVE to be enabled/disabled through use of the Device Tree overlays, i think it should be fine if the Armbian devs want to include it. I am happy to clean out some of the debug messages i added if they are interested in making a standard part of the build. If not, its easy enough to build your own image, just follow the guides on how to rebuild armbian. EDIT: I need to mention, all props go to Icenowy Zheng who wrote the original driver. I just tweaked the device tree stuff and got it in a state where it can apply cleanly to the armbian mainline kernel and build system. Original code is here: https://github.com/Icenowy/linux/tree/tve-v2
  23. How enable tv out on mainline kernel 4.19? script.bin not found and stevenj/h3-tve not working on my version of kernel.
  24. Hi, I want to try out my Odroid HC2 as an openvpn client. I don't expect great performance but I want to make sure I set it up correctly. This is why I want to ask if anyone can give any recommendations or tweaks for using it as an openvpn client. Idk much about openvpn, I know it uses openssl for de and encryption. Is there a way to use hardware de and encryption so I can speed things up and have a better download speed via openvpn? Or is hw de/encryption maybe already used by default if I just install openvpn package? Any recommendations on how to correctly set this up are appreciated.
  25. I tested with Armbian Stretch image on NanoPi-NEO-Core2. PJSIP VoIP Client. MIC input does not work. Additional USB sound cards work well. In FriendelyARM original firmware, MIC input works well. I hope that this issue will be resolved. Please help me.