Search the Community

Hi, A small discussion started here, but I would like to lift it to here. The question and tests should be. Are there alternatives to Etcher? A must was - standard writing verification. IIRC this was back in the days an option you had to set a 'tick' on Win32 DiskImager.. and so not an option. Before we change anything - proper testing and writing down the steps to achieve a great result is a must. Multiplatform, would be nice, but we can as well recommend 2 or 3 SDcard writing programs. Can you please help to write a table of available programs (you can do a table in the forum, but consider quantity of lines & rows first). And whether or not the software is an equivalent replacement for armbian? Please help us to collect here your knowledge and expericence Of course your recommendation should support the minimum mentioned above - otherwise it is not a recommendation but Spam Thank you in advance for your participation on this challenge

Dear Armbian community, we are looking for a low-power SBC with (deep sleep) / poweroff features for IoT applications. Arduino or any other MCU board are not suitable for doing our use cases, so we are investigating the use of an low-power SBC. i.MX6ULL (https://www.seeedstudio.com/NPi-i-MX6ULL-Dev-Board-Industrial-Grade-Linux-SBC-eMMC-Version-p-4221.html) has an integrated PMU with a lot of different low-power modes. Like SNVS mode, where only the power for the SNVS domain remain on. In this mode, only the RTC and tamper detection logic is still active This board is quietly new is there any possibility that this board can be supported by the Armbian community. Thankyou in advance. IMX6ULLIEC.pdf

Finally I got my lcd (some of them) to work with armbian on mainline kernel (5.4) using device tree overlay. It should be working on 4.19 kernel too. I test mine on orange pi zero. The one I am able to get working is ili9341 and st7735 based lcd. I'll add more detail later but for now I'd like to get this out. edit 1 : Adding ssd1306 and nokia 5110 overlay to the repo device tree overlay

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

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!

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

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.

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!

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

For the last few years I have been working on some hardware projects based on ARM SBCs. Every board I work with seems to have different kernel/overlay/GPIO/etc issues. So my question is - Which SBC, or chipset, has most complete and stable Armbian support? In other words if you had to pick a board to go into battle to run Armbian, without knowing any specific requirements, which SBC would it be?

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.

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!

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

the main proposal of this research is to enable cached apt archives for docker build. first apt cache can be saved by a docker volume, but due to `${SDCARD}/var/cache/apt/archives` is not a constant, then we can't use `-v=apt-cache:${SDCARD}/var/cache/apt/archives` to enable it. so I use `-v=apt-cache:/root/.apt` as a tmp place for apt cache, when need `apt install` in `${SDCARD}`, use `mount -o bind /root/.apt ${SDCARD}/var/cache/apt/archives` and after install finishes, `umount ${SDCARD}/var/cache/apt/archives` this looks perfect, but after I check /root/.apt, everything is gone. I double checked whether *.deb are saved to /root/.apt, I can find them before `umount`, or even use apt-cache in another container: `docker run --privileged --rm -v=apt-cache:/test -it ubuntu:18.04 bash` I can find debs in /test folder, and gone after `umount` I really don't know why.

Just curious, it has exists as patches for years, is there anything prevent it from being merged into mainline? This chip is quite widely used in TV boxes.

When building a kernel the device driver configuration asks which rtc should a system use for NTP and startup synchronisation . By default this is rtc0. The question is: In case there are more hardware RTCs in one embedded system ( in my case onboard RK808 and Dallas DS1307 over I2C), which one would be numbered as rtc0? Threre are several RTC device drivers available and checked by default, some marked as M and other as '*' , supposing 'module' or 'driver' respectively. Now if I have two hardware RTCs, I presume they should load as rtc0 and rtc1, but which part does numbering? I can't know this 'a priori' , I would like to use DS1307 for synchronisation.

What script is used in Armbian to build ram init image uInitrd?

mainline kernel support, libreelec is allready working. is there any chance on getting amrbian ported here, i allready did some test and made it boot, but network does not get an ip adress link with ethtool show up and 1 gbit. same for the eachlink device

As WiringPi was never meant to support other boards nor does the author like to support other boards and it is officially depreciated now (http://wiringpi.com/wiringpi-deprecated/). I want to ask why not put some efforts into libmraa https://github.com/intel-iot-devkit/mraa and put it into the Armbian repository. I have already a fork which fixes Rock Pi 4 on recent mainline 5.3 kernels with updated debian build scripts here: https://github.com/bootsy52/mraa, so debian packages could be simple built using dpgk-buildpackage. Why I think it is a good idea to supply libmraa with the Armbian repository Supporting multiple boards is a desired goal of the project Supporting a board is really easy, for Rock Pi for example this is just the files src/arm/rockpi4.c include/arm/rockpi4.h and an entry in src/arm/arm.c, that's it Instead of multiple forks of wiringPi and different sources of different versions (or even different gpio implementations) just have one common implementation for all boards with wiringPi you need additional bridges if you want to code in other languages like Java or Python for example, with MRAA you have out of the box bindings for Python, Java, Javascript, C/C++ and NodeJS support What do you think? @Igor

I'm creating this topic to track progress with support for EachLink H6 support. So far with patches in lines 127..202 in List of patches with patch files I was able to get: working: -boot with mainline 5.4 kernel -HDMI video (with correct DDC) -HDMI audio -Ethernet -GPU mali t720 -USB2/USB3 ports -CPU temp reading -DVFS (CPU freq scalling) -internal IR sensor (MCE remote works nicely) not tested: WiFi Blutooth This box might be cheap H6 box to become nice mediaplayer as current panfrost started to support really well t720 (I've got fully working GLES UI, playback with OpenG & yv12 renderers + GLSL based shader deinterlacers: OneFileld. LinearBlend & Kernel on mythtv). Only issue I had at this moment is insufficient cooling with stock cooler - so if You launch compute intensive tasks and Yours OPP has 1.8GHz cpu clock entries - after some time bow is self-reseting due overheated CPU. Solution seems to be: -lower max CPU clock in OPP tables to 1.4GHz or -add better cooler...

Today I noticed something strange about packages : armbian-config and armbian-firmware (bionic all) Repository version becomes 19.11.3 (via apt update) but self built packages created via kernel build script are version 5.98 Other kernel packages are ok, version 4.19.85 What about this?