Search the Community

This is known but currently we implemented this only in a somewhat hackish attempt for Pine64/Pinebook (and obviously no one so far took care of OPi Prime): https://github.com/armbian/build/blob/91ce8682cf672c44061fbf03b611b9fcf1226624/config/sources/sun50iw1.conf#L66 No idea though how to solve this in a more generic way (or without additional hacks)

Hi, first of all thank you for the great work. Let me tell you my story. I bought a Pinebook laptop some months ago and in my spare time I was playing with numerous OS-es. Installing and testing one by one. In total I've tested every single OS and so far Armbian is the winner. Why? Well because it is super fast, very stable, lightweight and with very simple xfce desktop look and feel. Now, like everything in life, there are some bad sides of Armbian. I am not sure if I will say something false or strange but I don't consider my self expert for hardware nor Linux world. So far I have also Raspberry Pi with Raspbian installed and don't see any bad sides. So, to get to the topic. Problem that I see is Ubuntu and architecture. Armbian is build on Ubuntu version 16.04 together on Pinebook with arm64 architecture. What is very limitation in terms of packages. Almost every single package that I would like to install eather doesn't exist because of the arm64 architecture (on ppa repositories) or doesn't exist at all. Of course I can install some old and outdated package, but for an example who would like to have Kodi version 15 installed, knowing that currently Kodi developers developers are developing version 18. Alternative to missing latest packages would be to compile nad build from the source, but then I loose having abiliti to update packages by simple apt-get upgrade command. The only package which I compiled was xrdp because I was hopping to have abiliti to connect remotely to my Pinebook with my Android phone or from Windows 10 laptop but with version 0.9.1 (latest buildable version on Ubuntu 16.04) it doesn't work so I use VNC. In my brain, next logical question is comming to my mind: Can I expect latest ubuntu release for my Pinebook somewhere in the future, and when? Basically that is my biggest concern. However, thank you one more time for great work. I hope that you will continue to work in long term, so that I don't need to switch to some other OS on my Pinebook or even give my Pinebook to my kid because otherwise I don't see any good enought OS for me to be usefull in my daily life. All best.

Hi. I've download the image built on 21/11, but it doesn't still work. I checked also the sha256 code to be sure that the image is not corrupted. Very strange. Did you burn the SD with Etcher? I think I have to try with Serial Console, but I have no usb to serial ttl bridge adapter. I want to buy a "CH340g usb to serial ttl bridge adapter". In this post https://forum.pine64.org/showthread.php?tid=5029 the connection is done with a Pinebook, but I think I can use any PC/notebook, isn't it. Thanks for support. Matteo

Hello Armbian Community, As you can see by my post count, I am new to Armbian, but so far have found it to be an amazing resource, and truly appreciate the hard work you all do. Its really impressive, and your knowledge and understanding of SBC’s is incredible. I am attempting to get Armbian working on a custom A64 device that was originally designed to be used as a Point-of-sale machine, that runs Android. I understand I am venturing into uncharted territory here, and this is absolutely not supported, but it’s a fun project and I am learning a ton. I am asking for help, but realize none may be available. Here is the hardware I have in hand. It is an A64 board connected to a touchscreen LCD panel, and it seems to be pretty closely related to a Pine64 or BananaPi m64. Allwinner A64 1gb RAM 4gb eMMC 10/100 Ethernet WiFi, Bluetooth (AP6212) 15”, 1920x1080 touchscreen HDMI output microSD Card slot 12-volt power barrel Android image based on the Allwinner BSP (u-boot 2014.7, kernel 3.10.65, and a sys_config.fex file) And here is what I have observed thus far: Just to begin isolating the hardware and testing what works / what doesn’t work, I ran a series of tests. This board can boot a vanilla Armbian 5.35 Pine64 image, and HDMI output works, ethernet works, and the touchscreen actually works even though the LCD is not lit or utilized. It functions like a giant trackpad thought, and I can move the mouse cursor on the HDMI monitor by running my finger across the unlit touchscreen. eMMC is not recognized by this image, however. Next, I custom built the (unsupported) BananaPi m64 Armbian image, and with this build I gained eMMC support, but lost ethernet. So, I believe the U-boot configuration differences led to those results. Attempting a brand new Pinebook Armbian 5.35 image, the board would not boot, I believe due to the difference in DDR3 memory used on that board. And here is what I *think* might be my path forward, but could use some guidance / assistance on: I would like to get the LCD panel lit up. I believe this requires a conversion of the sys_config.fex file in to a Device Tree, but am unsure where to place a full device tree file in the Armbian build folder. I believe this also requires some U-boot modification, but am not certain. I would like to achieve both ethernet and eMMC, so I believe this requires some sort of mashup of the BananaPi m64 U-boot (eMMC working, ethernet killed) along with the Pine64 U-boot config (no eMMC, but ethernet working). If there is any additional information needed that I forgot to provide, I apologize, just let me know and I’ll do my best to get it. And, as I mentioned, I appreciate the efforts of the Armbian developers and community, and understand I am in unsupported territory here. Thanks again, David

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

'Upstream' the idea to ship OS images with Firefox/Iceweasel has been dropped in the meantime due to horribly low performance in favour of chromium-browser. As far as I understood that's partially related to firefox acting single threaded (while Chromium uses all CPU cores). Here's longsleep's latest config and the mostly accepted 'fix' for Chromium complaining about running insecure due to missing sandboxing is disabling exactly this. (that's Hardkernel's method to 'fix' Chromium on ODROID-C2). Users will be happy with a fast(er) browser not throwing annoying error messages at them they click away without reading them anyway and surfing the web on Pinebook with crappy BSP kernel will get a little bit more insecure too. Will we follow or waste our time trying to find out why seccomp/sandboxing is not working on arm64?

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 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