Jump to content
  • 0

Quick Pinebook Preview / Review


tkaiser

Question

Yesterday my 14" Pinebook arrived so I thought I'll collect some already available information. A lot of work still has to be done to get a decent laptop experience with this hardware so this is neither a review nor a stupid Un-Review but just a preview instead.

 

To get the idea about dimensions I added a 13" and a 15" laptop to the picture. Pinebook is wedge-shaped and thickness matches both the 2011 15" MacBook Pro and the 13" from 2015:

 

Pinebook_14_Comparison.jpg

 

Display size closely matches the 13" MacBook Pro (but of course pixel density / resolution don't match as well as quality: TN vs. IPS and coating -- it should be obvious if you've the 'you get what you pay for' principle in mind but I'm sure we'll see reviews somewhere else where people are comparing Pinebook with Chrome/MacBooks and think they would get the same display quality for a fraction of costs)

 

Last hardware detail: heat dissipation. I've been curious how well the Pinebook's thermal design is and it looks pretty good. This is the moronic sysbench pseudo benchmark calculating prime numbers endlessly and the Pinebook sitting on a pillow to prevent airflow below the case bottom. Throttling settings are rather conservative with 65°C defined as first trip point and only after a couple of minutes the internal A64 SoC temperature reached this value and slight throttling occured (1.15 GHz down to 1.1 GHz, that's a 'difference' you won't be able to notice). So it seems the combination of a thermal pad with a large metal plate inside the case is rather sufficient:

 

Heat_Dissipation.png

 

What you see here is a graph drawn by RPi-Monitor, one of my favourite tools to get a clue what's going on with ARM devices (since it's not a heavy monitoring tool that changes the way the OS behaves but it's pretty lightweight sp you can run it in the background and let it monitor/record stuff like cpufreq scaling, consumption and so on).

 

Pinebook currently ships with a rather clean Ubuntu Xenial on the eMMC with Mate desktop environment based on latest BSP u-boot and kernel. To get RPi-Monitor installed on this Ubuntu @pfeerickprovides a script (please follow progress over there). When I played around with Wi-Fi I noticed that Wi-Fi powermanagement seems to be enabled (makes working via SSH close to impossible) and that MAC address changes on every reboot. To disable Wi-Fi powermanagement I simply used the Armbian way:

root@pinebook:~# cat /etc/NetworkManager/dispatcher.d/99disable-power-management
#!/bin/sh
case "$2" in
up) /sbin/iwconfig $1 power off || true ;;
down) /sbin/iwconfig $1 power on || true ;;
esac

Unless Wi-Fi driver gets a fix to use a MAC address based on the SoC's individual so called SID one way to assign a fixed MAC address for the Wi-Fi is to add a wifi.cloned-mac-address property to all NetworkManager profiles after establishing a Wi-Fi connection first:

nmcli con show | grep wlan | while read ; do set ${REPLY}; nmcli con modify "$1" wifi.cloned-mac-address $(cat /sys/class/net/$4/address); done

(I'm pretty sure some masochistic people prefer fiddling around in /etc/network/interfaces instead so if you're not using your laptop as a laptop being carried around and seeing a lot of Wi-Fis you can also use the usual tweaks for the interfaces file. Please also note that using a random MAC address can be considered a privacy feature on laptops since it makes tracking of you in public environments harder).

 

While watching the Pinebook's charging/discharging behaviour I noticed that consumption drawn from wall while charging oscillates between 9W and 15W while being used and display active so it's really great that Pine Inc fixed Pine64's design flaw N° 1: Pinebook is NOT equipped with shitty Micro USB for DC-IN leading to all sorts of trouble but just like SoPine baseboard now uses a 3.5mm/1.35mm barrel jack combined with a 5V/3A PSU (for other hardware details please refer to linux-sunxi wiki page).

 

Battery status (health, capacity, voltage and so on) is already available through sysfs but some values are wrong or need calibration. This needs to be fixed with further upgrades. Also interesting: charging seems to be under control of the ARISC core inside A64 SoC and works together with Pinebook's AXP803 PMIC (powermanagement IC) even when there's no OS running. This will be somewhat challenging to implement later with mainline I would believe...

 

I'll stop here for now since Pinebook is still stuff for developers and not end users. Just some resources for interested parties:

  • https://github.com/ayufan-pine64/boot-tools (Kamil implemented an u-boot based approach to flash directly to eMMC and there you find the necessary BLOBs to convert other BSP based Pine64 images for Pinebook since different DRAM and other settings require different SPL+u-boot)
  • https://github.com/ayufan-pine64/linux-pine64 (based on longsleep's BSP kernel but with more fixes currently for Pinebook)
  • $mainline resources (I lost track where to find most recent stuff but will add this later)

 

Wrt Armbian running on Pinebook we could now simply exchange u-boot+SPL+DT of our Xenial Desktop image... but I hope we won't do that but wait until dust has settled while helping with development efforts in the meantime. In other words: no Armbian on Pinebook (right) now :) 

Link to comment
Share on other sites

Recommended Posts

  • 0

I think at some point we added a script to ayufan's platfom package that reloaded alsa settings after resume from suspend, because sometimes those seemed to get lost... I have to see if I can find the info...

 

Edit: 

 

https://github.com/ayufan-pine64/linux-build/blob/master/package/root/etc/systemd/system/store-sound-on-suspend.service

https://github.com/ayufan-pine64/linux-build/blob/master/package/root/etc/systemd/system/restore-sound-after-resume.service

Link to comment
Share on other sites

Donate your old hardware to community. Start a giveaway Raffle!

  • 0

I think it's not related to suspend / resume ... there is no sound since start. Well, I'll remake image and do some close look.

 

Edit:
Sound works on fresh image from sources.

Link to comment
Share on other sites

  • 0
47 minutes ago, msev said:

So how much hours of battery life do you guys get?

 

Some time back I did a discharge test at full load for all cores and 100% backlight:

 

BvgSPiw.thumb.png.02d7158ef05ce4b5681759f4b94122ed.png

 

This was after I optimized the PB battery settings in the devicetree for AXP803. Nominal load was 2A on the battery side in the beginning, while the integrated capacity came out short over 10Ah after 5h an 16minutes.

 

Under more normal operating conditions I get about 8-10h battery life at the moment.

Link to comment
Share on other sites

  • 0
2 minutes ago, Igor said:

Release candidate :P latest fixes + this regarding audio on resume, touch pad and kernel upgraded with upstream patches.

I would prefer to move these services to the board support package so they can be upgraded in the future if needed

 

2 minutes ago, Igor said:

What about HDMI out - how to use it?

Same as on Pine64 - by patching the DT (manually or with some boot script hacks).

Link to comment
Share on other sites

  • 0
Just now, zador.blood.stained said:

Same as on Pine64 - by patching the DT (manually or with some boot script hacks).


What about to provide a separate pinebook-hdmi dtb file? I already searched to understand how to enable hdmi but not found.

 

5 minutes ago, zador.blood.stained said:

I would prefer to move these services to the board support package so they can be upgraded in the future if needed


OK, will RFC. Loaction of this file https://github.com/armbian/build/blob/master/config/50-pine64-pinebook-touchpad.conf is also not very logical. Where should we collect such things? 

Link to comment
Share on other sites

  • 0
46 minutes ago, Igor said:

What about to provide a separate pinebook-hdmi dtb file? I already searched to understand how to enable hdmi but not found.

It should be possible to do with boot script modifications. Unfortunately miniHDMI and limited display resolutions make it hard for me to test.

 

48 minutes ago, Igor said:

Loaction of this file https://github.com/armbian/build/blob/master/config/50-pine64-pinebook-touchpad.conf is also not very logical. Where should we collect such things? 

Ideally (in the future) - split build related configs, files copied when building OS images and files provided in board support packages into different directories. For now I didn't see any feedback on the older refactoring proposal in #633.

Link to comment
Share on other sites

  • 0

Ayufan recently managed with help from jernej to add two more resolutions to HDMI, check his github with pine64-linux.  I think what they did is replace the libhdmi blob with a source version from an older BSP (lots of magic registers in the source) and then hack in the missing modelines in a few places.

 

https://github.com/ayufan-pine64/linux-pine64/commit/9c32b49012fdbb983ae2e26b8cade0965950c9db  Initial support for custom resolutions

https://github.com/ayufan-pine64/linux-pine64/commit/7e19e18454cb450ad151cc77068b5324c8dd5edb  Automatically calculate ptbl for hdmi bsp driver

https://github.com/ayufan-pine64/linux-pine64/commit/bc64704cde960332459c7ed613daab7e701822ad  Merge branch 'support-custom-hdmi-resolutions' into my-hacks-1.2

 

There are some more fixes on there since someone added Arch linux back to the build system...

Link to comment
Share on other sites

  • 0
5 hours ago, zador.blood.stained said:

It should be possible to do with boot script modifications. Unfortunately miniHDMI and limited display resolutions make it hard for me to test.


Note added to download page - I can do tests but only for next few days, than I am notebook only for some time.

Link to comment
Share on other sites

  • 0

Update.
 

Pinebook was my Beachbook for some time. I used it for email, browsing, IRC and terminal. It proved to be sufficient while once it didn't start charging (from 5%) even plugged to charger - unplug / plug back solved that - and "heavy" Chromium usage ate all resources. I think we need to check Chromium caching - when using let's say about 10 tabs for some time - RAM is going down, swap is not getting used and system just become extremely slow / unresponsive. My environment did not provide enough motives for exploring the problem deeper :)

36037760832_73635bb416_o.jpg

Link to comment
Share on other sites

  • 0

My pinebook just arrived. I have to say it's excellent value, with both the keyboard and screen being very usable. I'm sure I'll run into a few problems soon enough, but so far I'm very pleased!

 

Update: First major problem isn't with the laptop itself, but the 64G eMMC that I ordered to go with it. Sadly it's dead-on-arrival. I've emailed them to let them know, so now I'll get to see what their customer support is like!

More minor issues, there is some instability with the trackpad that sometimes jumps the cursor to the bottom left corner. Overall, still very impressed :)

 

Update Aug 28th: the flashing of the screen backlight at low brightness has gone away. I'm not sure why, but it's working just fine now. I had a prompt reply to my email about the 64G eMMC saying they would forward the message to support, but haven't heard anything since. But it's been the weekend so that's not unreasonable. I opened a support ticket today in case the original email didn't make it to the right place, so we'll see how that turns out.

 

Sep 2: It looks like the problem with the 64G eMMC is that it is reporting an EXT_CSD revision of 8, and the mmc driver checks for a max value of 7. I'm hoping I can patch the kernel to accept 8 and get things going, but I'm wondering if uboot will need to be updated as well.

Link to comment
Share on other sites

  • 0

The fix for the 64G eMMC module looks promising - the module is now recognized when I boot armbian from sd card using the modified kernel. It's currently formatting the eMMC as the first stage of nand-sata-install...

 

The fix is trivial. In drivers/mmc/core/mmc.c, remove or comment out the conditional block at line 317

 card->ext_csd.rev = ext_csd[EXT_CSD_REV];
    /**
    if (card->ext_csd.rev > 7) {
        pr_err("%s: unrecognised EXT_CSD revision %d\n",
            mmc_hostname(card->host), card->ext_csd.rev);
        err = -EINVAL;
        goto out;
    }
    */

This test has been removed from later releases of the driver and a comment added to indicate that the cards should be backwards compatible so the test is unnecessary.

Link to comment
Share on other sites

  • 0

Hmm, the install to eMMC seemed to work ok in that if I boot from SD I can mount the eMMC and see the files, but it won't boot from the eMMC. Unfortunately I don't have a serial line hooked up to the pinebook so I can't see what's going on. Visually, the backlight of the screen turns on, but nothing appears on the display. The LED for caps lock is not responsive. When I mount the filesystem on the eMMC it is reported as 62G, so I assume that resizefs must have been run. /boot/Image on the eMMC is sym-linked to my kernel with the modified mmc driver, so that seems good.

 

I compiled the kernel by cloning longsleep's linux-pine64 kernel directly (I've been having problems building armbian), so maybe I'm missing some patches? It feels like it must be close to working, I'll see if I can dig into it some more.

Link to comment
Share on other sites

  • 0

Small steps - with Zador's help I got the armbian build system working with Docker and managed to force in my changes. The new kernel now runs better than my previous attempt which couldn't load any modules for some reason, which prevented wifi from working amongst other things.

 

I also found that the uboot version of mmc.c has the same test for csd.rev which seems like a reasonable explanation for the boot failure from eMMC, so I've removed the test and rebuilt uboot. I installed the resulting .deb onto the armbian running from sd card, rebooted and have now started a fresh run of nand-sata-install. The only problem is that I have no idea where nand-sata-install gets the copy of uboot to write to the eMMC, so I hope it picks up my modified version and not a copy of the original from somwhere!

 

Ah, looks like the installer gets uboot from /usr/lib/linux-u-boot-pinebook-a64_5.32_arm64/ and that's been updated today, so presumably contains my new build:

 

/usr/lib/linux-u-boot-pinebook-a64_5.32_arm64$ ls -l
total 960
-rw-rw-r-- 1 root root 983040 Sep  4 11:46 u-boot-with-dtb.bin
 

Fingers crossed!

Link to comment
Share on other sites

  • 0
On 5/9/2017 at 4:35 AM, tkaiser said:

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

 

Interesting, your eMMC is running much faster than the 64G module I have:

    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     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     5212     5531     9691     9710     5301     4522                                                          
          102400      16    10971    11371    18865    19056    13534    10918                                                          
          102400     512    21356    21507    22808    22763    22360    21477                                                          
          102400    1024    21410    21495    22718    22795    22618    21570                                                          
          102400   16384    21547    21517    22846    22849    22848    21577                                                          

 

Link to comment
Share on other sites

  • 0
On 28.7.2017 at 0:44 PM, Igor said:

and "heavy" Chromium usage ate all resources. I think we need to check Chromium caching - when using let's say about 10 tabs for some time - RAM is going down, swap is not getting used and system just become extremely slow / unresponsive.

 

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?
Link to comment
Share on other sites

  • 0

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

 

 

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0
1 hour ago, tkaiser said:

 

Yes, check DT for pmu_runtime_chgcur, pmu_suspend_chgcur and pmu_shutdown_chgcur. @Xalius (who came up with increased pmu_runtime_chgcur value in the beginning) collected some information here https://forum.pine64.org/showthread.php?tid=1430

 

 

Perfect! Many thanks

Edit - ah, I see, it's exactly backwards from what I want :) Age old story - everyone has different requirements. At least we have the freedom to change things around.

Link to comment
Share on other sites

  • 0

I dropped runtime_chgcur down to 1/2 amp and that seems much more manageable to me. I might go a little lower to try and bring the idle temp down further. I currently have suspend at 1.5A and shutdown at 1.8A. When I get some time I'll experiment with raising the shutdown charge rate. The typically recommended 1/2C charge rate would be 5A which we won't get anywhere near with this psu and charger. I'm hoping that something between 2 and 2.5A during shutdown will be usable which will give me a 'normal' overnight charge in suspend and a 'turbo' charge if I shut the machine down before charging. I'd drop the suspend rate lower but then I might not always get back to 100% overnight. I need to open the machine up and attach k-type probes before testing as I don't want to cook the pmic.

Link to comment
Share on other sites

  • 0
23 hours ago, James Kingdon said:

I see, it's exactly backwards from what I want

 

Well, I don't know if adjusting these 3 values in the way they are set now everywhere was much by intention and not just by accident. By looking at a lot of similar values (like CPU frequency steps, DVFS OPP or DRAM clockspeeds) in the meantime I came to conclusion that whoever defines them in the first place can do almost what he wants (numbers not being questioned) while later it needs an insane amount of discussions/efforts to change such numbers again.

 

After thinking somewhat about it given the PSU's 3A limitation and people probably attaching even a host powered USB disk to their Pinebooks having pmu_runtime_chgcur set that high seems questionable to me. These were the values we started with:

pmu_runtime_chgcur = <0x1c2>;
pmu_suspend_chgcur = <0x5dc>;
pmu_shutdown_chgcur = <0x5dc>;

And that's where we're now:

pmu_runtime_chgcur = <0x708>;
pmu_suspend_chgcur = <0x5dc>;
pmu_shutdown_chgcur = <0x5dc>;

(only change: increasing charge current on a running system from 450mA to 1800mA while not touching the other values).

Link to comment
Share on other sites

  • 0

I did a quick test with 2A charge rate in shutdown. I had the back of the case and the heatsink off so I could attach the probe, so it won't entirely reflect normal usage, but the pmic stabilised at just under 40C, with the battery at about 25. This was with the battery at 20% capacity, so the PMIC should be delivering most of the target current. I'm fairly happy with that rate/temperature compromise, so I don't think I'll try and push it any harder.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines