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
51 minutes ago, zador.blood.stained said:

now we need to make images and place them in /boot directory

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

Link to comment
Share on other sites

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

  • 0
3 hours ago, tkaiser said:

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

Everything that may need updates should go to the board support package, but battery images and boot logo can be installed in family_tweaks

So we need 4 files:

/boot/bat/low_pwr.bmp

/boot/bat/bempty.bmp

/boot/bat/battery_charge.bmp

bootlogo.bmp

Link to comment
Share on other sites

  • 0
28 minutes ago, zador.blood.stained said:

So we need 4 files:

/boot/bat/low_pwr.bmp

/boot/bat/bempty.bmp

/boot/bat/battery_charge.bmp

bootlogo.bmp

 

For the 3 battery logos I would strongly recommend using those from here so users don't get confused about different charging 'behaviour' based on OS image running. Wrt our boot logo my favourite was bootlogo-armbian_blue_1365_767.png from http://kaiser-edv.de/tmp/NumpU5/ but in the meantime I think it's too large. Now I think we should use official wallpaper instead: armbian-dark-1365_767.png (added some noise to compensate for TN panel crappiness)

 

 

Link to comment
Share on other sites

  • 0
8 hours ago, tkaiser said:

Wrt our boot logo my favourite was bootlogo-armbian_blue_1365_767.png from http://kaiser-edv.de/tmp/NumpU5/ but in the meantime I think it's too large.

 

Yeah, I was going to say when I saw the list of four images needed why not just re-use the battery ones that are already in use...

 

I also prefer the blue pinecone armbian logo... looks very slick. When you say too big... are you meaning file size? 3MB being too big for the time that you see the logo?

Link to comment
Share on other sites

  • 0
18 hours ago, tkaiser said:

Wrt our boot logo my favourite was bootlogo-armbian_blue_1365_767.png from http://kaiser-edv.de/tmp/NumpU5/ but in the meantime I think it's too large.

What do you mean by "too large"? File size? Default is 3MB, if saved to 256 colors it's 1MB without noticeable quality losses. I would prefer to use this as a boot logo too.

Link to comment
Share on other sites

  • 0
29 minutes ago, zador.blood.stained said:

What do you mean by "too large"?

 

Just the optical size (I've not touched Pinebook for a week and when booting it again I had the chance to look at it from an 'average user' perspective). Feel free to replace bootlogo with it.

Link to comment
Share on other sites

  • 0
Just now, tkaiser said:

Feel free to replace bootlogo with it.

OK, but it will be low priority for now since we have screen tearing issues (should be fixed by modifying the DTs according to the Pine64 IRC logs) and I have shutdown/reboot issues and no logo at all on Armbian builds (so will have to make a serial console adapter to see what's going on)

Link to comment
Share on other sites

  • 0
On 5/29/2017 at 1:01 PM, zador.blood.stained said:

Regarding suspend/resume and battery issues on legacy, I would prefer to have ARISC firmware sources and toolchain, otherwise I'm not sure how much can be fixed and improved

 

I have not heard back yet from TL regarding XPowers looking into the issue with the battery charger, and I pretty much would like to see the ARISC code by now since working around that black box is rather frustrating. For now I changed my UPower settings to shutdown at 4% and the default action to 'poweroff' instead of 'hibernate' to avoid issues...

Link to comment
Share on other sites

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

Quick update:


no support bmp picture without bpix 24 or 32

 

 

Since you're looking at the BMP stuff... any pointers or a link to some docs explaining what command (maybe a imagemagick convert cmd?) I should use to create/convert a compatible BMP for uboot? Either I fed it the wrong format, or ... oh wait, you just committed a change that explains part of it... the paths being wrong for the charge related BMPs anyway. 

 

I tried using the bootlogo.bmp from tkaiser's commit, and shoved it into the root of the microSD, but it still didn't like me... I think it said 'not a BMP' or words to that effect... so I'll look again in the morning... I gave up it for the night once I decided to give up and just use the commit BMP and that didn't work for me. 

 

And yes, have to look into it further but there is definitely something in the DTS that is causing it... ayufan pointed out one promising line... the lcd_clock, but have to investigate further... 

Link to comment
Share on other sites

  • 0
14 hours ago, tkaiser said:

You need latest u-boot with @zador.blood.stained's patches: linux-u-boot-pinebook-a64_5.27_arm64.deb.gz

 

Drats... was hoping I'd have those patches already as I was using the nightly from... maybe a week ago? Anyway... I'll run a self-build of the current master in a few minutes and see what it's like.

 

@zador.blood.stained: Edit: One remaining question... I get the boot logo now, but it vanishes as soon as the kernel starts up... normal? and rest doesn't apply Did you check the display settings by any chance? Does that one line also influence the screen refresh rate? I know Luke and I keep harping on about that... but it seems to be a common factor so far... screen refresh rate drops from 60hz to 56hz, funky bottom line  of pixels (green or line of red blue green depending on how close you look) goes away, and tearing isn't so obvious on the 11" with horizontal movement of objects on the screen.

Link to comment
Share on other sites

  • 0

Ok, I can also confirm on my 11" pinebook that changing reduces the tearing and gets rid of the bottom row of dots... it isn't interlaced like it was before, but I think it is still there a bit, but that may be a artefact of XFCE not liking window contents being shown when dragged (easiest way to spot) and not knowing how much we can push the lcd_dclk_freq without something going pop. Interestingly enough the reported screen refresh rate jumps from 60hz to 64 hz. Changing the lcd_ht and lcd_vt then drops it back to 56hz like we usually see on ayufans mate images

 

2180c2249
< 			lcd_dclk_freq = <0x48>; longsleep
---
> 			lcd_dclk_freq = <0x4d>; ayufan
2187c2256
< 			lcd_ht = <0x5dc>; longsleep
---
> 			lcd_ht = <0x640>; ayufan
2190c2259
< 			lcd_vt = <0x320>; longsleep
---
> 			lcd_vt = <0x35c>; ayufan

 

Link to comment
Share on other sites

  • 0
28 minutes ago, zador.blood.stained said:

we need to test these values on 14" and if it works fine then this can be considered as fixed.

 

Tested without issues on 14" Pinebook, PR merged already. Do we need a patch for the same set of changes for u-boot too?

Link to comment
Share on other sites

  • 0

Thanks tkaiser. I'll leave the u-boot patch to you guys (I'm guessing zador?)... I have absolutely no idea where to start on that one... other than guessing that a diff patch needs to go in https://github.com/armbian/build/tree/master/patch/u-boot/u-boot-pine64-default ?? But a diff of what... I'll wait for the commit and work it out then ;)

 

Two things I noticed in the latest build:

  • I get the boot logo now from uboot, but it vanishes as soon as the kernel starts up... or is that expected?
  • The LCD brightness doesn't seem to be able to be adjusted via the power management applet in XFCE.
Link to comment
Share on other sites

  • 0

"no action" when lid is closed might be related to this? After this mod "screen off" function works, while suspend is no go. Also it does not differentiate when on battery or AC. Brightness can be adjusted manually now, but not by power condition BAT/AC. I guess this power management needs some extra touch :)

Link to comment
Share on other sites

  • 0
7 minutes ago, Igor said:

"no action" when lid is closed might be related to this? After this mod "screen off" function works, while suspend is no go. Also it does not differentiate when on battery or AC. Brightness can be adjusted manually now, but not by power condition BAT/AC. I guess this power management needs some extra touch :)

As I said, I personally won't touch suspend/resume at all (on the legacy kernel) unless ARISC firmware sources are provided, but I'll try to fix other issues if I can.

Lid switch works in the kernel (there is an input device that sends events on lid open/close), so this just needs propagation to the power management suftware (upower, systemd-logind, ...)

Link to comment
Share on other sites

  • 0

I would prefer to go with no locker - its kind of pointless to lock console if we dont use display manager ... if i understand this properly?

Wrote on mobile

Link to comment
Share on other sites

  • 0
21 minutes ago, Igor said:

I would prefer to go with no locker - its kind of pointless to lock console if we dont use display manager ... if i understand this properly?

Yes, no locker for now is the way to go, though Pinebook is exactly a kind of device which may benefit from password protection in login manager and locking support in the future.

Link to comment
Share on other sites

  • 0

I was using Pinebook for a week and it's performing ... good as a light browsing and remote terminal console work - any objections to move it from WIP section? Any idea why audio stopped to work? IIRC we fixed that.

Link to comment
Share on other sites

  • 0
13 minutes ago, Igor said:

any objections to move it from WIP section?

I would prefer to collect all known issues first, and @tkaiser most likely would prefer if you started a "board bring up" thread.

 

Just now, Igor said:

I haven't try headphones  yet ... but speakers are off. I am using previous build with upgrade.

Then we should look at the mixer values or maybe extract asound.state from a fresh ayufan build.

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