All Activity

This stream auto-updates     

  1. Past hour
  2. I strongly want to buy T95Z PLUS, but I noticed that its operating system is Android 7.1. I am a bit worried that this version will be out of date, causing software incompatibility problems. I have searched on Google for a long time and have not found an answer. Does anyone can answer it?
  3. Today
  4. Good catch! We can afford 130Kb of extra size. I would propose to add it to the base set https://github.com/armbian/build/blob/master/lib/configuration.sh#L150 Send a PR, but we need few tests on other devices to see if this package does no harm? Also make this number +1 https://github.com/armbian/build/blob/master/lib/configuration.sh#L23
  5. What shows your output " cpufreq-info |grep governor " - Should be ondemand I suppose, or set to anything else - eg performance? Perhaps "conservative" is a nicer way for your situation ramping up step by step to reduce CPU temp ( cpufreq-set -g conservative ) ... Anyway will build ( BOARD=orangepioneplus BRANCH=dev RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no ) and flash my H6 OPiOnePlus later today , or is 5.3 already in default branch ( stable? )
  6. new version available? http://wiki.friendlyarm.com/wiki/index.php/NanoPi_M4V2
  7. 64° while running stuff like PiHole. And yes has a heatsink but now fan running right now. But yes, seems higher then before.
  8. @ManoftheSea Indeed it is and I am not sure why it was published in that state. I am calling the jumper setting "1-2" 1 and the jumper setting "2-3" 0. This is because I measured the jumpers with the multimeter and could measure a signal when setting the jumpers to 1-2. The labeling I am using is exactly inverted to the one from the table. 1, 0, 0 (meaning J11=1-2, J3=2-3, J10=2-3) for serial NOR, I actually will set them to 0,0,1 (meaning J11=2-3, J3=2-3, J10=1-2). As if exchanging J11 with J10. I tested it with booting from NOR and booting from UART.
  9. Hi, Two things come to my mind, reading your post armbianmonitor -u tells the reader all the details about your Installation, like Kernel-Version and much more Did you already use the search function in the right hand topcorner?
  10. Yes - I can confirm that the C2 take some time before I can ssh into it... but with normal armbian Debian Buster with Armbian Linux 5.3.0-meson64 package bsp-kernel[5.97.190917] u-boot[5.96] dtb[5.97.190917] firmware[5.96] config[5.96] it took me around 2-3 minutes. After your info about the entropy pool I did found firstly the following page which also suggest havegd: https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html But this on my mind, I compared my NanoPi Neo2 with the C2 NanoPi Neo2: dmesg | grep -E "(rng|random)" [ 0.000000] random: get_random_bytes called from start_kernel+0x2e4/0x478 with crng_init=0 [ 5.888987] random: fast init done [ 7.924082] random: systemd: uninitialized urandom read (16 bytes read) [ 7.933060] random: systemd: uninitialized urandom read (16 bytes read) [ 7.945521] random: systemd: uninitialized urandom read (16 bytes read) [ 11.610613] random: crng init done [ 11.610625] random: 7 urandom warning(s) missed due to ratelimiting Odroid C2: dmesg | grep -E "(rng|random)" [ 0.000000] random: get_random_bytes called from start_kernel+0x2f4/0x488 with crng_init=0 [ 4.708300] random: fast init done [ 6.124106] random: systemd: uninitialized urandom read (16 bytes read) [ 6.131317] random: systemd: uninitialized urandom read (16 bytes read) [ 6.132394] random: systemd: uninitialized urandom read (16 bytes read) [ 84.643984] random: crng init done [ 84.643999] random: 7 urandom warning(s) missed due to ratelimiting So a hugh difference between 11 and 84 in counting, As I only got this problem on the Odroid C2 (Amlogic S905) and my Sunvell T95K Pro (Amlogic S912) I searched for a Amlogic-CPU-Solution and did found the following for the Ordoid C1 (Amlogic S805): [FIXED] Random Number Generator on odroid-c1 ==> Hardware Random Number Generator Accelerator https://forum.odroid.com/viewtopic.php?f=115&t=8874 https://odroid.com/dokuwiki/doku.php?id=en:c1_hardware_number_generator You have to install rng-tools: apt-cache search rng-tools rng-tools - Daemon to use a Hardware TRNG rng-tools-debian - daemon to use a Hardware TRNG (classic version) rng-tools5 - Daemon to use a Hardware TRNG sudo apt-get install rng-tools After I did install the rng-tools I could immediately ssh into my C2 then the /etc/rc.local was processed (do get a voice info on my system). The time to fill the entropy pool is now with 12 as short as on the NanoPi Neo2 dmesg | grep -E "(rng|random)" [ 0.000000] random: get_random_bytes called from start_kernel+0x2f4/0x488 with crng_init=0 [ 4.684192] random: fast init done [ 6.221509] random: systemd: uninitialized urandom read (16 bytes read) [ 6.229215] random: systemd: uninitialized urandom read (16 bytes read) [ 6.230358] random: systemd: uninitialized urandom read (16 bytes read) [ 12.413199] random: crng init done [ 12.413207] random: 7 urandom warning(s) missed due to ratelimiting @zero_derivative Thanks for the info about the entrpy pool! @Igor maybe rng-tools should be an default installed packet on amlogic-devices? @balbes150 maybe also some users of your Amlogic-images would like this
  11. I am trying to host an web application (Python Django based) and i am using GPIO pins (library: OPi.GPIO==0.6.3). I got the permission error in "sys/class/gpio/* " and when i give manually permission to several files (location=sys/class/gpio/*) but the issue remains the same . Device :OrangePi Zero OS : Ubuntu Bionic with Armbian Linux 4.19.62-sunxi
  12. We build images every day. How did you build images? Menu driven or only from command line? Which parameters have you used? Where did you build it? Logs are in output/debug ... compilation.log is the one we are looking for.
  13. Greetings. I'm running a headless cluster of Odroid C2's (eMMC) using the latest Armbian buster minimal image with kernel 4.19.69-meson64. I'm encountering an issue where it takes a long time for SSH connection to be accepted (initially up to 30 min consistently). I get a connection refused. The issue seems to be due to the entropy pool becoming depleted during the early boot process which blocks SSH from starting while it refills the pool. The problem seems to be known and documented well here: https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html As suggested I have installed installed haveged which brings the SSH startup from 30 mins to 10 mins after boot, which is an improvement, but still not good. Has anyone else experienced this issue? Any ideas?
  14. Yesterday
  15. Upgraded to #5.97.190916 an hour ago and noticed Thermal reading is back. Left the system complete idle for an hour. After hour, I noticed thermal reading of 58C while ambient is 26C. It has a good heatsink installed. I remember old days on the board when it was that hot or may be more in idle state.
  16. Got an error message when trying to build an image for BPi-Pro: AR drivers/usb/built-in.a CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/phydm_rssi_monitor.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/phydm_auto_dbg.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/phydm_math_lib.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/phydm_api.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/phydm_pow_train.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/halrf/halrf.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/halrf/halphyrf_ce.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/halrf/halrf_powertracking_ce.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/halrf/halrf_powertracking.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/halrf/halrf_kfree.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/rtl8822b/halhwimg8822b_bb.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/rtl8822b/halhwimg8822b_mac.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/rtl8822b/halhwimg8822b_rf.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/halrf/rtl8822b/halrf_8822b.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/rtl8822b/phydm_hal_api8822b.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/halrf/rtl8822b/halrf_iqk_8822b.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/rtl8822b/phydm_regconfig8822b.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/rtl8822b/phydm_rtl8822b.o CC [M] drivers/net/wireless/rtl88x2bu/hal/phydm/txbf/haltxbf8822b.o CC [M] drivers/net/wireless/rtl88x2bu/hal/btc/halbtc8822bwifionly.o CC [M] drivers/net/wireless/rtl88x2bu/hal/btc/halbtc8822b1ant.o CC [M] drivers/net/wireless/rtl88x2bu/hal/btc/halbtc8822b2ant.o CC [M] drivers/net/wireless/rtl88x2bu/platform/platform_ops.o CC [M] drivers/net/wireless/rtl88x2bu/core/rtw_mp.o LD [M] drivers/net/wireless/rtl88x2bu/88x2bu.o AR drivers/net/wireless/built-in.a AR drivers/net/built-in.a Makefile:1083: recipe for target 'drivers' failed [ error ] ERROR in function compile_kernel [ compilation.sh:382 ] [ error ] Kernel was not built [ @host ] [ o.k. ] Process terminated I suppose that there are more logs somewhere?
  17. Indeed Try stock Solidrun builds? While Armbian_5.91_Cubox-i_Debian_buster_default_4.14.133 is more or less stock u-boot, stock kernel + few improvements.
  18. I don't know what you expect from that upgrade? Errors are kernel related and kernel will not be changed since Ubuntu does not provide it. Upstream user space upgrade scripts are outside our control. They can work or not. It's known bug but can't help in this area, not very familiar with imx6 and graphics drivers. I was looking for a solution some time ago, but ... not found, don't remember to what is this related to. Try around, if Librelec folks have done some progress with imx6 ... Perhaps its just a wrong kernel config. Or some parameter is needed ...
  19. So I did try a 5.3 kernel today, but the result does not look all to different from the 5.2 kernel available through apt already: http://ix.io/1Vr9 (is "etnaviv-gpu 130000.gpu: command buffer outside valid memory window" the cause of the Wayland failure?) All I did was checkout the repo, change 2 to 3 in the line KERNELBRANCH='branch:linux-5.2.y' in config/sources/cubox.conf, then run: ./compile.sh docker I had to answer a few questions about new kernel options, pretty much leaving all of them on default (usually N). Then I copied the debs from output/debs to the cubox (via scp), and installed them. So the build system is working nicely. Now I wonder what is the best way of updating to Ubuntu 19.04 (or 19.10 already)? I tried do-release-upgrade inside this Ubuntu 18.04 Armbian, but that lead to some errors:
  20. Hm, there are two ways to do that: You can try to chainload the u-boot binary from SD card with the help of the SPI u-boot. The SPL may check the presence of a SD card and try to load the u-boot binary from there instead of SPI flash. The first option requires some u-boot script hacking but should work with the existing firmware while the second option needs a modified SPL.
  21. I'm using flir's usb 3.1 camera with OrangiPi 3. default value for usbfs_memory (/sys/module/usbcore/parameters/usbfs_memory_mb) is 16. I should change it to a 1000 to be able to use full size image acquiring. testing this number, the higher I set it the higher image size I can get until 256mb. above 256, max image size is aprox 3200x2736 pixels (I need 5472x3648). so I guess somewhere in usbcore / kernel there is additional limit. Liad
  22. Hello @balbes150 and Others, I'm able to boot my X96 (S905x) device from a SD card with linux builds (tried Armbian 5.91 and 5.96). However, when I tried to configure the device as Wifi Hotspot / Access Point (AP), facing issues with connecting or pairing to the AP. The device appears to be configured with SSID and a static IP. But, when I tried to pair another device to this SSID + Passcode, it fails - something like invalid passcode. Could you please help to resolve or provide leads to the solution? - Krish
  23. I recently had a similar issue with my Tinkerboard. I was still using the legacy 4.4 kernel. To solve it: 1, I booted another SD card with TinkerOS 2. Plugged in the SD with Armbian using a USB SD-card adapter 3. mounted /dev/sda1 the partition with Armbian 4. bind mounted /dev /run /proc and /sys on the Armbian filesystem 5. chrooted into Armbian 6. ran armbian-config 7. first switched to the 5.2 kernel, but that didn't boot either, then did above again, switched to 4.19 and Armbian was booting again!!
  24. I done some thing no bad on my 2 hotspot in routing mode with a script to manage IPTABLES rules The script firewall_rules.sh in /etc/init.d/ load pre-defined rules in /etc/firewall.d/ firewall_rules.sh
  25. I made several tests: 1. burn all the possible pairs of SPL / u-boot.img on the existing SDCard --> each time the same story: U-Boot 2018.01-armbian (Jul 07 2019 - 11:26:59 +0200) CPU: Freescale i.MX6Q rev1.2 1200 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 33C Reset cause: POR Board: MX6 Cubox-i Watchdog enabled DRAM: 2 GiB U-Boot SPL 2018.01-armbian (Jul 07 2019 - 11:26:59) Trying to boot from MMC1 2. take a new SDCard, dd the SPL.sdhc and u-boot.img.sdhc then use Etcher to burn "Armbian_5.91_Cubox-i_Debian_buster_default_4.14.133" on it, boot with no hard drive connected to the cubox-i: U-Boot 2018.01-armbian (Jul 15 2019 - 21:19:21 +0200) CPU: Freescale i.MX6Q rev1.2 1200 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 35C Reset cause: POR Board: MX6 Cubox-i Watchdog enabled DRAM: 2 GiB U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21) U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21) U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21) U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21) U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21) U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21) That is crazy! It seems no more possible to boot that cubox!??!
  26. I have tried on my OPi3 the latest 5.3 nightly Buster and Buster Minimal, trying with USB power and DC connector 3A PS. It crashed in all cases....
  27. Pihole Core update to 4.3.2 https://github.com/pi-hole/pi-hole/releases also fixed: - Fix for 404 error when browsing to http://pi.hole/ (without /admin) #2826
  28. I have two OPi1+ and both running fine on 5.3.0 and earlier ran fine on 5.2.x as well... Just updated one of those SBCs to the 5.3.0-sunxi64 kernel image I built earlier today (and is available to the public, see link below) and is booting fine.
  1. Load more activity