All Activity

This stream auto-updates     

  1. Past hour
  2. Icenowy

    Orange Pi One Plus usability ?'

    Maybe it's some early patch. In early development of Pine H64 support, I missed bus-width for Pine H64. (BTW
  3. Petee

    A64 date/time clock issue

    Yes different revision and same pins...which ones are the RX-TX-Ground pins? Ahh found a Pine64 PDF...with connection pins
  4. martinayotte

    A64 date/time clock issue

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

    A64 date/time clock issue

    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...
  6. martinayotte

    Orange Pi One Plus usability ?'

    Yes ! Thanks a lot to @GeraltOfTrivia for reporting !!! This seems to have slipped in all Kernel Devs faces, even @megous or @Icenowy ... I'm just adding 3 patches to Armbian : one for H3-H5, one for A64 and one for H6 ... EDIT : I've figured out that some boards have the bus-width directly into their own DTS, like OPiPrime, but some other don't like Pine64. So, my patches done on DTSI is more general and more safe. Committed : https://github.com/armbian/build/commit/2645877aa5d5c58ac792d74f1bdc751ede55fa8d
  7. chwe

    Orange Pi One Plus usability ?'

    hmm interesting https://github.com/torvalds/linux/blob/e53f31bffe1d552f496b674cd1733658a268e177/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi#L58-L65 seems to be not default in mainline as well as in megous: https://github.com/megous/linux/blob/e22caec8c77183c5a54d332d55d9af53283ebb68/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi#L58-L65 going quickly through our patches doesn't show an obvious one here as well.. Just add @martinayotte
  8. Petee

    A64 date/time clock issue

    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?
  9. Today
  10. martinayotte

    A64 date/time clock issue

    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. Of course, this image is dated from Feb 10th, so the timer bug is still present ...
  11. Petee

    A64 date/time clock issue

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

    A64 date/time clock issue

    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
  13. martinayotte

    A64 date/time clock issue

    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 ?
  14. GeraltOfTrivia

    Orange Pi One Plus usability ?'

    Sorry to necro an old thread, but I didn't find a more suitable one and I didn't want to start a new one. Anyway, to the point. When I install or build any of the Armbian dev/nightly images with kernel 5.x, the sdcard is practically unusable after the installation. hdparm shows read/write speeds of max. 5 MB/sec. The reason is that unless the bus-width for mmc@4020000 is explicitly set to 4 bits in sun50i-h6-orangepi-one-plus.dtb mmc@4020000 { compatible = "allwinner,sun50i-h6-mmc", "allwinner,sun50i-a64-mmc"; reg = <0x4020000 0x1000>; clocks = <0x2 0x43 0x2 0x40>; clock-names = "ahb", "mmc"; resets = <0x2 0x12>; reset-names = "ahb"; interrupts = <0x0 0x23 0x4>; status = "okay"; #address-cells = <0x1>; #size-cells = <0x0>; pinctrl-names = "default"; pinctrl-0 = <0xb>; vmmc-supply = <0xc>; bus-width = <0x4>; cd-gpios = <0xd 0x5 0x6 0x1>; phandle = <0x2f>; }; the bus width defaults to 1 bit as seen in root@orangepi:~# cat /sys/kernel/debug/mmc0/ios clock: 50000000 Hz actual clock: 50000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 0 (1 bits) timing spec: 2 (sd high-speed) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) which practically cripples the SD card interface. By default there is no bus-width entry in sun50i-h6-orangepi-one-plus.dtb for mmc@4020000. I don't know if this is Armbian specific or not or if this has been mentioned again, I just thought I'd share my findings in case this helps someone.
  15. Petee

    A64 date/time clock issue

    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
  16. martinayotte

    A64 date/time clock issue

    Compiling the test_timer.c is so easy to do it yourself : gcc -o ./test_timer ./test_timer.c
  17. Petee

    A64 date/time clock issue

    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
  18. pkfox

    M4 Died

    Thanks for the info I'm pretty sure it's dead and I've just sent an email to FriendlyElec - will keep you all posted
  19. chwe

    M4 Died

    The point of the discussion is to ascertain whether the board is truly dead - which I believe it is and that's the point.. using a volt-meter to see if power is still on the important powerlines lines with your normal powering setup.. in case yes.. connect the UART and look if you get an output.. in case the main powerrails are dead.. the board is for sure dead as well..
  20. guidol

    apt-get update errors, what do they mean?

    Ja, sag einfach Bescheid ob es geklappt hat in der Bretagne
  21. Oh great Guidol, i'll try taht later the days and keep you informed hans
  22. pkfox

    SATA project Part IV

    Here's some photos of my M4 with SATA hat and 4 SSD's in a drive case - all working beautifully
  23. pkfox

    M4 Died

    Yes I agree Nico - I bought two of these , one from friendly direct and one from Amazon and I don't know which one is which - I don't suppose it matters as it's all from them originally
  24. pkfox

    M4 Died

    The point of the discussion is to ascertain whether the board is truly dead - which I believe it is
  25. guidol

    apt-get update errors, what do they mean?

    ign is ignore - when there is nothing new or not needed = no error W is in most logging files a Warning. you have a double entry in line 2 (without a #) is the same as in line 4 security.debian.org/updates and there main. you could comment out the second line as line 4 has it all from security
  26. F4VSJ

    OPI Lite wants to connect eth0

    Thanks this is solved Hans
  27. AndrewDB

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

    Your box is bricked. See how to unbrick on Freaktab website. or google "how to unbrick my Amlogic tv box". Also, please don't post off-topic anymore in this thread, since at this point this has nothing to do with Armbian.
  1. Load more activity