All Activity

This stream auto-updates     

  1. Past hour
  2. 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: -- -- -- -- -- -- -- --
  3. 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 ...
  4. Today
  5. 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.
  6. Igor

    Updated armbian-config v5.77

    Another update: Improved hotspot management Set proper metrics that default adaptor gets highest routing priority
  7. 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?
  8. pfry

    M.2 NVMe SSDs for NanoPC-T4

    "Were", at least, likely rectified by now. There were a few posts earlier this year.
  9. 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.
  10. 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
  11. 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?
  12. 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
  13. 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.
  14. 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.
  15. 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 ?
  16. Totally worth the $50 it costs. As a matter of fact, that would be my first recommendation for your use case.
  17. Are you using Default or Mainline kernel?
  18. Tnx. Check this: https://github.com/armbian/sunxi-DT-overlays
  19. 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.
  20. Hi all! I'm happily using Armbian on Cubieboard2 working as home server (samba, 4(!) LXC containers with Deluge, tor, owncloud and some other small apps) + VPN client. Pretty happy with it, especially for internal SATA. Recently found that Cubietech releases Cubieboard6 on S-500 CPU with same form-factor and SATA. That means, that all casing/housing can stay intact. LXC containers also can be migrated since CPU is still ARMv7. But at the same time found somewhere on this forum, that board is not really good quality... Cannot argue or agree with this since I don't have a board and it looks costly. So my question - what is advised for home server like my one described above ? Main requirements are: 2Gb RAM, Armbian full support, not-too-power-hungry. Still not sure about SATA -- it's really handy, but USB drive with UAS support speeds are comparable I guess ? Also thought about Odroid HC-1, but is it worth it's price ? What is on your mind ?
  21. Hi. Instruction and dts on https://github.com/hbars/BPI-M2-Ultra-Berry-i2c-enable
  22. TonyMac32

    Proof of concept - Realtek 1295

    Nope. That's how I handle adding parts typically. You need to keep the thing from floating around on you after all.
  23. martinayotte

    Orangepi 3 h6 allwiner chip

    Right, because Armbian is using Megous branch, and Megous branch didn't merge 5.0.9 yet. Armbian will switch to 5.1.y as soon as there is no more RCs, maybe in few days/weeks from now. (I'm using Megous 5.1.y branch locally).
  24. windysea

    A64 date/time clock issue

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

    A64 date/time clock issue

    I am still fine here after one day of running: The hardware clock is now not in sync with the system time after 24 hours: root@ICS-Pine64:~# date Sat Apr 20 06:44:53 CDT 2019 root@ICS-Pine64:~# hwclock 2019-04-20 06:44:57.138 root@ICS-Pine64:~# ./test_timer TAP version 13 # number of cores: 4 ok 1 same timer frequency on all cores # timer frequency is 24000000 Hz (24 MHz) ok 2 native counter reads are monotonic # 0 errors # min: 8, avg: 8, max: 4201 ok 3 Linux counter reads are monotonic # 0 errors # min: 541, avg: 560, max: 94959 # core 0: counter value: 2816701110464 => 117362 sec # core 0: offsets: back-to-back: 9, b-t-b synced: 8, b-t-b w/ delay: 10 # core 1: counter value: 2816701117040 => 117362 sec # core 1: offsets: back-to-back: 10, b-t-b synced: 9, b-t-b w/ delay: 11 # core 2: counter value: 2816701118687 => 117362 sec # core 2: offsets: back-to-back: 10, b-t-b synced: 9, b-t-b w/ delay: 10 # core 3: counter value: 2816701120142 => 117362 sec # core 3: offsets: back-to-back: 9, b-t-b synced: 9, b-t-b w/ delay: 11 1..3 Personally with these little issues I would not utilize the Pine64 as an NTP server with PPS. That is me though. Currently running an NTP server here using BSD on an Intel CPU and it is working great. ntpq> sysinfo associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern, system peer: GPS_NMEA(0) system peer mode: client leap indicator: 00 stratum: 1 log2 precision: -24 root delay: 0.000 root dispersion: 1.150 reference ID: GPS reference time: e0658a99.f937808b Sat, Apr 20 2019 7:10:01.973 system jitter: 0.001422 clock jitter: 0.001 clock wander: 0.005 broadcast delay: -50.000 symm. auth. delay: 0.000 Off of the main topic.... Doing an audible hourly chime here using SAPI or Alexa plus 15 touchscreens displaying time and they are in sync just fine. Pull down NOAA weather maps on a cron schedule (when satellite passes over head) which is really time specific. Collect antique clocks and my old regulator pendulum clock is in sync just fine with NTP server (a few other clocks from the 1800's are totally off though). Same with the use of geophones here fun stuff. Always been in to NTP / PPS satellite time sync here (since 1990's) for use with a aeroline flight vectoring program used around the world and precise measurements of incoming aeroplanes (Unix software).
  26. Hello, I'm buliding a music player for my old car using Orange Pi PC Plus. I would like to use external incoming logic levels (3.3V / 0V) to wake up the OPi from suspend state. Could you help me how to do that? Waking up using the HW button SW4 is working perfectly. I need to do this using external logic signal connected to PA11 / GPIO pin #5. I tried the following setting in fex editor: [gpio_power_key] key_used = 1 key_io = port:PA11<6><default><default><0> It doesn't work. I keep the pin on HIGH (3.3V) normally, and when I bring it to LOW state, OPi won't wake up. I tried also changing the second parameter 6 to 0, as input function. No success. Of course I have disabled the TWI0 interface in the fex editor, so pins PA12 and PA11 are available. I tried to read pin PA11 state as input using a Python code and it reads properly ON and OFF states. But the wake up function doesn't work. Could anyone give me any suggestion what shall I try to make it work?
  1. Load more activity