Search the Community

Showing results for tags 'mainline'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • 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

Marker Groups

  • Members

Product Groups

  • Misc


  • Armbian


  • Giveaways


  • Applications

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 819 results

  1. Hello, i prepared a microsd card with the Armbian_5.90_Odroidxu4_Debian_buster_next_4.14.127 image and started my ODROID XU4. However the problem encountered is the failure of the NetworkManager, which of course is a main service to operate the ODROIDXU4. Sofar ARMBIAN images had been very reliable and stable in the past. The failure of starting the Network Manager something unusual for ARMBIAN. Enclosed you'll find a error messages. I appreciate very much your help and supporting comments! regards, Ireng
  2. After upgrading from 4.14.70-sunxi64 to 4.19.13-sunxi64 Pine64+ board started to misbehave after running for some time. Dmesg shows: Armbian-release: BOARD=pine64 BOARD_NAME="Pine64" BOARDFAMILY=sun50iw1 VERSION=5.70 LINUXFAMILY=sunxi64 BRANCH=next ARCH=arm64 IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image With Armbian Pine64 3.10 kernel board worked without hanging for 2+ years. I also tried 4.18.xx-sunxi64 kernel from dev branch - same problem.
  3. Is there a way to boot the Pine-A64 LTS with Armbian via eMMC? I can use the SD card to boot the armian-Sopine image, but the eMMC memory is not recognized. With the Ayufan image (jessie-minimal) on SD card (, I can at least recognize the eMMC memory and using sudo dd bs = 30M if = Image / jessie-minimal-sopine-0.7.19-118.img of =/dev/ mmcblk1 copy to the eMMC memory. I removed the SD card and booted with eMMC. I did the same steps with the Armbian image and write the Armbian image on the eMMC (with the Ayufan image on SD card) sudo dd bs=30M if=Image/Armbian_5.38_Pine64so_Ubuntu_xenial_default_3.10.107.img of=/dev/mmcblk1 and nothings happens after the reboot. There are further steps that I have to carry out?
  4. Hi, I am running Armbian on four HardKernel HC2's and everything is working perfectly. The four SBC's are running a Moosefs cluster running Ubuntu 18.04 and Armbian 5.85, and this leads to my questions: I am trying to decide whether to upgrade as apt is proposing moving to 5.89 The change log does not currently list 5.89 and shows 5.87 as the newest. Am I missing something? When I look at previous change logs it is difficult to decipher which fixes impact the HC2/HC1/XU4. Is there an easy way to tell? How do you decide when to upgrade? Is it even worth upgrading when running more mature boards like this one? My boards run inside a private network behind a firewall, and my #1 priority is stability and reliability. Thank you.
  5. Hi, I have been looking to download "Armbian_5.52_Olinuxino-a20_Debian_stretch_next_4.17.19.img". Torrent that I have is not seed, it been stuck for all day. Can anyone please provide me with downloadable link or please seed the torrent? Thank you Jedi
  6. hi, I'm trying to use an OrangePiPC2 H5 processor on an old TV. I have got to edit the dts file but I dont know what to change to antivate RCA video & audio output. Plz, help me to set RCA port as default or give me links to learn to edit dts, I've seached a lot but found nothing. thx
  7. Looking for a current realtime RTOS real time deb package or SD card image for the tinkerboard. I have been trying to compile a current real time build. All of my attempts have failed so far. free offer described below
  8. We have initial support for Pine64/Pine64+ for a long time in our repository but not released any official images yet. Since this will change soon a sneak preview what to expect. Hardware related issues: Please don't blame Armbian for the few design flaws Pine64 and Pine64+ show: These boards use Micro USB for DC-IN which is the worst possible decision. Most USB cables have a resistance way too high and are responsible for severe voltage drops when consumption increases, then the tiny Micro USB contacts have also a pretty high contact resistance and also maximum amperage for this connector is limited to 1.8A by USB specs. So in case you want to do heavy stuff immediately look into linux-sunxi wiki page for Pine64 to get the idea how to use the pins on the so called Euler connector to power the board more reliably. If you think about buying a Pine now consider ordering their PSU too since there cable resistance shouldn't be a problem (should also apply to the Micro USB cables they sell) The only led on this board is a power led that immediately lights when power is provided. Pre-production samples had a green led, on the normal batches this has been replaced with a red led. So there's no way for an OS image to provide user feedback (activate an led when u-boot or kernel boots) and the red light has often been interpreted as 'something is wrong' USB: you find 2 USB type A receptacles on the board but only one is a true USB host port, the other/upper is A64's USB OTG port exposed not as Mini/Micro USB (with ID pin to be able to switch roles) but as a normal type A port. Expect performance to be lower on this port. I've also never been able to do disk benchmarking on the upper port but that might have changed in the meantime (I only have a pre-production developer sample here). Please note also that the maximum amperage available on the USB port is 650mA so connecting bus-powered USB disks might already exceed this so be prepared to use a powered USB hub in between A64 is prone to overheating but unfortunately the Pine64 folks do not sell the board with an effective heatsink by default (compare with ODROID-C1+ or ODROID-C2 for example how it looks like if the vendor cares about heat dissipation). They promised to provide a good heatsink as option but at least I'm not able to find one in their online store. But a heatsink is mandatory if you plan to run this device constantly with high loads, otherwise throttling will occur (when we tested an unrealistic heavy workload without a heatsink -- cpuburn-a53 -- A64 had to throttle down to as less as 600 MHz (for some numbers see IRC log from a while ago) Not a real hardware issue but a problem anyway: the HDMI driver in Allwinner's BSP does not negotiate any display output with a lot of displays that are connected with a HDMI <--> DVI converter or use non-common resolutions. Better do not expect any display output if your display is neither connected directly using HDMI nor capable of 1080p (we can't do anything here since Allwinner's driver uses closed source blobs and no documentation or code with useable license exists) On a couple of Gbit equipped Pine64+ users report that they're not able to negotiate Gbit Ethernet reliably and have to force the connection to Fast Ethernet (since we know that the RTL8211E PHY used on the boards needs an additional ~350 mW when negotiating a Gbit Ethernet connection this might be related to power problems or maybe different PHY batches or something else). Confirmed in the meantime to be a hardware issue. Now combine Micro USB encouraging users to combine this SBC with crappy phone chargers, 'smart' hubs/chargers that do only provide 500mA since Pine64 isn't able to ask for more and crappy USB cables leading to voltage drops (all sorts of power related issues 'by design' due to crappy Micro USB connector) with a missing custom led able to be used to provide user feedback while booting and the inability to use a lot of displays then you might already get what a support nightmare this device is. The only reliable DOA detection method without a serial console is to ensure you have a working SD card (test it before using either F3 or H2testw as outlined in our docs), then check download integrity of the Armbian image (again see the documentation), then ensure you burn the image correctly to SD card (see docs), insert SD card, power on the board and wait 20 seconds. If then the leds on the Ethernet jack start to flash randomly at least the kernel boots and after waiting an additional 2 minutes you'll be able to login with SSH or serial console (for the latter better choose the EXP header over the Euler connector -- reason here) Anyway: In case you run in booting or stability problems with Armbian on Pine64/Pine64+ be assured that it's not an Armbian issue. You run into any of the problems above therefore please try to resolve them on your own and send your complaints to Pine64 forum and not ours: (really, we don't do hardware and these issues are all related to hardware design decisions) Expectations: The Pine64 folks did a great job raising expectations to the maximum. They advertised this board as 'first $15 64-Bit Single Board Super Computer', promised an average consumption of just 2.5W, the SoC remaining at 32°C and a few other weird things while they already knew that reality differs a lot (the journey started here last Dec). Pine64 is not a 'Super Computer' but most probably the slowest 64-bit ARM board around due to A64 being limited regarding maximum cpufreq and overheating issues (40nm process being responsible for) and lack of fast IO interconnections (only one real USB 2.0 host port present, no eMMC option possible, no SD card implementation using the faster modes). If you then combine the high expectations with a rather clueless kickstarter crowd (many of them not even getting that they did not buy products but backed a project) and the hardware flaws it's pretty obvious why their forums are full of complaints and why they receive so much boards as being DOA that work flawlessly in reality. So why bringing Armbian to Pine64? Since for some (headless) use cases these boards are really nice and also cheap, A64 support is progressing nicely thanks to our awesome linux-sunxi community and also a few more A64 devices will be available soon. What do you get with Armbian on Pine64? User experience will not be much different compared to longsleep's minimal Ubuntu image. If you prefer Debian then at least you can be assured that our images do not contain bad settings and silly bugs like the one's from official Pine64 downloads section (since they fiddle around manually with their OS images for example all Pine boards running these have the same MAC address by default which will cause network troubles if you've more than one board in the same collision domain). We use the same thermal/throttling settings like OS images based on longsleep's kernel (since we helped developing them back in March), we use the same BSP kernel (patched by Zador up to the most recent version back in May) and share a few more similarities since our modifications were sent back to longsleep so all OS images for Pine64 might be able to benefit from. Differences: You don't need to execute longsleep's various platform scripts since kernel and u-boot updates are done using the usual apt-get upgrade mechanism in Armbian. You also don't need (and should not use) scripts like since they decrease network performance with Armbian (stay with our defaults unless you're an expert). And a few more tweaks might result in better performance and at least by using Armbian you have the usual Armbian experience with some additional tools at the usual location, automatic fs resize on first boot and so on. We already provide a vanilla image currently based on kernel 4.7 but that's stuff for developers only, see below. Performance with legacy Armbian image: 'Out of the box' CPU performance with A64 is not that great unless you are able to benefit from the new CPU features: A64 uses Cortex-A53 CPU cores that feature 64-bit capabilities (which are not that interesting since A64 devices are limited to 2 GB DRAM anyway at the moment) but more interestingly ARMv8 instruction set can be used which might increase performance a lot when software will be compiled for this platform. Best example: the commonly mis-used sysbench cpu test: When running an ARMv6 'optimized' sysbench binary on an ARMv8 CPU then performance will be 15 times slower than necessary (applies to the RPi 3 or the upcoming Banana Pi M64 when used with their OS images) But as soon as ARMv8 optimized code is used A64 can really shine in some areas. I used the default sysbench contained in Ubuntu Xenial's arm64 version, tried it with 20000 settings and got less than 8 seconds execution time (an RPi 3 running Raspbian has the faster CPU cores but here it will take 120 seconds -- just due to different compiler switches!). Then I tried whether I can optimize performance building sysbench from source using export AM_CFLAGS="-march=armv8-a -mtune=cortex-a53" and got 11 seconds execution time, so optimized code led to a huge performance loss? Not really, I checked out sysbench version 0.5 by accident and there for whatever reasons execution with ARMv8 optimization or in general takes longer (great! benchmark version influences execution time, so one more reason to never trust in sysbench numbers found on the net!). Using the '0.4' branch at version 0.4.12 I got an execution time of less than 7.5 seconds which is a 10 percent increase in performance for free just by using appropriate compiler flags: Another great example how using CPU features or not (NEON in this case) influences performance and 'benchmarking gone wrong' numbers are Linpack's MFLOPS scores. By choosing the package your distro provides instead of using one that makes use of your CPU's features you loose at lot of performance, ruin every performance per watt ratios and behave somewhat strange Someone sent me Linpack MFLOPS numbers generated with Debian Jessie which is known for horribly conserative compiler settings when building packages -- if you switch your distro from Jessie to Ubuntu Xenial for example you get a 30 percent improvement in sysbench numbers, yeah that's the 'benchmark' we already laughed at above. With Jessie's/Raspbian's hpcc package, Pine64+ gets a score of 1625 MFLOPS and RPi 3 just 1035. So is Pine64 1.6 times faster than RPi 3? Nope, that's just 'benchmarking gone wrong' since these numbers are the result of a joke: Using tools for 'High performance computing' with standard settings (no one interested in HPC would ever do that). By using the correct Linpack version that makes use of NEON optimizations on both CPUs we end up with 3400 MFLOPS (Pine64 at 1.3 GHz) vs 3600 MFLOPS (RPi 3 at 1.2 GHz). So if we're talking about this use case (HPC -- high performance computing) RPi 3 easily outperforms A64 (please keep in mind that the 3400 MFLOPS I got are the result of overclocking/overvolting at 1296 MHz, Pine64 is limited to 1152 MHz by default so we're talking about 3000 MFLOPS for A64 vs. 3600 MFLOPS for RPi 3's SoC. So it's not Pine64 being 1.6 times faster but RPi 3 being more suited for Linpack numbers and this type of benchmarks only shows how wrong it is to use distro packages that are built using conservative settings (which is a must if the distro wants to support a wide range of different SoCs!) Anyway: I's obvious that in case you want to use Pine64 for number crunching or performance stuff in general evaluating whether compiling packages from source might improve performance is a great idea (at least it's obvious that from a performance point of view using an ARMv6 distro with ARMv8 SoCs is stupid -- reality with Raspbian running on RPi 3 and BPi M64). ARMv8 also provides crypto extensions that might be used with OpenSSL for example. Didn't look into it yet but maybe huge performance gains when using a Pine64 as HTTPS enabled web server or VPN endpoint are possible just like we've already seen with sysbench. Network performance: Pine64+ combines the SoC internal GbE MAC implementation (the same as in H3 and A83T SoCs from Allwinner) with an external RTL8211E PHY as used on most GbE capable SBC. Default iperf performance with Armbian/Xenial: +900 MBits/sec in both directions (920/940 MHz) so no need for further tuning (please read through this explanation here why blindly trusting in iperf numbers is always stupid and why it's neither necessary nor useful to further tune network settings to get better iperf numbers). Please keep in mind that for yet unknown reasons a couple of Pine64+ are reported to not reliably work at Gbit Ethernet speeds. Please also keep in mind how settings might matter. If you run a standard iperf test in 'passive benchmarking' mode you might get throughput numbers 200-250 Mbits/sec lower than ours maybe just due to a wrong cpufreq governor. Ethernet throughput scales linearly with CPU clockspeed with most cheap ARM SoCs (our only known exception from this is Solid-Run's Clearfog which uses a SoC optimized for IO and network throughput) so by using the ondemand governor with wrong/default settings for example you ensure that an idle SBC will only slowly increase clockspeed when you start your iperf test. This is Armbian switching from interactive to ondemand governor now being below 700 Mbits/sec just due to adjusting CPU clockspeed too slow: The other stuff normally 'benchmarked' is not worth mentioning/testing it so just as quick notes: A64 is showing the same SDIO limitation as most other SoCs limiting sequential transer speeds to/from SD card to ~23MB/s (do the math yourself: SDIO with 4 bit @ 50 MHz minus some overhead is 23 MB/s) -- fortunately that's rather uninteresting since random IO matters on SBCs and there it's your choice to choose between crappy cards that horribly suck or follow our recommendations and choose a really fast card. But Pine64 can not use the faster eMMC interface so if you really need high IO bandwidth and high IOPS better choose a different device USB is USB 2.0 so expect ~35MB/s with BSP kernel and ~40MB/s with mainline kernel and UASP capable disk enclosures for individual USB connections (UASP + mainline kernel might show high random IO numbers if used together with an SSD!) HW accelerated video decoding is already possible (see here for the codec matrix) and situation with HW accelerated video encoding looks promising too: In case one is interested in performance testing on SBCs monitoring what's happening is mandatory. Currently our armbianmonitor tool does not install the necessary templates on A64 so still my script to install this stuff on A64 should be used: (read the script's header how to install) Performance with vanilla Armbian image: Not interesting at all at the time of this writing since while Pine64 happily boots mainline u-boot/kernel it's way too early to do tests in this area. Currently there's no access to the AXP803 PMIC from mainline kernel so not even VDD_CPUX voltage regulation works and as a result cpufreq scaling is also not working and the SoC is clocked pretty conservative. Since most performance relevant stuff running on cheap ARM SoCs depends on (switching as fast as possible to) high CPU clockspeeds benchmarking is absolutely useless now. You should also keep in mind that many core features still not work with mainline kernel so this is really stuff for developers (who normally prefer their own way to boot their freshly compiled kernels). So please don't expect that much from vanilla images for A64 boards now, better choose the legacy variant. The future? A few more A64 boards are announced or already available as dev samples, for example the aforementioned BPi M64 (possible advantages over Pine64: sane DC-IN, real USB OTG, more USB host ports behind an internal USB hub, eMMC available and custom leds being able to provide user feedback, everything else is more or less the same as the 2 GB Pine64+) or Olimex working on both an SBC and an A64 based Laptop. And then Xunlong announced 2 new SBC based on Allwinner's H5. H5 (product brief) seems to be A64's bigger sibling providing video/GPU enhancements, 3 true USB host ports in addition to one USB OTG (just like H3 where we can use all 4 USB ports that do not have to share bandwidth), integrating a Fast Ethernet PHY (just like H3) but lacks PMIC support (again just like H3, so no mobile useage, no battery support out of the box and it gets interesting how VDD_CPUX voltage regulation will work there -- maybe 'just like H3' again). Since A64 shares many/most IP blocks with H3 and A83T from Allwinner I still hope that H5 will be just a mixture of A64 and H3 and we will get full support based on what we now have for these 2 other SoCs pretty fast. But that's 100 percent speculation at this moment Update regarding longsleep's script. Benchmark results don't get automatically worse when applying the tweaks from his script but the result variation gets huge (730 - 950 Mbits/sec, exceeding 940 Mbits/sec is already an indication that buffers are invoked): So better enjoy defaults unless you really know what you do since network performance tuning works in different directions. Stuff that might increase throughput might negatively affect latency and vice versa. So if you start to tune, tune for your specific use case!
  9. Can the Audio port on the Orange Pi Win Plus A64 also output video (like TV output)? It seems like most of the orange Pi boards with an audio jack can do this and the CubieTruck (which is an A20 board) can do the same as well. Please let me know ASAP. Thanks!
  10. I am searching for an LCD 10 inches or above that works with the LCD connector on the Orange Pi Win Plus A64. Does anyone know of one that works and can you provide a link to it so I can purchase and use it? Thanks.
  11. 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: 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
  12. I tested the recently added sunxi-dev patch to improve the SATA write speed. Here are the results: Board: Cubietruck OS: Ubuntu Bionic (18.04.2), Armbian 5.86 Kernel: 5.1.0 with and without RFC-drivers-ata-ahci_sunxi-Increased-SATA-AHCI-DMA-TX-RX-FIFOs.patch SATA-device: SAMSUNG SSD 830 Series, 256GB Measurement method: dd if=/dev/zero of=/tesfile bs=? count=? oflag=direct bs: measured 4k, 64k and 1M block sizes count: adjusted to ensure that data written is ~500MB Measurements below are made with kernel 5.1.0 without (before) and with the mentioned patch: dd bs Before MB/s After MB/s Increase 4k 13.3 19.0 43% 64k 35.9 82.0 128% 1M 42.5 112.0 164% As you can see, the SATA write speed improved, especially when using larger block sizes. Up to now, no negative side-effects encountered.
  13. In the FriendlyARM thread;t=1427&amp;p=5685#p5685 we did try to use A64 images from the Pine64 or the BananaPi M64 with the NanoPi A64. The last times we did that with less success - OK Sytem is running but Network/Sound has to added via USB. No suppport for the onboard devices But today a user did wrote that - with the actual stable Pine64-image ( Armbian_5.69_Pine64_Debian_stretch_next_4.19.13 ) WiFi is useable. So I flasded the Pine64-image to a MicroSDCard and did boot. Additiionally I did see with "aplay -l" the HDMI and the analog Sound-device. But ethernet isnt "connected" right via the .dtb armbian inside can see the ethernet-part of the SoC (set IP and see MAC) and the external RTL8122E Phy blinks the Link and Transfered-Packets via LED.... My first idea was to edit the Pine64 DTB to match the NanoPI A64 DTB in the ethernet-part - but with these Pins & PHandle's I did get stuck BUT my second idea did work much better, because in the armbian-build-system I also did see the sun50i-a64-nanopi-a64.dtb So I checked the board-config-file for the pine64.conf ( under ./build/config/boards/ ) - there is an entry for a defconfig file and the armbin-build-system has also a defonfig file for the nanopi-a64 ./build/cache/sources/u-boot/v2018.11/configs/nanopi_a64_defconfig while the NanoPi A64 isnt (official) supported by the Meneu-System of the armbian-build-system. So I copied ./build/config/boards/pine64.conf to ./build/config/boards/nanopia64.conf and did edit it like in the following way: # A64 quad core 512MB-2GB SoC GBE BOARD_NAME="NanoPiA64" BOARDFAMILY="sun50iw1" BOOTCONFIG_DEFAULT="sun50iw1p1_config" BOOTCONFIG="nanopi_a64_defconfig" # MODULES="sunxi_codec sunxi_i2s sunxi_sndcodec 8723bs" MODULES_NEXT="" # KERNEL_TARGET="default,next,dev" CLI_TARGET="bionic,stretch:next" DESKTOP_TARGET="xenial:default" # CLI_BETA_TARGET="" DESKTOP_BETA_TARGET="" and did compile for the NanoPi A64 with ./ EXPERT="yes" in ./build/ Now I could select the NanoPi A64 (falsely) as supported board and did select DEV (armbian 5.71 with Kernel 4.20) I did build the console and the Desktop-version. In the console-version I was happy to see eth0 & wlan0 working, but the HDMI and analog soundsystem is missing (which was visible in Pine64 next 4.19.13) So there was no need for a RTL8211E-driver (because its only a PHY) like I did read before at In the Desktop-version the GUI did start without problems (not fast, but useable) - like on a older pinebook (a64) build Maybe DEV was "too much"? I will try the NEXT for my NanoPi A64 File Or maybe the nanopi A64 dtb isnt correct on the "sound-part"?
  14. Hello all. Okay: I am a total newbie to Orange Pi. I apologize upfront for any and all obvious self inflicted mistakes that you all spot. AGAIN: total newbie to the Orange Pi world. Please go easy in me! I have an Orange Pi Win Plus A64 board and frankly --- I love the darn thing! Powerful for my needs and I have a niche application that I am working on and this board is really the only one that fits my needs. The 2GB RAM is a must. The issue I am having is this: I am usinga waveshare 10.1 inch TFT HDMI display that has the SPI connector (lcd: I have attached the LCD to the WinPlus aligning Pin 1 of the WinPlus with pin 1 of the lcd. I used this as a tutorial guide of followed the steps to activate the spi interface and have used armbian config to turn on the spi interface as well: And .... nothing has worked at all. I really want and need to get this working successfully and I need to community's help in a major way.tfttft The display does light up when I power on the display. I get a message on the screen that says "No Signal Detected". Is there something I am missing with the GPIO pin configs for the A64 chipset on the WInPlus? Has anyone successfuly connected a TFT LCD display to the Opi WinPlus? The reason I want the SPI interface is because I want dual screens (SPI plus HDMI) for my application. *** If there is a 10 inch LCD panel (with touch) that will work with the OPi WinPlus that can be connected through LCD connector on this board, can someone post a link to it?? I have not been able to find one in my google searches. Thanks all!
  15. I just recently obtained a new Cubietruck A20 and I downloaded the latest armbian bionic, formatted my micro SD card and put the downloaded image on it (with Etcher). The board boots and everything is good .... until I get to the root prompt. The board doesnt boot to the desktop gui at all. Has anyone else experienced this? What steps am I missing? Can someone guide me to the proper armbian install for the Cubietruck a20? I am using an HDMI monitor with it. Thanks.
  16. Hello, A GPS module ublox is connected to a odroid c2 board on GPIOX.12 and GPIOX.13 for the RX and TX and GPIOX.10 for the PPS. The board is running the stable kernel 4.19.42-meson64 from Armbian based on Debian stretch which was dist-upgraded to Debian buster. I am trying to get the /dev/pps0 entry using GPIOX.10 to finish the chrony setup but I cannot find the correct syntax in the DTS file. Any pointer or idea ? I try either of the gpios line below, none of them seems to be correct. pps { gpios = "< 0x1e 0x66 0x0 >"; #gpios = "<&gpiox 10 GPIO_ACTIVE_HIGH>"; #gpios = "< 0x66 >"; assert-falling-edge; compatible = "pps-gpio"; }; The file include/dt-bindings/gpio/gxbb.h#L122 in the Linux kernel tree show the value of GPIOX.10 is set to 102 (aka 0x66 in hexa). After reboot, the pps-gpio module is loaded and cannot find the GPS connected. # dmesg | grep -i pps [ 1.414780] pps_core: LinuxPPS API ver. 1 registered [ 1.414783] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <> [ 5.460824] OF: /pps: could not find phandle [ 5.460835] pps-gpio pps: failed to get GPIO from device tree [ 5.460849] pps-gpio: probe of pps failed with error -22 The previous pps-gpio kernel module had the option for the gpio_pin which seems a bit easier to use :-/ Thank you.
  17. Hello,Respected Developers: I'm an Orange Pi user.In the process of using the armbian, I encountered serious problems. My Control Board is Orange Pi PC Plus.Armbian is "ARMBIAN 5.59 stable Ubuntu 18.04.1 LTS 4.14.65-sunxi" I installed jdk and mysql.And run a JAVA program.I set a time zone for Asia-Chongqing,The system language is Chinese,I use three serial ports. When running for a period of time,There will be bugs.About one to three days. The specific phenomena are as follows: 1.Run "date",the time is 1978. 2.Mysql occupy cpu 195%, occupy mem 27%,systemd occupy cpu 34%,Another systemd occupy cpu 14% ,systemd-jo+ occupy cpu 39%. 3.eth0‘s ip disappear,Unable to connect remotely from the network for ssh.I only use serial port to connect. 4.I can't use the reboot command to restart,I input "reboot",It didn't respond. Time automatically changed to 1978. I hope you can help me solve this problem,Thanks very much.
  18. update: the 5.59.180828 nightly building version may display a error temperature degree。 test real temperature using a thermometer ,two version display the same degree in thermometer about 49degree idle。 1. same board:orange pi zero plus v1.1,same room temp. 2. armbian 5.59.180828 nightly , idle cpu temp. about:49 degree. ------------------------------------------------------------------------------------------------------------- Welcome to ARMBIAN 5.59.180828 nightly Debian GNU/Linux 9 (stretch) 4.14.67-sunxi64 Linux opizeroh5 4.14.67-sunxi64 #85 SMP Tue Aug 28 10:55:16 CEST 2018 aarch64 GNU/Linux Stop monitoring using [ctrl]-[c] Time CPU n/a load %cpu %sys %usr %nice %io %irq CPU 12:30:54: --- 0.00 1% 0% 0% 0% 0% 0% 49.4°C 12:31:00: --- 0.00 0% 0% 0% 0% 0% 0% 49.2°C 12:31:05: --- 0.00 0% 0% 0% 0% 0% 0% 49.4°C 12:31:10: --- 0.00 0% 0% 0% 0% 0% 0% 49.2°C 12:31:15: --- 0.00 0% 0% 0% 0% 0% 0% 49.5°C 12:31:20: --- 0.00 0% 0% 0% 0% 0% 0% 49.0°C 12:31:25: --- 0.00 0% 0% 0% 0% 0% 0% 48.9°C 12:31:30: --- 0.00 0% 0% 0% 0% 0% 0% 49.0°C 12:31:35: --- 0.00 0% 0% 0% 0% 0% 0% 48.6°C 12:31:40: --- 0.00 0% 0% 0% 0% 0% 0% 49.0°C 12:31:45: --- 0.00 0% 0% 0% 0% 0% 0% 49.4°C ------------------------------------------------------------------------------------------------------------- 2. ARMBIAN 5.83 stable idle cpu temp. about:57 degree. Welcome to ARMBIAN 5.83 stable Debian GNU/Linux 9 (stretch) 4.19.38-sunxi64 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 04:37:59: 120MHz 0.09 1% 1% 0% 0% 0% 0% 57.6°C 0/6 04:38:04: 120MHz 0.08 1% 1% 0% 0% 0% 0% 57.5°C 0/6 04:38:09: 120MHz 0.07 1% 0% 0% 0% 0% 0% 57.4°C 0/6 04:38:15: 120MHz 0.07 1% 0% 0% 0% 0% 0% 57.5°C 0/6 04:38:20: 1008MHz 0.06 3% 1% 1% 0% 0% 0% 57.7°C 0/6 04:38:25: 120MHz 0.06 1% 0% 0% 0% 0% 0% 57.5°C 0/6 04:38:30: 120MHz 0.05 1% 1% 0% 0% 0% 0% 57.6°C 0/6 04:38:35: 120MHz 0.05 1% 1% 0% 0% 0% 0% 57.4°C 0/6 thanks
  19. Hello all, Recently, I bought an Orange Pi Win Plus board and have installed Armbian on SDcard and it works fine but when i try to install it on emmc using "sudo nand-sata-install" it just shows "install/update the bootloader on SD/eMMC" in the options instead of "boot from eMMC - system on eMMC" as i have seen on the internet . so guys! what am i doing wrong!? Regards,
  20. board: image: Armbian Bionic mainline based kernel 4.19.38 from There are two SPI separated buses with separated pins on NanoPi Core: SPI0 and SPI1 /boot/armbianEnv.txt: ... overlay-prefix=sun8i-h3 overlays=analog-codec i2c0 spi-spidev uart1 usbhost3 param_spidev_spi_bus=0 ... /dev/spidev0.0 presents How to activate a SPI1?
  21. I compared two boards (opi zero h3 and opi zero plus h5) and found that cpu pins for 26 gpio are the same . so I modify the code in wiringPi about cpu detection to force return true value . and it works. the step: 1. git clone 2. modify the code in WiringOP-Zero/wiringPi/wiringPi.c (or using the attached file to replace)。 3. make && make install 4. run "gpio readall " to test 5. run "gpio write 30 1" (the red-led on, wiringpi pin 30 control red-led status). wiringPi.c
  22. Hey guys, I've spent the last couple of weeks trying to get a TFT display with touch screen to work on my Orange Pi PC board, and I've decided to share my step-by-step solution here. This tutorial is heavily based on Guide: How to use Touchscreen + LCD on H3 devices by Kutysam, but I had to do some extra steps for it to work properly. This tutorial is only for Mainline kernel, I was able to get the graphical screen working with Kutysam's guide for Legacy, but couldn't make the touch work. First of all this is the display I'm using: LCD module Pi TFT 3.5 inch (320*480) Touchscreen Display Module TFT for Raspberry Pi 3. I believe it is a clone of this Waveshare screen. Also, I am using the image Armbian_5.38_Orangepipc_Debian_stretch_next_4.14.14_desktop, but it should work for the headless version (server) too, if you install a display manager, desktop environment and the X server. All the commands below are assumed to be run as root user. If you're not root, add "sudo" to the beginning of each command. --- Preparation First of all make sure you have the latest package updates by running apt-get update && apt-get upgrade This might take a while. If the packages have been installed successfully, reboot. On a fresh install I was getting the following error message: If that happens to you, just run the command again and it should download everything properly. If it still isn't working you could try cleaning the apt cache. After that, install these Make prerequisites: apt-get install build-essentials For some reason the linux-headers package for sunxi is not included in the repository, this thread might explain it better than me. Either way, download and install the package with dpkg: wget dpkg -i linux-headers-next-sunxi_5.41_armhf.deb Now we need to edit armbianEnv.txt to enable the overlays for spi and cs1 nano /boot/armbianEnv.txt Add the following lines to the end of the file (Be careful with spaces in the end of the lines... I lost a couple of days trying to figure out what the problem was when I had an extra space after "param_spidev_spi_bus=0" ) overlays=spi-spidev spi-add-cs1 param_spidev_spi_bus=0 param_spidev_spi_cs=1 And reboot. Screen Now we need to configure fbtft and fbtft_device on boot. Note: I had to put "98" in the start of the filename, or else I'd get the following error: "fbtft_device: spi_busnum_to_master(0) returned NULL" in dmesg after I installed the touchscreen. I believe it has something to do with the load order, so if you're having problems with this file you could try changing the prefix to 99 or removing it. nano /etc/modules-load.d/98-fbtft.conf Insert the following on the file: fbtft fbtft_device Now we have to load fbtft_device options on boot. Open the file with: nano /etc/modprobe.d/fbtft.conf Add the following: options fbtft_device rotate=90 name=piscreen speed=16000000 gpios=reset:2,dc:71 txbuflen=32768 fps=25 And reboot. At this point your screen should at least turn black. For me, the GUI wouldn't load unless I typed 'startx' on the console. So this is how I fixed it to always display the GUI on boot: apt-get install xserver-xorg-video-fbdev nano /usr/share/X11/xorg.conf.d/99-fbdev.conf Insert this in the file: Section "Device" Identifier "piscreen" Driver "fbdev" Option "fbdev" "/dev/fb0" EndSection At this point the screen should be displaying the Armbian GUI, with mouse and keyboard working, but without touch screen. Let's fix that. Touch First we need to download and compile the ads7846 driver (apparently it is compatible with xpt2046). mkdir ds7846 cd ds7846 wget mv ads7846.c?format=raw ads7846.c nano Makefile Insert the following on the makefile: obj-m := ads7846.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) all: $(MAKE) -C $(KDIR) M=$(PWD) modules clean: $(MAKE) -C $(KDIR) M=$(PWD) clean install: $(MAKE) -C $(KDIR) M=$(PWD) modules_install Now let's compile and load the module into the kernel: make make install depmod Now we'll build and install the ads7846_device module from fbtft_tools: cd .. git clone cd fbtft_tools/ads7846_device make make install depmod Let's load ads7846 and ads7846_device on boot sudo nano /etc/modules-load.d/99-ads7846.conf After that let's load the options for ads7846_device. These configs worked best for me, but you can play with them and tweak if needed. nano /etc/modprobe.d/ads7846_device.conf Insert the following: options ads7846_device model=7846 cs=1 gpio_pendown=1 keep_vref_on=1 swap_xy=1 pressure_max=255 x_plate_ohms=60 x_min=200 x_max=3900 y_min=200 y_max=3900 Reboot, and the touch should be working! Well, for me not entirely. The Y axis seemed to be reversed, so here are the steps I took to configure it: First of all, we need xinput to configure the touch screen options. Install it with this command: apt-get install xinput Now we need to set the "swap_xy" option to 0 in ads7846_device configuration file. Open it with: nano /etc/modprobe.d/ads7846_device.conf Replace its contents with this: options ads7846_device model=7846 cs=0 gpio_pendown=1 keep_vref_on=1 swap_xy=0 pressure_max=255 x_plate_ohms=60 x_min=200 x_max=3900 y_min=200 y_max=3900 Reboot to apply the changes. Now we need to find out the touchscreen name on xinput. Run this command: DISPLAY=:0.0 xinput list You should get a list of pointer devices, and the touchscreen should be on it. In my case the name is 'ADS7846 Touchscreen'. At this point you might get an "unable to connect to X server error". If that's the case, you can add the required X permissions for your user with the command (taken from this ask ubuntu answer): export XAUTHORITY=$(eval echo ~`who | grep tty7 | sed 's/\([a-z]*\).*/\1/'`)/.Xauthority And "xinput list" should be working. Now we can try to configure it with xinput's "set-prop" parameter: DISPLAY=:0.0 xinput --set-prop 'ADS7846 Touchscreen' 'Coordinate Transformation Matrix' 0 -1 1 1 0 0 0 0 1 Test your display to see if it works. This matrix worked best for me, but you might need to tweak it. Refer to this guide for more info on how coordinate transformation matrices work. Now you need to run this command every time the session starts. To automate it, I added the command to the .xsessionrc file: nano /home/{your username}/.xsessionrc Append the xinput set-prop command: DISPLAY=:0.0 xinput --set-prop 'ADS7846 Touchscreen' 'Coordinate Transformation Matrix' 0 -1 1 1 0 0 0 0 1 If you have multiple users logging in the session displayed on your screen, you might need to add this file for every user. ".xsessionrc" was the only file where I could get this working. And that's it! Your display + touch screen should be working properly now! I am still very newbie with Armbian and single board computers, and there is much I don't understand yet, so if you have any questions, comments or suggestions on this guide please post them below. See you all.
  23. Hello, I want to read data from UART3 on OrangePi One. I want to use UART3 (pin 8 & 10), so I enabled uart3 overlay at /boot/armbianEnv.txt. Now I expect to read data via minicom -b 115200 -D /dev/ttyS3 but I read nothing unfortunately. What am I missing? Any help is appreciated. I'm using Linux orangepione 4.19.38-sunxi (sorry, armbianmonitor doesn't generate link) Thank you, Regards
  24. Banana Pi M1+, kernel 4.19.38-sunxi, Debian stretch I needed to get bus i2c-2 working so I went to armbian-config, ticked i2c-2. After reboot I found some information from PMU were missing, some i2c buses were removed and some added. before crw-rw---- 1 root i2c 89, 0 May 26 18:24 /dev/i2c-0 crw-rw---- 1 root i2c 89, 1 May 26 18:24 /dev/i2c-1 after crw-rw---- 1 root i2c 89, 2 Jun 11 10:29 /dev/i2c-2 crw-rw---- 1 root i2c 89, 3 Jun 11 10:29 /dev/i2c-3 crw-rw---- 1 root i2c 89, 4 Jun 11 10:29 /dev/i2c-4 armbianEnv.txt verbosity=0 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun7i-a20 rootdev=UUID=078696dc-d479-4821-8b2f-47fa5c0e05f1 rootfstype=btrfs fdtfile=sun7i-a20-bananapi-m1-plus.dtb extraargs=net.ifnames=0 biosdevname=0 overlays=i2c2 w1-gpio param_w1_pin=PI18 param_w1_pin_int_pullup=1 usbstoragequirks=0x152d:0x1561:u,0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x61b7:u,0x152d:0x9561:u I found i2c-1 changed to i2c-4: before after So I tried "overlays=i2c2 w1-gpio" to "overlays=i2c0 i2c1 i2c2 w1-gpio" in armbianEnv.txt but after another reboot i2c-0 bus was still missing. crw-rw---- 1 root i2c 89, 1 Jun 11 10:58 /dev/i2c-1 crw-rw---- 1 root i2c 89, 2 Jun 11 10:58 /dev/i2c-2 crw-rw---- 1 root i2c 89, 3 Jun 11 10:58 /dev/i2c-3 crw-rw---- 1 root i2c 89, 4 Jun 11 10:58 /dev/i2c-4 Swapping i2c1 and i2c4 in rpimonitor config files is not big problem for me, it takes lest than 1 minute, but with i2c-0 missing I lost access to information what is undefined in the picture bellow and I do not know how can I get i2c-0 and i2c-2 working at once. Note: This device was connected to poor power source, this is reason why USB voltage is low(4.372V) and battery charging was going very slowly (20mA). This was not I believe affecting badly this test :-).
  25. Hello, I have a massive problem as the time/date on my Pine64 keep changing randomly to the year 2113. In my project, I use several Pine64s and the problem now occurs on many of these Pine64s. Unfortunately I need the correct time for my project. I am using the following system: ARMBIAN 5.32.170911 nightly Ubuntu 16.04.3 LTS 4.13.0-sun50iw1 (with additional overlays = uart3 and console = ttyS3) Could this be due to the error described in the post and is the bug fixed in kernel version 4.14? Could I install this kernel version 4.14 via armbian-config (next-kernel)? Thanks a lot for help.