Search the Community

Java Periphery has finally been released! Java Periphery is a high performance library for GPIO, LED, PWM, SPI, I2C, MMIO and Serial peripheral I/O interface access in userspace Linux. This will replace User Space IO. I'm seeing GPIO write speeds of 500K/s from userspace. Compared to User Space IO and libgopid speeds of 2K/s. I switched from JNA wrapper generation to JNI wrapper generation. The build process is much simpler (only single install.sh) and building libgpiod is no longer required. The API follows c-periphery, python-periphery and lua-periphery. This should cover the widest array of SBCs and languages around. Java Periphery should work on Armbian/Ubuntu/Debian, but also other non-Armbian distributions. If you run into issues please use Github issues to report. Nano Pi Duo 13:30:43.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 13:31:23.062 [main] INFO com.codeferm.periphery.demo.GpioPerf - 500613.25 writes per second 13:31:23.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 13:31:54.471 [main] INFO com.codeferm.periphery.demo.GpioPerf - 318440.91 reads per second Nano Pi Neo Plus 2 15:06:51.946 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 15:07:22.522 [main] INFO com.codeferm.periphery.demo.GpioPerf - 654964.63 writes per second 15:07:22.524 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 15:07:46.696 [main] INFO com.codeferm.periphery.demo.GpioPerf - 413770.27 reads per second

Hello, I'm currently running Gentoo on my BananaPIs (M1). I'm using one as graphical Dashboard using DirectFB. Unfortunately, DirectFB is deprecated, not anymore supported and facing some compilation issue. Time to change. I tried with SDL configured with KMS but it's crashing. I don't want to install X because it will take ages to compile without any garanty it will work at the end. So ... probably the time to change. So, is DirectFB still supported on Armbian ? If not, is SDL2 working without X support. If not, with X support ? And if so, is X accelerated ? Thanks Laurent

Goodmorning, i would like to ask if someone have ever tried to use musl libc with Armbian. From some research appear that using it instead of glibc make programs consume a lot less ram and less space on disk. I never tried personally, but i'm curious about that because it could be especially useful for single board computer with less than 2gb of ram (like mine ). Since, from what i know, programs do not statically link to glibc, but dynamically link to a generic libc at runtime, could be possible to use musl as drop in replacement for libc, without rebuild everything? From what i know there could be some incompatibilities because glibc does not fully respect the standards of libc, but i would like to know some opinions and experiences. Thanks for listening, have a good day

I'm setting up a new Armbian system from a cold start. I ran armbian-config and used the personal > welcome option to set the MOTD_DISABLE options in /etc/defaults/armbian-motd. It did not do anything to the welcome screen. I asked for the header tips and updates to be excluded. Looking at the resulting /etc/defaults/armbian-motd file : netadmin@ups-monitor:/etc/update-motd.d$ cat /etc/default/armbian-motd # add space-separated list of MOTD script names (without number) to exclude them from MOTD # Example: # MOTD_DISABLE="header tips updates" MOTD_DISABLE="" ONE_WIRE="" # yes = show 1-wire temperature sensor if attached netadmin@ups-monitor:/etc/update-motd.d$ The edit has been applied, but to the comment line, not the actual MOTD_DISABLE line. I don't know where the script that takes the action is located to check it, but I guess this is not intentional, and thus it needs to be updated to ignore lines beginning with # Second point, I'm reasonably sure, some time back, I put in a change to modify the script 41-armbian-config to change it's THIS_SCRIPT line to "config" rather than "armbian-config", so that it's disable syntax matched the other files in the set. At the moment, on a fresh install, it still needs armbian-config in the MOTD_DISABLE line. My build today is: Has that pull request got lost somewhere ? Harry

hello, do you already have SUBJ ? Thank you

Hi, Armbian gurus, I'm trying to make the build system to build image with LibreELEC kernel tree for PineH64 I heard the kernel is patched for being better at hardware decoding Here are what I have done in order: 1. Retrieve patched kernel tree from LibreELEC build system. Upload the patched kernel tree to my gitlab account. 2. Modify config/sources/families/include/sunxi64_common.inc to make KERNEL_SOURCE = my previous repo; KERNELBRACH = master. To make it fetchable during bilding. 3. Modify lib/compilation-prepare.sh: skip aufs patch. 4. Modify lib/compilation.sh: skip advanced_patch in compile_kernel() After all these hassle, I can use compile.sh to build an Armbian 64 bit image with the 5.5.6 patched. BUT unfortunately, I flash the image and found it cannot boot properly. So here are my question: 1. How do you typically debug boot problem for PineH64. 2. Do you think anything could go wrong in those procedure? 3. Do I need to upgrade u-boot as well? It's using v2019.10 as far as I can tell. Thank you.

Hi there, I am about to use an OrangePi Zero to handle the temperature and display some information on a custom contraption related to network. The problem I have is that this contraption will be powered on and powered off at will, without notice. So... I guess that after some time, the Zero running Armbian won't be that happy about being shut off brutally. I have seen some setups with supercapacitors for Raspberry Pis, but has anyone in here tried something similar with the OrangePi Zero? Or anything else that would delay the power loss, so that the board can shutdown properly? I made searches about supercapacitors with Armbian, but only found some information related to RTC (which would be nice to have too...). Thanks!

Found an old (2015) Ugoos UT3+ / UT3 Plus with an rk3288 - the neat thing about this board is it has HDMI-IN ! Also has PIP Specs: I'm was eventually able to successfully screen capture @ 1920 x 1080 ~29 fps using the Android 5.1.1 firmware V3.0.7 for UT3+ https://mega.nz/#!cQpl0ICS!8EgHddI3_PXQsSe-TSrkHfxdHCmkbckNWBYuLhfuA7w The firmware crashes frequently and the painful part is the IR remote is required to start recording.. so I'll be porting gentoo / armbian to this device to turn this paper weight into a linux friendly screen capture device. It maybe also worthwhile to document the process and create an armbian porting guide. Aside, for those interested, its worth to mention the LKV373A HDMI / ethernet sender is a potential $30 HDMI screen capture alternate.

Since I've seen some really weird disk/IO benchmarks made on SBCs the last days and both a new SBC and a new SSD arrived in the meantime I thought let's give it a try with a slightly better test setup. I tested with 4 different SoC/SBC: NanoPi M3 with an octa-core S5P6818 Samsung/Nexell SoC, ODROID-C2 featuring a quad-core Amlogic S905, Orange Pi PC with a quad-core Allwinner H3 and an old Banana Pi Pro with a dual-core A20. The device considered the slowest (dual-core A20 with just 960 MHz clockspeed) is the fastest in reality when it's about disk IO. Since most if not all storage 'benchmarks' for SBC moronically focus on sequential transfer speeds only and completely forget that random IO is way more important on any SBC (it's not a digital camera or video recorder!) I tested this also. Since it's also somewhat moronically when you want to test the storage implementation of a computer to choose a disk that is limited the main test device is a brand new Samsung SSD 750 EVO 120GB I tested first on a PC whether the SSD is ok and to get a baseline what to expect. Since NanoPi M3, ODROID-C2 and Orange Pi PC only feature USB 2.0 I tested with 2 different USB enclosures that are known to be USB Attached SCSI (UAS) capable. The nice thing with UAS is that while it's an optional USB feature that came together with USB 3.0 we can use it with more recent sunxi SoCs also when running mainline kernel (A20, H3, A64 -- all only USB 2.0 capable). When clicking on the link you can also see how different USB enclosures (to be more precise: the included USB-to-SATA bridges used) perform. Keep that in mind when you see 'disk performance' numbers somewhere and people write SBC A would be 2MB/s faster than SBC B -- for the variation in numbers not only the SBC might be responsible but this is for sure also influenced by both the disk used and enclosure / USB-SATA bridge inside! The same applies to the kernel the SBC is running. So never trust in any numbers you find on the internet that are the results of tests at different times, with different disks or different enclosures. The numbers presented are just BS. The two enclosures I tested with are equipped with JMicron JMS567 and ASMedia ASM1153. With sunxi SBCs running mainline kernel UAS will be used, with other SoCs/SBC or running legacy kernels it will be USB Mass Storage instead. Banana Pi Pro is an exception since its SoC features true SATA (with limited sequential write speeds) which will outperform every USB implementation. And I also used a rather fast SD card and also a normal HDD with this device connected to USB with a non UASP capable disk enclosure to show how badly this affects the important performance factors (again: random IO!) I used iozone with 3 different runs: 1 MB test size with 1k, 2k and 4k record sizes 100 MB test size with 4k, 16k, 512k, 1024k and 16384k (16 MB) record sizes 4 GB test size with 4k and 1024k record sizes The variation in results is interesting. If 4K results between 1 and 100 MB test size differ you know that your benchmark is not testing disk througput but instead the (pretty small) disk cache. Using 4GB for sequential transfer speeds ensures that the whole amount of data exceeds DRAM size. The results: NanoPi M3 @ 1400 MHz / 3.4.39-s5p6818 / jessie / USB Mass Storage: Sequential transfer speeds with USB: 30MB/s with 1MB record size and just 7.5MB/s at 4K/100MB, lowest random IO numbers of all. All USB ports are behind an USB hub and it's already known that performance on the USB OTG port is higher. Unfortunately my SSD with both enclosures prevented negotiating an USB connection on the OTG port since each time I connected the SSD the following happened: WARN::dwc_otg_hcd_hub_control:2544: Overcurrent change detected ) ODROID-C2 @ 1536 MHz / 3.14.74-odroidc2 / xenial / USB Mass Storage: Sequential transfer speeds with USB: ~39MB/s with 1MB record size and ~10.5MB/s at 4K/100MB. All USB ports are behind an USB hub and the performance numbers look like there's always some buffering involved (not true disk test but kernel's caches involved partially) Orange Pi PC @ 1296 MHz / 4.7.2-sun8i / xenial / UAS: Sequential transfer speeds with USB: ~40MB/s with 1MB record size and ~9MB/s at 4K/100MB, best random IO with very small files. All USB ports are independant (just like on Orange Pi Plus 2E where identical results will be achieved since same SoC and same settings when running Armbian) Banana Pi Pro @ 960 MHz / 4.6.3-sunxi / xenial / SATA-SSD vs. USB-HDD: This test setup is totally different since the SSD will be connected through SATA and I use a normal HDD in an UAS incapable disk enclosure to show how huge the performance differences are. SATA sequential transfer speeds are unbalanced for still unknown reasons: write/read ~40/170MB/s with 1MB record size, 16/44MB/s with 4K/100MB (that's huge compared to all the USB numbers above!). Best random IO numbers (magnitudes faster since no USB-to-SATA bottleneck as with every USB disk is present). The HDD test shows the worst numbers: Just 29MB/s sequential speeds at 1MB record size and only ~5MB/s with 4K/100MB. Also the huge difference between the tests with 1MB vs. 100MB data size with 4K record size shows clearly that with 1MB test size only the HDD's internal DRAM cache has been tested (no disk involved): this was not a disk test but a disk cache test only. Lessons to learn? HDDs are slow. Even that slow that they are the bottleneck and invalidate every performance test when you want to test the performance of the host (the SBC in question) With HDDs data size matters since you get different results depending on whether the benchmark runs inside the HDD's internal caches or not. SSDs behave here differently since they do not contain ultra-slow rotating platters but their different types of internal storage (DRAM cache and flash) do not perform that different When you have both USB and SATA not using the latter is almost all the time simply stupid (even if sequential write performance looks identical. Sequential read speeds are way higher, random IO will always be superiour and this is more important) It always depends on the use case in question. Imagine you want to set up a lightweight web server dealing with static contents on any SBC that features only USB. Most of the accessed files are rather small especially when you configure your web server to deliver all content already pre-compressed. So if you compare random reads with 4k and 16k record size and 100MB data size you'll notice that a good SD card will perform magnitudes faster! For small files (4k) it's ~110 IOPS (447 KB/s) vs. 1950 IOPS (7812 KB/s) so SD card is ~18 times faster, for 16k size it's ~110 IOPS (1716 KB/s) vs. 830 IOPS (13329 KB/s) so SD card is still 7.5 times faster than USB disk. File size has to reach 512K to let USB disk perform as good as the SD card! Please note that I used a Samsung Pro 64GB for this test. The cheaper EVO/EVO+ with 32 and 64GB show identical sequential transfer speeds while being a lot faster when it's about random IO with small files. So you save money and get better performance by choosing the cards that look worse by specs! Record size always matters. Most fs accesses on an SBC are not large data that will be streamed but small chunks of randomly read/written data. Therefore check random IO results with small record sizes since this is important and have a look at the comparison of 1MB vs. 100 MB data size to get the idea when you're only testing your disk's caches and when your disk in reality. If you compare random IO numbers from crap SD cards (Kingston, noname, Verbatim, noname, PNY, noname, Intenso, noname and so on) with the results above then even the slow HDD connected through USB can shine. But better SD cards exist and some pretty fast eMMC implementations on some boards (ODROID-C2 being the best performer here). By comparing with the SSD results you get the idea how to improve performance when your workload depends on that (desktop Linux, web server, database server). Even a simple 'apt-get upgrade' when done after months without upgrades heavily depends on fast random IO (especially writes). So by relying on the usual bullshit benchmarks only showing sequential transfer speeds a HDD (30 MB/s) and a SD card (23 MB/s) seem to perform nearly identical while in reality the way more important random IO performance might differ a lot. And this solely depends on the SD card you bought and not on the SBC you use! For many server use cases when small file accesses happen good SD cards or eMMC will be magnitudes faster than HDDs (again, it's mostly about random IO and not sequential transfer speeds). I personally used/tested SD cards that show only 37 KB/s when running the 16K random write test (some cheap Intenso crap). Compared to the same test when combining A20 with a SATA SSD this is 'just' over 800 times slower (31000 KB/s). Compared to the best performer we currently know (EVO/EVO+ with 32/64GB) this is still 325 times slower (12000 KB/s). And this speed difference (again: random IO) will be responsible for an 'apt-get upgrade' with 200 packages on the Intenso card taking hours while finishing in less than a minute on the SATA disk and in 2 minutes with the good Samsung cards given your Internet connection is fast enough.

Just got this error at the very end of a build. [ o.k. ] Checking git sources [ linux-firmware-git master ] fatal: unable to access 'https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/': The requested URL returned error: 504 [ .... ] Fetching updates fatal: unable to access 'https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/': The requested URL returned error: 504 [ .... ] Checking out error: pathspec 'FETCH_HEAD' did not match any file(s) known to git. I checked a very few minutes later and the URL https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ did eventually respond with a reasonable page, though with a huge delay. Presume that git.kernel.org had a problem, and returned the 504 error, not that the build system timed out waiting, but maybe wiser heads than me can check. If it was just lag, we may see a lot more of this sort of error, given the load on the internet at the moment.... Harry

I have a supported build host running, and successfully building and testing kernels for a few targets that I have examples of. I'm looking to extend my repertoire to building complete armbian images. I think I also want to use EXTERNAL and/or EXTERNAL_NEW to configure additional packages into the image. This has led me to this stanza: BUILD_MINIMAL (yes|no): set to “yes” to build bare CLI image suitable for application deployment. This option is not compatible with BUILD_DESKTOP=”yes” and BUILD_EXTERNAL=”yes” I can find no BUILD_EXTERNAL referenced elsewhere, should this be simply EXTERNAL ? or have I missed something. Is there documentation on how EXTERNAL and EXTERNAL_NEW parameters are invoked? Harry

Hello together, I need help to build a new ARMBIAN - Image based on DEBIAN fort this board: https://www.tq-group.com/de/produkte/tq-embedded/arm-architektur/stka8mx/ Can anyone help me with building, etc. for this board? Best regards Matthias

In my browsing I have just stumbled across this... https://tibbo.com/store/plus1.html Basic rundown Here are the key characteristics of the SP7021, the first member of the new PLUS1 line: Easy-to-use LQFP package. Quad-core 1GHz Cortex-A7 CPU, plus A926 and 8051 cores. Single 3.3V power*. Integrated 128MB or 512MB DDR3 DRAM. Eight 8-bit 5V-tolerant IO ports, plus one high-current port. Flexible Peripheral Multiplexing (PinMux). Dual PinMuxable Ethernet MACs. Four PinMuxable Enhanced UARTs, plus one console UART. Industrial operating temperature range: -40C ~ +85C. Low EMI simplifies certification. Modern, Yocto-based Linux distribution. Might do a bring up on a couple of boards and see how it goes... Just thought it was cool and others might find it that way too EDIT1: More detailed info can be found here https://sunplus-tibbo.atlassian.net/wiki/spaces/doc/overview

Using systemd-networkd for network management on a small cluster of orangepi r1's and an orangepi zero. All are connected to a single TP-Link 8 port gigabit switch. Version of systemd-networkd is what is shipping in the current armbian buster image networkctl --version systemd 241 (241) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid All four devices are configured to emit lldp and to monitor lldp. All devices are emitting lldp, seen here from one of the four devices. netadmin@probe1:~$ tshark ether proto 0x88cc Capturing on 'eth0' 1 0.000000000 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 2 13.009395698 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 3 13.999563625 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 4 15.953929402 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 5 30.255577659 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 6 43.011986058 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 7 44.249476615 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 8 45.954353503 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 9 60.259316364 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 10 73.014544815 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 11 74.249343777 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 12 75.955214745 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor ^C12 packets captured netadmin@probe1:~$ However networkctl only ever shows two neighbors at the orangepi R1s and only one at the Orangepi zero (ups-monitor) netadmin@probe1:~$ networkctl lldp -a LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe3 .......a... eth0 \"probe3 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: o - Other; p - Repeater; b - Bridge; w - WLAN Access Point; r - Router; t - Telephone; d - DOCSIS cable device; a - Station; c - Customer VLAN s - Service VLAN; m - Two-port MAC Relay (TPMR) 2 neighbors listed. netadmin@probe1:~$ From an r1: netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe2 .......a... eth0 \"probe2 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe3 .......a... eth0 \"probe3 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe3 .......a... eth0 \"probe3 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe3 .......a... eth0 \"probe3 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe1:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe2 .......a... eth0 \"probe2 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. From the zero: netadmin@ups-monitor:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe1 .......a... eth0 \"probe1 uplink… Capability Flags: a - Station 1 neighbors listed. netadmin@ups-monitor:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe2 .......a... eth0 \"probe2 uplink… Capability Flags: a - Station 1 neighbors listed. netadmin@ups-monitor:~$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe2 .......a... eth0 \"probe2 uplink… Capability Flags: a - Station 1 neighbors listed. netadmin@ups-monitor:~$ tshark ether proto 0x88cc Capturing on 'eth0' 1 0.000000000 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 2 1.440290330 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 3 4.231811986 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 4 19.653023845 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 5 30.282432096 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 6 31.720208055 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 7 34.481361824 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 8 49.931488643 02:42:63:e3:6a:8f → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe2 9 60.550552316 02:42:45:92:9d:96 → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe3 10 61.986085939 02:42:1c:e9:eb:be → LLDP_Multicast LLDP 93 TTL = 120 System Name = probe1 ^C 11 64.480995938 02:42:8e:41:09:de → LLDP_Multicast LLDP 103 TTL = 120 System Name = ups-monitor 11 packets captured netadmin@ups-monitor:~$ It's as the neighbor table has one, and only one "neighbor" slot for each interface. Which seems crazy, but i'm not familiar enough with the code to check... Harry

This "motd" fragment has a bug/inconsistency. # any changes will be lost on board support package update THIS_SCRIPT="armbian-config" MOTD_DISABLE="" /etc/defaults/armbian-motd has : # add space-separated list of MOTD script names (without number) to exclude them from MOTD # Example: # MOTD_DISABLE="header tips updates" This works correctly for the other "motd" fragments which contain, for instance : THIS_SCRIPT="sysinfo" MOTD_DISABLE="" but fails to disable 41-armbian-config unless the MOTD_DISABLE string includes armbian-config. I've verified that nothing untoward happens if you change 41-armbian-config to THIS_SCRIPT="config" MOTD_DISABLE="" and suppression then occurs correctly with /etc/defaults/armbian-motd set to: # add space-separated list of MOTD script names (without number) to exclude them from MOTD # Example: # MOTD_DISABLE="header tips updates" MOTD_DISABLE=" header tips updates config" ONE_WIRE="" # yes = show 1-wire temperature sensor if attached On a separate, but related note, I do use the 30-armbian-sysinfo script. However my version has a minimally modified output. My modified version first. System load: 0.02 0.01 0.00 Up time: 1:18 hour Memory usage: 29 % of 238MB Zram usage: 16 % of 119Mb IP: eth0: 192.168.1.5 CPU temp: 43°C Usage of /: 5% of 29G System load: 0.02 0.01 0.00 Up time: 1:18 hour Memory usage: 29 % of 238MB Zram usage: 16 % of 119Mb IP: 192.168.1.5 CPU temp: 44°C Usage of /: 5% of 29G Note the IP information starting on a new line, and the interface information included. netadmin@probe3:~$ diff ~/motd/30-armbian-sysinfo /etc/update-motd.d/30-armbian-sysinfo 141c141 < [[ -n $tmp ]] && ips+=("$intf: $tmp") --- > #[[ -n $tmp ]] && ips+=("$intf: $tmp") 143c143 < #[[ -n $tmp ]] && ips+=("$tmp") --- > [[ -n $tmp ]] && ips+=("$tmp") 199c199 < printf "\nIP: " --- > printf "IP: " I prefer my version. I'm very much a newbie on this board, I have no idea where to post the suggestion. Cheers Harry

I've installed a wireless alarm system, but I want to use all my old wired stuff from my original alarm system. I started down the road of using an ESP8266, but GPIO.INT was flaky and GPIO pins limited, so I ordered a MCP23017 and figured Why not just do everything with one NanoPi Duo? I have a few of them and they are made for breadboard prototyping. Plus with the built in Ethernet I can have wired primary and wireless backup networking. I even rolled my own Ethernet adapter since the breakout adapters cost $5+. If you have already done this and have any wisdom to share I'd like to hear it. No turning back now!

Hi, i own a Libre Computer Le Potato (AML-S905X-CC) board and i would like to compile my own customized kernel to try patches for bug fixing and experimenting unstable "features", like lima driver. The problem is that i currently use this board as daily driver and i would like the possibility to have a backup kernel (a stable one) in case something goes wrong. So the question is: it is possible to have multiple installed kernel and decide which one boot (like GRUB behaviour) using the uboot bootloader? If it is impossible, i'm sorry for the stupid question. I don't know how exactly the boot sequence works, from a low level point of view. Thanks a lot for the attention and the dedicated time.

Where are the Odroid C1 images? This page is empty: https://dl.armbian.com/odroidc1/archive/ What is/was the latest stable Debian? I don't need Desktop but sound should work over HDMI. Its to bad the C1 has no support anymore. Seems to be the only board that does up to 384kHz Audio.

I'm currently on the hunt for the cheapest decently reliable board to use for building a glusterfs cluster. Requirements are simple: GbE, SATA port, arm64, preferably low power. While helios64 is obviously the way to go for a NAS when it lands, it's totally overkill for a setup like this and I just realized that ODROID HC2 won't fly due to being 32-bit only. Most other 64-bit boards require expansion boards for SATA, which drags up the total cost. Finally I realized that the PC Engines APU boards fit all criteria, and come with what I understand to be performant GX-412TC CPUs. This one, for example, for 86EUR (maybe a bit on the pricey side, but I haven't found better actually): https://www.pcengines.ch/apu2d0.htm These boards are generally only used as router boards, and I am actually already using one as a router (which prevents me from doing tests myself right now unfortunately :P) Does anyone have any idea of if this is a Bad Idea or worth a shot? Looking at the specs I don't see an obvious reason why this wouldn't work. EDIT: While I guess an interesting topic to use these boards for other purposes, I realized now that the Espressobin looks more suitable at smaller size and lower cost at ~60EUR + shipping, so I think that's the best bet for now. EDIT2: Seems like GlusterFS has higher requirements than I thought and performs poorly with Gluster; this user got a measly 35Mbps (albeit with 5 disks): https://www.reddit.com/r/DataHoarder/comments/92zwct/espressobin_5drive_glusterfs_build_follow_up/. Redhat recommends 16GB minimum but surely it could be reasonable for home use with less... https://access.redhat.com/articles/66206 The APU has 2 instead of 4 cores and comes with in a 4GB version over the Espressobin's 2GB, so maybe it's the better alternative after all.

I noticed that on the Duo I can select 5.5.0-rc6-sunxi in dev. Is there any idea when 5.5.0 will be the default release? Also, I noticed that there's no matching 5.5.x kernel source. I'm playing with linux-headers-dev-sunxi to see if I can compile libgpiod master which requires 5.5.0.

howdy community, I am very keen on installing motioneye on my orangepi PC - Question: can i try Orange Pi PC Beta image with Xenial and mainline kernel with the Orange Pi One and Lite. i have heard that Motioneye (not os) works very well with Orange Pi PC when installed on top of Armbian-OS. It is told to be great for multiple network cameras as they are cheap and can run 2 cameras per SBC comfortably. i got 2 orange pi pc How should i go ahead: - installing ffmpeg. Otherwise it was the raspbian instructions on armbian. - Did anybody get armbian up and going properly before installing motioneye? btw: which camera do you suggest: for CSI camera you must stay on legacy. CSI on mainline is on WIP stage. should i take a good USB camera H264/MJPEG capable. links:; https://forum.armbian.com/topic/2168-motioneye-opi/ https://github.com/ccrisan/motioneyeos/issues/252

Hi! It seems http://www.cubieforums.com/ is dead (can't sign up), so may I ask here. Is anybody tried to install Android TV on a CubieTruck? I have armbian booting from Sd Card, so I want to have similar SD Card (128Gb), but with Android TV. So - is this possible? What version of Android TV we can use? links appreciated!

I have been playing around the Rock Pi S from radxa, and am stumbling at enabling the I2S output using a device tree overlay. (Building using current Armbain that uses @piter75's kernel branch) As per the data sheet and pinout, `i2s_8ch_0` should be broken out to the GPIO, but I don't seem to be getting far enabling it via the device tree. Any inputs? This is what I am playing around with atm, but `dmesg` doesn't show anything helpful atm, and no "I2S-Card" device turns up. Tried disabling the inbuilt audio codec ( connected to `i2s_8ch_2`), but still no dice. The closest example I could find was from `rk3308-ai-va-v10.dts`, that similarly enables the `i2s_8ch_0`, but am unable to mimic it. /dts-v1/; /plugin/; / { model = "Radxa ROCK Pi S"; compatible = "radxa,rockpis-rk3308", "rockchip,rk3308"; fragment@0 { target-path = "/"; __overlay__ { pcm5102a: pcm5102a { #sound-dai-cells = <0>; compatible = "ti,pcm5102a"; pcm510x,format = "i2s"; }; }; }; fragment@1 { target = <&i2s_8ch_0>; __overlay__ { status = "okay"; #sound-dai-cells = <0>; sound-dai = <&pcm5102a>; }; }; fragment@2 { target-path = "/"; __overlay__ { sound_i2s { compatible = "simple-audio-card"; simple-audio-card,name = "I2S-Card"; simple-audio-card,mclk-fs = <256>; simple-audio-card,format = "i2s"; status = "okay"; simple-audio-card,dai-link { format = "i2s"; codec { sound-dai = <&pcm5102a>; }; cpu { sound-dai = <&i2s_8ch_0>; }; }; }; }; }; };

https://forum.armbian.com/topic/11857-free-software-supported-wifi-card-phone-usable-esp8089-esp8266-esp32/ It says, that adding an usb ar9271 wifi card to a pinephone is not feasible because the wifi card uses to much power. How much power is acceptable for an usb ar9271 wifi card to use? I do not have extended equipment. I made the following arrangement. One pc. Connected an usb power meter. https://images-na.ssl-images-amazon.com/images/I/61fKDfC3pgL._AC_SL1000_.jpg Connected an usb ar9271 wifi card to the usb power meter. Started an youtube video. After that downloaded an ubuntu image. Distance to router about 10yards. One brick wall. Usb power meter displayed about 5.1v and 0.16a. Is that much? To much to use on a pinephone? The modem on the pinephone has an usb connection. About the modem, why is the power consumption not a problem? I know connecting an usb ar9271 wifi card to a samsung i9100 replicant phone is working terrible. Infrequent disconnects, battery power level has to be above 90%. Thanks.

Hi all. I've made a new video where I test all storage devices for the NanoPi M4. 8GB, 16GB and 32GB eMMC modules, NVMe drive, sd-card and SSD over USB3. Here's the video. Here's my gathered data. Storage speeds -------------- 8GB eMMC module read : 160 MB/s write : 11 MB/s 16GB eMMC module read : 175 MB/s write : 50 MB/s 32GB eMMC module read : 173 MB/s write : 111.6 MB/s 256GB NVMe read : 697.7 MB/s write : 401 MB/s (630MB/s for 2.5GB, then 300 MB/s) M4 sd-card read : 70 MB/s write : 20 MB/s M4 swap read : 1.9GB/s 0.01 msec access time Greetings, NicoD