All Activity

This stream auto-updates     

  1. Past hour
  2. I'm using Armbian's Ubuntu Bionic image on a Libre Computer AML-S905X-CC (LePotato). It appears the chromedirver package is not available: Package chromedriver is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'chromedriver' has no installation candidate My use case is, I need to file an online complaint with a regulatory agency. The complaint is filed via a Python script, and Python uses Selenium to operate the web browser and populate the four page form. Please provide chromedriver (Chromium) and geckodriver (Firefox/Iceweasel) for the platform. ----- Note that the web drivers can be tricky on ARM. I've got a working script that uses Python and Selenium on Fedora 29, x86_64. I need to port to low cost ARM hardware. To date I have not been successful with getting things working with Chromium/Chromedriver or Firefox/Geckodriver on ARM. I've even tried to build Geckodriver from Rust/Cargo sources. One of the sore spots in building chromedriver and geckodriver is, the projects use that damn abandonware model. You have to start at Chromium or Firefox provided by the platform, and then use an old version of the driver that matches the web browser. The old version of the driver will be unsupported because they only support bleeding edge, so you have to work around past problems that never got fixed. ----- $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.2 LTS Release: 18.04 Codename: bionic
  3. Yesterday
  4. AndrewDB

    Armbian for Amlogic S9xxx kernel 4.1x (>= ver 5.55)

    Try a different kernel version (earlier/later).
  5. I soldered the two wires to my OPi Lite, running Armbian 5.75 stable. I was only able to listen noise. Already tested to configurate /etc/asound.conf and alsa volume. Can you help me? Thanks.
  6. TonyMac32

    Moving to the newer kernel version

    For the Tinker, the 4.4 kernel is the only one to have VPU support. Because of that, the kernel will remain 4.4 on "default" images until such a time as this stabilizes in the mainline (work is happening).
  7. NicoD

    Armbian for Amlogic S9xxx kernel 4.1x (>= ver 5.55)

    @balbes150 Great job with the Odroid N2 image. It seems better than anything else I tried. Almost everything works out of the box. I'm very happy with this, I could kiss you. I've had many problems with all other OS'es(Ubuntu Mate/Meveric's Stretch) to get zram(and swap files) to work. It was enabled, but when it needed to use zram, it just crashed the application. With yours zram is used like it should. I'll increase it from 1024MB to 1800MB. And add a 4GB swap file for when it's needed. I had so much problems rendering the armbian backgrounds because I ran out of memory. If only I knew to use Armbian for it... There's nothing in "/sys/class/thermal/..." I use that to check cpu temperature on a taskbar app. ("cat /sys/class/thermal/thermal_zone0/temp") Also the cpu frequencies can't be shown. But those are small details. You should advertivse your image more. There's no thread on the Odroid forum about it. I didn't know you had one for the N2 until I found a post where you talked about it. Thanks, cheers.
  8. adogado

    RK3288 Media Script (TinkerBoard)

    Yes I am using default kernel . (Fresh install armbian , installing gstreamer package and install media script.)
  9. windysea

    A64 date/time clock issue

    You really shouldn't need to set a cron job to sync the system time back to the hardware clock since this is already a builtin kernel feature. It just appears that feature was disabled (broken) by something. When ntpd or systemd-timesyncd start they will set a flag in the kernel to enable this feature: ntpd will do so after it obtains sync but systemd-timesyncd does so almost immediately. Running 'hwclock -s' after this will in turn disable this feature again. After some time ntpd may discover this (if the kernel tells it) and try to reset the flag, but systemd-timesyncd will not. When using systemd-timesynd (the standard default out-of-the-box) you should never use hwclock -s. It only causes bad things to happen, and is why /etc/init.d/hwclock.sh and its many incantations explicitly check for running systemd and will exit without taking any action if so. Before systemd that standard script would run before ntpd and all was good. Then came systemd and that caused breakage so the extra checks were put in. There are many discussions on this elsewhere so there's no need to discuss further here: The summary is if you are using systemd do not run 'hwclock -s'. Ever. When using ntpd (and after systemd-timesyncd has been appropriately disabled/removed), 'hwclock -s' may be run once but only when it may be assured that this happens before ntpd is started. That isn't as simple as it sounds with systemd either . This is also discussed in many other forums so no need to rehash that here. I do have a proper implementation for a raspberry pi with an I2C-based RTC that requires this - it is doable but it is a bit more complex than simply putting a one-liner in /etc/rc.local In short, all current armbian kernels for platforms with an on-board RTC, including the PineA64(+), should have the proper configuration for the kernel to read the RTC and set the system time during its early startup, as is standard. This removes virtually any need to ever use 'hwclock -s' manually or during boot. Whether using systemd-timesyncd or ntpd the system time will already be correct, the appropriate daemon will begin synchronizing the system time from a reliable source, and will enable the kernel to periodically update the hardware clock from the system clock on its own as well (every 11 minutes IIRC). There should be no need to manually sync time in either direction. I am using pin PH9 for PPS on a pine64 since that is one that is interrupt-capable (not all are): user@pine64:~$ egrep pps_pin /boot/armbianEnv.txt param_pps_pin=PH9 Using a GPS as a reference clock without PPS is not very useful unless it is the only source of time. There is significant delay that must be accurately compensated for ("fudge time2" with the .20 NMEA GPS driver), plus there will always be quite a bit of jitter especially if the GPS output isn't reduced to the single sentence desired. I've found that typically the offsets are close to 1/2 second even with 115Kbaud. Using kernel ("hard") PPS can provide much lower jitter than NTP ("soft") PPS, but requires a custom kernel be built with this capability enabled. That in turn requires the kernel be configured at compile-time as non non-tickless since the two configurations are not currently compatible. A standard kernel may also be configured at boot time to run non-tickless by adding 'nohz=off' to the kernel command line arguments. Running non-tickless can help reduce jitter but will increase power usage (slightly) For now I am using NTP PPS and attempting to use non-tickless on the pine64. This gets good results on its own: I had spent some time dialing-in the offset for the PPS, since there is more overhead with NTP discipline over kernel discipline. The only issue is that I am hitting what appears to be the known timer issue on topic for this thread so that is where I want to try to look next. With 4.14 (or earlier) kernels this is not an issue and the same mitigation appears to work well there but does not seem so complete with 4.19 and later.
  10. guidol

    Enable i2c ports in bpi m2 berry-ultra.

    I2C-0 doenst work for me on the M2 Berry (like - with the same commands - on my NanoPi Neo Core2) But I also cant compile the V40-I2C-0 root@bpi-m2-berry(192.168.6.20):/home/guido# dtc -I dts -O dtb v40-bananapi-m2-berry-i2c-0.dts -o v40-bananapi-m2-berry-i2c-0.dtbo Error: v40-bananapi-m2-berry-i2c-0.dts:2.2-8 syntax error FATAL ERROR: Unable to parse input tree I did wget the raw version od the dts and also did a clipboard-copy - but the has the same error. When I activate i2C-0 from normal armbian-config I do get root@bpi-m2-berry(192.168.6.20):/home/guido# i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@bpi-m2-berry(192.168.6.20):/home/guido# i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- but my I2C clock should be at 68 on I2C-0 like on my NanoPi Neo Core2 echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device modprobe rtc-ds1307 i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- armbian: https://raw.githubusercontent.com/armbian/sunxi-DT-overlays/master/sun8i-h3/sun8i-h3-i2c0.dts V40: https://raw.githubusercontent.com/hbars/BPI-M2-Ultra-Berry-i2c-enable/master/v40-bananapi-m2-berry-i2c-0.dts
  11. martinayotte

    Enable i2c ports in bpi m2 berry-ultra.

    At least for I2C-0, where the PMIC is attached, they are there, but for the other ports, you can prepare a patch and submit a PR to Armbian ...
  12. Igor

    Moving to the newer kernel version

    Removing older linux-image-rockchip and linux-dtb-rockchip package to avoid troubles, then installing linux-image-next-rockchip linux-dtb-next-rockchip ... it should be possible also from armbian-config, but I just discover some problems and have to check, before recommending that option. apt update upgrade upgrades the kernel you have, bot generation change is done manually/armbian-config way.
  13. Igor

    Updated armbian-config v5.77

    Another update: Improved hotspot management Set proper metrics that default adaptor gets highest routing priority
  14. I'm using Armbian on a Tinker Board S. I did the installation back when the 4.4 kernel was still the default one. I expected that I'd get the newer 4.19 kernel by using 'apt update && apt dist-upgrade' at some point as it would become the new stable. This does not seem to be the case however, as I see the new downloads use 4.19 by default, but the stable package still points to a 4.4 kernel. Is it recommended to just move up by installing the kernel package with the next suffix or are there still reasons to wait with upgrading?
  15. pfry

    M.2 NVMe SSDs for NanoPC-T4

    "Were", at least, likely rectified by now. There were a few posts earlier this year.
  16. hbars

    Enable i2c ports in bpi m2 berry-ultra.

    But not work. And how can they work when in dts and dtsi nowhere describes the pins of the ports.
  17. guidol

    Enable i2c ports in bpi m2 berry-ultra.

    ____ ____ _ __ __ ____ ____ | __ )| _ \(_) | \/ |___ \ | __ ) ___ _ __ _ __ _ _ | _ \| |_) | | | |\/| | __) | | _ \ / _ \ '__| '__| | | | | |_) | __/| | | | | |/ __/ | |_) | __/ | | | | |_| | |____/|_| |_| |_| |_|_____| |____/ \___|_| |_| \__, | |___/ Welcome to ARMBIAN 5.81 user-built Debian GNU/Linux 9 (stretch) 5.0.7-sunxi package bsp-kernel[5.81] u-boot[5.81] dtb[5.81] firmware[5.81] config[5.81] root@bpi-m2-berry(192.168.6.20):/# more /boot/armbianEnv.txt verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 rootfstype=ext4 overlays=analog-codec i2c0
  18. storms

    Docker-compose version error. odroid-xu4

    hello! not sure, i had the offical ubuntu arm version from odroid before installing armbian and i was able to install docker-compose without problems. but i will keep diging. edit: i was able to install it and confirm it is working following this: https://www.berthon.eu/2019/revisiting-getting-docker-compose-on-raspberry-pi-arm-the-easy-way/ so it appears its not an armbian problem...i think? case closed! edit edit! where would be the best place to give this info so that a fix could be made? it appears the docker-compose official team dont have plans to add it to arm. so, debian repos people?
  19. Thanks a lot for clarification. Looks like shipping it from reseller in USA will be much cheaper than from official Korean store. Will think about it one more time =) Waiting for more opinions
  20. If you want to power a external drive relaibly, I would not use any power source that provides less than 3 amps, not only with HC1 but with any board. About power consumption, it will be higher compared to less powerful boards as the Cubie2, but it will stay under 1 amp most of the time, except when you run very demanding tasks.
  21. martinayotte

    Enable i2c ports in bpi m2 berry-ultra.

    Since H3 and R40 are similar, I presume the overlays already provided in any Armbian images under /boot/dtb/overlay should already work.
  22. One point still here - about "not too power hungry". What about consumption ? It requires quite solid PSU as far as I see. Does it really consumes 3 amperes ?
  23. Totally worth the $50 it costs. As a matter of fact, that would be my first recommendation for your use case.
  24. Are you using Default or Mainline kernel?
  25. Tnx. Check this: https://github.com/armbian/sunxi-DT-overlays
  26. Petee

    A64 date/time clock issue

    Thank you WindySea. If your hardware clock is not being synced from your system clock then something is broken. Runing 'hwclock -s' after systemd-timesyncd or ntpd has started is one of those things that will cause such breakage but there can be other reasons. Having an RTC isn't much value if it won't be kept decently accurate. Most RTCs are intended to be periodically updated by the host OS as they utilize low-cost and not very-high-accuracy components and design.  created a once a day cron job to sync the system time to the hardware time. root@ICS-Pine64:~# date Sat Apr 20 10:05:00 CDT 2019 root@ICS-Pine64:~# hwclock 2019-04-20 10:05:06.192985-0500 As for using a Pine64 as an NTP server - it actually works very well. I've had this pine64 doing exactly that with KPPS with 4.14.y and earlier kernels with great success, and with a total power utilization of less than 3.5W. There is something with 4.19.y and later kernels that is not right, and trying to work with NTP is just one use case that is exposing this. Understood. Is your PPS off now with the newer kernels? What pin on the Pine64 are you using for PPS? Here have added an NTP/PPS GPS serial connection to the PFSense box. Historically the NTP server here was an autonomous device. Started the whole NTP server endeavor with GPS antenna mounted on the roof of a two story home in the 1990's using a Trimble GPS module (from a tank). Then with the SURE GPS moved the antenna to the attic of the two story home. Now have the antenna next to a glass block window in the basement of the two story home and it works great seeing 9 satellites just fine. Syncs in about 30 seconds these days. In the automobiles with GPS doing similiar to sync time and position with computer connected to the HU (BMW). The car computer connects to the ODB2 and bus ports (I can DIY almost drive them remotely these days). The PFSense box today has two WAN ports / ISP connections and 6 LAN ports today. It's too big and uses too much power today running on a low powered iSeries CPU. I would like to take this to an ARM based smaller footprint computer. I am test running OpenWRT on a NEXX microrouter which is about 1/2" tall and 1" X 2" sized. I have added an RTC/Battery to this device (tiny thing). This is perhaps not a "little issue" - again it is not itself a time/date problem but rather a problem when reading a hardware counter (one of many) in the SoC. That counter is used by the kernel for core functionality, of which tracking system time is just one use. If some are experiencing an issue while others are not, using the same kernel, then there is something about the difference in workloads that is exposing an un-mitigated issue that can be triggered at any time. Here time will tell. I am currently over 24 hours using the nightly build. That said the "time" issue would crop up days after cold boot up. And connecting the running OS with HA automation software and combo Alarm automation (OmniPro 2) wrecked havoc here with scheduled events. That and might turn the Pine64 in to a weather computer here for connection to my Davis weather station and NOAA downloading stuff and move this microserver over to a TV box.
  1. Load more activity