Search the Community

Is there a command to switch the boot priority back to uSD in armbian? Doesnt seem to be possible: So I neet a eMMC to uSD adapter Doenst see that kind of adapter alone at eBay The eMMCs at FriendlyElec got another Connector and is Out of Stock. I do need a version like from hardkernel (or the sellers of the Pinebook) (Hardkernel wants $16 postage for this $1.50-Item )

also a updated Armbian_5.33.171013_Odroidc2_Debian_stretch_next_4.13.5.7z doesnt boot anymore I did update the version above on my eMMC and now the C2 wont boot anymore from eMMC. But I dont understand - he wont boot anymore when the updated eMMC is connected AND a uSD with a older (13.10.2017) version is inserted. Shouldnt the uSD have priority before the eMMC? - and I didnt got a uSD adapter fo the eMMC because it was out of my Pinebook. So I cant fresh format the eMMC Now I'll take the v5.35 with legacy kernel on uSD....

Tried a new image on a Pinebook and am slightly shocked. A huge penguin is starting at me. When/where was the wallpaper switch from armbian06-1430-very-dark to armbian03-Dre0x-Minum discussed? I want to understand the reasons...

Current categories: 64-bit: Useless since Orange Pi R1 is listed here. Drop the category if we can't manage to provide correct information!!! Wi-Fi: Useless since onboard Wi-Fi is crap on all the boards we support (on some even real crappy) and boards are listed that have no onboard Wi-Fi but mPCIe slots. Yes, it's known that for good Wi-Fi you need to buy another device (either USB or mPCIe) and attach it. So what is this 'selection criteria' for other than spreading misleading information? If we want to help users we would need to explain what onboard Wi-Fi is usable for. BT: What is this for? Working BT support or 'chip that could do BT if you use kernel xy and solve the remaining problems yourself'. Useless as criteria if Armbian can't provide full BT support so either it will be this or should be dropped entirely. A10: One board nobody is using, let's make pcDuino 2 EOL and get rid of the category H2 vs H3: Why? These SoCs are more or less identical and differentiation between makes no sense IMO SoC vendors: Is anyone ever searching for this? Almost all boards appear when clicking on Allwinner and with the other vendors it's not much to gain mpci: should be mPCIe msata: totally wrong Notebook: Why? We support only one and people will never search for this since they visit us only since they already own a PineBook and not since they want to inform themselves about 'laptops with good Linux support' USB3/SATA: Highly misleading though I have no idea how to solve this other than starting to implement subjective categories like 'fast storage' (A20 and i.MX6 SATA) and 'very fast storage' (USB3 and Marvell SATA)

I still wonder how to proceed. His branch we're currently using on Pinebook has not been updated since 4 months, there's also outdated my-hacks-1.2-with-mmc3 and most recent my-hacks-1.2-with-drm. Has anyone here already tried switching branches in the build system? Then I realized that we got the last 3.10 LTS update recently: VERSION = 3 PATCHLEVEL = 10 SUBLEVEL = 108 EXTRAVERSION = NAME = END-OF-LIFE

if the costs are rising to fast - how about installing a standard-eMMC socket like on the ODROID C2 or inside the Pinebook? I think this would cost only a few cents? For me that would be fine - then while I upgraded my Pinebook to 32GB eMMC I could use the old 16Gb eMMC on my ODROID C2 AND if the market will supply faster/bigger eMMC modules I can swap out the slower/smaller against a faster/bigger one

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'm trying to make suspend on lid close work. i saw in this thread that some people are aware that there's a problem. i'd prefer to achieve this from within xfce4-power-manager. here's the thing: 1. using the normal xfce desktop * for "when laptop lid is closed", only 'lock screen' and 'switch off diplay' are available * "System sleep mode" is completely grayed out, as well as security 'lock screen when system is going to sleep' * the 'Ask' option is available only for "Buttons". Choosing it, then choosing "Suspend" from the dialog, causes the ui to hang (desktop darkened), but after a minute i can 'escape' out of it. * 'systemctl suspend' suspends as expected (without locking the screen) 2. using plain openbox without display manager (i.e. console login & startx instead of nodm) or desktop environment, xfce4-power-manager autostarted * for "when laptop lid is closed", 'lock screen', 'switch off diplay', 'suspend' and 'hibernate' are available, but only the first 2 work * "System sleep mode" gives me a choice between 'suspend' and 'hibernate' - only suspend works (!) as expected. * security 'lock screen when system is going to sleep' is not greyed out, and un/checking it works as advertised * the 'Ask' option is available only for "Buttons". It does nothing. * 'systemctl suspend' suspends as expected (without locking the screen) in other words, choice nr. 2. works in all aspects except the lid switch! i tried to let systemd handle the lid switch - to no avail. i also tried to not use xfce4-power-manager at all, only systemd - to no avail. reading `man logind.conf` i notice this: Interesting... 'udevadm monitor' showed nothing for opening/closing the lid. dmesg showed this: hall: (D) hall_isr hall: (I) HALL_CLOSE hall: (D) hall_isr hall: (I) HALL_OPEN every time i open/close the lid... so, where exactly would i have to add this "power-switch" udev tag? phew, my head swims... any ideas? maybe a secret solution already exists?

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

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.

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.