Jump to content

Quick Pinebook Preview / Review


tkaiser

Recommended Posts

on hibernation, RAM content is stored on the secondary storage by the FW or OS. Which is eMMC on this laptop. thus the relation. So, does it?

I know that linux distros can, I am asking whether they do. in this case.

Link to comment
Share on other sites

8 hours ago, valant said:

is it present or not, hibernation?

 

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

Link to comment
Share on other sites

10 minutes ago, Igor said:

 

Not even tried, sorry. I tested around with Chromium (tried to get a clue about the sandboxing issue with arm64 but to no avail) and after switching to Firefox gave up (too slow to not get mad but maybe our settings would already cure this). BTW: latest armbianmonitor change allows write monitoring on block device level: 'armbianmonitor -d mmcblk0' will report 'flush to disk' for /dev/mmcblk0. I would always have an eye on this when testing.

 

BTW: I compared storage requirements of firefox:armhf with firefox:arm64 already: 'Switching from arm64 FF to armhf means 173 MB more disk space wasted' (http://irc.pine64.uk --> 04-05-2017). I wanted to compare memory requirements of both variants but failed to get an automated test suite than can be used to browse a couple of pages to monitor memory consumption/requirements.

Link to comment
Share on other sites

4 minutes ago, tkaiser said:

Switching from arm64 FF to armhf means 173 MB more disk space wasted'


If arm64 version still faces stability issues we don't have much choices. Better to waste this space than having half working app. Which chromium you used? From stock Ubuntu repository?

Link to comment
Share on other sites

4 minutes ago, Igor said:

If arm64 version still faces stability issues we don't have much choices.

 

According to others arm64 variants should work (and at least I did not experience any problems but I gave up too early). Maybe all the issues with those monstrous Mozilla apps on arm64 is that they simply let the machine 'swap to death' when used a bit (wens found that theory quite probable when discussing it at linux-sunxi IRC some time ago). And yes, all apps from stock Ubuntu repo.

Link to comment
Share on other sites

1 hour ago, Igor said:

 

Tested as follows: disabled RPi-Monitor (since constant IO activity) and did a reboot: https://pastebin.com/LbptW1aP

 

Did an 'apt upgrade && sync' that finished at 06:51:06. Did then nothing (no IO activity). At 06:53:28 I replaced /etc/firefox/syspref.js with our version and started FF (arm64) at 06:53:38. Visited a few pages, then did nothing between 06:55 and 06:58, then started to browse again a little bit and closing FF at 07:00:03.

 

TL;DR: An awful lot of storage activity needs to be addressed ;)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Link to comment
Share on other sites

BTW: While we're at it. @zador.blood.stainedhave you got your PB already?

 

Then how to proceed with regard to

  • u-boot wanting some logos on a FAT partition (u-boot uses sunxi_bmp_display("bat\\battery_charge.bmp"); and such all over the place)
  • @longsleepnot having merged the various u-boot branches yet, same with kernel branches (patience would be my 'solution')

And then just a list of things we shouldn't forget:

IMO not needed: https://github.com/ayufan-pine64/linux-build/commit/f20137ad894aaf2ca81364cab4fd865fc5652e94 (our NM based attempt is sufficient)

 

Edit: Also necessary:

 

https://github.com/longsleep/build-pine64-image/commit/7ff45bca2036f6b1ab04422942e7e67dfca47def (NM otherwise shows wrong connection info in menu item)

Link to comment
Share on other sites

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:

Spoiler

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

 

 

Link to comment
Share on other sites

2 hours ago, Igor said:

Battery was discharged down to null and when attaching a charger, current remains at 120 mA ... shouldn't this be little higher?

 

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

 

Link to comment
Share on other sites

On 14. 5. 2017 at 10:51 AM, tkaiser said:

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


My Pinebook is officially dead - it does not charge the battery - with stock system, latest build or Android image. Any known workarounds?

Link to comment
Share on other sites

Just now, Igor said:

Any known workarounds?

Desolder (or cut) the battery wire(s)? It should reset the AXP and allow starting from DC IN power.

I noticed similar issues on Pine64 (with no battery) - after shutdown u-boot thinks that battery (that is not connected in my case) needs charging and it can be solved by cycling the power.

Link to comment
Share on other sites

4 minutes ago, Igor said:

My Pinebook is officially dead - it does not charge the battery - with stock system, latest build or Android image. Any known workarounds?

 

I remember learning from @Xaliusthat there's a 'reset PMIC' method (pressing power button for IIRC 20 seconds) but don't know whether implemented or not with current u-boot.

Link to comment
Share on other sites

1 hour ago, zador.blood.stained said:

Desolder (or cut) the battery wire(s)? It should reset the AXP and allow starting from DC IN power.

 

I only get this, looping.

Spoiler

INFO:    Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):0bc348a
NOTICE:  BL3-1: Built : 01:16:30, Jan  4 2017
NOTICE:  BL3-1 commit: 0bc348ab272ad81a4faf128ef38f4724f36fded6

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-4-pine64-gaa53f12-dirty (Apr 17 2017 - 10:12:30) Allwinner Technology 

uboot commit : aa53f12d5033bf3ba525d52d0a83d5115b8d662d
 
rsb: secure monitor exist
[      0.254]pmbus:   ready
[      0.257][ARISC] :arisc initialize
[      0.729][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.904][ARISC] :sunxi-arisc driver startup succeeded
[      0.951]PMU: AXP81X
[      0.953]PMU: AXP81X found
bat_vol=0, ratio=100
[      0.960]PMU: dcdc2 1100
[      0.963]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 = 2500, 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=1

 

 

SD card boot:

 

Spoiler

HELLO! BOOT0 is starting!
boot0 commit : 045061a8bb2580cb3fa02e301f52a015040c158f
 
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 = 0x00000000
rtc[4] value = 0x00000000
rtc[5] value = 0x00000000
DRAM driver version: V1.1
start ddr type auto scan mode
rsb_send_initseq: rsb clk 400Khz -> 3Mhz
PMU: AXP81X
ddr voltage = 1280 mv
DRAM init OK 
lpddr3 try success
DRAM Type = 7 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3)
DRAM clk = 408 MHz
DRAM zq value: 003939b9
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]: 7620 MB
[mmc]: ***SD/MMC 0 init OK!!!***
sdcard 0 init ok
The size of uboot is 000f8000.
[mmc]: mmc 0 data timeout, err 00000080
[mmc]: mmc 0 cmd 18 err 00000080
[mmc]: mmc 0  read blcok failed
[mmc]: mmc 0 block read failed
Fail in reading uboot head.
Ready to disable icache.

 

 

Link to comment
Share on other sites

It works with SoPine default 3.10.105 image ... but battery remains dead.


Battery connected:

/sys/class/power_supply/battery/voltage_now

3267000 DC

3225000 Battery

/sys/class/power_supply/battery/capacity

0

/sys/class/power_supply/battery/present

1

Without:

/sys/class/power_supply/battery/voltage_now

0

/sys/class/power_supply/battery/capacity

100

/sys/class/power_supply/battery/present

0

 

"Charging" for 25 minutes, capacity remains 0, voltage idling at 3247-8, current draw at socket 0.3A at 5.00V

Link to comment
Share on other sites

Igor,  please see today's (16/05) log from Pine IRC starting with my question at 15:54:39.  Marcushh777 reported the same issue and claims to have managed to get the battery back up and working by repeatedly connecting and disconnecting the battery while the unit was plugged into mains. Either way, I too had this issue on one of the prototype units - while the unit was in hibernation the battery drained to 3.24 V and wouldn't power on again. As a side note, Marcushh777 also claims that this is an issue which affects the Pine board too when connected to battery.

 

Xalius believes the issue is related to AXP: 

 

16:08:33     Xalius_PB11 | it is a problem of the AXP not starting charging                              

16:08:42     Xalius_PB11 | and i cant explain the behavior

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

We do not have an Errata sheet for the AXP803, do we? Maybe it has to d!)o something with the undervoltage lockout settings in the dts..., but that would be silly, or a bug...

 

As far as I understand the datasheet, there is only two states for the charger to be in if it is enabled, and that is more or less hardwired. Under 3.0V it charges slowly with 1/10 of the programmed normal current (which doesn't seem to happen either) and above 3.0V it should charge with the programmed online/offline charge current... maybe there are some fault conditions that get triggered that turn it off... but I haven't found anything in the datasheet yet to explain the behavior and didn't manage to trigger it myself yet...

 

As for recovery I would try to manually charge the LiPo a bit with a bench lab supply, set some save end voltage like 4.0V and current limit to 2A and just hold some test probe to the terminals (disconnect from PCB first!) for a couple minutes, that should get it back up enough if it is an undervoltage problem

Link to comment
Share on other sites

If I would have to take a potshot I would maybe start trying with setting both undervoltage lockouts below 3.0V in the u-boot dts, then disconnect the battery from the AXP to reset it's registers and see if that changes anything... but there should be no connection between undervoltage lockout (prevents AXP from turning on) and the charger, since we see u-boot displaying the red battery bitmap apparently... which means the AXP turns on fine...

Link to comment
Share on other sites

1 minute ago, Xalius said:

If I would have to take a potshot I would maybe start trying with setting both undervoltage lockouts below 3.0V in the u-boot dts, then disconnect the battery from the AXP to reset it's registers and see if that changes anything... but there should be no connection between undervoltage lockout (prevents AXP from turning on) and the charger, since we see u-boot displaying the red battery bitmap apparently...

According to my observations with Pine64 battery detection may be broken or disabled in some cases: on cold start u-boot correctly prints that no battery is connected, but when powering on after a shutdown it thinks that a battery is present and needs charging

get Pine64 model from DRAM size
DRAM >512M
Pine64 model: pine64-plus
PowerBus = 2(0: not exist 1:vBus 2:acBus 3:vBus&acBus)
Battery Voltage=0, Ratio=0
key trigger
Warning: Low battery power, shutting down to recharge
sunxi bmp: unable to open file \boot\bat\bempty.bmp
set next system normal
drv_disp_exit
[mmc]: MMC Device 2 not found
[mmc]: mmc 2 not find, so not exit
[      5.706]power off
set power off vol to default

 

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