Jump to content

A64 date/time clock issue


Recommended Posts

I am experiencing the issue with 5.0.6. kernel. Here are some details:

+ uname -a
Linux pine1 5.0.6-sunxi64 #5.78.190407 SMP Mon Apr 8 00:11:35 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux
+ grep ERRATUM /boot/config-5.0.6-sunxi64
CONFIG_ARM64_ERRATUM_826319=y
CONFIG_ARM64_ERRATUM_827319=y
CONFIG_ARM64_ERRATUM_824069=y
CONFIG_ARM64_ERRATUM_819472=y
# CONFIG_ARM64_ERRATUM_832075 is not set
CONFIG_ARM64_ERRATUM_845719=y
CONFIG_ARM64_ERRATUM_843419=y
CONFIG_ARM64_ERRATUM_1024718=y
CONFIG_ARM64_ERRATUM_1188873=y
CONFIG_ARM64_ERRATUM_1165522=y
CONFIG_ARM64_ERRATUM_1286807=y
# CONFIG_CAVIUM_ERRATUM_22375 is not set
CONFIG_CAVIUM_ERRATUM_23144=y
# CONFIG_CAVIUM_ERRATUM_23154 is not set
# CONFIG_CAVIUM_ERRATUM_27456 is not set
# CONFIG_CAVIUM_ERRATUM_30115 is not set
# CONFIG_QCOM_FALKOR_ERRATUM_1003 is not set
# CONFIG_QCOM_FALKOR_ERRATUM_1009 is not set
# CONFIG_QCOM_QDF2400_ERRATUM_0065 is not set
CONFIG_HISILICON_ERRATUM_161600802=y
CONFIG_QCOM_FALKOR_ERRATUM_E1041=y
CONFIG_FSL_ERRATUM_A008585=y
# CONFIG_HISILICON_ERRATUM_161010101 is not set
# CONFIG_ARM64_ERRATUM_858921 is not set
CONFIG_SUN50I_ERRATUM_UNKNOWN1=y
+ hwclock
2019-04-10 05:16:28.921505+0000
+ date
Wed May 30 11:22:32 UTC 2114

Relevant part of kern.log:

Apr  9 13:52:45 pine1 kernel: [   29.628109] cni0: port 3(veth778aa596) entered blocking state
Apr  9 13:52:45 pine1 kernel: [   29.628124] cni0: port 3(veth778aa596) entered disabled state
Apr  9 13:52:45 pine1 kernel: [   29.628569] device veth778aa596 entered promiscuous mode
Apr  9 13:52:45 pine1 kernel: [   29.628668] cni0: port 3(veth778aa596) entered blocking state
Apr  9 13:52:45 pine1 kernel: [   29.628676] cni0: port 3(veth778aa596) entered forwarding state
May 29 20:39:46 pine1 kernel: [ 2488.514955] ohci-platform 1c1a400.usb: frame counter not updating; disabled
May 29 20:39:46 pine1 kernel: [ 2488.514970] ohci-platform 1c1a400.usb: HC died; cleaning up
May 29 20:39:46 pine1 kernel: [ 2488.593368] usb 2-1: USB disconnect, device number 2
May 30 11:20:02 pine1 kernel: [55306.258901] Console: switching to colour frame buffer device 240x67
May 30 11:20:02 pine1 kernel: [55306.308636] sun4i-drm display-engine: fb0: DRM emulated frame buffer device

Relevant part of syslog:

Apr  9 14:09:24 pine1 systemd-timesyncd[489]: Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com).
Apr  9 14:15:01 pine1 CRON[4391]: (root) CMD (/usr/lib/armbian/armbian-truncate-logs)
Apr  9 14:15:01 pine1 CRON[4392]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Apr  9 14:17:01 pine1 CRON[4631]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Apr  9 14:25:01 pine1 CRON[5548]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Apr  9 14:30:01 pine1 CRON[6130]: (root) CMD (/usr/lib/armbian/armbian-truncate-logs)
May 29 20:39:46 pine1 kernel: [ 2488.514955] ohci-platform 1c1a400.usb: frame counter not updating; disabled
May 29 20:39:46 pine1 kernel: [ 2488.514970] ohci-platform 1c1a400.usb: HC died; cleaning up
May 29 20:39:46 pine1 kernel: [ 2488.593368] usb 2-1: USB disconnect, device number 2

 

Link to comment
Share on other sites

In your dmesg output (or /var/log/messages) do you see any lines similar to:

arch_timer: Enabling global workaround for Allwinner erratum UNKNOWN1

 

If not you may want to update to the latest nightly build.  There was a commit that removed the activation for this fix and the following nightly build had this issue return.  That has since been corrected and the latest DEV build once again has the mitigation to avoid this issue.

 

 

Link to comment
Share on other sites

I am having clock issue with kernels 5.0.5 and 5.0.7, where "Allwinner erratum UNKNOWN1" is active.

 

Here are some additional observations:

1) It only affects system time. Hardware clock (sudo hwclock) is still correct.

2) Trying to execute "sudo hwclock -s", returns error for invalid argument

3) After reboot "sudo hwclock -s" works and system time is updated.

4) A reboot soon after "sudo hwclock -s" results in the wrong system time being back right away.

5) If I wait for a 1-2 minutes after setting the correct system time, the reboot does not break the time.

6) I need to reconnect the keyboard attached to the board, each time the issue appears. It seems the issue affects USB, as the following is logged in kern.log:

Jun  3 01:33:54 pine1 kernel: [105898.980814] ohci-platform 1c1a400.usb: frame counter not updating; disabled
Jun  3 01:33:54 pine1 kernel: [105898.980828] ohci-platform 1c1a400.usb: HC died; cleaning up

7) The following types of errors are also recorded in kern.log: "rcu: INFO: rcu_sched self-detected stall on CPU" or "rcu: INFO: rcu_sched detected stalls on CPUs/tasks: ".

I am attaching the full kern.log with different variations of the above errors.

 

I am running same kernel on 5 boards and the issue happens on one board only. It was happening on all boards

with previous kernels, before the "UNKNOWN1" patch. The board where it happens is receiving a bit more load,

as it is kubernetes master. The load is not big at all, as the cluster is empty at the moment.

 

Here are some details, captured after the issue appeared:

+ uname -a
Linux pine1 5.0.5-sunxi64 #5.77.190401 SMP Mon Apr 1 17:57:15 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux
+ grep ERRATUM /boot/config-5.0.5-sunxi64
CONFIG_ARM64_ERRATUM_826319=y
CONFIG_ARM64_ERRATUM_827319=y
CONFIG_ARM64_ERRATUM_824069=y
CONFIG_ARM64_ERRATUM_819472=y
# CONFIG_ARM64_ERRATUM_832075 is not set
CONFIG_ARM64_ERRATUM_845719=y
CONFIG_ARM64_ERRATUM_843419=y
CONFIG_ARM64_ERRATUM_1024718=y
CONFIG_ARM64_ERRATUM_1188873=y
CONFIG_ARM64_ERRATUM_1165522=y
CONFIG_ARM64_ERRATUM_1286807=y
# CONFIG_CAVIUM_ERRATUM_22375 is not set
CONFIG_CAVIUM_ERRATUM_23144=y
# CONFIG_CAVIUM_ERRATUM_23154 is not set
# CONFIG_CAVIUM_ERRATUM_27456 is not set
# CONFIG_CAVIUM_ERRATUM_30115 is not set
# CONFIG_QCOM_FALKOR_ERRATUM_1003 is not set
# CONFIG_QCOM_FALKOR_ERRATUM_1009 is not set
# CONFIG_QCOM_QDF2400_ERRATUM_0065 is not set
CONFIG_HISILICON_ERRATUM_161600802=y
CONFIG_QCOM_FALKOR_ERRATUM_E1041=y
CONFIG_FSL_ERRATUM_A008585=y
# CONFIG_HISILICON_ERRATUM_161010101 is not set
# CONFIG_ARM64_ERRATUM_858921 is not set
CONFIG_SUN50I_ERRATUM_UNKNOWN1=y
+ hwclock
2019-04-15 05:36:16.535140+0000
+ date
Mon Jun  4 19:51:04 UTC 2114
+ cat /var/log/syslog
+ grep UNKNOWN
Jun  1 21:50:34 pine1 kernel: [    0.000000] arch_timer: Enabling global workaround for Allwinner erratum UNKNOWN1
Jun  1 21:53:07 pine1 kernel: [    0.000000] arch_timer: Enabling global workaround for Allwinner erratum UNKNOWN1
Jun  1 21:50:34 pine1 kernel: [    0.000000] arch_timer: Enabling global workaround for Allwinner erratum UNKNOWN1
Jun  1 21:50:34 pine1 kernel: [    0.000000] arch_timer: Enabling global workaround for Allwinner erratum UNKNOWN1
Jun  1 21:50:34 pine1 kernel: [    0.000000] arch_timer: Enabling global workaround for Allwinner erratum UNKNOWN1
Apr 12 05:39:44 pine1 kernel: [    0.000000] arch_timer: Enabling global workaround for Allwinner erratum UNKNOWN1
Apr 12 05:50:18 pine1 kernel: [    0.000000] arch_timer: Enabling global workaround for Allwinner erratum UNKNOWN1
Apr 12 05:54:21 pine1 kernel: [    0.000000] arch_timer: Enabling global workaround for Allwinner erratum UNKNOWN1

 

kern.log

Link to comment
Share on other sites

On a Pine A64+ I've actually started to see frequent 'rcu_sched self-detected stall on CPU' again with recent builds since the switch to the new toolchain, without any other changes.  This includes both the armbian nightlies as well as my own custom builds.

 

I haven't tried to go back to the previous toolchain yet, nor have I seen any problems with either the system clock or the hardware clock.

 

I have noticed that two other (unrelated) A53 errata are no longer activated on boot even though they are still both configured and built into the kernel:  843419 and 845719.  Again the only difference appears to be the toolchain used to build the kernel.

 

Link to comment
Share on other sites

Thanks guys here same issue with an original Pine64 2Gb computer....

 

Pine64:~# uname -a
Linux ICS-Pine64 4.19.25-sunxi64 #5.78 SMP Mon Apr 8 07:19:19 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux

 

date and time has held up for 1 day but I know it will reset to some date in the future...

 

Pine64:~# grep ERRATUM /boot/config*
/boot/config-4.19.25-sunxi64:CONFIG_ARM64_ERRATUM_826319=y
/boot/config-4.19.25-sunxi64:CONFIG_ARM64_ERRATUM_827319=y
/boot/config-4.19.25-sunxi64:CONFIG_ARM64_ERRATUM_824069=y
/boot/config-4.19.25-sunxi64:CONFIG_ARM64_ERRATUM_819472=y
/boot/config-4.19.25-sunxi64:# CONFIG_ARM64_ERRATUM_832075 is not set
/boot/config-4.19.25-sunxi64:CONFIG_ARM64_ERRATUM_845719=y
/boot/config-4.19.25-sunxi64:CONFIG_ARM64_ERRATUM_843419=y
/boot/config-4.19.25-sunxi64:CONFIG_ARM64_ERRATUM_1024718=y
/boot/config-4.19.25-sunxi64:# CONFIG_CAVIUM_ERRATUM_22375 is not set
/boot/config-4.19.25-sunxi64:CONFIG_CAVIUM_ERRATUM_23144=y
/boot/config-4.19.25-sunxi64:# CONFIG_CAVIUM_ERRATUM_23154 is not set
/boot/config-4.19.25-sunxi64:# CONFIG_CAVIUM_ERRATUM_27456 is not set
/boot/config-4.19.25-sunxi64:# CONFIG_CAVIUM_ERRATUM_30115 is not set
/boot/config-4.19.25-sunxi64:# CONFIG_QCOM_FALKOR_ERRATUM_1003 is not set
/boot/config-4.19.25-sunxi64:# CONFIG_QCOM_FALKOR_ERRATUM_1009 is not set
/boot/config-4.19.25-sunxi64:# CONFIG_QCOM_QDF2400_ERRATUM_0065 is not set

 

Updated just know to nightly build...

 

BTW armbian update web site keeps getting blocked by MaxMind (PFBlockerNg) ....coming in from Chicago....FYI...

 

Pine64:~# uname -a
Linux ICS-Pine64 4.19.34-sunxi64 #5.78.190416 SMP Tue Apr 16 22:52:20 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux

 

Am I doing this right?  Or should I update the kernel instead? (using armbian-config)

 

 

Link to comment
Share on other sites

Great news Martin!!!

 

Rushed a bit here and updated when I posted above to the then nightly build.

 

Rebooted and all was fine for a bit.  Then did update / upgrade and Pine64 does not boot now; my fault for rushing.

 

Removing SD card and will have a look see at it.  I have historically bricked the Armbian Pine 64 by updating the kernel.

 

I  do not have a monitor connected to it and cannot ping the ip although the network port LED is blinking.

 

It is not a big deal relating to updating it as the automation and automation configuration files can be backed up and restored to a new running Armbian Pine64.

 

Takes only a few minutes to create SD card and update it.

Link to comment
Share on other sites

2 hours ago, martinayotte said:

The new nightly build will only be available tomorrow, and it should be DEV build 5.0.y ...

If I can anything test/check for you? because my NanoPi A64 build is based on the Pine64-config,

but I havent seen any time-errors in the last time.

Maybe actually I wouldnt anymore, because I got now a real new compile running:
 

Welcome to ARMBIAN 5.78 user-built Debian GNU/Linux 9 (stretch) 5.0.7-sunxi64
package bsp-kernel[5.78] u-boot[5.78] dtb[5.78] firmware[5.78] config[5.78]

root@npi-a64(192.168.6.116):~# sudo hwclock -s
root@npi-a64(192.168.6.116):~# hwclock
2019-04-17 20:33:24.785733+0300
root@npi-a64(192.168.6.116):~# date
Wed Apr 17 20:33:32 +03 2019

ERRATUM:
 

Spoiler

root@npi-a64(192.168.6.116):~# grep ERRATUM /boot/config-5.0.7-sunxi64
CONFIG_ARM64_ERRATUM_826319=y
CONFIG_ARM64_ERRATUM_827319=y
CONFIG_ARM64_ERRATUM_824069=y
CONFIG_ARM64_ERRATUM_819472=y
# CONFIG_ARM64_ERRATUM_832075 is not set
CONFIG_ARM64_ERRATUM_845719=y
CONFIG_ARM64_ERRATUM_843419=y
CONFIG_ARM64_ERRATUM_1024718=y
CONFIG_ARM64_ERRATUM_1188873=y
CONFIG_ARM64_ERRATUM_1165522=y
CONFIG_ARM64_ERRATUM_1286807=y
# CONFIG_CAVIUM_ERRATUM_22375 is not set
CONFIG_CAVIUM_ERRATUM_23144=y
# CONFIG_CAVIUM_ERRATUM_23154 is not set
# CONFIG_CAVIUM_ERRATUM_27456 is not set
# CONFIG_CAVIUM_ERRATUM_30115 is not set
# CONFIG_QCOM_FALKOR_ERRATUM_1003 is not set
# CONFIG_QCOM_FALKOR_ERRATUM_1009 is not set
# CONFIG_QCOM_QDF2400_ERRATUM_0065 is not set
CONFIG_HISILICON_ERRATUM_161600802=y
CONFIG_QCOM_FALKOR_ERRATUM_E1041=y
CONFIG_FSL_ERRATUM_A008585=y
# CONFIG_HISILICON_ERRATUM_161010101 is not set
# CONFIG_ARM64_ERRATUM_858921 is not set
CONFIG_SUN50I_ERRATUM_UNKNOWN1=y

 

root@npi-a64(192.168.6.116):~# armbianmonitor -u
System diagnosis information will now be uploaded to http://ix.io/1Gth
 

Link to comment
Share on other sites

16 minutes ago, martinayotte said:

In case you wish to confirm, APritzel wrote a small test tool that check the timer during few seconds and display or not if there are errors https://github.com/apritzel/pine64/blob/master/tools/test_timer.c

my result seems to show 0 errors ;)
 

root@npi-a64(192.168.6.116):/home/guido/timertest# ./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: 6, avg: 6, max: 8274
ok 3 Linux counter reads are monotonic # 0 errors
# min: 500, avg: 545, max: 39834
# core 0: counter value: 8158738900557 => 339947 sec
# core 0: offsets: back-to-back: 14, b-t-b synced: 7, b-t-b w/ delay: 13
# core 1: counter value: 8158738902490 => 339947 sec
# core 1: offsets: back-to-back: 8, b-t-b synced: 7, b-t-b w/ delay: 10
# core 2: counter value: 8158738906396 => 339947 sec
# core 2: offsets: back-to-back: 9, b-t-b synced: 7, b-t-b w/ delay: 9
# core 3: counter value: 8158738908122 => 339947 sec
# core 3: offsets: back-to-back: 8, b-t-b synced: 7, b-t-b w/ delay: 10
1..3
root@npi-a64(192.168.6.116):/home/guido/timertest#

 

Link to comment
Share on other sites

Created new build here this morning using Etcher on Ubuntu 18.04

1 - first attempt with nightly build write to SD card resulted in a non booting OS - tried 3 times

2 - Wrote standard release to SD card and it booted fine; then updated it to nightly and it reboots fine now.

3 - changed IP to static, changed hostname, configured time, update and upgraded.

 

Note: Pine64 2Gb computer Hardware modes - heatsinks top and bottom and Euler Bus 5VDC power and RTC with battery add on.
 

|  _ \(_)_ __   ___ / /_ | || |  
| |_) | | '_ \ / _ \ '_ \| || |_
|  __/| | | | |  __/ (_) |__   _|
|_|   |_|_| |_|\___|\___/   |_|  
                                 

Welcome to ARMBIAN 5.78.190415 nightly Ubuntu 18.04.2 LTS 4.19.35-sunxi64   
System load:   0.00 0.00 0.00      Up time:       1:11 hour        
Memory usage:  4 % of 2001MB     IP:            192.168.244.149
CPU temp:      38°C               
Usage of /:    4% of 29G        

[ General system configuration (beta): armbian-config ]

Pine64:~# date
Thu Apr 18 07:01:54 CDT 2019
Pine64:~# hwclock
2019-04-18 07:01:59.383710-0500

 

Time stuff....

BSD GPS/PPS NTP server:
 

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_NMEA(0)     .GPS.            0 l   14   16  377    0.000    0.000   0.000
 0.pfsense.pool. .POOL.          16 p    -   64    0    0.000    0.000   0.000
 0.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
-time1.google.co .GOOG.           1 u   11   64  377   40.356   -4.164   1.537
+time2.google.co .GOOG.           1 u   41   64  377   20.664    2.556   0.828
*time3.google.co .GOOG.           1 u   28   64  377   20.776    2.343   0.429
+ntp1.wiktel.com .PPS.            1 u   32   64  377   29.694    2.206   1.258
+206-55-191-142. .PPS.            1 u   38   64  377   20.695    2.051   1.035
+ntp.your.org    .CDMA.           1 u   24   64  357   12.141    2.914   1.077
-clock.sjc.he.ne .CDMA.           1 u   60   64  277   69.569   -2.548   1.606

Pine64 time stuff:

 

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 1.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 2.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 3.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 ntp.ubuntu.com  .POOL.          16 p    -   64    0    0.000    0.000   0.002
*ntp-server-host .GPS.            1 u   12   64  377    0.339    2.760   2.227
#0.time.dbsinet. 129.6.15.28      2 u    9   64  377   28.870   10.107   2.615
+198.46.223.227  204.9.54.119     2 u   10   64  377   13.611    5.827   1.641
-propjet.latt.ne 46.233.231.73    2 u   10   64  377   78.768    4.163   2.124
-vps6.ctyme.com  216.218.254.202  2 u    1   64  377   70.614    0.789   2.649
+palpatine.pha.l 132.239.1.6      2 u    4   64  377   73.786    0.598   3.818
#ntp.glorb.com   129.6.15.29      2 u    7   64  377   52.197    5.521   3.004
#quake.intrstar. 45.79.13.206     3 u    7   64  377   61.276    6.189   1.651
#2001:19f0:8001: 128.138.141.172  2 u    6   64  377   61.477    5.285   2.994
#44.190.6.254    127.67.113.92    2 u    8   64  377   71.124    0.680   2.661
#208.67.72.43    152.2.133.55     2 u    4   64  377   57.691    6.677   2.961
+96.8.121.205 (9 132.163.96.3     2 u    6   64  377   58.101    3.499   2.870
+t1.time.gq1.yah 208.71.46.33     2 u   12   64  377   62.805    3.724   2.284
#155.94.238.29 ( 128.59.0.245     2 u   14   64  377   75.313    0.122   2.840
+2001:67c:1560:8 140.203.204.77   2 u   25   64  377  106.604    3.796   3.067
+172.98.77.203 ( 204.48.58.50     2 u    7   64  377   44.240    4.074   2.189
+ntp-stm32.glads .GPS.            1 u    4   64  377   46.610    1.498   3.105
#2001:67c:1560:8 140.203.204.77   2 u   27   64  377  102.470    5.011   1.619

 

 

Did not compile test timer to test with.  Can any body post the compiled test timer here?

 

grep ERRATUM /boot/config*

 

root@ICS-Pine64:~# grep ERRATUM /boot/config*
CONFIG_ARM64_ERRATUM_826319=y
CONFIG_ARM64_ERRATUM_827319=y
CONFIG_ARM64_ERRATUM_824069=y
CONFIG_ARM64_ERRATUM_819472=y
# CONFIG_ARM64_ERRATUM_832075 is not set
CONFIG_ARM64_ERRATUM_845719=y
CONFIG_ARM64_ERRATUM_843419=y
CONFIG_ARM64_ERRATUM_1024718=y
# CONFIG_CAVIUM_ERRATUM_22375 is not set
CONFIG_CAVIUM_ERRATUM_23144=y
# CONFIG_CAVIUM_ERRATUM_23154 is not set
# CONFIG_CAVIUM_ERRATUM_27456 is not set
# CONFIG_CAVIUM_ERRATUM_30115 is not set
# CONFIG_QCOM_FALKOR_ERRATUM_1003 is not set
# CONFIG_QCOM_FALKOR_ERRATUM_1009 is not set
# CONFIG_QCOM_QDF2400_ERRATUM_0065 is not set
CONFIG_HISILICON_ERRATUM_161600802=y
CONFIG_QCOM_FALKOR_ERRATUM_E1041=y
CONFIG_FSL_ERRATUM_A008585=y
# CONFIG_HISILICON_ERRATUM_161010101 is not set
# CONFIG_ARM64_ERRATUM_858921 is not set
CONFIG_SUN50I_ERRATUM_UNKNOWN1=y

Link to comment
Share on other sites

Thank you Martin.

Did:

1 - wget https://raw.githubusercontent.com/apritzel/pine64/master/tools/test_timer.c

2 - gcc -o ./test_timer ./test_timer.c

3 -

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: dbbffff7, time2: db87c200, diff: -3685879
# time1: e4233ff7, time2: e4233f00, diff: -247
# time1: e55773f7, time2: e5577300, diff: -247
not ok 2 native counter reads are monotonic # 3 errors
# min: -3685879, avg: 7, max: 4321
# diffs: -10083, -10083, -10083, -10083
not ok 3 Linux counter reads are monotonic # 4 errors
# min: -10083, avg: 560, max: 32458
# core 0: counter value: 4127213058 => 171 sec
# core 0: offsets: back-to-back: 10, b-t-b synced: 8, b-t-b w/ delay: 12
# core 1: counter value: 4127216711 => 171 sec
# core 1: offsets: back-to-back: 10, b-t-b synced: 9, b-t-b w/ delay: 11
# core 2: counter value: 4127218576 => 171 sec
# core 2: offsets: back-to-back: 10, b-t-b synced: 8, b-t-b w/ delay: 11
# core 3: counter value: 4127220240 => 171 sec
# core 3: offsets: back-to-back: 10, b-t-b synced: 8, b-t-b w/ delay: 10
1..3

I see errors above. 

 

Pine64:~# lshw
ics-pine64                  
    description: AArch64 Processor rev 4 (aarch64)
    product: Pine64+
    serial: 92c000ba768ca3be
    width: 64 bits
    capabilities: smp

 

Link to comment
Share on other sites

1 hour ago, Petee said:

1 - first attempt with nightly build write to SD card resulted in a non booting OS - tried 3 times

I've verified with this following nightly and was working fine, and I've even tested it with test_timer with success...

https://dl.armbian.com/pine64/nightly/Armbian_5.79.190419_Pine64_Ubuntu_bionic_dev_5.0.7.7z

Did you uncompress it first before using Etcher ?

Link to comment
Share on other sites

Understood.

 

Yes uncompressed the file in Ubuntu and used img file to write to the card with Etcher.  The second time I deleted the old partition using GParted which probably fixed the card.  I'll try it again with the nightly image on another card (cleaned with GParted).

 

On a different Ubuntu 18.04 laptop now...

 

1 - using new 32 gb fast SD card (Samsung) - deleted old partition from earlier testing.

2 - download new build - https://dl.armbian.com/pine64/nightly/Armbian_5.79.190419_Pine64_Ubuntu_bionic_dev_5.0.7.7z

3 - uncompress file

4 - load Etcher

5 - write image to SD card

6 - ssh'd to Pine64 and did a shutdown now

7 - inserted newly written card to Pine64

8 - powered up / NIC port flashing / waiting here

9 - looking at DHCP clients on PFSense

10 - do not see Pine64 coming up as a client on DHCP server (PFSense) as earlier described.

 

ARP on local network shows that there is something trying to get a DHCP address.

 

pete# arp -a

? (192.168.244.252) at <incomplete> on enp0s25

 

This is what would happen before....Pine64 would just drop off the network

 

 

 

 

Link to comment
Share on other sites

Unpowered Pine64 and powered it up.  Again NIC LED flashing but Pine64 never starts and gets a DHCP address.

 

Now will write a standard release to SD card and try again.

 

1 - same card - deleted partition with GParted

2 - downloaded https://dl.armbian.com/pine64/Ubuntu_bionic_next.7z

3 - uncompressed file

4 - wrote image to SD card with Etcher

5 - inserted new card / old image in to Pine64

6 - booted up fine with DHCP address

pine64:~# uname -a
Linux pine64 4.19.20-sunxi64 #5.75 SMP Fri Feb 8 10:29:25 CET 2019 aarch64 aarch64 aarch64 GNU/Linux

 

testing on old OS

 

./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: 1c0edc7f6, time2: 1c0edc400, diff: -1014
# time1: 1c10147f7, time2: 1c1014400, diff: -1015
# time1: 1c10447f7, time2: 1c1044400, diff: -1015
# time1: 1c104d7f7, time2: 1c104d400, diff: -1015
# time1: 1c115b7f6, time2: 1c115b400, diff: -1014
# time1: 1c11c77f7, time2: 1c11c7400, diff: -1015
# time1: 1c122a7f7, time2: 1c122a400, diff: -1015
# time1: 1c12a27f7, time2: 1c12a2400, diff: -1015
# time1: 1c12f37f7, time2: 1c12f3400, diff: -1015
# time1: 1c13777f7, time2: 1c1377400, diff: -1015
# time1: 1c13cb7f7, time2: 1c13cb400, diff: -1015
# time1: 1c15c8bf7, time2: 1c15c8b00, diff: -247
# time1: 1c15d87f7, time2: 1c15d8400, diff: -1015
# time1: 1c15f07f7, time2: 1c15f0400, diff: -1015
# time1: 1c169e7f7, time2: 1c169e400, diff: -1015
# time1: 1c17917f7, time2: 1c1791400, diff: -1015
# too many errors, stopping reports
not ok 2 native counter reads are monotonic # 300 errors
# min: -508919, avg: 8, max: 1273
# diffs: -42000, -42000, -42042, -42042, -42000, -42000, -42042, -42000, -42000, -42000, -42042, -42042, -42000, -42000, -42042, -42000
# too many errors, stopping reports
not ok 3 Linux counter reads are monotonic # 249 errors
# min: -734418200325, avg: -72828, max: 55875
# core 0: counter value: 8001875539 => 333 sec
# core 0: offsets: back-to-back: 9, b-t-b synced: 9, b-t-b w/ delay: 12
# core 1: counter value: 8001879658 => 333 sec
# core 1: offsets: back-to-back: 10, b-t-b synced: 8, b-t-b w/ delay: 11
# core 2: counter value: 8001881513 => 333 sec
# core 2: offsets: back-to-back: 9, b-t-b synced: 8, b-t-b w/ delay: 11
# core 3: counter value: 8001883075 => 333 sec
# core 3: offsets: back-to-back: 10, b-t-b synced: 9, b-t-b w/ delay: 10
1..3

 

At this point earlier just did the armbian-config update to a nightly build to get to the above.

Link to comment
Share on other sites

31 minutes ago, Petee said:

This is what would happen before....Pine64 would just drop off the network

That is strange ... For me, this image is working perfectly ... Use a USB-TTL Serial Debug dongle to figure out what is happening during network setup.

9 minutes ago, Petee said:

Of course, this image is dated from Feb 10th, so the timer bug is still present ...

Link to comment
Share on other sites

Yes have a USB-TTL serial dongle that I have been using for my Tasmota / ESPurna updating of devices.

 

Only thing is that I never used one on the Pine64 and have a custom 3 D printed case for it (from a guitar player in Spain).

 

Where are the JTAG pins on the Pine64?

 

Should I use the Euler bus or Pi bus?

Link to comment
Share on other sites

Can I just

 

1 - write the new image on an SD card

2 - boot up with that image

3 - pull the card out and look at the /var/logs kernel stuff to see what is happening there when it starts (won't it write to the kernel logs with errors?)

 

Well found the USB TTL connector....just need to know what pins to use...

Reading the forum looks like the "plan" was to add JTAG pins on future builds...having a close look at my board do not see anything marked that looks like JTAG Pins...

 

 

Pine64-TTLUSB.jpg

Link to comment
Share on other sites

14 minutes ago, Petee said:

Well found the USB TTL connector....just need to know what pins to use...

You need to verify with schematics, since there are several board revisions, mine seems to be different than your :

image.png.8c8ed6d35fb21746668281538180062e.png

Link to comment
Share on other sites

OK all connected. 

Building a new SD card with firmware.

 

Should I utilize minicom to watch serial port...what do I set baud rate to?

 

Will it boot up with 3.3VDC from USB TTL device or do I have to connect external power supply?

 

 

 

JTAG.jpg

Link to comment
Share on other sites

9 minutes ago, Petee said:

Should I utilize minicom to watch serial port...what do I set baud rate to?

Personally, I hate minicom, so I use "picocom -b 115200 /dev/ttyUSB0" .

9 minutes ago, Petee said:

Will it boot up with 3.3VDC from USB TTL device or do I have to connect external power supply?

Plug only GND/TX/RX (don't connect 3.3V) and use you usual external PSU  ...

Link to comment
Share on other sites

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

 

 

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines