James Kingdon

The fix for the 64G eMMC module looks promising - the module is now recognized when I boot armbian from sd card using the modified kernel. It's currently formatting the eMMC as the first stage of nand-sata-install... The fix is trivial. In drivers/mmc/core/mmc.c, remove or comment out the conditional block at line 317 card->ext_csd.rev = ext_csd[EXT_CSD_REV]; /** if (card->ext_csd.rev > 7) { pr_err("%s: unrecognised EXT_CSD revision %d\n", mmc_hostname(card->host), card->ext_csd.rev); err = -EINVAL; goto out; } */ This test has been removed from later releases of the driver and a comment added to indicate that the cards should be backwards compatible so the test is unnecessary.

Hi, I'm new to Docker but was hoping that I could use it for building Armbian. Was the howto/FAQ ever written? My initial attempts aren't going so well [much downloading of cross compilers] [ .... ] Downloading [ gcc-linaro-7.1.1-2017.08-x86_64_arm-linux-gnueabihf ] ######################################################################## 100.0% ######################################################################## 100.0% [ .... ] Verifying [ .... ] Extracting [ o.k. ] Download complete cannot open tty-output [ error ] ERROR in function source [ main.sh:105 ] [ error ] No option selected [ o.k. ] Process terminated

If you want to experiment (or depending on your needs, move into production), packet rent Cavium ThunderX hosts for 50c/hr https://www.packet.net/bare-metal/servers/type-2a/ That gives you 96 cores at 2GHz with 128 GB of ram. It makes me feel both happy and slightly dizzy just thinking about it. I intend to buy some time at some point and see how the individual cores stack up against things we can get our hands on. Which brings us back to the rk3399. Sure hope Orange are making progress with their board.

My pinebook just arrived. I have to say it's excellent value, with both the keyboard and screen being very usable. I'm sure I'll run into a few problems soon enough, but so far I'm very pleased! Update: First major problem isn't with the laptop itself, but the 64G eMMC that I ordered to go with it. Sadly it's dead-on-arrival. I've emailed them to let them know, so now I'll get to see what their customer support is like! More minor issues, there is some instability with the trackpad that sometimes jumps the cursor to the bottom left corner. Overall, still very impressed Update Aug 28th: the flashing of the screen backlight at low brightness has gone away. I'm not sure why, but it's working just fine now. I had a prompt reply to my email about the 64G eMMC saying they would forward the message to support, but haven't heard anything since. But it's been the weekend so that's not unreasonable. I opened a support ticket today in case the original email didn't make it to the right place, so we'll see how that turns out. Sep 2: It looks like the problem with the 64G eMMC is that it is reporting an EXT_CSD revision of 8, and the mmc driver checks for a max value of 7. I'm hoping I can patch the kernel to accept 8 and get things going, but I'm wondering if uboot will need to be updated as well.

Drat, just got confirmation that the m3 has been discontinued, just as 64 bit support is starting to come together courtesy of @rafaello7 https://github.com/friendlyarm/linux-3.4.y/issues/3 There's still the T3 with the same processor, but it's not as cost effective for my uses. It would be more compelling with 2G of ram - perhaps we can hope for a new version.

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.

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!

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.

Good point, that's a pretty good use case.

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

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.

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

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.

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?

Well there's one mistake for starters - I've linked the xu3 dtb to my dts source file. I'll get that fixed...

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

Excellent - where do I find the boot script?

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.

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.

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.

Never had 512k of ram on my Z80 either. I wonder how they have that set up, given the 64k address space.

Re heatsinks on PC+, I guess depends on your use case - all of mine do, plus a fan It's probably overkill, but I had the parts to hand for the higher power boards and I prefer the simplicity of not getting into thermal throttling (I mostly run benchmarks looking for performance improvements or regressions). I also run overclocked, which perhaps isn't very smart. With heatsinks but the fan turned off it will gradually climb into the 60 to 70C range, which would be fine. 1.54 GHz 0.000V 69.0C fan off 1.54 GHz 0.000V 68.0C fan off 1.54 GHz 0.000V 70.0C fan off 1.54 GHz 0.000V 70.0C fan off 1.54 GHz 0.000V 71.0C fan off Without the heatsinks it will certainly be into throttling with this workload (scalar, mostly integer, no gpu). Putting the fan back on holds the temperature in the 40s (it's a 12v fan running on the 5v line, so only very light flow and little noise. I use 12v supplies for the fans on the bigger boards) 1.54 GHz 0.000V 47.0C fan on 1.54 GHz 0.000V 46.0C fan on 1.54 GHz 0.000V 47.0C fan on 1.54 GHz 0.000V 48.0C fan on 1.54 GHz 0.000V 47.0C fan on Idle temperature (with the fan off) is typically in the low 30s (depending on ambient of course). The fan comes on and off automatically at a threshold I pick to be a bit above idle temp for each board.

I've run in to the same problem, and I've not yet been able to get perf running on any of my boards. I was thinking of pulling the sources and compiling it locally. I'd be interested to hear if anyone has already solved the problem! Edit: I had a go at compiling perf for the NanoPi M3 this evening. I realised I already had the source included in the download for the kernel, in tools/perf. Cross compiling seemed to get bogged down with dependencies, so I ended up copying the entire linux source tree to the M3 and compiling perf there. cd into the tools/perf directory and type make. I still ran into several dependency issues (lex, yacc, bison and others), but I just installed them one by one and tried again. I couldn't find python-config so I ignored that - it doesn't seem to be needed for core functionality. sudo make DESTDIR=/usr install annoyingly recompiles everything again, but I ended up with a working perf command. There's also a 'make install-man' target, but it has a dependency on asciidoc, and trying to install that has sent apt into a frenzy of downloading a couple of Gigs of stuff! Still, it's nice to have a working perf, even if not all the stats I'm used to on x86 are available.

Well recovered! I would have guessed the unpopulated header for the serial port too, I wonder what it is for.

Hi, Not sure I should be getting involved here, but the weirdness you describe above looks very much like a problem I ran into a couple of weeks ago, caused by a faulty gigabit ethernet switch. I replaced the switch with a new one and no problems since. The frustration was that the problem was ridiculously difficult to diagnose - I spent hours convincing myself it was this Pi, no, this Pi, no this cable before finally considering that it might be the switch. All cables and all Pis have since proved to be fine. Regards, James