emk2203

Members
  • Content Count

    12
  • Joined

  • Last visited

About emk2203

  • Rank
    Member

Recent Profile Visitors

221 profile views
  1. emk2203

    NanoPi M4 performance and consumption review

    Shows that you shouldn't trust unfounded assumptions. I thought gcc variation would account for 3 - 4% variation at most, but not the 22% I see. I tried to run the setup you suggested; my SoC won't heat up beyond 69 °C. The temperature fluctuates between 67 and 69 °C, but never reaches 70 °C. Took it off the table and put it back in the box it came in, but this accounts only for 1 K difference. Your benchmark shows for a moment "Heating SoC from 70 °C to 70 °C", but nothing happens, and then the temperature drops again. So, would like to run the test, but cannot get it to work. I had switched over to the development kernel 4.19rc1, since your table shows 4.17 as kernel version for tests, it should be even better comparable than the 4.4 version from the first test. @Igor @hjc: With the Armbian Bionic image for download, I couldn't get wireless to work. armbian-config accepted my input for wireless up to the password, but after exiting and restarting, the NanoPi M4 didn't show up on the WLAN. I went to the nightly with the dev version of 4.19rc1. Files were needed from the full Armbian package, but even after switching to full firmware, I still get the error about `brcmfmac4356-sdio.txt` missing shown below. `brcmfmac4356-sdio.bin` is in the full firmware image, but was not in the "lite" firmware package which came with the downloaded Bionic image. When I google the error, it seems that I need to copy NVRAM contents from the device to the txt file mentioned in the error message. Any pointer on how to do this is welcome. Worrisome things from `dmesg`, for zswap, I attached statistics also below: zswap: default zpool zbud not available zswap: pool creation failed ... rockchip_mmc_get_phase: invalid clk rate ... dwc3 fe800000.dwc3: Failed to get clk 'ref': -2 dwc3 fe800000.dwc3: failed to initialize core ... brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac4356-sdio.txt failed with error -2 sudo grep -R . /sys/kernel/debug/zswap [sudo] password for emk2203: /sys/kernel/debug/zswap/same_filled_pages:0 /sys/kernel/debug/zswap/stored_pages:0 /sys/kernel/debug/zswap/pool_total_size:0 /sys/kernel/debug/zswap/duplicate_entry:0 /sys/kernel/debug/zswap/written_back_pages:0 /sys/kernel/debug/zswap/reject_compress_poor:0 /sys/kernel/debug/zswap/reject_kmemcache_fail:0 /sys/kernel/debug/zswap/reject_alloc_fail:0 /sys/kernel/debug/zswap/reject_reclaim_fail:0 /sys/kernel/debug/zswap/pool_limit_hit:0
  2. emk2203

    NanoPi M4 performance and consumption review

    I am quite surprised about your results, my own ones with the standard sudo /bin/bash bin/sbc-bench.sh -c show significant differences to my NanoPi M4 (4GB). Yes, I have noticed the differences in compiler versions etc., but that you get 8.7 kH/s in CPUMiner and I get 10.6 kH/s is quite a difference - more than 22%. My system also has a copper shim (15x15x1.0mm) and reaches only 66.1 °C after cpuminer. The version is also 1.3.3, same as you used.
  3. emk2203

    NanoPi M4 performance and consumption review

    The official FriendlyELEC adapter is NOT needed if you have another type. It is a BULL GN901-G plug converter, impressively built and worth the money, but you can use any other plug adapter as well. I am currently running the NanoPi M4 with an el cheapo adapter for 0.18€/piece, and it works well.* *) PS: Please take note that these are actually illegal in the EU (and in Japan and most probably US), since they expose the hot plugs if you pull them out halfway. Do not use them with children around.
  4. emk2203

    ROC-RK3399-PC (Renegade Elite)

    It wouldn't hurt to ask Libre Computer and point out that their not-so-successful campaign (around 68% of target reached) might have been successful if they would have broad and stable support from Armbian. That was the main road block for me - the software. The fact that they promise mainline kernel, starting from 4.19, actually made me buy it. All ARM devices are sketchy in this regard. With mainline support, I can use the device as long as I like, without falling behind and stuck with old kernels.
  5. emk2203

    ROC-RK3399-PC (Renegade Elite)

    They probably think that if you want it, you want the maximum amount. Quite similar to high-end phones now. That said, I hope for Armbian support soon. I bit the bullet and bought one, maybe I sell my old Firefly RK3399 instead.
  6. Any chance for you to share your kernel? My first attempt to compile a 4.19rc1 was unsuccessful. Or, let's say the compile went through, but I am still not sure what to put where afterwards. I would like to try with something known to work.
  7. For people reading this: Before you get your hopes up, the aluminum case is out of stock, and the Firefly sales rep told me in the chat that there probably won't be a second series. Demand was too low and price too high.
  8. emk2203

    DNS issues for local network with Armbian only

    How do I get the nightlies? dl.armbian.com has no nightlies, and the info I googled was outdated.
  9. emk2203

    DNS issues for local network with Armbian only

    Thanks for letting me know, I purged the contents of `/etc/resolvconf/resolv.conf.d/head` to get rid of the `nameserver 8.8.8.8` line. Otherwise, `systemd-resolved` would probably sneak it in again next time it has a chance. I agree, leaving it in there at image creation time can create a lot of unnecessary confusion. As you said, user's local config should take preference, maybe with a commented line with Google's nameserver and the additional comment `# In case of DNS problems, try uncommenting this for debugging` or similar.
  10. emk2203

    DNS issues for local network with Armbian only

    @tkaiser: Added the links to the post. @guidol: Network is default Armbian configuration, didn't mess with it. DHCP comes from router, correctly configured, all other devices work well. PiHole resolves whatever I throw at it. One device with Debian 8.11 has only the information for the PiHole in `/etc/resolv.conf` (coming from the router DHCP) and works excellent. --- Actually, problem solved. I was used to not look at `/etc/resolv.conf` anymore because it's just a dummy file when `systemd-resolved` is used, but in the Armbian version, `/etc/resolv.conf` is a file with `nameserver 8.8.8.8` as the first line. Why is this in there? I use CloudFlare DNS(SEC), and not Google's servers. Definitely didn't enter this. This is the contents of `/etc/resolv.conf` on my laptop, which I expected to be standard in Armbian as well. # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 127.0.0.53 Instead, I had nameserver 8.8.8.8 nameserver 127.0.0.53 search lan with the first line now commented out, and now it works on the Armbian machines as well. Maybe this is in there as an artifact from whatever, but it takes precedence over the `systemd-resolved` nameserver 127.0.0.53. If this a bug of the standard Armbian image? Well, a lot of writing for nothing, but it helped me debug. Thanks to you all.
  11. Setup: I have a small home network with several SBCs, PCs, NASs and two devices are running Armbian ARMBIAN 5.59, ARMBIAN 5.59 stable Ubuntu 18.04.1 LTS 4.14.65-sunxi for the Orange Pi Zero and ARMBIAN 5.59 testing Ubuntu 18.04.1 LTS 4.14.65-sunxi for the Cubieboard 1. The OPi Zero runs the PiHole application for the whole network. There's a MikroTik router which does DHCP for the network. Problem: The Armbian devices are not able to do a local name resolution, a `ping router.lan` or `ping orangepizero.lan` or `ping cubieboard.lan` from either device gives the error: "Name or service not known". A ping by IP is without issues, same problem for services like SSH. All other devices, NAS with FreeNAS 11.2, a My Book Live with a custom Debian 8.11, Hardkernel XU4 and HC1 as well as all PCs with Linux or Windows are able to ping all local devices by name. The Armbian devices have OK outside connectivity. `ping google.com` is giving the expected results. Conclusions: The problem is restricted to the Armbian machines. PiHole might be the root cause, but all other machines are able to deal with this specific configuration, and both Armbian devices won't resolve local names. Failed: sudo dpkg-reconfigure resolvconf didn't solve the problem. So far, I decided to post here to find a good way to debug this. A `dig router.lan` (this is the router at 192.168.88.1) from my laptop: ; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> router.lan ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51279 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;router.lan. IN A ;; ANSWER SECTION: router.lan. 547794 IN A 192.168.88.1 ;; Query time: 3 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Fri Aug 24 15:12:14 CEST 2018 ;; MSG SIZE rcvd: 55 A `dig router.lan` from an Armbian device: ; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> router.lan ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25576 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;router.lan. IN A ;; AUTHORITY SECTION: . 86395 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2018082400 1800 900 604800 86400 ;; Query time: 27 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Aug 24 15:11:50 CEST 2018 ;; MSG SIZE rcvd: 114 I clearly see that the results are different, but don't know how to fix. What's the best approach here? The results of `armbianmonitor -u` are at http://ix.io/1l7x for the Cubieboard and at http://ix.io/1l7y for the OPi Zero.
  12. Thanks for supporting this old board! Just a couple of days ago, I found a Cubieboard 1 in one of my drawers and decided to use it for testing and benchmarking my old 2.5" drives. While I downloaded and installed the old Xenial version, you put up a version for Bionic after all of these years. Even though I have to reinstall it now, it's worth having up-to-date versions which I am used to work with. One question: Why was NAND support dropped in modern kernels? Looking at some of the crufty old stuff still supported in the kernel, it doesn't make much sense to leave out this moderately useful feature.