Xalius Posted May 16, 2017 Posted May 16, 2017 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...
Xalius Posted May 16, 2017 Posted May 16, 2017 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....
Igor Posted May 17, 2017 Posted May 17, 2017 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.
zador.blood.stained Posted May 18, 2017 Posted May 18, 2017 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.
zador.blood.stained Posted May 18, 2017 Posted May 18, 2017 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, ®_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) {
Igor Posted May 18, 2017 Posted May 18, 2017 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
zador.blood.stained Posted May 18, 2017 Posted May 18, 2017 Hm. Does it have a charging LED? Edit: according to the schematics it does. Can you try replacing DTB package on SoPine image with one built after my latest commit and check the charge LED behavior?
zador.blood.stained Posted May 18, 2017 Posted May 18, 2017 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
Igor Posted May 18, 2017 Posted May 18, 2017 Yes, battery led beside power plug started to blink in red colour.
zador.blood.stained Posted May 18, 2017 Posted May 18, 2017 Blinking means error according to the AXP datasheet. Does it blink ~once per second or ~4 times per second?
Igor Posted May 19, 2017 Posted May 19, 2017 Once per second. Edit #1: revitalised with this RC toy charger to 3.6V. Now charging ... Edit #2: Armbian running on Pinebook 1
Igor Posted May 20, 2017 Posted May 20, 2017 1st build. https://dl.armbian.com/pinebook-a64/Ubuntu_xenial_default_desktop.7zhttps://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
pfeerick Posted May 21, 2017 Posted May 21, 2017 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). 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!
tkaiser Posted May 21, 2017 Author Posted May 21, 2017 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
Igor Posted May 21, 2017 Posted May 21, 2017 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 ...
tkaiser Posted May 21, 2017 Author Posted May 21, 2017 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
hojnikb Posted May 21, 2017 Posted May 21, 2017 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). 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 1
Igor Posted May 21, 2017 Posted May 21, 2017 https://github.com/ayufan-pine64/linux-build/blob/master/package/root/usr/local/sbin/pinebook_restore_sound.sh This one is not working for me. I did enable headphones and I get sound controls but no sound. Will continue in the afternoon & evening.
tkaiser Posted May 21, 2017 Author Posted May 21, 2017 18 minutes ago, Igor said: This one is not working for me. Outdated, please check the list, it's https://github.com/ayufan-pine64/linux-build/commit/e3c09e2faf508ecf4bc535e1d64fbb7496451437 instead.
tkaiser Posted May 21, 2017 Author Posted May 21, 2017 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?
pfeerick Posted May 21, 2017 Posted May 21, 2017 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.
Xalius Posted May 21, 2017 Posted May 21, 2017 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.... 1
hojnikb Posted May 21, 2017 Posted May 21, 2017 Maybe AXP is "dead" in suspend and the only thing keeping the battery fron discharging is protection circuit inside the battery ? Is this possible ?
zador.blood.stained Posted May 21, 2017 Posted May 21, 2017 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. 1
Igor Posted May 21, 2017 Posted May 21, 2017 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
tkaiser Posted May 21, 2017 Author Posted May 21, 2017 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. 2
Luke Posted May 28, 2017 Posted May 28, 2017 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.
pfeerick Posted May 29, 2017 Posted May 29, 2017 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?
Igor Posted May 29, 2017 Posted May 29, 2017 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, ... 1
zador.blood.stained Posted May 29, 2017 Posted May 29, 2017 6 hours ago, Igor said: Some small rework of u-boot will be needed for that This was done already, now we need to make images and place them in /boot directory 1
Recommended Posts