• Posts

  • Joined

  • Last visited

Everything posted by vlad59

  1. 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) ?
  2. 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.
  3. I've successfully used BMP180 (Igor gave you a link), BME280, SI7021 based devices (search on aliexpress, you'll find plenty).
  4. 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 :(.
  5. 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.
  6. 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, 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]
  7. 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.
  8. 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 !
  9. @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.
  10. @megi Yeah I won the allwinner lottery (or at least the interesting stuff lottery), tell me if you need anything else
  11. Tanix TX6 : LibreELEC:~ # ./regtool h6-soc-bin SoC bin: invalid (bin=0) (raw=2)
  12. 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.
  13. 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
  14. 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 ?
  15. @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.
  16. 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
  17. 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.
  18. 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.
  19. 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.
  20. For the record my cable length was over 70m (meters not centimeters)
  21. 60cm should be very safe, it should not hurt to try 3K3.
  22. @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