valant Posted May 8, 2017 Posted May 8, 2017 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.
martinayotte Posted May 8, 2017 Posted May 8, 2017 Well, eMMC is acting as a SSD here, yes, but Samsung eMMCs have good endurance. For the swap, on the latest Ayufan's image, he choose to set it to 1GB.
valant Posted May 8, 2017 Posted May 8, 2017 you will be laughing at me, but I didn't get, is it present or not, hibernation? xD thanks for the answers anyway.
tkaiser Posted May 9, 2017 Author Posted May 9, 2017 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). 1
Igor Posted May 9, 2017 Posted May 9, 2017 6 minutes ago, tkaiser said: due to the common browsers hammering storage with IO requests What about stock Armbian settings? https://github.com/armbian/build/blob/master/config/firefox.conf
tkaiser Posted May 9, 2017 Author Posted May 9, 2017 10 minutes ago, Igor said: What about stock Armbian settings? https://github.com/armbian/build/blob/master/config/firefox.conf 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.
Igor Posted May 9, 2017 Posted May 9, 2017 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?
tkaiser Posted May 9, 2017 Author Posted May 9, 2017 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.
tkaiser Posted May 9, 2017 Author Posted May 9, 2017 1 hour ago, Igor said: What about stock Armbian settings? https://github.com/armbian/build/blob/master/config/firefox.conf 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
hojnikb Posted May 9, 2017 Posted May 9, 2017 i wouldn't worry about wearing eMMC, these things have pretty advanced ECC nowadays. Unless you're hammering it with random 4k writes 24/7, it's going to outlast the whole laptop
tkaiser Posted May 9, 2017 Author Posted May 9, 2017 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 1
hojnikb Posted May 9, 2017 Posted May 9, 2017 Looking at the seq. write speeds, it seems to be MLC, so even less worry about wearing it out prematurely
zador.blood.stained Posted May 9, 2017 Posted May 9, 2017 5 hours ago, tkaiser said: 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 Beelink GT1 uses FORESEE eMMC too: http://www.cnx-software.com/wp-content/uploads/2016/09/Beelink-GT1-Teardown-Large.jpg
tkaiser Posted May 9, 2017 Author Posted May 9, 2017 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: https://github.com/ayufan-pine64/linux-build/commit/a550cb83ba319b58042599c77548101146059386 https://github.com/ayufan-pine64/linux-build/commit/e3c09e2faf508ecf4bc535e1d64fbb7496451437 https://github.com/ayufan-pine64/linux-build/commit/d291cdc0630ac3a56c373cc7155a95b290080432 (affects Pine64 too, longsleep managed to create one file that fits all models) https://github.com/ayufan-pine64/linux-build/commit/d53dc09dea2ef975652bc75e9ba96e4a5b9b617a https://github.com/ayufan-pine64/linux-build/commit/16a9cd80fdd673f2bdaadf74b54569ff70509eb5 https://github.com/ayufan-pine64/linux-build/commit/82426fa921a4026341f366355243b483ac7fc231 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)
Igor Posted May 14, 2017 Posted May 14, 2017 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
tkaiser Posted May 14, 2017 Author Posted May 14, 2017 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
Igor Posted May 15, 2017 Posted May 15, 2017 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?
zador.blood.stained Posted May 15, 2017 Posted May 15, 2017 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.
tkaiser Posted May 15, 2017 Author Posted May 15, 2017 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.
Igor Posted May 15, 2017 Posted May 15, 2017 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.
zador.blood.stained Posted May 15, 2017 Posted May 15, 2017 Hm. Try booting legacy and mainline Armbian SoPine images?
Igor Posted May 15, 2017 Posted May 15, 2017 SoPine legacy just booted now from DC ... inspecting further.
Igor Posted May 15, 2017 Posted May 15, 2017 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
hojnikb Posted May 16, 2017 Posted May 16, 2017 Disconnect the battery and try to manually charge it. to like 3.5-3.6V
Luke Posted May 16, 2017 Posted May 16, 2017 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
Igor Posted May 16, 2017 Posted May 16, 2017 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!
Xalius Posted May 16, 2017 Posted May 16, 2017 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
zador.blood.stained Posted May 16, 2017 Posted May 16, 2017 4 minutes ago, Xalius said: We do not have an Errata sheet for the AXP803, do we? Maybe it has to do something with the undervoltage lockout settings in the dts..., but that would be silly, or a bug... Dumping AXP registers from the affected device would definitely help
Xalius Posted May 16, 2017 Posted May 16, 2017 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...
zador.blood.stained Posted May 16, 2017 Posted May 16, 2017 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
Recommended Posts