3 3
tkaiser

Quick Pinebook Preview / Review

Recommended Posts

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

 

Share this post


Link to post
Share on other sites
On 5/14/2017 at 8:41 AM, Igor said:

Problem? Battery was discharged down to null and when attaching a charger, current remains at 120 mA ... shouldn't this be little higher? I'll leave it for the day ...

 

 

This is last log I got:

  Reveal hidden contents


--------fastboot partitions--------
mbr not exist
base bootcmd=run mmcbootcmd
bootcmd set setargs_mmc
key 0
recovery key high 10, low 10
fastboot key high 4, low 4
no misc partition is found
to be run cmd=run mmcbootcmd
update dtb dram start
update dtb dram  end
serial is: 841050344318440e088e
get Pine64 model from DRAM size and used storage
Pinebook: has ANX9807 chip
Pine64 model: pine64-pinebook
PowerBus = 2(0: not exist 1:vBus 2:acBus 3:vBus&acBus)
Battery Voltage=3286, Ratio=0
power trigger
battery low power and vol with dc or ac, should charge longer
[mmc]: Has init
[      4.041]---drivers/mmc/mmc.c 2733 mmc_init
reading bat\bempty.bmp
120056 bytes read in 5 ms (22.9 MiB/s)
bmp file buffer: 0x41000000, bmp_info.buffer: 47400000
fetch script data boot_disp.output_full fail
screen_id =0, screen_width =1366, screen_height =768
frame buffer address 47400036
set next system normal
drv_disp_exit
[mmc]: mmc exit start
[mmc]: start mmc_calibrate_delay_unit, don't access device...
[mmc]: delay chain cal done, sample: 178(ps)
[mmc]: delay chain cal done, ds: 185(ps)
[mmc]: mmc 2 exit ok
[      7.293]power off
set power off vol to default

 

 

 

Question, how did it run dry? Was that with system active or did it run dry in suspend? Maybe the ARISC does weird things and leaves the AXP in some faulty state... just a wild guess, I tried to discharge my PB a couple times now and couldn't get it into that state so far... I even disabled upower once and let it run until the kernel crashed, that was around 3.4V at 2A load and well past 2% capacity left... but even after that it came back fine and just charged the battery....

Share this post


Link to post
Share on other sites
8 hours ago, Xalius said:

Question, how did it run dry?


I don't know, I assume I left it on ... I got it with full battery and after few hours here and there I lost few 10% and charge it back to 100% .. than after a day or two when I wanted to proceed with porting Armbian I could only boot into empty red battery followed by power off. Beside stock boot from eMMC I used one of Ayufan builds.

Share this post


Link to post
Share on other sites

I dumped AXP registers when powering on after shutdown and after reboot, and looks like shutdown disables AXP battery detection by clearing all bits in register 0x32, but reboot leaves the battery detection bit intact. Similar issue exists in mainline AXP209 code, but here AFAIK shutdown is controlled by the ARISC core (and closed source firmware), so fixing this would not be easy.

Share this post


Link to post
Share on other sites

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)

 

diff --git a/u-boot-pine64/board/sunxi/common/power_check.c b/u-boot-pine64/board/sunxi/common/power_check.c
index d427081..b0b1318 100644
--- a/u-boot-pine64/board/sunxi/common/power_check.c
+++ b/u-boot-pine64/board/sunxi/common/power_check.c
@@ -4,6 +4,8 @@
 #include <asm/arch/timer.h>
 #include <power/sunxi/pmu.h>
 #include <power/sunxi/power.h>
+#include <power/sunxi/axp.h>
+#include <power/sunxi/axp81X_reg.h>
 #include <sunxi_board.h>
 #include <fdt_support.h>
 
@@ -235,13 +237,26 @@ int PowerCheck(void)
     int LowBatRatioFlag =0;
     BOOT_POWER_STATE_E BootPowerState;
     int nodeoffset;
+    u8 reg_value;
+
+    /* Force enable battery detection - reg 0x32 bit 6 */
+    if(!axp_i2c_read(AXP81X_ADDR, BOOT_POWER81X_OFF_CTL, &reg_value))
+    {
+        if (!(reg_value & (1 << 6)))
+        {
+            printf("battery detection was disabled, setting it to enabled\n");
+            
+            reg_value |= (1 << 6);
+            
+            axp_i2c_write(AXP81X_ADDR, BOOT_POWER81X_OFF_CTL, reg_value);
+        }
+    }
 
     if(get_boot_work_mode() != WORK_MODE_BOOT)
     {
         return 0;
     }
 
-
     nodeoffset =  fdt_path_offset(working_fdt,PMU_SCRIPT_NAME);
     if(nodeoffset >0)
     {

 

Share this post


Link to post
Share on other sites

No change ... the problem is also that, even I have connected power, I experience SD media problems - next step is manual charge :)
 

Spoiler

[mmc]: mmc 0 data timeout 80
[mmc]: smc 0 err, cmd 18,  DCE
[mmc]: mmc 0 close bus gating and reset
[mmc]: mmc 0 mmc cmd 18 err 0x00000080
[mmc]: read block failed, mmc_read_blocks 271
[mmc]: block read failed, mmc_bread 324
 ** ext4fs_devread read error - block
[mmc]: mmc 0 cmd 16 timeout, err 100
[mmc]: smc 0 err, cmd 16,  RTO
[mmc]: mmc 0 close bus gating and reset
[mmc]: mmc 0 mmc cmd 16 err 0x00000100
[mmc]: Set block len failed
** Can't read partition table on 0:0 **
** Invalid partition 1 **
Bad Linux ARM64 Image magic!
Booting with defaults ...
[mmc]: mmc 0 cmd 16 timeout, err 100
[mmc]: smc 0 err, cmd 16,  RTO
[mmc]: mmc 0 close bus gating and reset
[mmc]: mmc 0 mmc cmd 16 err 0x00000100
[mmc]: Set block len failed
** Can't read partition table on 0:0 **
** Invalid partition 1 **
[mmc]: mmc 0 cmd 16 timeout, err 100
[mmc]: smc 0 err, cmd 16,  RTO
[mmc]: mmc 0 close bus gating and reset
[mmc]: mmc 0 mmc cmd 16 err 0x00000100
[mmc]: Set block len failed
** Can't read partition table on 0:0 **
** Invalid partition 1 **

 


Boot log: sopine legacy image with this patch

 

Spoiler

HELLO! BOOT0 is starting!
boot0 commit : 43e77041d17badbf8be959b8db97232c5e3a0a75
 
boot0 version : 4.0.0
set pll start
set pll end
rtc[0] value = 0x00000000
rtc[1] value = 0x00000000
rtc[2] value = 0x00000000
rtc[3] value = 0x0000a102
rtc[4] value = 0x00000000
rtc[5] value = 0x00000000
DRAM driver version: V1.1
rsb_send_initseq: rsb clk 400Khz -> 3Mhz
PMU: AXP81X
ddr voltage = 1280 mv
DRAM Type = 7 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3)
DRAM clk = 552 MHz
DRAM zq value: 003b3bdd
DRAM dual rank full DQ gate training OK
DRAM size = 2048 MB
DRAM init ok
dram size =2048
card boot number = 0, boot0 copy = 0
card no is 0
sdcard 0 line count 4
[mmc]: mmc driver ver 2015-05-08 20:06
[mmc]: sdc0 spd mode error, 2
[mmc]: Wrong media type 0x00000000
[mmc]: ***Try SD card 0***
[mmc]: HSSDR52/SDR25 4 bit
[mmc]: 50000000 Hz
[mmc]: 122623 MB
[mmc]: ***SD/MMC 0 init OK!!!***
sdcard 0 init ok
The size of uboot is 000e8000.
sum=17816203
src_sum=17816203
Succeed in loading uboot from sdmmc flash.
boot0: start load other image
boot0: Loading BL3-1
Loading file 0 at address 0x40000000,size 0x0000a200 success
boot0: Loading scp
Loading file 2 at address 0x00040000,size 0x00019a00 success
set arisc reset to de-assert state
Ready to disable icache.

onfiguring SPC Controller
NOTICE:  BL3-1: v1.0(debug):3cdc5c3
NOTICE:  BL3-1: Built : 20:14:26, May 18 2017
INFO:    BL3-1: Initializing runtime services
INFO:    BL3-1: Preparing for EL3 exit to normal world
INFO:    BL3-1: Next image address = 0x4a000000
INFO:    BL3-1: Next image spsr = 0x1d3


U-Boot 2014.07-g6f37e5c-dirty (May 18 2017 - 20:14:27) Allwinner Technology 

uboot commit : 6f37e5cf6a65b0b10455d12dbd631effabe765ec
 
rsb: secure monitor exist
[      0.381]pmbus:   ready
[      0.383][ARISC] :arisc initialize
[      0.756][ARISC] :arisc_dvfs_cfg_vf_table: support only one vf_table
[SCP] :sunxi-arisc driver begin startup 2
[SCP] :arisc_para size:1a8
[SCP] :arisc version: [v0.1.76]
[SCP] :sunxi-arisc driver v1.10 is starting
[      0.899][ARISC] :sunxi-arisc driver startup succeeded
[      0.936]PMU: AXP81X
[      0.938]PMU: AXP81X found
bat_vol=3229, ratio=0
[      0.945]PMU: dcdc2 1100
[      0.948]PMU: cpux 1008 Mhz,AXI=336 Mhz
PLL6=600 Mhz,AHB1=200 Mhz, APB1=100Mhz AHB2=300Mhz MBus=400Mhz
device_type = 3253, onoff=1
dcdc1_vol = 3300, onoff=1
dcdc2_vol = 1100, onoff=1
dcdc6_vol = 1100, onoff=1
aldo1_vol = 2800, onoff=0
aldo2_vol = 1800, onoff=1
aldo3_vol = 3000, onoff=1
dldo1_vol = 3300, onoff=0
dldo2_vol = 3300, onoff=0
dldo3_vol = 2800, onoff=0
dldo4_vol = 3300, onoff=1
eldo1_vol = 1800, onoff=1
eldo2_vol = 1800, onoff=0
eldo3_vol = 1800, onoff=0
fldo1_vol = 1200, onoff=0
fldo2_vol = 1100, onoff=1
gpio0_vol = 3100, onoff=0
vbus not exist
normal dc exist, limit to dc
run key detect
no key found
no uart input
DRAM:  2 GiB
fdt addr: 0xb6ebcf40
Relocation Offset is: 75f0f000
In:    serial
Out:   serial
Err:   serial
gic: sec monitor mode
[      1.266]start
drv_disp_init
init_clocks: finish init_clocks.
enable power vcc-hdmi-33, ret=0
drv_disp_init finish
boot_disp.output_disp=0
boot_disp.output_type=3
boot_disp.output_mode=10
fetch script data boot_disp.auto_hpd fail
disp0 device type(4) enable
attched ok, mgr0<-->device1, type=4, mode=10
[      1.673]end
workmode = 0,storage type = 1
[      1.677]MMC:        0
[mmc]: mmc driver ver 2015-06-03 13:50:00
SUNXI SD/MMC: 0
[mmc]: start mmc_calibrate_delay_unit, don't access device...
[mmc]: delay chain cal done, sample: 185(ps)
[mmc]: media type 0x0
[mmc]: Wrong media type 0x0
[mmc]: ************Try SD card 0************
[mmc]: host caps: 0x27
[mmc]: MID 1b PSN db1b0226
[mmc]: PNM 00000 -- 0x30-30-30-30-30
[mmc]: PRV 1.0
[mmc]: MDT m-11 y-2015
[mmc]: speed mode     : HSSDR52/SDR25 
[mmc]: clock          : 50000000 Hz
[mmc]: bus_width      : 4 bit
[mmc]: user capacity  : 122623 MB
[mmc]: ************SD/MMC 0 init OK!!!************
[mmc]: erase_grp_size      : 0x1WrBlk*0x200=0x200 Byte
[mmc]: secure_feature      : 0x0
[mmc]: secure_removal_type : 0x0
[      1.883]sunxi flash init ok

** Unable to use mmc 0:1 for loading the env **
Using default environment

--------fastboot partitions--------
mbr not exist
base bootcmd=run mmcbootcmd
bootcmd set setargs_mmc
key 0
recovery key high 12, low 10
fastboot key high 6, low 4
no misc partition is found
to be run cmd=run mmcbootcmd
update dtb dram start
update dtb dram  end
serial is: 841050344318440e088e
check for ANX9807
get Pine64 model from DRAM size
DRAM >512M
Pine64 model: pine64-plus
PowerBus = 2(0: not exist 1:vBus 2:acBus 3:vBus&acBus)
pre sys mode
Battery Voltage=3229, Ratio=0
key trigger
sunxi bmp: unable to open file \boot\bootlogo.bmp
[      2.283]inter uboot shell
autoboot in 3 seconds, Press s or <Esc><Esc> to abort

 

 

Share this post


Link to post
Share on other sites

I connected a battery and a charge LED to Pine64 and based on LED and console logs:

  • power off the board with battery and no AC or with AC without battery - battery detection is disabled (poweroff is handled by kernel->ATF->ARISC)
  •  otherwise (battery + AC power) poweroff is handled by rebooting to u-boot. This bypasses ARISC so battery detection is not disabled

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

It looks like there may also be an issue with the fact that the battery has a dedicated battery protection circuit, which will isolate itself from the outside world until the undervoltage lockout has been lifted... and since the AXP can't see it... you get a chicken-egg situation happening. Same stupid situation as the TP5100 lipo charge boards with protection circuitry... it needs power before it works, but when you first connect it stays off, so you need to bypass that protection to 'arm' it (hence why all the 'buy-your-own-battery' powerbanks all have a reset pinhole/switch in order to power them on when you first insert the batteries).

 

34707942996_271826e429_n.jpg

 

By rights, you can cheat if you didn't have a charger or variable power supply handy, and hook up a pair of AA batteries (i.e. 3v) to the lithium battery for 5-10 seconds, and that would have given it the (gentle) kick it needed to dis-arm the low-voltage cuttoff. Obviously you need to get the polarity right, otherwise you're going to really hope you used thin wires so you can feel them heat up or smoke if you get it back to front! 

 

 

Share this post


Link to post
Share on other sites
10 hours ago, Igor said:

Chromium RAM caching / Known bugs:

 

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

 

Share this post


Link to post
Share on other sites
10 minutes ago, tkaiser said:

works but might not be a real solution.


Exactly. I don't want to put this into the build. Let's put this behind - here in the forum as a tip - since it's not that urgent. Current browsing experience is already very nice - I haven't try with adding this tool.
 

10 minutes ago, tkaiser said:

Did you look already through the list

 

Looked yes, implemented not much. I am also having some thought regarding services in general withing a build system. We already have some and not well organised ... I put first one here -> build/scripts/services, but do we need to separate further? What would be the best future proof way?

 

Currently struggle with hall / laptop lid and audio ...

Share this post


Link to post
Share on other sites
1 hour ago, Igor said:

Current browsing experience is already very nice

 

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

 

Share this post


Link to post
Share on other sites
7 hours ago, pfeerick said:

It looks like there may also be an issue with the fact that the battery has a dedicated battery protection circuit, which will isolate itself from the outside world until the undervoltage lockout has been lifted... and since the AXP can't see it... you get a chicken-egg situation happening. Same stupid situation as the TP5100 lipo charge boards with protection circuitry... it needs power before it works, but when you first connect it stays off, so you need to bypass that protection to 'arm' it (hence why all the 'buy-your-own-battery' powerbanks all have a reset pinhole/switch in order to power them on when you first insert the batteries).

 

34707942996_271826e429_n.jpg

 

By rights, you can cheat if you didn't have a charger or variable power supply handy, and hook up a pair of AA batteries (i.e. 3v) to the lithium battery for 5-10 seconds, and that would have given it the (gentle) kick it needed to dis-arm the low-voltage cuttoff. Obviously you need to get the polarity right, otherwise you're going to really hope you used thin wires so you can feel them heat up or smoke if you get it back to front! 

 

 

 

How about just lifting minimum voltage in AXP to above that of protection circuit ? This way, axp will cut off battery before internal protection can kick in. Or if you're brave enough, just remove protection from the battery all together and let axp do it's thing :)

Share this post


Link to post
Share on other sites
2 hours ago, Igor said:

I don't want to put this into the build. Let's put this behind - here in the forum as a tip - since it's not that urgent.

 

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?

Share this post


Link to post
Share on other sites
1 hour ago, hojnikb said:

 

How about just lifting minimum voltage in AXP to above that of protection circuit ? This way, axp will cut off battery before internal protection can kick in. Or if you're brave enough, just remove protection from the battery all together and let axp do it's thing :)

 

Yeah, that's what I'm hoping we can do. I listed the part number in the desc on flickr, but didn't have any luck finding the datasheet, so hoping either TL can provide it, or someone else has luck finding it.

 

I was thinking about bypassing the protection circuit, but it obviously was needed as something went wrong and the AXP didn't kill the juice. So I'd prefer a temperamental battery to a dead battery. Hopefully they add a bypass button in the future so that you can simply pop the back cover (or poke a toothpick through a hole)  and plug in the power, and it should then be good. 

 

Share this post


Link to post
Share on other sites

The protection circuit specs are in the battery datasheets which are already on the Pine wiki. The UVLO voltages for are around 2.7-2.8V and should be well below those set in the AXP. I still have a suspicion that whatever happens, it has something to do with running out of battery in suspend. Under normal load the battery cuts out well above 3.0V , I saw values around 3.2-3.4V in my tests....

Share this post


Link to post
Share on other sites
Just now, hojnikb said:

Maybe AXP is "dead" in suspend and the only thing keeping the battery fron discharging is protection circuit inside the battery ? Is this possible ?

Without the ARISC firmware sources it's hard to predict what AXP flags are enabled or disabled on suspend or shutdown.

Share this post


Link to post
Share on other sites
3 hours ago, tkaiser said:

Can we add profile-sync-daemon_6.31-1_all.deb to apt.armbian.com and add it to desktop package list?

 

apt update && apt install profile-sync-daemon 

Share this post


Link to post
Share on other sites
3 hours ago, Igor said:

apt update && apt install profile-sync-daemon 

 

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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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?

 

 

 

Share this post


Link to post
Share on other sites

I also does not experience any screen tearing with our build. There was some in system on eMMC, one of the first Ayufan's builds.

 

45 minutes ago, pfeerick said:

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?


Some small rework of u-boot will be needed for that but I guess its doable. But first I wanted to solve "going to suspend when lid is closed". I think it's some xfce related issue, since lid driver is present and working, manual suspend also work, ...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
3 3