vlad59
Members-
Posts
180 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Community Map
Everything posted by vlad59
-
I just did a armbian-config -> System -> Firmware : run apt update & apt upgrade. It went fine. I'm not sure it worked though (u-boot stayed with 20.02.5 and not 20.02.7 with label 2019.10) : root@minus:~# dpkg -l | grep linux- ii binutils-arm-linux-gnueabihf 2.30-21ubuntu1~18.04.2 armhf GNU binary utilities, for arm-linux-gnueabihf target ii linux-base 4.5ubuntu1.1 all Linux image base package ii linux-bionic-root-current-bananapi 20.02.5 armhf Armbian tweaks for bionic on bananapi (current branch) ii linux-dtb-current-sunxi 20.02.7 armhf Linux DTB, version 5.4.28-sunxi ii linux-image-current-sunxi 20.02.7 armhf Linux kernel, version 5.4.28-sunxi ii linux-libc-dev:armhf 4.15.0-91.92 armhf Linux Kernel Headers for development ii linux-u-boot-bananapi-current 20.02.5 armhf Uboot loader 2019.10 is there a quick way to check the uboot installed in the SD (I'll hook a HDMI monitor and see if the version is show there) ?
-
will do this afternoon
-
I just updated my Banana pi to latest kernel (5.4.26), SATA is still detected (and it's a good thing as I used `nand-sata-install`). I understand it's not the same test (not a clean install) but at least kernel/dtb/uboot should be the same. Hope this helps.
-
I've successfully used BMP180 (Igor gave you a link), BME280, SI7021 based devices (search on aliexpress, you'll find plenty).
-
Can you link a git repo with your changes ?
-
I use Armbian (of course) with debian or ubuntu (lately I've been using ubuntu but debian also work). I followed this documentation : https://docs.docker.com/install/linux/docker-ce/ubuntu/ you just have to use the armhf repository (there's 5 tabs with different arch). I never have tested kubernetes on Arm devices even though I really want to test k3s but time is a limited resource :(.
-
I use docker 24/7 for my home automation for at least 2 years (almost 3). First on a banana pi and since 3 months on a Orange Pi +2E (I switched for the 2Gb of RAM). I have a dozen of small containers (many small home made python script, mqtt server, nzbget, home assistant, traefik, ...) running all the time and it works great. I don't know what to say specifically as it's been working mostly good. The only caveat I have is that sometimes docker bridge network get stucked and I have to reboot to get it back but it happened 3 times over 2 years.
-
I also did the test with wget (on a SSD) : wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.5.tar.xz --2019-12-19 09:17:14-- https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.5.tar.xz Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:1d::432, 151.101.121.176 Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:1d::432|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 109435988 (104M) [application/x-xz] Saving to: ‘linux-5.4.5.tar.xz’ linux-5.4.5.tar.xz 100%[=========================================================================>] 104,37M 15,1MB/s in 6,9s 2019-12-19 09:17:21 (15,1 MB/s) - ‘linux-5.4.5.tar.xz’ saved [109435988/109435988]
-
Nope the Bpi M1 can do much more, see here : Your test file is not so quick to download : root@minus:~# curl -o /dev/null https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.5.tar.xz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 104M 100 104M 0 0 13.0M 0 0:00:07 0:00:07 --:--:-- 13.4M root@minus:~# curl -o /dev/null http://test-debit.free.fr/1048576.rnd % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 32 1024M 32 332M 0 0 93.6M 0 0:00:10 0:00:03 0:00:07 93.6M^C The slowing factor is often the disk.
-
Hi, I just had a huge boost on my Internet speed (1Gbs down / 600Mbps up), it's a good thing but it showed that many of my SBC that are running 24/7 are not ready to handle such high bandwidth. In each case running a curl outputting to /dev/null -> I almost top out the Gigabit interface -> 99Mo/s. When I test download speed (while saving on disk) : * Old Banana pi running kernel 4.14.18-sunxi (armbian of course but not updated with stretch) with an Kingston SSD on the SATA port -> cannot go over 12~14Mo/s (Mo/s not Mb/s) * Orange Pi +2E running 4.19.62-sunxi (armbian with ubuntu Bionic) with a Sandisk SSD on usb2 with a UAS adaptor -> cannot go over 35~37Mo/s. I have updated another Banana pi with latest Armbian (Bionic / kernel 5.3.X), it includes the patch to fix SATA write speed still with a SSD -> 37Mo/s using wget and 44Mo/s using aria2c (with a single connection) Each test was done with HTTP download from a VPS I own with 1Gb/s interface and plenty of bandwidth. I'll make other test with NFS later. So far the lesson I learned -> update Armbian more often ! I'll debug more to see if I can tweak some interrupts / mtu / disk parameter to get a few % more. If you have some idea please share !
-
@megi Forgot to tell if you want more Tanix TX6 report, go to librelec forum or ask Jernej, he is the one who made the librelec image.
-
@megi Yeah I won the allwinner lottery (or at least the interesting stuff lottery), tell me if you need anything else
-
Tanix TX6 : LibreELEC:~ # ./regtool h6-soc-bin SoC bin: invalid (bin=0) (raw=2)
-
Last time I checked LZ4 kernel algo was not properly optimized for ARM (with NEON) so I don't think you can directly apply this blog results to ARM. The same "problem" happen with zram which is slower than in x86 world.
-
Hi all, I have a Tanix TX6 4Gb/32Gb on the way. I hope to use it with armbian (if that does not work, I'll use libreelec but I'd prefer having a generic linux). Is there a step by step guide on how to build an armbian image. I read the whole thread and saw that megous tree is almost good to go especially with 5.4 that got a lot of patch included. It's less clear for uboot, is latest uboot good to use or is there some patch to use. Is there a fork of armbian/build with everything included maybe ? Thanks in advance for any help
-
Done, I hope the PR is good .
-
A little late but it's working fine : root@pine64:~# uname -a Linux pine64 5.3.1-sunxi64 #5.97 SMP Mon Sep 23 18:28:48 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux root@pine64:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x0000003f (63) drv probe link timer ifdown ifup Link detected: yes root@pine64:~# for now my patch is in `userpatches/kernel/sunxi-dev/`. If I understand correctly I just have to move the patch to `patch/kernel/sunxi-dev/` and make a PR, right ?
-
@martinayotte@Igor I finally found where I read about problem on some pine64+ for ethernet, it was in Librelec forums and Jernej added a patch fixing that a few weeks ago : https://github.com/LibreELEC/LibreELEC.tv/blob/9d68e4ba191d7b0bd319e1e254610917e69526e0/projects/Allwinner/devices/A64/patches/linux/03_pine64_plus_ethernet_fixes.patch The last part of the patch is interesting (= could fix my problem) and was queued for kernel 5.4 : https://lkml.org/lkml/2019/9/18/714 Grepping for `config-magic-for-pine64` or `regulator-enable-ramp-delay = <100000>` inside armbian build source return nothing so I guess that can be it. I'll try a dev build with this patch tomorrow and report here either way.
-
That's strange indeed, I'll try a new build in a few days (it's currently building and uploading new arm64 docker images 24/7) It was perfectly working with a dev build between the end of july and the beginning of august. I had many problem with date jump in 2114 so I tried updating yesterday (apt-get update && upgrade) and had the problem with eth0. I then tried a full install and I had the same problem. As I said I still have a few days of work for the pine64 and I'll retry a new build
-
I rebuilt a full image this morning and I still have no wired network. I went back to kernel 4.19.X. I'll spend some time tonight to compare the device trees between 5.2 and 5.3.
-
Hi, I just updated my pine64 1Gb today (so 190916), it restarted perfectly with 5.3.0 kernel but I lost eth0 with `no phy at addr -1` in dmesg (wlan0 still works fine). Anybody can confirm ? I remember reading about this on irc about 5.3 and pine64 some weeks ago , I'll try to find it again.
-
Hi all, FYI, I just build an image for a Pine64 (1Gb) and everything seems perfectly fine with kernel 5.2.X -> thanks a lot to all armbian team and especially to @martinayotte I'll probable rebuild my Banana pi image later this month.
-
For the record my cable length was over 70m (meters not centimeters)
-
60cm should be very safe, it should not hurt to try 3K3.
-
@eyatsko What is the total cable length for your 6 sensors ? Do you use CAT5 / CAT6 ? 5 or 6 years ago, I tried to add 4 sensors in each of my first floor rooms (in the ceiling) -> 4 * 4 = 16 DS18B20 but it was way too much cable length (even with cat5) to have a consistent sensor read. I often had only 8 or 9 sensor available (and sometimes to whole bus disappeared). I tried lowering the pullup, it helped. I tried replacing my only pullup with 3 (and even 4) 15k (distributed along the cable) : it also helped but it was never perfect. Finally I ended up with 4 buses of 4 sensors using 4 pins and it was flawless. Less interesting for you but now I have a single ESP8266 for each room with a some i2c sensors (SI7021, ...). All my DS18B20 were donated or binned. Hope this helps