Search the Community

Pinebook (A64) and ROCK64 (RK3328) also with Ubuntu Xenial arm64 sysbench distro package (that's important! Otherwise just numbers without meaning since sysbench is a compiler settings benchmark and not able to meausre hardware performance) echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor for i in $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies) ; do echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo -e "$(( $i / 1000)): \c" sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4 2>&1 | grep 'execution time' done Pinebook (no throttling happening -- just compare time_in_state before/after every run). CPU clockspeed above 1152 MHz are disabled by Allwinner's budget cooling settings that's why 1200 and 1344 results are the same as for the 1152, since that's the real clockspeed: 480: execution time (avg/stddev): 19.1398/0.01 600: execution time (avg/stddev): 15.2882/0.01 720: execution time (avg/stddev): 12.7485/0.01 816: execution time (avg/stddev): 11.2629/0.01 912: execution time (avg/stddev): 10.1254/0.01 960: execution time (avg/stddev): 9.5806/0.00 1008: execution time (avg/stddev): 9.0986/0.01 1056: execution time (avg/stddev): 8.6765/0.01 1104: execution time (avg/stddev): 8.3067/0.01 1152: execution time (avg/stddev): 7.9538/0.00 1200: execution time (avg/stddev): 7.9521/0.00 1344: execution time (avg/stddev): 7.9843/0.01 ROCK64 (no throttling happened): 408: execution time (avg/stddev): 23.4966/0.01 600: execution time (avg/stddev): 15.4553/0.00 816: execution time (avg/stddev): 11.3848/0.01 1008: execution time (avg/stddev): 9.1798/0.01 1200: execution time (avg/stddev): 7.6882/0.00 1296: execution time (avg/stddev): 7.1025/0.00 ROCK64 is slightly slower which most probably is related to L1 cache latencies or something like that. You'll find a lot of additional information here: https://forum.armbian.com/topic/1748-sbc-consumptionperformance-comparisons/ (see there especially that how the sysbench binary has been built is the most important factor and that sysbench numbers of devices with totally different DRAM configuration/performance show identical sysbench scores)

Just for the record: tested latest Pinebook image and Profile-sync-daemon still isn't enabled automatically: tk@pinebook:~$ psd preview Profile-sync-daemon v6.31 on Ubuntu 16.04.3 LTS Systemd service is currently inactive. Systemd resync-timer is currently inactive. Overlayfs v22 is currently active. Psd will manage the following per /home/tk/.config/psd/psd.conf: tk@pinebook:~$ systemctl --user enable psd Created symlink from /home/tk/.config/systemd/user/default.target.wants/psd.service to /usr/lib/systemd/user/psd.service. tk@pinebook:~$ systemctl --user start psd tk@pinebook:~$ psd preview Profile-sync-daemon v6.31 on Ubuntu 16.04.3 LTS Systemd service is currently active. Systemd resync-timer is currently active. Overlayfs v22 is currently active. Psd will manage the following per /home/tk/.config/psd/.psd.conf: Anyone able to confirm?

With latest commits it's now implemented like this: zram-config added to Xenial default package list firstrun checks for this package and if installed will neither create a swap file nor write vm.swappiness=0 to /etc/sysctl.conf nand-sata-install (hopefully) learned to deal with what's configured and will honor existing settings when transferring installation So only new Xenial images are affected currently since there SD card based swap will be replaced by zram with default vm.swappiness. I did a lot of testing mostly with legacy kernels and to be honest find it really hard to 'measure' effects. With Pinebook I had to open 40 Chromium tabs to let Chromium eat up to 2.7 GB memory and as expected it just felt slow. But it feels slow all the time (compared to what I'm used to) so it's really hard to 'measure' any effects. I read about people adjusting vm.swappiness to much lower values happily reporting back that 'everything way better now' but based on user experience tests I wouldn't count on this and my personal tests resulted in me just thinking 'well, still slow'. With my very own use cases (server tasks) I'm not able to get zram swap being used extensively, mostly since it seems I'm only using daemons that behave well. So we really need some experiences made by users out there. In the meantime installation of zram-config package is not needed any more since I added everything this package does to an activate_zram function in armhwinfo (wrong place, I know -- reasons below). I took most of the functionality unaltered except a few details amount of memory used is the same (half of DRAM) and it's only configurable by adjusting armhwinfo code (done by intention, I really want to avoid dealing with problem reports from users adjusting everything to death while not even understanding virtual memory and paging basics) number of zram devices == count of CPU cores but limited to 4 (using all CPU cores works well on x86 but we don't want compression/decompression happening on A7 cores in big.LITTLE designs) set LZ4 as algorithm where possible (otherwise fallback to what the kernel is configured to use -- LZO today -- will happen). This might need adjustments in the future if we switch to 'better' compression algos on a specific platform (eg. zstd -- an interesting read here) So what's next (please keep in mind that I'm solely focused on a way to collect user experiences in the least 'expensive' (time consuming) way -- it kinda sucks how much efforts are needed to get good user feedback! With new Xenial images users are testing zram + vm.swappiness=60 behaviour Experienced users who know what they do can be encouraged by another forum thread to start experimenting with zram on their installations (it's as easy as uncommenting the 'activate_zram' line in armhwinfo, adjusting vm.swappiness in /etc/sysctl.conf and/or deleting the swap entry in /etc/fstab) Experienced users with interesting hardware setups (eg. running off pretty fast ODROID eMMC or a SATA SSD and not a slow SD card) can be encouraged to do even more testing (combining zram with swap on SSD for example with modified vm.swappiness) We can uncomment the 'activate_zram' line in armhwinfo in a few months causing no harm on existing installations since due to vm.swappiness=0 there nothing will change (only emergency swap behaviour will improve a lot) In half a year based on the collected experiences we can remove zram-config from Xenial package list and finally adjust firstrun to skip swapfile creation and adjusting vm.swappiness (or maybe we came up with a better value in the meantime and set this as default) There's only a single change that affects already existing installations and that would be activate_zram enabled which only affects (improves) emergency swap behaviour. All other changes only affect new images/installations so users are safe. BTW: What about renaming armhwinfo? For example armbian_hw_setup?

We didn't get there yet but you can try to look how this is done on Pinebook which fancy similar chip. BT is working there - but on the old kernel. Check here if you can make use of it: https://github.com/armbian/build/tree/master/packages/bsp/pinebook

Since 100MHz worked in hs200 mode, and porting the dynamic tuning code looks like a fair bit of work, I decided to try 150MHz and see what happens. Result is it seems to be stable (I'm typing on the pinebook in that mode now), and it gave a nice boost to the iozone results: Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random kB reclen write rewrite read reread read write 102400 4 6891 7237 11490 11482 6614 5651 102400 16 19316 19884 49466 48654 25507 17839 102400 512 67821 58035 126793 127178 114462 47874 102400 1024 67095 57421 127057 127459 119481 46386 102400 16384 68019 58935 125989 126261 126379 54282 I'm going to leave the pinebook with this as the default setup and see how it shakes out. In the meantime, I hope to make some progress on dynamic tuning and the long march towards hs400 Maybe I'm too easily pleased, but 120+ MB/s read blows my mind for a $30 module (and the write speed isn't exactly bad either).

He's definitely making progress. I haven't checked the new release, but from what he said on irc I don't think it's working properly with the 64G sandisk on pinebook. Apparently it works great on the rock64. I've been looking at the code changes in the new release and one in particular has let me make a bit more progress - I can now successfully switch into hs200 mode, which is a necessary step to full speed. The next thing is to run auto-tuning in hs200 mode, without it the host<->mmc communications don't work reliably at 200MHz. Unfortunately the normal code path is via function pointer that hasn't been set, so I have to do some searching to try and find where the routine is. For giggles I tried running hs200 at 100MHz which seems to work fine. It's currently running in sdr mode and it has almost identical performance to 50MHz/ddr, which makes sense. Baby steps...

I put a copy of the kernel image I'm using on filebin for one of the guys on irc: https://filebin.ca/3dBZ0qmNivMa/Image-3.10.107-pine64 Of course I forgot you'd also need a copy of the modified uboot, and it's been long enough since I've looked at uboot that I'll have to dig around to find where I left a copy. I'll update when I find it. OK, here's the uboot to go with the above kernel: https://filebin.ca/3dBng1sFqg02/linux-u-boot-pinebook-a64_5.32_arm64.zip The zip file contains the uboot binary and a very simple script to install it. Check the device in the script matches the device for the emmc on your machine before running it, which will need to be done as root/sudo. I'll try and get these contributed as patches to armbian as soon as I can (sorry for the delay, work has been very busy recently)

After doing some research I came to the conclusion that blindly trusting in MAC address randomization working as expected isn't a good idea, that I lack time and will to test whether Pinebook really does it correctly and that we can't 'prevent' predictable network device names anyway (eg. Debian declares the old scheme deprecated in version 9 and not available any more in 10). So I'm fine with the proposed fix.

Why? This disabled predictable network device names, but we are also talking about MAC address randomization which is IMO only useful for portable devices (so only for the Pinebook) "Predictable names" were added mostly for USB (and PCI/PCIe) devices so you could plug them in any port at any time and would get a permanent MAC address based device name, so yes, it's not very useful for SDIO and memory-mapped devices, but I wouldn't jump to "zero improvement" and "lot of complexity" conclusions straight away. If we disable this, IMO it's better to do it with an udev rule than with kernel command line modification.

And then reverting the additional NM defaults change back? Also individually for the Pinebook? As far as I understood the 'problems' are nmtui connect problem reported by Igor (most probably since NM changing MAC address in between call of nmtui and trying to establish connection?) According to the github issue syslog spamming (which I consider not being a problem since 'attaching to a network seems to have stopped the noise as well') According to the same github issue 'NetworkManager is keeping the CPU busy'. Does this change after stopping MAC address randomization? Is NM silent now or is it still busy bot now with the same MAC address? Adding to the above I wonder what's the state of affairs wrt Wi-Fi powermanagement and NM in Stretch (since dmesg output on Github seems to indicate it's not working as on Jessie or Xenial). I haven't looked into this myself but to me the issues that should been looked at a little bit closer wrt Stretch are powermanagement settings constant try to search for networks (how to disable this would be my first question) nmtui-connect problems (if we can stop NM from permanently searching for open Wi-Fis on its own is this still an issue then?) Adopting a workaround that's 'recommended' by countless Debian/Ubuntu users reminds of the 'UAS is evil' stupidity mess we have to deal with in the Linux world.

We can always override settings by adding another file specifically for the Pinebook.

I'm really not sure since MAC address randomization should be considered an essential feature these days especially when we think about supporting devices like PineBook. At least I would suggest to first check whether stopping device renaming isn't the better option as described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839605#25 Does this apply to Stretch too?

I got a mainline kernel up and running. It detects the mmc ok, but clearly fails to get it into hs200 or hs400, so I'm not going to get any clues from the new driver. kB reclen write rewrite read reread read write 102400 4 10712 11284 11803 11642 5615 8249 102400 16 15740 16719 18346 18308 12720 15285 102400 512 21920 22029 22545 22659 21987 21794 102400 1024 22085 22075 22784 22810 22470 21942 102400 16384 21628 22318 23012 23019 23007 21744 the /sys info suggests it's in 50MHz sdr mode: root@pinebook:/sys/kernel/debug/mmc2# cat ios clock: 52000000 Hz actual clock: 50000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 3 (8 bits) timing spec: 1 (mmc high-speed) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) I contacted SanDisk to see if they would provide a datasheet or app note for the chip, but they politely declined. Such is life.

While I had the pinebook open just now I grabbed the chip markings from the emmc module. SanDisk SDINADF4-64G 7265DRKGP02Z I haven't had any luck finding a real datasheet or application note for the SanDisk modules, so if anyone finds one please throw me a link

That's a hack for the old stock kernel which we don't use on this board. We use that kernel on a similar board - Pine64 and Pinebook but haven't managed to adjust it for Oranges or Bananas ... we lack resources and working mostly with a modern kernel. That one is not very far away.

Sorry I have missed you were using a pinebook. I'm use mainline on a Pine64 and it's working fine but I'm not using any desktop / gui About aufs vs Overlay2 : when I was still using my SDCard as storage for my docker containers (one year ago), I had a lot of performance problem with aufs -> using overlay2 solved most of it. Back I was reading this site and it convinced me https://github.com/chriskuehl/docker-storage-benchmark But I'm not selling anything, if it works good enought don't touch it

Hi, I hit a problem on pinebook where docker would hang with defunct processes consuming high cpu. A bit of googling turned up a known problem with aufs as the cause, so I grabbed the patches, combined them and created a pull request https://github.com/armbian/build/pull/772 I gave the resulting kernel a fairly good work-out this evening and it seems to be working fine now.

Legacy. I haven't had a chance to try mainline on the pinebook yet (which would be an interesting thing to do), but my understanding is that it isn't ready for desktop/gui use yet. As far as aufs vs Overlay2 goes, I read enough to realise there's a lot of political stuff around the adoption into the kernel and newer distributions, but I haven't seen any technical comparisons of the two. Apart from the bug above, aufs seems to have been working extremely well, but I guess if the momentum now is behind overlay2 then that's the direction we will all be going in.

Is the charging current adjustable? I'd quite like to be able to set the charge current to a relatively low value if I'm using the pinebook, and then boost it to a higher value as part of the suspend/shutdown sequence.

I remember reading somewhere (probably in this thread) tkaiser saying that charging the battery generates a lot of heat that transfers to the cpu through the shared heat-sink. I normally put the pinebook on charge when I'm not using it, so it's not something I'd run into before, until the battery got low today and I plugged it in. My word! It's really warm and it's the first time I've seen thermal throttling in normal use. I was coming around to the idea of liking not having a fan, but if you want to use while charging, I think adding a fan would be a good idea, although it's likely to be an ugly hack. Perhaps I'll stick to charging overnight

Hi, I'm trying to iterate quickly to test out some ideas on the mmc driver, so I was wondering if it is possible to prevent re-downloading the sources every time. It looked like IGNORE_UPDATES=yes might be what I want, but when I tried that I got a failure during compile_atf: [ o.k. ] Installing [ rkbin-tools ] [ o.k. ] Cleaning output/debs for [ pinebook-a64 default ] [ o.k. ] Cleaning [ o.k. ] Compiling ATF [ o.k. ] Compiler version [ aarch64-linux-gnu-gcc 6.4.1 ] [ o.k. ] Started patching process for [ atf pine64-pinebook-a64-default ] [ o.k. ] Looking for user patches in [ userpatches/atf/atf-pine64 ] make: *** No rule to make target 'bl31'. Stop. [ error ] ERROR in function compile_atf [ compilation.sh:65 ] [ error ] ATF compilation failed [ o.k. ] Process terminated I'm using docker so my command line was $ ./compile.sh docker IGNORE_UPDATES=yes

Ok, I removed the insufficient u-boot patch (we tested yesterday also with the wrong module -- FORESEE and not SanDisk). Are you able to generate a PR against https://github.com/armbian/build with the necessary changes to both u-boot and kernel? BTW: Would be interesting to get output from the following (sample output for 16GB FORESEE eMMC in my Pinebook here: http://sprunge.us/JcZG) git clone https://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git cd mmc-utils make ./mmc extcsd read /dev/mmcblk0 | egrep -v '0x00$|0x0000$|0x000000$|0x00]$'

Quick update for anyone following this thread but not having seen With lots of help from Tkaiser and more we now have the pinebook booting from the new Sandisk 64G modules (older modules used Foresee chips and may still be available for a while). It needs a relatively small patch to the mmc driver in both the kernel and u-boot, and we're trying to home in on the safest minimal patch to add to the armbian builds. The speed delta noted above is related - one of the reasons that u-boot was failing is that for some reason the driver fails to switch this module into high speed mode. We haven't solved that yet, but even so the system is very usable running from the new cards. I'm optimistic that we'll get the card running faster with time (we may need some help from the original authors of the driver, or at least find the programming guide for the chip though).

Since I had Pinebook today in my hands again after a long time I wonder what's missing to move it from WiP to supported section? We should collect/include @James Kingdon's patches of course to get everything working with Pine's new eMMC modules Then I had to realize that profile-sync-daemon isn't enabled so this needs a fix too And then I wonder whether we shouldn't install zram-config by default? And do you think it would be a good idea to ask Pinebook users after account creation whether they've 11" or 14" (to adjust /etc/X11/xorg.conf.d/50-pine64-pinebook-touchpad.conf) or could this be stuff for armbian-config?

I threw the following patch in and rebuilt u-boot: http://kaiser-edv.de/tmp/NumpU5/linux-u-boot-pinebook-a64_5.32_arm64.deb -- at least on my Pinebook with 16 GB eMMC everything ok after 'dpkg -i linux-u-boot-pinebook-a64_5.32_arm64.deb && reboot'. @James Kingdon are you able to test this too? diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index d160bd5..c9f0b9e 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -2272,7 +2272,7 @@ static int mmc_complete_init(struct mmc *mmc) err = sunxi_switch_to_best_bus(mmc); if (err) { MMCINFO("switch to best speed mode fail\n"); - return err; + /* return err; */ } init_part(&mmc->block_dev); /* it will send cmd17 */