Search the Community
Showing results for 'pinebook' in topics.
-
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"
-
'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?
-
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).
-
I added a simple benchmarking script to the StabilityTester repo: https://github.com/ThomasKaiser/StabilityTester/commit/c6c72812d1e5d1458f9257f0398534e253fa3373 If you clone the repo it's just switching into the directory and doing a 'sudo ./benchmark-pinebook.sh' (don't forget to let a 'sudo watch -n2 pine64_health.sh' run in another shell in parallel to get an idea what's going on). My results (Pinebook allowed to clock up to 1.2 GHz since proven reliable and increased thermal trip points so let throttling start later): w/o throttling throttled openssl speed rsa2048 -multi 4: 9170 7313 (80%) minerd --benchmark: 3.59 khash/s 2.84 khash/s (79%) xhpl64: 2.86 GFLOPS 2.30 GFLOPS (80%) 7z b: 2680 -- (lightweight) Interestingly the first three benchmarks are all affected by throttling in a similar way (20% performance drop) with Pinebook lying flat on a table and an idle SoC temp of ~40°C. For anyone trying this out: You won't get my scores above since your Pinebook is only allowed to run at 1152 MHz max and throttling settings today are not optimized too (if you want to be able to run your Pinebook at 1.2 GHz please read above how to contribute, test and submit your results). In case you want to explore how badly battery charging affects benchmark scores please keep in mind that you would have to adjust the following line since SoC idle temperature will be around/above 50°C in this situation anyway: COOLDOWNTEMP=50 This benchmark script should execute on any other 64-bit ARM platform and comparing results can be quite interesting (since some of those benchmarks benefit greatly from higher memory throughput for example)
-
Today @longsleepadopted community's work from last year on improved throttling and so called dvfs settings: https://github.com/longsleep/build-pine64-image/commit/227b8b7641390b6d3181166b53514a39e0c12820 In other words: Now (or with ayufan's Android and Linux builds starting from tomorrow or the day after) benchmarking Pinebook gets interesting since settings prior to this fix were broken Allwinner defaults resulting in low performance. In other words: forget about any benchmark results you've seen so far, they were all made with wrong settings. It should also be noted that while Pinebook is charging top performance is negatively affected since the PMIC gets quite hot while charging the battery and dissipates that heat over to the SoC which will in turn throttle earlier under full load --> benchmarking Pinebook is recommended while running on battery! On a related note: If community helps (we need results from at least 20 different Pinebook) there's a chance to enable 1200 MHz instead of 1152 MHz as maximum cpufreq on Pinebook: https://github.com/ThomasKaiser/StabilityTester All you need is a Pinebook, ayufan's 0.4.4 Xenial or above, some room in your fridge (since otherwise the test is useless since 'Throttling happened, results invalid'), 30 minutes of patience to let the Pinebook cool down and then: sudo apt install git git clone https://github.com/ThomasKaiser/StabilityTester cd StabilityTester sudo ./check-pinebook-cpufreq.sh Pinebook will reboot after approx 30 seconds, then login again, simply execute 'check-pinebook-cpufreq.sh' as root again and submit results (full output as can be seen on Github). To revert changes after testing it's as simple as sudo mv /boot/pine64/sun50i-a64-pine64-pinebook.dtb.bak /boot/pine64/sun50i-a64-pine64-pinebook.dtb && sudo reboot
-
Good to know (for whatever reasons I did not even try suspend/resume now). BTW: In this release /usr/local/sbin/install_rpi_monitor.sh is included with a more recent RPi-Monitor template that displays/records battery parameters. I'm especially interested in results from 11" users whether battery capacity calculation gets better over time (also a lot of other parameters are exposed, see commit from 3 days ago), One issue I ran into is that rpimonitor for whatever reason quits one hour after booting: root@pinebook:~# uptime 07:31:31 up 17:07, 2 users, load average: 0.16, 0.11, 0.13 root@pinebook:~# systemctl status rpimonitor ● rpimonitor.service - LSB: RPi-Monitor daemon Loaded: loaded (/etc/init.d/rpimonitor; bad; vendor preset: enabled) Active: active (exited) since Fri 2017-05-05 15:08:14 UTC; 16h ago Anyone has a clue what the culprit might be? Besides that: Yes, IMO both keyboard and touchpad are rather annoying on the 14" (no 11" around so this does only apply to the large variant)
-
I've installed Ayufan build xenial-mate-pinebook-bspkernel-0.4.2-47.img.xz and it effectively seems to be fixed. I've closed/flipped the screen and left it in suspend mode, and I opened back 4 hours later, battery was still around same 94% level seen previously. EDIT : about 8 hours later, my pinebook is around 81% charged/unplugged, it was probably around 92% when I resumed halt an hour ago. BTW, one thing I start hating : the trackpad is too much sensitive : I try to avoid touching it, and I'm still using external mouse, because I hate those pads anyway, but even not using this pad, while typing on keyboard, if my fingers are too near of the pad, it product a mouse-click event and I'm doing bad typos ...
-
Prime scores identical with Pinebook (tested again, this time two times to ensure the benchmark runs all the time with A64 just clocked with 1104 since slight throttling occured). So there's something wrong with cpufreq (H5 should be allowed to clock up to 1.34GHz). Anyway just to keep this in mind for those working on OPi PC2 or Prime right now: 7z/tinymembench numbers of Pinebook as reference (running at just 1.1GHz and using 2 GB LPDDR3) here: https://pastebin.com/rvrhevXr
-
Thank you! So in 'active benchmarking' mode we discovered that there's something horribly wrong with our RK3288 images currently! Numbers are way too low (XU4 scores with 4966 vs. 2725 -- first number running on the big cluster, latter on the little, so MiQi must get close to or exceed 5000). Fortunately you submitted whole output so most probably there's something wrong with both cpufreq settings and DRAM bandwidth. Even a boring Pinebook scores higher:
-
Just to asking people to give their own feedback here about suspend/resume of the Pinebook. Today I've experienced a total battery drain-out in 12 hours after a manual explicit suspend or a screen flip-close (what I'm not sure which I've done). In the past days, I did it often, but most of the time, either I've re-plugged charger for the night, or only suspended it for couple of hours. It would be interesting to know for all of you how long a real suspend can last without charging.
-
My charger is unfortunately limited to 5W discharge, but since this is pretty close to the PineBook consumption it should be okay. It's certainly good enough to accurately determine the battery capacity. I'm just waiting for my PineBook to ship. When it arrives I will do a few cycles on the battery to test the capacity outside the PineBook. Edit: I have a coupon valid until 4 May 2017 (tomorrow) to order a 14" PineBook, if you want to skip the queue. The order is estimated to ship at the end of May. If anyone is interested, PM me your email address and I will send you the code to order. You'll have to use my email address, but I'm happy to forward any emails from Pine to you.
-
Some Pinebook news: In the meantime a lot of issues have been resolved by community and fortunately ayufan added also Linux as target to his fully automated builds. Here you get latest releases: https://github.com/ayufan-pine64/linux-build/releases For anyone wanting to explore the bleeding edge (that means i3) be prepared that the Desktop uses a Debian wallpaper but since auyfan's builds are based on @longsleep's it's an Ubuntu Xenial and default login/pwd are ubuntu:ubuntu. First steps with i3: https://i3wm.org/docs/userguide.html The Network Manager GUI is not installed (fortunately since it would add half of the GNOME desktop stuff) therefore connecting to Wi-Fi is just the usual 'sudo nmtui' in a terminal and a second later you're in (in this build there is both wlan0 and wlan1 enabled -- choose either one for your client connection and keep in mind that you can use the other Wi-Fi interface later for an AP that works in parallel to client mode) Now exploring i3 booting ayufan's image from SD card the Pinebook starts to make some sense... eMMC is accessible in this release and a simple pine64_install_to_emmc.sh script is contained so you can even transfer the image to eMMC if you want (just like with Armbian's nand-sata-install) which asks you to choose a fresh OS image from a list which will then be downloaded and overwrites the eMMC's contents. But it's not necessary to run from eMMC so in case you own an SD card with high random IO performance exploring new OS images the next few weeks booted from SD card seems to be the best way.
-
And another update. Did another charge/discharge cycle and now it seems something went wrong: All graphs being at zero from 20:20 - 22:10 was due to RPi-Monitor being stopped then. But what troubles me is that the '2 percent battery capacity' event didn't fire. The Pinebook should've issue a 'shutdown -h now' at 3:45 but instead continued to run and drain the battery until input voltage might be that low that AXP803 cut power?
-
Another minor update on Pinebook battery (for those having trouble to understand what's written: this is still NOTHING related to battery life estimates since the OS image I'm running is not in good shape and an ugly monitoring hack is running in the background) This is another full charge/discharge cycle. I allowed charging with up to 15W which is somewhat problematic since further activity will add consumption (eg. running the stupid sysbench pseudo benchmark) and then the power budget easily exceeds the PSU's capabilities (5V/3A). So as @Xaliusalready suggested decreasing this value by a few W might be a good idea. With these settings PMIC temperature again maxed out at 81°C while charging (and SoC temperature is affected since connected to same metal plate). When running on battery with disabled camera stuff and only Wi-Fi connected the average battery drain was ~2.8W and reported capacity rather precise. The OS is configured to do a 'shutdown -h now' when battery capacity reaches 2% and this worked flawlessly since my SSH/Wi-Fi session did not time out but was correctly terminated -- see below. As can be seen also below there's constant background activity that might be responsible for a few 100 mW more being wasted than necessary and after following some discussions over at http://irc.pine64.uk I came to the conclusion to let the dust settle first and put the Pinebook in the drawer for at least two weeks. In the meantime ayufan let an automated Linux build that works a lot better than official Pinebook Ubuntu image, @longsleep started to work on Pinebook and so everything is simply too much WiP at the moment.
-
I honestly expected better power efficiency out of this (my before mentioned asus typically draws around 1-2W less while being much more powerful) but i guess this is the cost of bottom barrel components (namely soc). Any news on when pine has intention of selling these things to the public (and not just built-to-order) ? edit: just for fun i measured some values on my x205ta (11", baytrail cpu, same battery as pinebook): -no wifi, idle screen off -- 0.7W -display on, idle, wifi off -- 2.0-2.2W -browsing armbian, wifi on -- 3.3-4.5W Budget SoCs have still a long way to go as far as power is concerned; but then again we're talking about a soc that costs at least 5x more in bulk than a64
