| Welcome, Guest |
You have to register before you can post on our site.
|
| Forum Statistics |
» Members: 12,398
» Latest member: vladk
» Forum threads: 5,543
» Forum posts: 43,747
Full Statistics
|
| Latest Threads |
Rock64 Seafile Installati...
Forum: General Discussion on ROCK64
Last Post: klaus_nase
2 hours ago
» Replies: 0
» Views: 6
|
Pinewatch ?
Forum: General
Last Post: Kochise
2 hours ago
» Replies: 0
» Views: 5
|
PinePhone, PineTab and Pi...
Forum: News
Last Post: mattcfox
7 hours ago
» Replies: 17
» Views: 1,582
|
Make Wiki Great Again
Forum: General
Last Post: fire219
Yesterday, 05:52 PM
» Replies: 11
» Views: 3,484
|
Pine64 E-ink screen - And...
Forum: Projects, Ideas and Tutorials
Last Post: clamum
Yesterday, 07:31 AM
» Replies: 3
» Views: 1,636
|
Hardware Status Monitorin...
Forum: Linux
Last Post: PopcornMaker
Yesterday, 04:04 AM
» Replies: 5
» Views: 2,472
|
10mm Low Profile Heatsink...
Forum: Hardware and Accessories
Last Post: evilbunny
Yesterday, 02:45 AM
» Replies: 1
» Views: 26
|
Android 9 for Rock64?
Forum: Android
Last Post: Vanbesem
Yesterday, 12:39 AM
» Replies: 37
» Views: 4,560
|
how to keep MAC address a...
Forum: Android
Last Post: AlexS
06-24-2019, 11:52 PM
» Replies: 0
» Views: 24
|
Android Images (ROCK64)
Forum: Android
Last Post: totalgaara
06-24-2019, 11:01 PM
» Replies: 58
» Views: 31,595
|
|
|
| Building a custom kernel on @mrfixit's Debian distro? |
|
Posted by: Tim Jones - 06-12-2019, 02:34 PM - Forum: Linux
- Replies (1)
|
 |
Hi Folks,
I've been building Linux kernels since 0.99.12, but I can't come up with a formula that allows me to build the kernel from the kernel-source package that is available for the 190531 release.
I'm trying to enable native SAS, scsi generic, and scsi tape support and add support for the HighPoint RR27XX card family.
EDIT - the RR27XX is seen properly by the kernel, and lspci reports proper configuration information.
Pointers and tips are highly welcomed 
|
|
|
|
| Rock64 Android 9 source code now available |
|
Posted by: jonsmirl - 06-12-2019, 07:10 AM - Forum: Android
- Replies (4)
|
 |
I have put the Rock64 Android 9 source code up here:
https://github.com/a9rock64/manifests
It boots but it needs work.
Neither Ethernet or Wifi is properly configured.
It does not have gapps integrated.
Several more minor issues
On the plus side it looks like OTG/adb is working now.
This is not ready for a casual user.
If your are Android developer please give it a try and help fix the broken parts.
Send me email and I will give you write access to the repositories.
|
|
|
|
| Screen flicker and tearing |
|
Posted by: RussianNeuroMancer - 06-12-2019, 03:57 AM - Forum: Linux
- No Replies
|
|
Hello!
I discover two issues with ROCKPro64 GPU drivers:
1. Constant screen flicker with display resolution above 2048x1280. For instance, I was able to reliable reproduce this with screen resolution 2560x1600 with LXDE, KDE and Mate.
I expected 2560x1600 to work as resolution is within the "4K Digital Video Out" spec advertised on product web-site. Issue is reproducible via both of HDMI and USB-C, by the way.
Switching from 2560x1600 to 2048x1280 as workaround is highly undesirable because image became blurry, which is very noticeable on 30 inch display.
2. Constant screen tearing, i.e. not working V-Sync in Xorg session (to reproduce this issue move windows around, play video in web-browser or desktop player). I hoped to get red of this issue by using Mutter Wayland session, but so far I found "Mutter on Mali" guides only for ODROID boards. On ROCKPro64 with installed Mali Wayland driver gdm3 just crash on start with both of enabled and disabled Wayland support in /etc/gdm3/custom.conf
I tried all combinations of modesetting dri2vsync and pageflip options, tried no compositing, default mate compositing, and all variants of kwin vsync options, issue is reproducible with every combination (which is why there is rkmpv wrapper that allow to watch video without tearing, I guess).
Is there any proper (not workaround-ish, like rkmpv, which is less then useful for my usecase, unfortunately) solution for these two issues? Like, maybe, newer GPU driver that not crash gdm3 and Mutter?
|
|
|
|
| Improve the life of your Pinebook battery by setting charger's voltage limits |
|
Posted by: wlad - 06-11-2019, 02:27 PM - Forum: Linux
- No Replies
|
|
It is a good practice for lithium battery powered devices to briefly think about the charging configuration which can significantly influence the health and usable capacity over time of a battery. Typically, a LiPo battery -- as is also used in the Pinebook -- has a minimum voltage of 3.0 volts (falling below quickly damages the battery) and a maximum voltage of slightly above 4.2 volts (further charging can destroy the battery and even ignite a fire).
The higher the difference of the battery voltage to these two extremes is, the longer it will keep its initial capacity and the less stress it has to withstand (temperature as another dimension can be critical also, but will be ignored for now). So, quite good voltage limits for charging your Pinebook may be 3.2 to 4.0 volts. The more tentative these limits are set, the less actual battery capacity will be usable, thus less time your Pinebook will be working on battery before it needs to charge.
Luckily, the power management unit AXP803 of the Pinebook allows you to configure, how you wish to set the voltage limits for your actual use case. To this end, you can use the virtual sysfs files in '/sys/class/power_supply/axp20x-battery/' which allow read and write access. I tested this on the current Armbian 5.86, but other distros may offer similar functionality, as they might use the same "axp20x" kernel module for accessing the AXP803 power management unit.
With read access, you can find out how the limits are currently set. By echoing values into the virtual files, you can persistently write settings to the unit (yes, written values reside on the AXP803 and keep changed even after reboot or shutdown). As the AXP803, for instance, supports only four possible maximum voltages (4.10v, 4.15v, 4.20v, or 4.35v), invalid values as write attempts are caught by the operating system.
Code: cat /sys/class/power_supply/axp20x-battery/voltage_max_design
cat /sys/class/power_supply/axp20x-battery/voltage_min_design
Charging voltage limits (example with a range of 3.2v ... 4.1v) can be set with:
Code: echo 4100000 > /sys/class/power_supply/axp20x-battery/voltage_max_design
echo 3200000 > /sys/class/power_supply/axp20x-battery/voltage_min_design
It seems that the maximum voltage is handled by AXP803 (or the kernel driver) with precaution so that my Pinebook battery only charged to up to 4.0 volts with this configuration. The capacity value that is provided in '/sys/class/power_supply/axp20x-battery/capacity' is adjusted automatically to the min and max settings.
I hope, some of you can use these hints to improve the endurance of your Pinebook's battery. Please post a message on your findings relating to practical observations or a different OS.
See for reference on more internals on the power management unit as investigated by xalius:
AXP803 Battery Charger Support
|
|
|
|
| Adding coherent_pool to boot.cmd on Xenial Mate by Ayufan causes boot loop |
|
Posted by: k_mp - 06-11-2019, 01:36 PM - Forum: Linux
- No Replies
|
|
Hi,
Due to my external WiFi driver, I added,
in /boot/boot.cmd at the end of
and ran
Code: $ sudo mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
But after a restart, the Pinebook didn't load up anymore and stuck in the boot loop (hangs on the logo). I'm using the Xenial Mate by Ayufan (the original factory distribution). Is there any solution to solve it? I know how to restore it. But to get my external WiFi works, I also need to have coherent_pool.
Unfortunately, since the Pinebook stuck in the boot logo, I can't see any logs.
|
|
|
|
| How to use dts or other setup to declare gpio pin Interrupt (e.g. a button)? |
|
Posted by: dkebler - 06-11-2019, 01:11 PM - Forum: Pi2, Euler and Exp GPIO Ports
- Replies (1)
|
|
Using armbian bionic mainline kernel on A64-v1.1 board
Linux pine64 4.19.38-sunxi64 #5.83 SMP Fri May 3 21:02:31 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux
In RPI bionic could just set values in boot.txt. Is this possible in armbian bionic mainline?
I know that one can use device tree overlays but can't find any examples specific to the A64.
Anyone have a dts file or otherwise know how to declare a pin as an interruptible input? I've come across nothing in any A64 docs.
|
|
|
|
| HDMI out not working on Pine64 11.6" XFCE |
|
Posted by: Fox7799 - 06-11-2019, 12:23 PM - Forum: Linux
- Replies (2)
|
|
This is the software that came with my Pinebook 11.6" laptop but HDMI out doesn't work with XFCE or Plasma so I can't display on external screens. Everything else works well. Xubuntu is my preferred software so I don't want to install something else. How soon can this be fixed? Thanks
|
|
|
|
| Display battery charge value with LXDE and lxpanel |
|
Posted by: wlad - 06-11-2019, 09:56 AM - Forum: Linux
- No Replies
|
|
In my opinion, Armbian with LXDE as window manager is a good fitting combination for the limited power of the Pinebook. LXDE provides only few visual effects, so the system can be used with acceptable performance. Unfortunately, I had an issue with the battery plugin of the lxpanel (the bar where all current windows/processes are stacked into).
Indication: Battery plugin (batt) of lxpanel does not show the current "capacity" (charged value in percent) of Pinebook's battery. Instead, it displays "0% charged" and continuously fires the low-battery alarm.
Reason: The integrated functionality of the battery plugin calculates the charged value by using the coulomb-based counters "charge_now" and "charge_full" (or alternatively "energy_now" and "energy_full"). These counters are usually provided by the power management unit's Linux kernel module. The kernel module (axp20x) for the AXP803 power management unit of the Pinebook does not provide "charge_now" and "charge_full" information. Instead, a percentage value for the current charge is provided as "capacity" (try 'cat /sys/class/power_supply/axp20x-battery/capacity').
Solution: I have changed the source code for the batt plugin with respect to the above mentioned reasons. Now, the percentage value is directly read from the corresponding sysfs file and not longer calculated indirectly.
The original code (lxpanel version 0.10.0) that you can find in 'lxpanel-0.10.0/plugins/batt/batt_sys.c' looked like this:
Code: battery* battery_update(battery *b) {
gchar *gctmp; int promille;
/* [...] */
/* read from sysfs */
b->charge_now = get_gint_from_infofile(b, "charge_now");
b->energy_now = get_gint_from_infofile(b, "energy_now");
b->current_now = get_gint_from_infofile(b, "current_now");
b->power_now = get_gint_from_infofile(b, "power_now");
if (b->current_now < -1)
b->current_now = - b->current_now;
b->charge_full = get_gint_from_infofile(b, "charge_full");
b->energy_full = get_gint_from_infofile(b, "energy_full");
b->charge_full_design = get_gint_from_infofile(b, "charge_full_design");
b->energy_full_design = get_gint_from_infofile(b, "energy_full_design");
b->voltage_now = get_gint_from_infofile(b, "voltage_now");
gctmp = get_gchar_from_infofile(b, "type");
b->type_battery = gctmp ? (strcasecmp(gctmp, "battery") == 0) : TRUE;
g_free(gctmp);
g_free(b->state);
b->state = get_gchar_from_infofile(b, "status");
if (!b->state)
b->state = get_gchar_from_infofile(b, "state");
if (!b->state) {
if (b->charge_now != -1 || b->energy_now != -1
|| b->charge_full != -1 || b->energy_full != -1)
b->state = g_strdup("available");
else
b->state = g_strdup("unavailable");
}
if (b->charge_now != -1 && b->charge_full != -1)
promille = (b->charge_now * 1000) / b->charge_full;
else if (b->energy_full != -1 && b->energy_now != -1)
/* no charge data, let try energy instead */
promille = (b->energy_now * 1000) / b->energy_full;
else
promille = 0;
b->percentage = (promille + 5) / 10; /* round properly */
if (b->percentage > 100)
b->percentage = 100;
/* [...] */
return b;
}
This code has been changed to the following:
Code: battery* battery_update(battery *b) {
gchar *gctmp; int promille;
/* [...] */
/* read from sysfs */
b->charge_now = get_gint_from_infofile(b, "charge_now");
b->energy_now = get_gint_from_infofile(b, "energy_now");
b->current_now = get_gint_from_infofile(b, "current_now");
b->power_now = get_gint_from_infofile(b, "power_now");
if (b->current_now < -1)
b->current_now = - b->current_now;
b->charge_full = get_gint_from_infofile(b, "charge_full");
b->energy_full = get_gint_from_infofile(b, "energy_full");
b->charge_full_design = get_gint_from_infofile(b, "charge_full_design");
b->energy_full_design = get_gint_from_infofile(b, "energy_full_design");
b->voltage_now = get_gint_from_infofile(b, "voltage_now");
// changed to direct read of percentage value (supported by pinebook)
b->percentage = get_norm_gint_from_infofile(b, "capacity");
gctmp = get_gchar_from_infofile(b, "type");
b->type_battery = gctmp ? (strcasecmp(gctmp, "battery") == 0) : TRUE;
g_free(gctmp);
/* [...] */
if (b->charge_now != -1 && b->charge_full != -1)
promille = (b->charge_now * 1000) / b->charge_full;
else if (b->energy_full != -1 && b->energy_now != -1)
/* no charge data, let try energy instead */
promille = (b->energy_now * 1000) / b->energy_full;
else
promille = 0;
// percentage was indirectly calculated, this has changed to direct read of value
//b->percentage = (promille + 5) / 10; /* round properly */
if (b->percentage > 100)
b->percentage = 100;
/* [...] */
return b;
}
As this requires a new function for reading the numerical value as provided by '/sys/class/power_supply/axp20x-battery/capacity', I introduced the following function which was inserted below the existing function "static gint get_gint_from_infofile(battery *b, gchar *sys_file)" in the same source code file "batt_sys.c":
Code: /* get_norm_gint_from_infofile():
* If the sys_file exists, then its value is converted to an int,
* and returned.
* Failure is indicated by returning -1. */
static gint get_norm_gint_from_infofile(battery *b, gchar *sys_file) {
gchar *file_content = parse_info_file(b, sys_file);
gint value = -1;
if (file_content != NULL)
value = atoi(file_content);
g_free(file_content);
return value;
}
The most time consuming part of this change was building the plugin's shared library file 'batt.so' because of all the required dependencies. But finally, it worked and I could replace the original file in '/usr/lib/aarch64-linux-gnu/lxpanel/plugins/'. The charge indicator now works as it should (except that I see no practical way how to predict the remaining power-on time).
I provide to you my build of 'batt.so' here (together with the changed 'batt_sys.c'), so that you do not need to build it by yourself:
lxde-lxpanel_batt-plugin.zip (Size: 39.15 KB / Downloads: 2)
I use it on Armbian 5.86 Debian stretch with LXDE 9.9 and lxpanel version 0.9.3. It may also work with other versions of LXDE/lxpanel and in combination with different Armbian versions. Please post your message on whether it worked for you by mentioning your system configuration. Thanks!
|
|
|
|
|
[June 20] Manjaro KDE (micro SD to eMMC Boot) 19.04 -1080P Pinebook |