Search the Community

Well, creating/making such images isn't the hard part but how to deal with 'installation'? Adding a cp call to family_tweaks function or should we add the logos to board support package (same with the various 'Pinebook only' services/settings)?

For what it's worth since this is a nightly development build, I can also confirm this on the 5.27.170529 nightly on my 11" pinebook. The bottom line isn't green for me though... its a one pixel high line of green-red-blue pixels (which repeats for the entire line), but does sort of look like a green dotted line at the right distance. And yes, screen tearing is present also. Interlaced screen output perhaps? Performance seems good though, and it starts up very fast even from a not-particularly-fast microSD. WiFi connected without any issue, haven't tried bluetooth but no reason to suspect it doesn't work. I also like how the network connection is dropped before the system suspends, making sure the network-manager refreshes when the system resumes. Since there's no fat boot partition (which is great as it won't stuff things up as far as system updates), is it going to be possible to add a boot screen and possibly the charge indicator/power on reason screen, or is that likely to be in the too hard/unimportant and unnecessary frills basket?

Just tried out the nightly build. I noticed that there is a line of green pixels at the very bottom of the screen and there is tearing when moving windows or when interactive elements open on the display (e.g. in a browser). I have seen this before - it was also present in the very first build of the ubuntu image that shipped with the initial production units of the Pinebook. I believe that this issue is somehow related to the refresh rate - ayufan's Linux and Android images both report 56hz, while the old Pine image and the current nightly armbian image report running at 60hz. This is strange, because I am convinced that the Prototype unit I had ran at 60hz (cant check right now, because its dead) and the issue described above was not present. Perhaps someone more tech literate may have an insight into why this is happening.

Oh my... you should make a mod of the 'Random Ubuntu flavours as build system chaos' sub-forum as well... at least I can guarantee zero results as I'll do absolutely nothing but say "Use 16.04... the Armbian devs chose to base off a LTS build for a reason". You foolish devs... what will you require next... that all 'aspiring devs' should actually compile stuff on an actual computer instead of one drawn on paper? :-P And why for the love of god is Windows Subsystem for Linux not supported... I mean... what can go wrong? A crappy linux emulation running inside a crappy microshaft os? They've only just recently added support for mounting external drives in the linux subsystem... what's not to love hate? Right... even I've wandered in and said something... someone should lock this thread soon before this gets absolutely loopey and bat-shit crazy. Hell, I can't get ayufan's jenkins/docker builds to work for the pinebook images, but at least I didn't turn around and say "thou must make it work for me because it can't be a PBKAC"... I've kept fiddling, and will be contritely asking soon "wtf am I doing wrong here". I haven't tried the armbian build system yet, but I'm sure I can screw even it up somehow... but I'll at least read the warnings and follow them!

Thank you, should now be active as part of installation and user creation: https://github.com/armbian/build/commit/92dbd66b33f5eb8d4fb837e420a5a9a62050fad3 BTW: On current Pinebook image mpv isn't working and can we please provide only nightlies for Pinebook now? IMO it's useless to provide a normal build at this stage now that every day fixes and enhancements are commited.

Running with psd or not makes a difference, especially on slow SD cards (so not 'urgent' from a Pinebook perspective since here installation will be moved to eMMC anyway and that is rather fast). Since profile-sync-daemon is just a bunch of scripts I gave it a try, grabbed https://launchpad.net/~graysky/+archive/ubuntu/utils/+files/profile-sync-daemon_6.31-1_all.deb, installed it via 'dpkg -i' and followed then manually the installation routine. Works like a charme. Can we add profile-sync-daemon_6.31-1_all.deb to apt.armbian.com and add it to desktop package list?

Well, I don't really agree. Wrt other services/tools needed. Shouldn't they be part of board support package? Would apply to at least /etc/systemd/system/restore-sound-after-resume.service /etc/systemd/system/pinebook-headphones.service /etc/systemd/system/restart-network-manager-after-resume.service /usr/local/sbin/pinebook_restore_sound.sh /etc/X11/xorg.conf.d/50-pine64-pinebook-touchpad.conf

How to proceed with profile-sync-daemon? Adding package 'software-properties-common' on build host and doing add-apt-repository -y ppa:graysky/utils apt update apt install -y profile-sync-daemon works but might not be a real solution. Did you look already through the list at https://forum.armbian.com/index.php?/topic/4133-quick-pinebook-preview-review/&do=findComment&comment=31463

1st build. https://dl.armbian.com/pinebook-a64/Ubuntu_xenial_default_desktop.7z https://dl.armbian.com/pinebook-a64/Ubuntu_xenial_default_desktop.7z.torrent Daily builds: https://dl.armbian.com/pinebook-a64/Ubuntu_xenial_default_desktop_nightly.7z Edit: Tested and working: - wireless, bluetooth, suspend & wakeup, install to eMMC, Chromium RAM caching Known bugs: - audio not working, two wireless adaptors present, no boot logos

Once per second. Edit #1: revitalised with this RC toy charger to 3.6V. Now charging ... Edit #2: Armbian running on Pinebook

Since u-boot shutdown code is correct, it may be possible to at least make a workaround that will explicitly enable battery detection after powering on. @Igor Can you check if this applied to SoPine u-boot (or to Pinebook if WIP target works in general) enables the charger (a reboot may be required, for me only 2nd boot works)

I implemented dynamic detection of overlayfs with https://github.com/armbian/build/commit/50a6c0791e243b227a541f7f4163d2288d98c445 Missing part: installation of the daemon itself as part of desktop.sh. Won't touch this since not sure whether it's ok to add a 3rd party PPA like here or we should integrate the scripts in build system or repo? IMO we should use our rather useless nightly builds within the next days to ask users to test through stuff... BTW: to check efficiency it's always just 'psd p[review]': pine64@pinebook:~$ psd preview Profile-sync-daemon v6.31 on Ubuntu 16.04.2 LTS Systemd service is currently active. Systemd resync-timer is currently active. Overlayfs v22 is currently active. Psd will manage the following per /home/pine64/.config/psd/.psd.conf: browser/psname: firefox/firefox owner/group id: pine64/1000 sync target: /home/pine64/.mozilla/firefox/7ebocrc0.default tmpfs dir: /run/user/1000/pine64-firefox-7ebocrc0.default profile size: 14M overlayfs size: 0 recovery dirs: none find: ‘/home/pine64/.config/htop’: Permission denied browser/psname: midori/midori owner/group id: pine64/1000 sync target: /home/pine64/.config/midori tmpfs dir: /run/user/1000/pine64-midori profile size: 292K overlayfs size: 0 recovery dirs: none find: ‘/home/pine64/.config/htop’: Permission denied browser/psname: chromium/chromium owner/group id: pine64/1000 sync target: /home/pine64/.config/chromium tmpfs dir: /run/user/1000/pine64-chromium profile size: 32M overlayfs size: 4.6M recovery dirs: none

Yeah I think there might be a bug somewhere in that u-boot power state handling code. One thing I noticed while I did my battery life test a while back is also that with the current u-boot we have on the Pinebook images, it does not run just with DC power and without a battery like the Pine64 does... so maybe those issues are somehow connected...

My suspicions were similar - AXP does not start charging for some reason. Yesterday I screwed my Pinebook back together, since we are getting late with general update and this will have to wait ... I already did many tricks including plug / unplug ... but perhaps not enough? ASAP I'll try to charge it manually and dig back in. Thanks for the tips!

My Pinebook is officially dead - it does not charge the battery - with stock system, latest build or Android image. Any known workarounds?

We can push an image for the Pinebook at any time, it doesn't have to come with this stable release.

Well, IMO that's not the same if you look above: https://forum.armbian.com/index.php?/topic/4285-changing-to-chromium/&do=findComment&comment=31759 Either we get things sorted before next major release (and then a persistent cache living in RAM with a dynamic size depending on DRAM that gets synced is IMO mandatory) or we can leave everything as is and drop the idea of a Pinebook image for now. I thought reusing the log2ram skeleton would be a good idea since it requires just minimal changes when we add another xdgcache2ram.service unit and an own config file so testing efforts are minimal since log2ram is confirmed to work on a huge number of Armbian installations. But I agree that it's somewhat ugly.

Hmm... Chromium started to complain on my installation after defining XDG_CACHE_HOME pointing to DRAM but XDG_CACHE_HOME="/var/log/.cache" didn't fix it. Needs more investigations. I won't do that much here within the next week(s) since performing an 'Aunt Tilly' test: handing my Pinebook over to an elderly lady used to OS X since her MacBook died. Currently backing up the installation, then trying to upgrade to 16.10 and installing GNOME OS X II theme.

I did few tests on Odroid C2 since my Pinebook is still dead and have nothing against to switch to Chromium. Firefox can't match. There are still some writing to SD but minimal. Follow, waste later. We know about this problem and eventually will be fixed.

Thank you. Now this works surprisingly well with Chromium (with 'export XDG_CACHE_HOME="/var/log/.cache"' and /var/log/.cache created with 777 mode manually before): root@pinebook:~# cat /etc/chromium-browser/default # Default settings for chromium-browser. This file is sourced by /bin/sh from # /usr/bin/chromium-browser # Options to pass to chromium-browser CHROMIUM_FLAGS="--disable-smooth-scrolling \ --disable-low-res-tiling \ --enable-low-end-device-mode \ --num-raster-threads=4 \ --disk-cache-size=314572800 \ --profiler-timing=0 \ --disable-composited-antialiasing \ --disable-seccomp-filter-sandbox" root@pinebook:~# cat /etc/default/log2ram # configuration values for the log2ram service # # enable the log2ram service? ENABLED=true # # size of the tmpfs mount SIZE=350M # # use rsync instead of cp -r # requires rsync installed, may provide better performance # due to copying only new and changed files USE_RSYNC=true

Setting this improves everything a lot with FF, Midori and Chromium. But it's not a 'real' solution since this way most probably all available RAM will be eaten up over time unless the browsers have a configurable cache size. Also everything is lost after a reboot (so setting XDG_CACHE_HOME="/var/log/.cache" might be an idea since log2ram then does the job). I will stop now testing with the following results: root@pinebook:/dev/shm/.cache# du -sh * 4.0K blueman-applet-1000 27M chromium 12K event-sound-cache.tdb.aab709d4dc8efb47e12e29ac5910e6a8.aarch64-unknown-linux-gnu 100K fontconfig 276K gstreamer-1.0 616K mate 3.6M midori 5.7M mozilla 0 obexd 0 tilda 4.0K webkit root@pinebook:/dev/shm/.cache# cat /etc/chromium-browser/default # Default settings for chromium-browser. This file is sourced by /bin/sh from # /usr/bin/chromium-browser # Options to pass to chromium-browser CHROMIUM_FLAGS="--disable-smooth-scrolling \ --disable-low-res-tiling \ --enable-low-end-device-mode \ --num-raster-threads=4 \ --disable-seccomp-filter-sandbox" With '--disable-seccomp-filter-sandbox' every time Chromium will be started a security/stability warning will appear with our current kernel config which might be better than fooling users by disabling sandboxing without notice? Then on Pinebook installation of this Extension is recommended: https://chrome.google.com/webstore/detail/no-mousewheel-zoom/ckhlfagjncfmdieecfekjbpnnaekhlhd For anyone doing further testing I strongly recommend to always run htop and 'iostat 5' in 2 separate terminals in the background to watch for multithreading behaviour and Pinebook being bottlenecked by slow IO (or not when caches live in memory and not on slow storage). Testing with https://www.theguardian.com/international seems like a good idea (@Xaliusidea -- see today's http://irc.pine64.uk log) BTW: using LZO compression my chromium cache folder shrinks only to ~75% so most probably it's useless to further explore ways to use compressed tmpfs. I did just a quick static test and already gave up on the idea.

Well, if you compare Chromium with Firefox side by side it's impossible to use FF any more since it's too slow to not get immediately mad. But Chromium would require weakening security (further, I'm not that convinced that the BSP kernel everyone uses on A64 devices is suitable for connecting devices to the Internet with Linux anyway). Midori looks nice and fast especially after: root@pinebook:~# cat /etc/profile.d/xdg_cache_home.sh #!/bin/bash export XDG_CACHE_HOME="/dev/shm/.cache"

Same observation here, I tried it again after 5 minutes (red 'emtpy battery' logo shown and powered off again) but after 15 min Pinebook started and is now at root@pinebook:~# cat /sys/class/power_supply/battery/capacity 4

Short update on the 16 GB eMMC in my 14" variant: http://sprunge.us/bHZW (search for 'mmc2:0001', it's oemid: 0x0103, manfid: 0x000088) Google search for '0x0103 0x000088' found just a few hits (one in Armbian forum, this thing has also been used in Beelink X2). Iozone numbers: random random kB reclen write rewrite read reread read write 102400 4 3893 4021 20855 20681 13244 3223 102400 16 18059 18444 51219 50298 39452 13805 102400 512 54907 55186 85896 84475 82634 50187 102400 1024 56220 56011 85560 85681 85800 52369 102400 16384 55816 55464 86533 86408 86711 55289 OEM ID points to FORESEE and this link -- is this vendor trustworthy? First two hits when searching for 'oemid 0103' were failure reports and @longsleepalso already reported that the eMMC in his Pinebook was DOA. I've seen eMMC from them only in these Beelink X2 before: eg. http://linux-sunxi.org/File:Beelink_X2_AP6181_Heatpad.jpg or https://forum.armbian.com/uploads/monthly_09_2016/post-1183-0-96913400-1474264138.jpg Edit: FORESEE eMMC is used quite a lot on Chinese gadgets: foresee emmc site:www.cnx-software.com Edit 2: ayufan measured eMMC on a pre-production unit 3 months ago: https://gist.github.com/ayufan/caf1a581a53e3d16772ee363f7f5b075 Edit 3: According to what's silkscreened on the 16 GB module it's 'FORESEE; NCEMBSF9-16G: 01L 1608032589; 1633' -- picture now also available: http://linux-sunxi.org/File:16GB_NCEMBSF9-16G_eMMC.jpg

No hibernation, not even ACPI (this is not an x86 design -- if you want that, choose the sibling but currently both aren't available due to supply chain issues and the 11" panel is unavailable for the next 2 to 3 months). With latest community builds suspend/resume (to RAM) works and I would recommend to use only community release version 0.5 or above (or Armbian soon ) Back to the technical aspects: eMMC is not soldered but replaceable and uses the same mechanical connector as Hardkernel uses for their ODROIDs. So even if it wears out it can be replaced and since boot priority always is 'SD card first' you don't even need that, just get an SD card following the new A1 or A2 specifications then (in a year they should be affordable). Wrt swap: ubuntu@pinebook:~$ free total used free shared buff/cache available Mem: 2037388 153692 1134912 13424 748784 1834044 Swap: 1018688 0 1018688 1 GB defined, nothing used. I neither fear swapping nor 'hibernation' wrt eMMC longevity but something else. One of the challenges we face with this device will be browsing (which has some pretty high memory requirements and due to the common browsers hammering storage with IO requests can be also considered a storage benchmark on such devices like the Pinebook). We already talked about that: http://irc.pine64.uk --> 03-05-2017 --> search for 'graysky'. I think especially with Pinebook it will get interesting how to intelligently use the DRAM (tmpfs for example without further compression always seems like a waste of ressources to me).