Jump to content

Quick Pinebook Preview / Review


tkaiser

Recommended Posts

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Important Information

Terms of Use - Privacy Policy - Guidelines