Jump to content

pfeerick

Members
  • Posts

    148
  • Joined

  • Last visited

Posts posted by pfeerick

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

  3. 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!

  4. @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... :blink:

     

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

     

     

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

     

     

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

     

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

     

    image.png.24f11087c3d34fafb35e2ae37712b4e6.png

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

     

  9. I see two things... one minor cosmetic, the other bloody annoying! :P

     

    Firstly the bloody annoying 'feature'... :lol:

    image.png.57e2a29b7dcb4fc54b0459b91e9d428b.png

     

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

     

    image.png.eb4bfa64a504b04d72df46ecf07b36f0.png

     

    On Chrome, Windows 10. 

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

     

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

     

  12. I can't give any board specific advice, as I don't have an Orange Pi Win, so I can't help much sorry.

     

    Can I just confirm this was with the " Ubuntu server – legacy kernel" from the downloads page? And that ubuntu server was one of the previous ones you'd used, not the debian stretch nightly? And *exactly* what is the behaviour? Type in '1234', press enter, and it freezes? Type in '1234', press enter, type in new password first time, press enter, type in the new password the second time, press enter, and it freezes... some variation of that? I remember that happening something similar happening to me before, but it was because entering the new password wrong (or was it the old one wrong) didn't give an error and just kicked the ssh session. 

     

     

  13. It's somewhere in the region of 1.5G when installing (Ubuntu Server, that is). Haven't run the server install on PC for while, but I would have thought it would partition the device at the start, so it should just be a matter of USB booting an install image and installing the sucker. 

     

    Why is Lubuntu taking up so much space now? It's only supposed to need 3Gb, with a recommended 6Gb for some free space? Are you using Lubuntu images from http://lubuntu.me/downloads/, so that you're only getting the required bits?

  14. Login/welcome messages come from the scripts in /etc/update-motd.d, so you can remove/change them as you wish.  If you didn't want the sysinfo, tips,update nofications and armbian-config messages, you can just remove the executable bit (i.e. chmod -x) from the four scripts responsible for those messages (30-sysinfo 35-tips 40-updates 41-armbian-config), and then you'd be left with just the board name. You can also turn that off by disabling the 10-header script. You can also make your own, and have them run and display on login (if properly written and the executable bit is set). 

     

    The easiest way to run something before login is to use crontab. i.e. run crontab -e, and then add a new @reboot command for a script that will run after the device has rebooted, and before login.  See this page for some more information and examples. 

  15. On 12/12/2017 at 8:44 PM, Rar9 said:

    The 0.6x image wont boot. and the existing 0.5x image won't upgrade to this new build.

    1

     

    Both of these behaviours are to be expected. I've not been following pine64/rock64 development for the last 2/3 months, but I looked at the changelog the other day, and I see in the release notes for ayufan's rock64 builds "0.6.0: Highly experimental", so it's probably a known thing that it will break. You'd have to go onto the forum or IRC to find out more. The thing to realise is that it is still marked a pre-release build, and unless their development structure has changed in the last few months, 'pre-release' (in GitHub parlance)  is considered testing' 'latest' (in GitHub parlance)  is considered beta, and the images available from the pine64 website are the more tested 'stable' versions. The update scripts included with those builds will always default to the 'latest', but you can specify the version you want to update to if you want to force the issue. To see which one it will update to automatically, just go to the latest release tag on GitHub ->  https://github.com/ayufan-rock64/linux-build/releases/latest

  16. @Joe_PS PuTTY is a piece of software that you use to connect to a remote computer, and access a terminal prompt (or a desktop GUI using X11 forwarding). You can use a serial connection (the simplest and most direct), and then later SSH over a network once the device is setup if you wish. You'll basically have a terminal/console prompt, and will be controlling the device as if you had a monitor and keyboard hooked up to it. So yes, you'll be able to type in 'armbian-config' and then use the keyboard to navigate the menus and install OMV via the software packages section. 

  17. New homepage UX looks fine, once the carousel is replaced with a newsfeed (or even the armbian twitter?) of some sort... as someone mentioned... New WiP board, x board depreciated for x reason, new beta in the works...  I agree about the consistency of the links... make sure the big buttons are in the same order as the links in the menu. 

     

    For the download page, list view looks great. Server/Desktop may become more apparent once options are seen. Else there would need to be an explanatory note at the top that Server images are mean for setups where a monitor is not connected, and Desktop images are... that sort of thing. If you wanted to introduce faster torrent / slower HTTP concept, why not just put links in smaller print underneath "HTTP link (slow), Torrent link (fast)". Experienced people will know to click the icon for the torrent, big text for HTTP, others will be guided by the smaller links.

     

    re: forum logo... if the guideline from the w3c is that the logo on sub-site should link to the main site, then that is just plain stupid. I am on the forum.armbian.com domain... when I click the logo, it should to forum.armbian.com... not some other site (armbian.com). The pine64 forum does the same, and that is just annoying. If you want a link to the main site, it belongs in the menu bar. 

     

    With a suitable template, Wordpress should do just fine... it a CMS after all! 

     

    Tutorials... will a hybrid approach work? Tutorials written/managed under WordPress/main site, so they remain 'clean' and 'to the point' (i.e. more wiki style) , and a link on the forum to the tutorial when it is published, and a link in the tutorial to the forum page for discussion and questions? Or does that sound too convoluted? 

     

    Now @chwe What's wrong with talking about the need for a 'stable' release branch in this thread... doesn't that come under 'redesign'? :-P :-D :-D And I've also been guilty of the Mali misunderstand too.... trying to apply the old PC graphics card understanding to SoCs, when they threw that idea out the window! :-O And hey, it's great we're discussing this stuff, as between all of us this might take a bit longer, but there is some mutual ownership of what's going on, and some great ideas are coming out! 

  18. 11 hours ago, tkaiser said:

    All armbianmonitor thermal read outs are broken on at least pine64/legacy and odroidxu4/next

     

    Confirmed on my Orange Pi Zero w/ 5.36/legacy. After some digging, the extra

    [ ! -z "${SocTemp##*[!0-9]*}" ]

    on https://github.com/armbian/build/blob/master/packages/bsp/common/usr/bin/armbianmonitor#L346 that Igor added to make Soc readings more resilient with badly behaved kernels is the culprit.  I've added an issue for it, and some explanation as to what broke.

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines