zador.blood.stained Posted July 1, 2017 Posted July 1, 2017 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. 1
Xalius Posted July 1, 2017 Posted July 1, 2017 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
tkaiser Posted July 1, 2017 Author Posted July 1, 2017 23 minutes ago, Xalius said: I have to see if I can find the info... All those listed long ago for a reason in the very same thread: https://forum.armbian.com/index.php?/topic/4133-quick-pinebook-preview-review/&do=findComment&comment=31463
Igor Posted July 1, 2017 Posted July 1, 2017 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.
Xalius Posted July 3, 2017 Posted July 3, 2017 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: 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.
Igor Posted July 4, 2017 Posted July 4, 2017 Release candidate latest fixes + this regarding audio on resume, touch pad and kernel upgraded with upstream patches. Download: (touch pad fix not included) https://dl.armbian.com/pinebook-a64/Ubuntu_xenial_default_desktop.7z What about HDMI out - how to use it?
zador.blood.stained Posted July 4, 2017 Posted July 4, 2017 2 minutes ago, Igor said: Release candidate 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).
Igor Posted July 4, 2017 Posted July 4, 2017 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?
zador.blood.stained Posted July 4, 2017 Posted July 4, 2017 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.
Xalius Posted July 4, 2017 Posted July 4, 2017 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...
zador.blood.stained Posted July 4, 2017 Posted July 4, 2017 I'm assuming video modes are still defined by "magic numbers" in the DT? Then it's just a question of adding new numbers into the boot script, since we are already using my-hacks-1.2 for A64 legacy kernel.
Igor Posted July 4, 2017 Posted July 4, 2017 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.
Igor Posted July 28, 2017 Posted July 28, 2017 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 1
James Kingdon Posted August 23, 2017 Posted August 23, 2017 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.
hojnikb Posted August 25, 2017 Posted August 25, 2017 Does anyone else have cheap little arm laptops in the pipeline ?
James Kingdon Posted September 3, 2017 Posted September 3, 2017 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. 2
James Kingdon Posted September 3, 2017 Posted September 3, 2017 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.
James Kingdon Posted September 4, 2017 Posted September 4, 2017 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! 1
martinayotte Posted September 4, 2017 Posted September 4, 2017 The u-boot is taken from this similar path : /usr/lib/linux-u-boot-dev-pinebook-a64_5.xx_arm64/u-boot-sunxi-with-spl.bin
James Kingdon Posted September 4, 2017 Posted September 4, 2017 Ah, still doesn't boot from eMMC. I guess I'm going to have to figure out that serial port connection. Wonder what I'm missing.
James Kingdon Posted September 6, 2017 Posted September 6, 2017 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
tkaiser Posted September 10, 2017 Author Posted September 10, 2017 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?
James Kingdon Posted September 11, 2017 Posted September 11, 2017 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).
James Kingdon Posted September 14, 2017 Posted September 14, 2017 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
James Kingdon Posted September 19, 2017 Posted September 19, 2017 Is the charging current adjustable? I'd quite like to be able to set the charge current to a relatively low value if I'm using the pinebook, and then boost it to a higher value as part of the suspend/shutdown sequence.
tkaiser Posted September 21, 2017 Author Posted September 21, 2017 On 20.9.2017 at 12:52 AM, James Kingdon said: Is the charging current adjustable? 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
James Kingdon Posted September 21, 2017 Posted September 21, 2017 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.
James Kingdon Posted September 22, 2017 Posted September 22, 2017 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.
tkaiser Posted September 22, 2017 Author Posted September 22, 2017 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).
Recommended Posts