Jump to content

pfeerick

Members
  • Posts

    148
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling
  • Location
    Queensland, Australia
  • Interests
    Electronics, SBCs, cats

Recent Profile Visitors

4466 profile views
  1. Thanks for finding out the cause of the problem! I just updated all seven nodes of my clusterboard, only to have them not boot... It was probably time to clean them up, but it's still annoying, and affects more than just the clusterboard, but also the Pine64 A64 LTS. I thought I was having trouble with getting this to take, but I was probably being too imatient, and not waiting long enough for the microSD resize to complete... If I understand right, the patch would go in here - https://github.com/armbian/build/tree/master/patch/kernel - but I'm not sure which of the sunxi branches it goes in... current? Making it so the patch belongs in `archive/sunxi-5.10` ... Anyway... all seven nodes will be happy once I apply this to the remaining six
  2. I also got the same email, three days ago now ... three failed attempts from London UK, and three from Finland... not even the right continent... needless to say, nice long new password generated.
  3. I have been running the rockpro64 as a NAS for over a year now - since somewhere around 6 months after it's release. During it's time as a NAS, I have only had downtime due to maintenance on the power system it runs on (runs on a 12v solar system). I run a pair of USB Seagate 4TB Expansion HDDs (plus another pair I periodically network connect for offline backups), both shared out via minidlna and samba. It's running one of the ayufan-OMV images, so is still on OMV4. I'm waiting to see if the 20.08 refresh of the images will bump the stable kernel for debian from 4.x to 5.x, and then I will migrate to Armbian + OMV5. I did try bumping the Buster 'stable' image kernel from 4.4 to 5.4 via `armbian-config` on a second rockpro64, but that resulted in what appears to be a no-boot scenario (no HDMI, no network), so I won't be trying that again in a hurry.
  4. Just a quick question due to having just updated and rebooted my Cubietruck.... I was running 5.38 mainline Stretch, but I see that armbian-firmware 5.45 was installed over 5.38... so shouldn't the welcome screen now be saying "Welcome to ARMBIAN 5.45" instead of "Welcome to ARMBIAN 5.38" still? Or is that package not the one that determines the Armbian 'version'? Maybe a better question would be what would update /etc/armbian-release ? The update process was otherwise smooth and doesn't seem to have rise to any nasty surprises . I also look forward to trying out the pineH64 image since I see that has just made a big jump, as well as the new pinebook image. Keep up the great work!
  5. How about creating/editing /etc/rc.local and running script from there? i.e. Something like #!/bin/bash python <name of script> & exit 0 Make sure that /etc/rc.local is executable (sudo chmod +x /etc/rc.local) and it'll be picked up and run when you reboot.
  6. @Jason Fisher er... not sure why you commented about ZFS as that has nothing to do with this thread... have you replied to the wrong thread?
  7. @AnythingIsFine Ouch! That sounds like me with the raspberry pi... when the recent 'disabled by default' behavior of the SSH... scratching my head to work out why the SSH wasn't working, and I'd firstly forgotten to make the enable file, then made a typo in the filename... At least it's working now! Hm. so the artful images... interesting... will have to poke around and see why it changed. Be handy to port that back to other images. If the artful images are using the kernel that supports it, it could be signifying disk activity...
  8. If you subsequently mounted and unmounted the partition, a sync shouldn't have been needed, as you introduced enough time for the buffers to be written to disk, and the unmount shouldn't release the drive until everything has been written to disk. I don't know what's happening on your side with the verification, since at least version 0.9 Etcher has done a verify/validate on a write after the write phase on both Linux and Windows, but it was very subtle... the progress bar would just run through a second time but would state it was verifying instead of writing. In a update (1.4.2 or 1.4.4?) that was pushed a couple weeks ago, the verify progress bar is a different colour now, making it more visible. If you're using a serial console cable with the rock64, it would be a good idea to disconnect it (from the computer), powerup the rock64, and reconnect it, as sometimes the power feeding in from the serial console cable via either the TX or RX pin is enough to leave the rock64 in a non-booting state. Other than that, if Ether is verifying the image, it sounds like the image writing to eMMC is fine, so I don't know what else is going on. If you want to get really bored, you can watch these two screen record caps of me writing the current rock64 Ambian xenial image to the eMMC and then booting it... firstly using Etcher and then secondly using dd. Note with the dd capture I ran into the intermittent issue where the rock64 will not boot properly if there is a serial console cable connected at power on- it gets some residual power via the serial console cable and doesn't reset the CPU properly. Side-note: Can you link to a image that does this 'led' flashing... I've been using the Xenial images (initially the minimal images, but now container ones) of ayufan's images since he started producing them and hadn't noticed any of them flash the either of the LEDs OOTB, other than ones that flash the SPI Flash memory chip. I seem to remember the Android ones doing that though.
  9. The format of your command in /etc/fstab looks fine. Did you make sure that the /home/orangepi/ramdisk directory exists for mounting? You could have done a 'sudo mount /home/orangepi/ramdisk' after making the changes to /etc/fstab, and hopefully got a reaonsable error message then, instead of at boot time. And just a quick FYI, this isn't the OrangePi support forum! :-P
  10. When you did the dd, did you do a sync afterwards to ensure the image had completely finished writing to the sd card? pfeerick@ASUS-H55D:~$ sudo dd if=~/Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img of=/dev/sdf status=progress bs=1M 832569344 bytes (833 MB, 794 MiB) copied, 3.00251 s, 277 MB/s 1052+0 records in 1052+0 records out 1103101952 bytes (1.1 GB, 1.0 GiB) copied, 3.97628 s, 277 MB/s pfeerick@ASUS-H55D:~$ time sync real 0m11.902s user 0m0.000s sys 0m0.028s As can be seen above, I needed to wait 12 seconds after dd had finished before I could safely remove the microSD card. (Edit: Just to remove any confusion, I loaded Armbian on a microSD this time to show the timing and that a sync is needed with dd. I previously loaded and booted a 16GB FORESEE eMMC using the pine64 eMMC to USB adapter.) Armbian does not need a separate /boot partition, as the version of uboot it ships with supports ext4, hence they were able to get rid of that extra partition. pfeerick@ASUS-H55D:~$ sudo fdisk -l /dev/sdf Disk /dev/sdf: 15 GiB, 16118710272 bytes, 31481856 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x91a1b523 Device Boot Start End Sectors Size Id Type /dev/sdf1 32768 2154495 2121728 1G 83 Linux pfeerick@ASUS-H55D:~$ fdisk -l Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img Disk Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img: 1 GiB, 1103101952 bytes, 2154496 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x91a1b523 Device Boot Start End Sectors Size Id Type Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img1 32768 2154495 2121728 1G 83 Linux Why does running Fedora Workstation mean that Etcher skips the verification/validation after writing? Are you running an older version, or have it turned off in the options? Etcher can read a xz compressed image (e.g. xenial-containers-rock64-0.6.27-196-arm64.img.xz) natively, without any need to extract the image from it. It cannot do the same for yet, although it has been discussed on their issue tracker as a possibility.
  11. You can most certainly just flash Armbian to the eMMC instead of to microSD and using nand-sata-install... I just tried it with the 5.42 xenial build of Armbian and it worked just fine. https://pastebin.com/qvNad516 1) Download 7z file containing image from Armbian website 2) Extract .img file from 7z archive (i.e. Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img at time of writing) 3) Write .img file with Etcher using USB eMMC adapter 4) Once verified (man that eMMC verifies fast on USB3!!), clip eMMC onto rock64 and apply power It's possible what was tripping you up is that ayufan's images are xz compressed, and Etcher can read then natively. It can't read the 7z archives natively, so you have to help it and extract the disk image from the archive before writing it.
  12. I see two things... one minor cosmetic, the other bloody annoying! Firstly the bloody annoying 'feature'... And then the minor cosmetic detail... probably a legacy of the multi-reaction thingy... you mouse over the heart, that grey slider starts trying to pop out... On Chrome, Windows 10.
  13. Oh my, nice work! Actually booting into linux and not promptly bursting in flames... That in itself is an noteworthy milestone! Not sure of performance, but the processor is running very cool on 'idle' . barely warm to touch. No frequency or thermals yet, so it'll be interesting to see what is really going on. I don't think it was able to shut down properly on a 'sudo poweroff'... need the plug in a console cable to see what happened there. Addendum: Got the serial console working on the EXP header @ 115200 baud. It does 'power off' / "Starting Power-Off... [ 2557.657434] reboot: Power down", but continues to draw a health 0.8W or 170mA (basically the same as when it's idling, and leaves the green LED near the headphones jack lit. A forcible power off by pressing and holding the power button for ~8 seconds results in a drop to 0.18W or 32ma. Serial logs for Debian (first boot) and Ubuntu (rebooted). It looks like I booted the same build as Igor... Bionic... as I'm more partial to Ubuntu than Debian. My armbianmonitor dump is here, vanilla pineH64, nothing plugged in except for power and GbE via a switch : http://ix.io/18UC Edit re Debian: For the sake of completeness, I also booted the Debian build, and it's armbianmonitor log is http://ix.io/18V7 I can also report zero activity from the USB3 port. It is being powered, but there is no response/kernel messages when a device is plugged in, USB3, 2 or otherwise. On the other hand, this was the output from plugging something into the USB2 ports... Seems to be working fine (can see and mount drives) just the dwc3 error. == Lower USB Port == [Apr28 04:48] usb 3-1: new high-speed USB device number 2 using ehci-platform [ +0.160142] usb-storage 3-1:1.0: USB Mass Storage device detected [ +0.012355] scsi host0: usb-storage 3-1:1.0 [ +0.005677] dwc3 5200000.dwc3: failed to initialize core [ +1.007158] scsi 0:0:0:0: Direct-Access Generic STORAGE DEVICE 1532 PQ: 0 ANSI: 6 [ +0.004774] dwc3 5200000.dwc3: failed to initialize core [ +0.367311] sd 0:0:0:0: [sda] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB) [ +0.000978] sd 0:0:0:0: [sda] Write Protect is off [ +0.000008] sd 0:0:0:0: [sda] Mode Sense: 21 00 00 00 [ +0.001013] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ +0.012624] sda: sda1 [ +0.003756] sd 0:0:0:0: [sda] Attached SCSI removable disk == Disconnect and Upper USB Port == [Apr28 04:49] usb 3-1: USB disconnect, device number 2 [ +2.625559] usb 1-1: new high-speed USB device number 2 using ehci-platform [ +0.160284] usb-storage 1-1:1.0: USB Mass Storage device detected [ +0.005631] scsi host0: usb-storage 1-1:1.0 [ +0.003775] dwc3 5200000.dwc3: failed to initialize core [ +1.027671] scsi 0:0:0:0: Direct-Access Generic STORAGE DEVICE 1532 PQ: 0 ANSI: 6 [ +0.002970] dwc3 5200000.dwc3: failed to initialize core [ +0.367868] sd 0:0:0:0: [sda] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB) [ +0.001101] sd 0:0:0:0: [sda] Write Protect is off [ +0.000008] sd 0:0:0:0: [sda] Mode Sense: 21 00 00 00 [ +0.000993] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ +0.010520] sda: sda1 [ +0.003916] sd 0:0:0:0: [sda] Attached SCSI removable disk Edit re Debian: The Debian image from the didn't have the dwc3 errors when plugging into the USB2 ports... [Apr28 08:28] usb 3-1: new high-speed USB device number 2 using ehci-platform [ +0.159409] usb 3-1: New USB device found, idVendor=05e3, idProduct=0749, bcdDevice=15.32 [ +0.000009] usb 3-1: New USB device strings: Mfr=3, Product=4, SerialNumber=2 [ +0.000005] usb 3-1: Product: USB3.0 Card Reader [ +0.000005] usb 3-1: Manufacturer: Generic [ +0.000005] usb 3-1: SerialNumber: 000000001532 [ +0.000938] usb-storage 3-1:1.0: USB Mass Storage device detected [ +0.000994] scsi host0: usb-storage 3-1:1.0 [ +0.175901] usbcore: registered new interface driver uas [ +0.844075] scsi 0:0:0:0: Direct-Access Generic STORAGE DEVICE 1532 PQ: 0 ANSI: 6 [ +0.000708] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ +0.370255] sd 0:0:0:0: [sda] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB) [ +0.000981] sd 0:0:0:0: [sda] Write Protect is off [ +0.000007] sd 0:0:0:0: [sda] Mode Sense: 21 00 00 00 [ +0.000994] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ +0.008896] sda: sda1 [ +0.004247] sd 0:0:0:0: [sda] Attached SCSI removable disk Just tried the "Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter" (from the pine64 store) for the first time, and it seems to have been just a plug an play affair even in this early stage... quick run of nmtui and it was up and running. == Plugging in USB Wifo, bottom USB2 port == [Apr28 05:01] usb 3-1: new high-speed USB device number 5 using ehci-platform [ +0.161519] dwc3 5200000.dwc3: failed to initialize core [ +0.256283] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ +0.007980] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ +0.002099] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ +0.000014] cfg80211: failed to load regulatory.db [ +1.350222] usb 3-1: USB disconnect, device number 5 [ +0.000496] usbcore: registered new interface driver 8812au [ +0.421349] usb 3-1: new high-speed USB device number 6 using ehci-platform [ +0.463789] dwc3 5200000.dwc3: failed to initialize core [ +0.117435] 8812au 3-1:1.0 wlx08107aff527a: renamed from wlan0 [ +0.089667] IPv6: ADDRCONF(NETDEV_UP): wlx08107aff527a: link is not ready [ +0.576959] IPv6: ADDRCONF(NETDEV_UP): wlx08107aff527a: link is not ready [ +0.000041] IPv6: ADDRCONF(NETDEV_CHANGE): wlx08107aff527a: link becomes ready [ +0.142635] IPv6: ADDRCONF(NETDEV_UP): wlx08107aff527a: link is not ready [Apr28 05:02] IPv6: ADDRCONF(NETDEV_CHANGE): wlx08107aff527a: link becomes ready == ip addr == 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 86:99:5f:3e:0e:2d brd ff:ff:ff:ff:ff:ff inet 192.168.0.122/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0 valid_lft 84343sec preferred_lft 84343sec inet6 fe80::8eb6:99f:513a:2d7/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlx08107aff527a: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 08:10:7a:ff:52:7a brd ff:ff:ff:ff:ff:ff inet 192.168.0.123/24 brd 192.168.0.255 scope global dynamic noprefixroute wlx08107aff527a valid_lft 85820sec preferred_lft 85820sec inet6 fe80::ff65:b46c:ed97:2d32/64 scope link noprefixroute valid_lft forever preferred_lft forever == lsusb == Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 006: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  14. Don't know if it is of any interest, but since it's tinymembench and a rock64, here goes :-P. Running the ayufan-xential-linux-0.7.x image with docker and stuff in the background. Compiled tinymembench with default parameters. rock64 v2 board w/ 4GB memory. No HDMI plugged in, headless box. rock64@rock64:~/tinymembench$ uname -a Linux rock64 4.4.114-rockchip-ayufan-193 #1 SMP Sun Mar 4 20:24:21 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux rock64@rock64:~/tinymembench$ sudo cat /sys/kernel/debug/clk/clk_summary |grep clk_ddr clk_ddrmon 0 0 24000000 0 0 pclk_ddr 3 3 98304000 0 0 pclk_ddr_grf 1 1 98304000 0 0 pclk_ddrstdby 0 0 98304000 0 0 pclk_ddr_mon 1 1 98304000 0 0 pclk_ddr_msch 1 1 98304000 0 0 pclk_ddrupctl 0 0 98304000 0 0 pclk_ddrphy 1 1 75000000 0 0 sclk_ddrc 2 2 786000000 0 0 aclk_ddrupctl 0 0 786000000 0 0 clk_ddrupctl 1 1 786000000 0 0 clk_ddrmsch 1 1 786000000 0 0 rock64@rock64:~/tinymembench$ ./tinymembench tinymembench v0.4.9 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 1438.1 MB/s (1.9%) C copy backwards (32 byte blocks) : 1449.3 MB/s (3.1%) C copy backwards (64 byte blocks) : 1354.0 MB/s (0.3%) C copy : 1360.7 MB/s (1.5%) C copy prefetched (32 bytes step) : 1280.4 MB/s C copy prefetched (64 bytes step) : 1447.5 MB/s (2.6%) C 2-pass copy : 1645.8 MB/s (2.5%) C 2-pass copy prefetched (32 bytes step) : 1214.7 MB/s C 2-pass copy prefetched (64 bytes step) : 1165.4 MB/s C fill : 5678.7 MB/s C fill (shuffle within 16 byte blocks) : 5681.5 MB/s (3.1%) C fill (shuffle within 32 byte blocks) : 5681.5 MB/s C fill (shuffle within 64 byte blocks) : 5685.2 MB/s (3.0%) --- standard memcpy : 1330.4 MB/s standard memset : 5680.6 MB/s (3.0%) --- NEON LDP/STP copy : 1530.9 MB/s NEON LDP/STP copy pldl2strm (32 bytes step) : 1261.7 MB/s (2.8%) NEON LDP/STP copy pldl2strm (64 bytes step) : 1466.2 MB/s NEON LDP/STP copy pldl1keep (32 bytes step) : 1668.5 MB/s NEON LDP/STP copy pldl1keep (64 bytes step) : 1674.7 MB/s (2.9%) NEON LD1/ST1 copy : 1511.5 MB/s NEON STP fill : 5681.3 MB/s NEON STNP fill : 2242.6 MB/s (1.9%) ARM LDP/STP copy : 1531.0 MB/s ARM STP fill : 5681.9 MB/s (2.8%) ARM STNP fill : 2251.2 MB/s (2.3%) ========================================================================== == Framebuffer read tests. == == == == Many ARM devices use a part of the system memory as the framebuffer, == == typically mapped as uncached but with write-combining enabled. == == Writes to such framebuffers are quite fast, but reads are much == == slower and very sensitive to the alignment and the selection of == == CPU instructions which are used for accessing memory. == == == == Many x86 systems allocate the framebuffer in the GPU memory, == == accessible for the CPU via a relatively slow PCI-E bus. Moreover, == == PCI-E is asymmetric and handles reads a lot worse than writes. == == == == If uncached framebuffer reads are reasonably fast (at least 100 MB/s == == or preferably >300 MB/s), then using the shadow framebuffer layer == == is not necessary in Xorg DDX drivers, resulting in a nice overall == == performance improvement. For example, the xf86-video-fbturbo DDX == == uses this trick. == ========================================================================== NEON LDP/STP copy (from framebuffer) : 305.5 MB/s NEON LDP/STP 2-pass copy (from framebuffer) : 288.1 MB/s NEON LD1/ST1 copy (from framebuffer) : 80.3 MB/s NEON LD1/ST1 2-pass copy (from framebuffer) : 79.2 MB/s ARM LDP/STP copy (from framebuffer) : 157.3 MB/s (2.0%) ARM LDP/STP 2-pass copy (from framebuffer) : 152.5 MB/s (1.9%) ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.1 ns / 0.1 ns 65536 : 5.3 ns / 9.0 ns 131072 : 8.2 ns / 12.5 ns 262144 : 11.5 ns / 16.9 ns 524288 : 67.3 ns / 106.0 ns 1048576 : 101.9 ns / 143.6 ns 2097152 : 120.3 ns / 159.0 ns 4194304 : 133.9 ns / 171.1 ns 8388608 : 142.0 ns / 178.2 ns 16777216 : 147.6 ns / 183.7 ns 33554432 : 152.0 ns / 188.1 ns 67108864 : 168.1 ns / 215.8 ns
  15. Right, why did you post to this topic while I had it open? I think I need to go check my network security now! Anyway, indeed... if this is node red and MQTT running, there is nothing to stop an ESP8266 with screen... say a 1.3" OLED or a 2.2" TFT, etc, from also polling the orange pi / etc and showing the data.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines