Petee

Thank you Sundry. The ATL (Atlanta, Georgia) Pine64 crashed and burned up (literally) after the heat sinks installed slide off yesterday. I ordered a new TVBox / SD card to replace the dead Pine64 today and it will be there tomorrow and configured by end of business day tomorrow. I shut local Pine64 off (near Chicago here) and switched over to using a TVBox for the mini automation server. Currently moving all of the automation software from the ATL Pine64 to another TVBox there in Atlanta. That said and relating to the Pine64 I had asked about a promised updated to the Rock64 that never materilized for a year so I gave up on them and decided to maybe try the RockPi4 with more features and same size as the Rock64. Posted on the Rock64 forum- yeah I was nagging a bit here... ROCK64 RTC December 3, 2017 Question: Will the RTC be available in the December 12, 2017 Rock64 release? Answer: RTC is working, just lacking battery backup. The battery backup circuit not available on December production, we plan to merge in on January production but not sure will happen. This due to there is super long lead time on PCB manufacturing. January 30, 2018 Question: Wondering if the RTC / battery stuff is available on current Rock54 hardware? If not can I have instructions for soldering in battery posts and utilize the Pine64 battery holder? Answer: Attached is the RTC mod circuit for ROCK64. However, ROCK64 don't support battery charging and no such circuit available. February 9, 2018 Question: Thank you tlimm. So the hardware RTC with battery changes have been abandoned eh? Basically then all I need to do is solder on a battery to the Rock64 board. I have done similar here with my tabletop touchscreens. Answer: The ROCK64 board with RTC battery connector is not abandon. Check out the FOSDEM PINE64 table stand photo and you may able to spot this board. This is just a minor change and we will revise board revision during production run sometimes on Q2 2018 timeframe. May 2, 2018 Question: Curious if the new Rock64 hardware release has the built in RTC battery connections? Answer: This release already on the plan and originally plan release to production on this month. However, due to focus on ROCKPro64 activity, and has push to June/July. June 11, 2018 Posting another couple of requests today. 1 - when will the updated Rock64 with RTC and Battery will be available? 2 - will the Rock64Pro ever have a battery RTC option? (it would be a great little firewall) August 6, 2018 tllim Wrote: already factor into new ROCK64 revision including PoE option and micro SD UHS design. Needs to test all new function first before release and this takes couple months. 02-08-2019, 07:17 AM I do not see any update to using a battery for RTC on newest Rock64 which was going to be utilized as an automation server combo firewall. I have not used the Internet for time in over 15 years now and always used an NTP server with GPS / PPS. Over the years transitioned to using the PFSense box with a serial / PPS connection to a GPS which provides great time for me. I am very particular about automation and time. We are at the two year mark here. Time to give up and move on. The best thing that happened for the Pine64 was Armbian. That said I have moved on now from the Pine64 / Rock64 stuff. I would like to add an RTC / Battery to the TV Box. (icing on the cake)

Did a nightly build update to the second TV Box here (TX9 Pro - Octocore, 3Gb, 1Gb NIC) and it is working well. Only thing though when logging in to the computer see the following stuff relating to RockPro64 changing from S912 standard release logo when logging in. ____ _ ____ __ _ _ | _ \ ___ ___| | _| _ \ _ __ ___ / /_ | || | | |_) / _ \ / __| |/ / |_) | '__/ _ \ | '_ \| || |_ | _ < (_) | (__| <| __/| | | (_) | | (_) |__ _| |_| \_\___/ \___|_|\_\_| |_| \___/ \___/ |_| Welcome to ARMBIAN 5.82.190423 nightly Ubuntu 18.04.2 LTS 5.1.0-rc1-aml-s912 System load: 0.00 0.00 0.00 Up time: 8:33 hours Memory usage: 10 % of 2840MB Zram usage: 1 % of 1023Mb IP: 192.168.244.150 CPU temp: 44°C Usage of /: 14% of 29G Last login: Thu Apr 25 00:25:58 2019 from 192.168.244.232 Running a couple of automation pieces of software, docker and mono (CPU sucker)..it is hardly working...headless Found the configuration file for the MOTD here: /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=rockpro64 BOARD_NAME="RockPro 64" BOARDFAMILY=rockchip64 VERSION=5.82.190423 LINUXFAMILY=rockchip64 BRANCH=default ARCH=arm64 IMAGE_TYPE=nightly BOARD_TYPE=conf INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image /etc/update-motd.d/10-armbian-header printf '\nWelcome to \e[0;91mARMBIAN\x1B[0m %s %s %s %s\n' "$VERSION $IMAGE_TYPE $PRETTY_NAME $KERNELID" Changed the file above such that I see this when I log on. _ ___ ___ _ ____ / ___|/ _ \/ |___ \ \___ \ (_) | | __) | ___) \__, | |/ __/ |____/ /_/|_|_____| Welcome to ARMBIAN 5.82.190423 nightly Ubuntu 18.04.2 LTS 5.1.0-rc1-aml-s912 System load: 0.13 0.18 0.23 Up time: 7:09 hours Memory usage: 31 % of 2840MB IP: 192.168.244.149 CPU temp: 47°C Usage of /: 18% of 29G Last login: Fri Apr 26 08:16:38 2019 from 192.168.244.231 root@ICS-TX9:~# Box is doing well running Docker, Home Assistant, Node Red, HomeSeer, Mosquitto. I have it connected to a Leviton OmniPro 2 security panel which also does automation via X10, UPB, Zigbee and ZWave. Doing WiFi using Tasmota and Espurna firmware for 1-wire temperature sensors, LED controllers, et al. This was all originally running on an XiS Xi5a dual AMD cube, then on a Pine64 and today on the TX9. I am impressed so far with the performance I see.

Thank you JMCC.

Looking to purchase a tablet with Android to run Armbian Desktop on. Any suggestions? Looking at the FreakTab forum and see a bunch of tablets listed but no subtopics of removal of Android. Here I was able to install Ubuntu just fine on my Intel based Pipo X7.

Just having a look at another Pine64 this morning which I configured for an automation peer in ATL a couple of months ago. I see the time issue here and updating. | _ \(_)_ __ ___ / /_ | || | | |_) | | '_ \ / _ \ '_ \| || |_ | __/| | | | | __/ (_) |__ _| |_| |_|_| |_|\___|\___/ |_| Welcome to ARMBIAN 5.75 stable Ubuntu 18.04.2 LTS 4.19.20-sunxi64 System load: 0.46 0.27 0.26 Up time: 24855 days Memory usage: 42 % of 2001MB IP: 192.168.1.85 CPU temp: 46°C Usage of /: 28% of 29G [ 0 security updates available, 187 updates total: apt upgrade ] Last check: 2114-06-16 06:29 [ General system configuration (beta): armbian-config ] root@ATL-Pine64:~# date Sat Jun 16 07:16:14 EST 2114 root@ATL-Pine64:~# hwclock 2019-04-24 07:04:02.984370-0400 root@ATL-Pine64:~# I couldn't change the date so doing the nightly upgrade and hopefully a reboot will fix the date?? Nightly upgrade fixed the date stuff. (note doing this remotely) root@ATL-Pine64:~# date Wed Apr 24 07:30:34 EDT 2019 root@ATL-Pine64:~# hwclock 2019-04-24 07:31:09.806147-0400 oot@ATL-Pine64:~# uname -a Linux ATL-Pine64 4.19.20-sunxi64 #5.75 SMP Fri Feb 8 10:29:25 CET 2019 aarch64 aarch64 aarch64 GNU/Linux root@ATL-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) # time1: 8948417f7, time2: 894841400, diff: -1015 # time1: 89484d7f7, time2: 89484d400, diff: -1015 # time1: 8948f87f7, time2: 8948f8400, diff: -1015 # time1: 89491f7f7, time2: 89491f400, diff: -1015 # time1: 894a457f7, time2: 894a45400, diff: -1015 # time1: 894bb07f7, time2: 894bb0400, diff: -1015 # time1: 894cbe7f7, time2: 894cbe400, diff: -1015 # time1: 894ce27f7, time2: 894ce2400, diff: -1015 # time1: 894d397f7, time2: 894d39400, diff: -1015 # time1: 894d8a7f7, time2: 894d8a400, diff: -1015 # time1: 894ead7f7, time2: 894ead400, diff: -1015 # time1: 894f917f7, time2: 894f91400, diff: -1015 # time1: 89511a7f7, time2: 89511a400, diff: -1015 # time1: 8951297f7, time2: 895129400, diff: -1015 # time1: 8951717f7, time2: 895171400, diff: -1015 # time1: 8952be7f7, time2: 8952be400, diff: -1015 # too many errors, stopping reports not ok 2 native counter reads are monotonic # 293 errors # min: -14695416, avg: 6, max: 15369 # diffs: -42000, -41958, -42000, -42000, -42000, -42042, -42042, -42042, -42042, -42041, -42041, -42000, -42000, -42041, -42041, -42041 # too many errors, stopping reports not ok 3 Linux counter reads are monotonic # 141 errors # min: -42042, avg: 612, max: 78125 # core 0: counter value: 37320126012 => 1555 sec # core 0: offsets: back-to-back: 10, b-t-b synced: 9, b-t-b w/ delay: 12 # core 1: counter value: 37320127893 => 1555 sec # core 1: offsets: back-to-back: 15, b-t-b synced: 8, b-t-b w/ delay: 11 # core 2: counter value: 37320129416 => 1555 sec # core 2: offsets: back-to-back: 14, b-t-b synced: 8, b-t-b w/ delay: 11 # core 3: counter value: 37320131492 => 1555 sec # core 3: offsets: back-to-back: 9, b-t-b synced: 9, b-t-b w/ delay: 10 1..3 root@ATL-Pine64:~#

Here near Chicago have been able to purchase the S912 (two of them) for around $60 each. One is a running KODI Coreelec box and doing OK with older kernal. The other is going to be a combo automation server. Looking next to purchase an RK3399 although these are closer and above $100 these days. Hopefully soon will find one with a Gb NIC, 4Gb of RAM, USB 3.0, 64Gb eMMC built in for $60 USD.

Been running now around 72 hours with no time or network issues from what I can tell here. Updated this morning to current build. | _ \(_)_ __ ___ / /_ | || | | |_) | | '_ \ / _ \ '_ \| || |_ | __/| | | | | __/ (_) |__ _| |_| |_|_| |_|\___|\___/ |_| Welcome to ARMBIAN 5.79.190420 nightly Ubuntu 18.04.2 LTS 4.19.36-sunxi64 System load: 0.20 0.30 0.27 Up time: 10:52 hours Memory usage: 32 % of 2001MB IP: 192.168.244.149 CPU temp: 45°C Usage of /: 17% of 29G [ General system configuration (beta): armbian-config ] Last login: Tue Apr 23 04:19:50 2019 from 192.168.244.231 Removed hwclock sync on reboot root@ICS-Pine64:~# date Tue Apr 23 15:11:36 CDT 2019 root@ICS-Pine64:~# hwclock 2019-04-23 15:11:39.210334-0500 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) # time1: dc584c0bf7, time2: dc584c0b00, diff: -247 # time1: dc5f5f93f7, time2: dc5f5f9300, diff: -247 not ok 2 native counter reads are monotonic # 2 errors # min: -247, avg: 8, max: 16137 # diffs: -10084 not ok 3 Linux counter reads are monotonic # 1 errors # min: -10084, avg: 552, max: 116709 # core 0: counter value: 946811128468 => 39450 sec # core 0: offsets: back-to-back: 12, b-t-b synced: 8, b-t-b w/ delay: 11 # core 1: counter value: 946811131161 => 39450 sec # core 1: offsets: back-to-back: 15, b-t-b synced: 8, b-t-b w/ delay: 10 # core 2: counter value: 946811134613 => 39450 sec # core 2: offsets: back-to-back: 14, b-t-b synced: 8, b-t-b w/ delay: 10 # core 3: counter value: 946811136586 => 39450 sec # core 3: offsets: back-to-back: 10, b-t-b synced: 8, b-t-b w/ delay: 10 1..3

Thank you WindySea. Yes just put the hardware sync once on boot. Will disable it. Noticed no time jumps but after ~48 hours the hardware clock is drifting off time sync. I started this little mini automation computer stuff here on RPi's with RTCs (used PiFace RTC shim) and then also on micro OpenWRT routers (made for tinkering with easy to get to GPIO pins) the got a Pine64 (pro bono to ticker with). I waited for over a year for the Rock64 to implement an RTC (it was promised) and I was told it would be in the next production batch....never came to being switched to maybe getting a RockPi4 (still thinking of this one) and meanwhile found out about Armbian and drifted over to getting a TVBox and running Armbian on it. I got in to the NTP stuff in the 1990's tinkering in my home sandbox. So then the nightly upgrade has created a timing issue that you are looking to resolve. Understood. Not sure if you are tinkering with any of the Armbian based TV boxes. Here looking to add a battery backed up RTC in a new automation server based on the S912 Octocore arm tvbox. I have yet to take one apart. Are there schematics out there in internetlandia for any of these devices?

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.

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).

Thank you Martin. Yes have already installed Docker, Home Assistant, et al on this build a bit at a time over last day...

Ahh...thank you Martin... root@ICS-Pine64:~# fdtdump /boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb | grep erra **** fdtdump is a low-level debugging tool, not meant for general use. **** If you want to decompile a dtb, you probably want **** dtc -I dtb -O dts <filename> allwinner,erratum-unknown1; root@ICS-Pine64:/boot/dtb/allwinner# dtc -I dtb -O dts -o sun50i-a64-pine64-plus.dts /boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb sun50i-a64-pine64-plus.dts: Warning (avoid_unnecessary_addr_size): /soc/spi@1c68000/spi-flash@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property sun50i-a64-pine64-plus.dts: Warning (graph_child_address): /soc/lcd-controller@1c0c000/ports/port@0: graph node has single child node 'endpoint@0', #address-cells/#size-cells are not necessary root@ICS-Pine64:/boot/dtb/allwinner# nano sun50i-a64-pine64-plus.dts Apologies for being dense here.... Found the timer stuff.. add the line "allwinner,erratum-unknown1;" into that node and save. timer { compatible = "arm,armv8-timer"; allwinner,erratum-unknown1; interrupts = < 0x01 0x0d 0xf04 0x01 0x0e 0xf04 0x01 0x0b 0xf04 0x01 0x0a 0xf04 >; }; It is already there when I looked at the file sun50i-a64-pine64-plus.dts. What do I do next?

root@ICS-Pine64:~# fdtdump / boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb | grep erra **** fdtdump is a low-level debugging tool, not meant for general use. **** If you want to decompile a dtb, you probably want **** dtc -I dtb -O dts <filename> Couldn't open blob from '/ boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb': No such file or directory FATAL ERROR: could not read: / boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb root@ICS-Pine64:/boot/dtb/allwinner# ls overlay sun50i-h5-nanopi-k1-plus.dtb sun50i-a64-amarula-relic.dtb sun50i-h5-nanopi-m1-plus2.dtb sun50i-a64-bananapi-m64.dtb sun50i-h5-nanopi-neo2.dtb sun50i-a64-nanopi-a64.dtb sun50i-h5-nanopi-neo2-v1.1.dtb sun50i-a64-olinuxino.dtb sun50i-h5-nanopi-neo-core2.dtb sun50i-a64-orangepi-win.dtb sun50i-h5-nanopi-neo-plus2.dtb sun50i-a64-pine64.dtb sun50i-h5-orangepi-pc2.dtb sun50i-a64-pine64-lts.dtb sun50i-h5-orangepi-prime.dtb sun50i-a64-pine64-plus.dtb sun50i-h5-orangepi-zero-plus2.dtb sun50i-a64-pine64-plus.dtb-ORIGINAL sun50i-h5-orangepi-zero-plus.dtb sun50i-a64-pinebook.dtb sun50i-h6-orangepi-lite2.dtb sun50i-a64-sopine-baseboard.dtb sun50i-h6-orangepi-one-plus.dtb sun50i-a64-teres-i.dtb sun50i-h6-pine-h64.dtb sun50i-h5-libretech-all-h3-cc.dtb Getting an error here: root@ICS-Pine64:/boot# git-work/dtc/dtc -I dtb -O dts -o sun50i-a64-pine64-plus.dts /boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb -bash: git-work/dtc/dtc: No such file or directory root@ICS-Pine64:/boot/dtb/allwinner# git-work/dtc/dtc -bash: git-work/dtc/dtc: No such file or directory

I changed the host name from pine64 to ICS-Pine64. root@ICS-Pine64:~# uname -a Linux ICS-Pine64 4.19.35-sunxi64 #5.79.190418 SMP Thu Apr 18 01:36:11 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux Welcome to ARMBIAN 5.78.190415 nightly Ubuntu 18.04.2 LTS 4.19.35-sunxi64 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) # time1: 7d5fffff7, time2: 7d5e7c200, diff: -1588727 not ok 2 native counter reads are monotonic # 1 errors # min: -1588727, avg: 8, max: 824 ok 3 Linux counter reads are monotonic # 0 errors # min: 541, avg: 74002, max: 734418224158 # core 0: counter value: 34044992124 => 1418 sec # core 0: offsets: back-to-back: 14, b-t-b synced: 9, b-t-b w/ delay: 11 # core 1: counter value: 34044993581 => 1418 sec # core 1: offsets: back-to-back: 11, b-t-b synced: 8, b-t-b w/ delay: 10 # core 2: counter value: 34044995467 => 1418 sec # core 2: offsets: back-to-back: 11, b-t-b synced: 8, b-t-b w/ delay: 10 # core 3: counter value: 34044996666 => 1418 sec # core 3: offsets: back-to-back: 10, b-t-b synced: 8, b-t-b w/ delay: 10 1..3

Gb transfer speeds are fine... Pine64:~# iperf -c 192.168.244.171 ------------------------------------------------------------ Client connecting to 192.168.244.171, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.244.149 port 57916 connected with 192.168.244.171 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.08 GBytes 926 Mbits/sec

Historically with the standard build and doing an armbian-config kernel update it would lock up on reboot and I would start all over with a fresh build.

Actually looking at the difference here...looking at the updated standard via nightly good booting ... See this on boot via serial... U-Boot SPL 2018.11-rc3-armbian (Feb 08 2019 - 11:37:16 +0100) root@ICS-Pine64:~# uname -a Linux ICS-Pine64 4.19.35-sunxi64 #5.79.190418 SMP Thu Apr 18 01:36:11 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux root@ICS-Pine64:~# ls -l /boot total 34144 -rw-r--r-- 1 root root 153 Apr 18 16:19 armbianEnv.txt -rw-r--r-- 1 root root 1536 Feb 10 02:54 armbian_first_run.txt.template -rw-r--r-- 1 root root 230454 Feb 10 02:54 boot.bmp -rw-r--r-- 1 root root 2970 Feb 10 02:51 boot.cmd -rw-r--r-- 1 root root 4882 Feb 10 02:54 boot-desktop.png -rw-rw-r-- 1 root root 3042 Feb 10 02:55 boot.scr -rw-r--r-- 1 root root 153079 Apr 17 18:36 config-4.19.35-sunxi64 lrwxrwxrwx 1 root root 19 Apr 18 05:38 dtb -> dtb-4.19.35-sunxi64 drwxr-xr-x 3 root root 4096 Apr 18 05:37 dtb-4.19.35-sunxi64 lrwxrwxrwx 1 root root 23 Apr 18 05:37 Image -> vmlinuz-4.19.35-sunxi64 -rw-r--r-- 1 root root 8624976 Apr 18 05:43 initrd.img-4.19.35-sunxi64 -rw-r--r-- 1 root root 3040151 Apr 17 18:36 System.map-4.19.35-sunxi64 lrwxrwxrwx 1 root root 23 Apr 18 05:43 uInitrd -> uInitrd-4.19.35-sunxi64 -rw-r--r-- 1 root root 8625040 Apr 18 05:43 uInitrd-4.19.35-sunxi64 -rwxr-xr-x 1 root root 14245896 Apr 17 18:36 vmlinuz-4.19.35-sunxi64

Is the nightly Armbian_5.79.190418_Pine64_Ubuntu_bionic_dev_5.0.7.img is now working for you ? No. If I write the nightly image to an SD card it does not boot and shows the errors above via the terminal session. root@pine64:~# [ 312.018172] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 312.024768] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 312.064009] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY If I write the standard release Pine64 image to the SD card the Pine64 boots up fine. If I update the standard release to the new nightly build via armbian-config it boots up fine which doesn't make sense. Isn't it the same kernel being updated with the 1 - writing standard release then updating to current nightly build 2 - current nightly build write

Wierd...via serial terminal see: root@pine64:~# dmesg | grep eth [ 0.000000] psci: probing for conduit method from DT. [ 2.795398] dwmac-sun8i 1c30000.ethernet: PTP uses main clock [ 2.795483] dwmac-sun8i 1c30000.ethernet: Linked as a consumer to regulator.6 [ 2.796023] dwmac-sun8i 1c30000.ethernet: Current syscon value is not the default 6 (expect 0) [ 2.796045] dwmac-sun8i 1c30000.ethernet: No HW DMA feature register supported [ 2.796050] dwmac-sun8i 1c30000.ethernet: RX Checksum Offload Engine supported [ 2.796056] dwmac-sun8i 1c30000.ethernet: COE Type 2 [ 2.796061] dwmac-sun8i 1c30000.ethernet: TX Checksum insertion supported [ 2.796067] dwmac-sun8i 1c30000.ethernet: Normal descriptors [ 2.796072] dwmac-sun8i 1c30000.ethernet: Chain mode enabled [ 11.869154] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 11.875870] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 12.010109] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 12.016825] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 12.102540] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 12.109185] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 12.145562] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 12.152178] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 12.191148] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 12.197780] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) Booting up with the standard release to updated nightly see: root@ICS-Pine64:~# dmesg | grep eth [ 0.000000] psci: probing for conduit method from DT. [ 2.021202] dwmac-sun8i 1c30000.ethernet: PTP uses main clock [ 2.021289] dwmac-sun8i 1c30000.ethernet: Linked as a consumer to regulator.6 [ 2.021480] dwmac-sun8i 1c30000.ethernet: Current syscon value is not the default 6 (expect 0) [ 2.021494] dwmac-sun8i 1c30000.ethernet: No HW DMA feature register supported [ 2.021499] dwmac-sun8i 1c30000.ethernet: RX Checksum Offload Engine supported [ 2.021505] dwmac-sun8i 1c30000.ethernet: COE Type 2 [ 2.021510] dwmac-sun8i 1c30000.ethernet: TX Checksum insertion supported [ 2.021515] dwmac-sun8i 1c30000.ethernet: Normal descriptors [ 2.021521] dwmac-sun8i 1c30000.ethernet: Chain mode enabled [ 11.662540] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 11.665029] dwmac-sun8i 1c30000.ethernet eth0: No Safety Features support found [ 11.665042] dwmac-sun8i 1c30000.ethernet eth0: No MAC Management Counters available [ 11.665049] dwmac-sun8i 1c30000.ethernet eth0: PTP not supported by HW [ 11.665527] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 12.674853] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 12.674889] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Yes per your instruction did not utilize the 3.3VDC pin on the JTAG port and used a 2 AMP external PS connected to Euler Bus. Aside from the time sync issue (well the time going way off) the network port just disconnects randomly after a day or so with the default Gb setting or adjusted to Mb setting. Does this mean that I have a bad Pine64 here? With the original posted on the Pine64 wiki / forum never had an issue with the legacy Ubuntu 16.04. I did update that original build to Ubuntu 18.04 and it worked OK but did have some issues with it. Had a few minutes here to type between this and that....

Not sure where you are at Martin. Here it is 1130 C time and will be back later on this afternoon....

So did the login in stuff and ... root@pine64:~# ifconfig lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 root@pine64:~# [ 344.021339] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 344.027934] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 344.067108] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 344.073698] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 344.110071] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 344.116638] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 344.145095] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 344.151667] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) Got to leave in a little bit here for about 3 hours....do you need anything more for time bean?

See an error...using a little 8 port Gb switch (unmanaged) to test... ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 EHCI failed to shut down host controller. EHCI failed to shut down host controller. Loading Ramdisk to 497b4000, end 49fff3a9 ... OK reserving fdt memory region: addr=4fa00000 size=6e000 Loading Device Tree to 0000000049743000, end 00000000497b3fff ... OK Starting kernel ... [ 5.275317] asoc-simple-card sound: ASoC: codec-analog@1f015c0 not registered [ 43.843643] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 43.850256] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 43.953417] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 43.960064] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 43.998929] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 44.005578] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 44.045335] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 44.051973] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 44.091948] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY [ 44.098542] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) Ubuntu 18.04.2 LTS pine64 ttyS0

OK I hand typed the terminal command and it is working...wow...seeing it boot... U-Boot SPL 2018.11-rc3-armbian (Apr 18 2019 - 13:09:20 +0200) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000) NOTICE: Configuring SPC Controller NOTICE: BL3-1: v1.0(debug):c9f55c0 NOTICE: BL3-1: Built : 13:09:12, Apr 18 2019 NOTICE: DT: sun50i-a64-pine64-plus INFO: Configuring AXP PMIC NOTICE: PMIC: fixing DRAM voltage from 1.24V to 1.36V INFO: PMIC: DRAM voltage: 1.36V INFO: PMIC: setup successful NOTICE: SCPI: dummy stub handler, implementation level: 000000 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9 U-Boot 2018.11-rc3-armbian (Apr 18 2019 - 13:09:20 +0200) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: Pine64+ DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 Loading Environment from FAT... Unable to use mmc 0:1... In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c30000 230454 bytes read in 20 ms (11 MiB/s) starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3042 bytes read in 13 ms (228.5 KiB/s) ## Executing script at 4fc00000 U-boot loaded from SD

OK...so it seems to start with the 3.3VDC but minicom is set to 115200 8N1 and I do not see anything... Getting hash when booting and it looks like baud rate is incorrect when I use: picocom -b 115200 /dev/ttyUSB0 see this: root@ICS-IBM-T540P-1:/home/pete# picocom -b 11520 0 /dev/ttyUSB0 picocom v3.1 port is : /dev/ttyUSB0 flowcontrol : none baudrate is : 11520 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no hangup is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, logfile is : none initstring : none exit_after is : not set exit is : no !! Settings mismatch !! Type [C-a] [C-v] to see actual port settings Type [C-a] [C-h] to see available commands Terminal ready �(����a|�(���'���c��!7 �(��q�o ��������q��{� ���������=5-�c0�(A!��)����q�m�8� � ���� H� H�����aŜ���aE�� ��(�)�s� �(���� k��(�8=9���ku��8(�8=9��(����%���s(�9�)s �)Q �s!�)����u!)�5�(������� �� �i%�('�'#q'�i����)