James Kingdon

  • Content count

  • Joined

  • Last visited

1 Follower

About James Kingdon

  • Rank
    Advanced Member
  1. Now that there are an increasing number of boards running in 64 bit mode (Aarch64) it might happen that you want/need to run a 32 bit application on a 64 bit OS. I suspect that there is more than one way to do this, but here's what I've been using: dpkg --add-architecture armhf apt-get update apt-get install libc6:armhf libstdc++6:armhf Some applications need the following step to run: cd /lib ln -s arm-linux-gnueabihf/ld-2.23.so ld-linux.so.3 There is a downside to this approach - after adding armhf you have to be careful when installing new packages that you get the right version and don't end up installing 32bit packages that you don't need.
  2. Hi Pouria, welcome to the forum The support for the OPi Win board is still very much being developed. You're welcome to try the images out and see how they work, but they will probably change from day to day and there is no particular expectation that anything will work. If I remember correctly hdmi output isn't working for me either, but since I use it headless that's not a problem for me. If you're expecting a more complete OS you'll need to give the devs more time and wait until a release is made in the "stable builds" group. All the best!
  3. Ah, forgive me for joining both sides of the argument... Double the cpu registers is good, the fact that those registers are 64 bits wide instead of 32 bits also helps dramatically if the application is dealing with 64 bit data, and it also brings the newer instruction set. All of those things together will often add up to 20 to 40% performance boost on the same hardware (i.e. switching from 32 bit userspace to 64 bit), and sometimes substantially more. The A53 core is pretty good, and I think once we see more use of aarch64 it will become better appreciated (which is not to say I wouldn't be happy with a bunch of A75 cores either). Even in 32bit mode a good 8 way A53 soc can hold it's own with A17 cores in terms of max throughput (i.e. when all cores can be kept busy). A standard test case I use runs about 40% faster on a NanoPi M3 than on a UGOOS UT3S, and 10% faster than an XU4. As another example, checkout the M3 on the John the Ripper benchmark: You can see more benchmarks from this comparison here: http://openbenchmarking.org/result/1707120-TR-1703199RI54&obr_sor=y&obr_sor=y&obr_hgv=NanoPi+M3+32bit I only ran the M3 results, the other results were merged in from previous peoples work. As is typical with performance discussions, there's an awful lot of "it depends" involved. A small number of faster cores is often easier to get max performance out of. Some applications are well suited to running on a larger number of cores, some applications devolve into a memory bandwidth test. And sometimes performance per watt or performance per $ is more critical than absolute max throughput.
  4. Good point, that's a pretty good use case.
  5. preview

    Just booted an OPi win for the first time and wanted to say thank you to everyone that has contributed to supporting it. I'm looking forward to testing it out and comparing it with an OPi prime and a geekbox. I still get a kick out of seeing a new board boot up with Armbian for the first time
  6. It really does depend on the specific use case and the particular hardware being compared. A lot of tasks will have a significant component that is single threaded that will benefit from a faster single core speed, and a lot of 8 core SOCs are asymmetric which poses an additional layer of complexity for parallel work-loads. I was running a benchmark on an XU4 last night and realised that the threads were running in lock-step, so the slow cores were throttling the fast ones. I got better throughput by restricting the benchmark to just the 4 fast cores. If you have a large number of independent jobs then more cores work well (provided there's sufficient total memory bandwidth), but that tends to be more a server style of workload than a typical SBC case. Of the 8-way boards, the NanoPi M3 works the best for me so far, as long as I can stay within the 1G ram budget. Can't wait to get that running 64 bit.
  7. Thanks for writing that up EkSel, much appreciated. My cable for flashing the emmc still hasn't arrived, so being able to try this on an sd card is a big help
  8. Yes, "SD card and eMMC with stock hardkernel Ubuntu ... attached at once" was exactly my situation, and it's quite likely I changed something along the way too. I'll put grabbing a fresh image and doing a clean install on my todo list Thanks for your work on this board, it's a good performer even if it is difficult to pull the heat out of that soc. I'm guessing it's a PoP layout with the memory on top insulating the cpu.
  9. OK, so I appear to have caused myself a lot of confusion by having both the emmc and the sd card installed all the time, both with linux installed, and both apparently having 'partitions' labelled boot containing dtb files (and kernels etc). I'm guessing the boot partition on the sd card was supposed to have been mounted on /boot, but for some reason wasn't. Life is looking a little simpler now that I've unplugged the emmc. Update: Rational behaviour has been restored. The *xu4.dtb in the boot partition of the sd-card is live and the changes to the trigger temperatures and pwm values have taken affect. The heatsink/fan combo I'm using at the moment isn't up to the job, but at least I can control what's happening. Now can I keep things straight if I put the emmc back again... Incidentally, what is the 'normal' setup, should the boot partition be mounted during normal operation?
  10. Well there's one mistake for starters - I've linked the xu3 dtb to my dts source file. I'll get that fixed...
  11. Interesting, no boot.* files in /boot as seen on the running filesystem. Currently /boot contains -rw-r--r-- 1 root root 140214 Mar 28 07:13 config-4.9.13-19 -rw-r--r-- 1 root root 140214 Apr 3 16:29 config-4.9.20-21 -rw-r--r-- 1 root root 140251 Apr 10 20:40 config-4.9.20-26 lrwxrwxrwx 1 root root 32 Jul 1 17:15 exynos5422-odroidxu3.dtb -> tmp/exynos5422-odroidxu3-jbk.dts -rw-r--r-- 1 root root 60782 Apr 10 21:29 exynos5422-odroidxu3.dtb_orig -rw-r--r-- 1 root root 60031 Apr 10 21:29 exynos5422-odroidxu3-lite.dtb -rw-r--r-- 1 root root 60936 Jul 1 12:55 exynos5422-odroidxu4.dtb -rw-r--r-- 1 root root 60936 Jul 1 12:54 exynos5422-odroidxu4.dtb_orig -rw-r--r-- 1 root root 7662780 Feb 22 05:51 initrd.img-3.10.96+ -rw-r--r-- 1 root root 9395964 Mar 30 22:08 initrd.img-4.9.13-19 -rw-r--r-- 1 root root 9395397 Apr 5 20:46 initrd.img-4.9.20-21 -rw-r--r-- 1 root root 5443110 May 2 20:50 initrd.img-4.9.20-26 -rw------- 1 root root 2081916 Mar 28 08:00 System.map-4.9.13-19 -rw------- 1 root root 2082296 Apr 3 17:19 System.map-4.9.20-21 -rw------- 1 root root 2083024 Apr 10 21:27 System.map-4.9.20-26 drwxr-xr-x 3 root root 4096 Jul 1 17:56 tmp -rw-r--r-- 1 root root 9444217 Oct 9 2016 uInitrd-3.10.103-123 -rw-r--r-- 1 root root 9444044 Oct 11 2016 uInitrd-3.10.103-124 -rw-r--r-- 1 root root 9618690 Feb 22 05:50 uInitrd-3.10.104-132 -rw-r--r-- 1 root root 8357696 Jul 6 2016 uInitrd-3.10.96-110 -rw-r--r-- 1 root root 8361957 Jul 6 2016 uInitrd-3.10.96-113 -rw-r--r-- 1 root root 8361406 Jul 6 2016 uInitrd-3.10.96-114 -rw-r--r-- 1 root root 7878131 Feb 22 06:54 uInitrd-4.9.11-8 -rw-r--r-- 1 root root 9396028 Mar 30 22:09 uInitrd-4.9.13-19 -rw-r--r-- 1 root root 9395461 Apr 5 20:46 uInitrd-4.9.20-21 -rw-r--r-- 1 root root 9395241 Apr 14 19:59 uInitrd-4.9.20-26 -rw------- 1 root root 4551112 Feb 22 03:21 vmlinuz-4.9.11-8 -rw------- 1 root root 4790304 Mar 28 08:00 vmlinuz-4.9.13-19 -rw------- 1 root root 4791080 Apr 3 17:19 vmlinuz-4.9.20-21 -rw------- 1 root root 4793000 Apr 10 21:27 vmlinuz-4.9.20-26
  12. Excellent - where do I find the boot script?
  13. Ah, it looks like the config appends the dtb to the kernel, so the files I'm editing are likely not being used: CONFIG_ARM_APPENDED_DTB=y Looks like I need to recompile the kernel. Thanks for the pointer to /sys/firmware/devicetree. Sadly most of the data in pwm-fan reads as binary, making it a little inconvenient to work with.
  14. Hi. My dtb skills seem to be lacking, so I'm seeking guidance I'm running Armbian 5.27 from the sd card, kernel is 4.9.20-26 after an Apr 10 update. /boot has the following dtbs: -rw-r--r-- 1 root root 60782 Apr 10 21:29 exynos5422-odroidxu3.dtb -rw-r--r-- 1 root root 60031 Apr 10 21:29 exynos5422-odroidxu3-lite.dtb -rw-r--r-- 1 root root 60936 Jul 1 12:55 exynos5422-odroidxu4.dtb I want to change the fan threshold settings and pwm values to try and get more aggressive cooling as I'm not quite staying out of thermal throttling. After converting exynos5422-odroidxu4.dtb with dtc it's easy to see where both the thresholds and pwm values are set, so I edited to taste, recompiled the dts -> dtb and rebooted. And, absolutely nothing changed. I'm guessing I either have the wrong dtb (maybe it's using the xu3 version?) or maybe it's not using any of the dtbs in /boot? How do I confirm what's going on? One possible source of confusion - I have the emmc plugged in with the original hardkernel software on it, so I guess there exists the small possibility that something is getting picked up from there. I guess I'll try making the changes to the xu3 file and see what happens, but I'd like to understand how this fits together a little better.
  15. Assuming you have internet connectivity and ntp is not blocked, the time should be correctly set by timedate at startup. You can check the status with timedatectl status To configure the timezone use sudo dpkg-reconfigure tzdata and follow the prompts.