zador.blood.stained Posted February 13, 2016 Author Posted February 13, 2016 Made some kind of configuration program. Ugly, but should work (latest kernel/patch version required).
chradev Posted March 28, 2016 Posted March 28, 2016 Hi to All, As I have noticed in http://forum.armbian.com/index.php/topic/155-testers-wanted-sunxi-adjustments-for-rpi-monitor/page-2#entry6942 there is a way to setup battery parameters for legacy kernel 3.4 using lime2.bin/fex file. Is there such a way for mainline kernel using device tree? Best regards Chris
zador.blood.stained Posted March 28, 2016 Author Posted March 28, 2016 Is there such a way for mainline kernel using device tree? No, there is no proper driver for axp209 battery charger part, but it's possible to add charging current entries to sysfs interface.
chradev Posted March 28, 2016 Posted March 28, 2016 Thanks Zador, I suppose it should be done by script executed at boot time. If this parameters are added to sysfs who will make adjustment of axp209 chip? Does axp209 driver in mainline kernel have or not have a battery charge control at all?
zador.blood.stained Posted March 28, 2016 Author Posted March 28, 2016 I suppose it should be done by script executed at boot time. You can set it once, after that changes will persist until axp209 has at least one power source available. OR you can write scripts to change it on suspend/resume/shutdown too. Does axp209 driver in mainline kernel have or not have a battery charge control at all? There were at least 2 attempts of writing such driver 1.5 - 2 years ago, but it wasn't mainlined and there is no progress since. So for charging either default values are used, or values left from booting OS with old 3.4.x kernel.
chradev Posted March 28, 2016 Posted March 28, 2016 Thanks Zador You can set it once, after that changes will persist until axp209 has at least one power source available. OR you can write scripts to change it on suspend/resume/shutdown too. There were at least 2 attempts of writing such driver 1.5 - 2 years ago, but it wasn't mainlined and there is no progress since. So for charging either default values are used, or values left from booting OS with old 3.4.x kernel. Unfortunately, using setup left by other OS booting is not acceptable. Is it means that writing values in sysfs will be written in axp209 directly? Does the file have to be first created if it does not exists? Or it is enough to issue: echo 6600 > /sys/class/power_supply/battery/energy_full_design or something like related to mainline kernel sysfs staff?
zador.blood.stained Posted March 28, 2016 Author Posted March 28, 2016 Is it means that writing values in sysfs will be written in axp209 directly? Yes. In theory it's possible to also use i2cget/i2cset, but you need to be extra careful to not overwrite other settings. Does the file have to be first created if it does not exists? It's not implemented yet, but if it's needed I can add this today or tomorrow.
chradev Posted March 29, 2016 Posted March 29, 2016 Thanks Zador, Unfortunately, I am working with legacy kernel for now but plan to migrate to mainline one very soon so do not see what and how is available there. My expectations are to have ability to customize all needed parameters for charging and discharging the battery like in legacy kernel via fex/bin file. I also need of mechanism to monitor power (DC-IN, USB OTG and battery) status for displaying it. RPI Monitor is helpful in development process only but I will use own web interface for local control. It is also required to have clean shut down when battery is reached a given threshold (5% for example). As I understand: power status parameters from axp209 can be monitored via and sysfs like in legacy kernel new calculated status parameters like discussed battery percentage can be added to sysfs clean shut down mechanism based on battery percentage will / could be added in next versions setting up of the battery parameters is not supported in device tree because of driver luck it is not feasible such support to be added soon could be worked around using sysfs probably not all features are supported via sysfs for now you can add none existing features (probably in Armbian development branch patching the kernel) while new features become mainlined patching the kernel can be applied in production branch as well Is there something wrong and/or missing in the picture above? If so which features are supported in latest: mainline release kernel (not patched)? Armbian production release (with patches)? Is there a process of mainlining of some of the work done around Armbian and what?
zador.blood.stained Posted March 29, 2016 Author Posted March 29, 2016 My expectations are to have ability to customize all needed parameters for charging and discharging the battery like in legacy kernel via fex/bin file. Not possible ATM, you can make configuration for a limited number of properties via sysfs interface or via i2cget/i2cset and some bit arithmetics magic. I also need of mechanism to monitor power (DC-IN, USB OTG and battery) status for displaying it. RPI Monitor is helpful in development process only but I will use own web interface for local control. If you want to reinvent the wheel, you can read values from sysfs/i2c bus directly, use data sources provided by "armbianmonitor" (WIP) or read them from RPi-monitor database It is also required to have clean shut down when battery is reached a given threshold (5% for example). Just write a small daemon that will poll capacity value from userspace and execute shutdown command when value falls below defined threshold As I understand: power status parameters from axp209 can be monitored via and sysfs like in legacy kernel new calculated status parameters like discussed battery percentage can be added to sysfs clean shut down mechanism based on battery percentage will / could be added in next versions setting up of the battery parameters is not supported in device tree because of driver luck it is not feasible such support to be added soon could be worked around using sysfs probably not all features are supported via sysfs for now you can add none existing features (probably in Armbian development branch patching the kernel) while new features become mainlined patching the kernel can be applied in production branch as well yes, just sysfs paths and property list are different I don't see any reasons to add complicated calculations to kernel space code, for displaying battery percentage changing OCV table should be enough to get better results. However new properties (like charging current control) may appear if needed it's better to implement "clean" shutdown logic in userspace, by writing a daemon that will poll battery capacity value yes doesn't look like it yes all major features are supported this patch is already present in sunxi-next branch (since new kernel branch v4.6 introduces changes to axp driver, this patch will be temporarily removed from dev branch) I'll try to maintain this patch to work with newer kernel branches
chradev Posted March 29, 2016 Posted March 29, 2016 Thanks Zador for your prompt answer, I definitely do not like to invent the wheel. That is why I ask all these questions. My feeling is that I am not alone with above requirements and there is a clever group of people working on all of them. I am grateful to your responsiveness for answering my questions (stupid some times) and willingness to help. Best regards Chris
zador.blood.stained Posted March 29, 2016 Author Posted March 29, 2016 I definitely do not like to invent the wheel. That is why I ask all these questions. Sorry, I wasn't clear, I meant that RPi-monitor should be enough for monitoring stuff, and you don't need to reinvent "own web interface for local control"
chradev Posted March 29, 2016 Posted March 29, 2016 Hi Zador, Sorry, I wasn't clear, I meant that RPi-monitor should be enough for monitoring stuff, and you don't need to reinvent "own web interface for local control" You are right for the general purpose devices like server or desktop boxes. I am working on project with distributed application having its own web based interface using browser staff like HTML5, Canvas, Web Workers, Web Sockets etc. It will be the only user interface (GUI) and battery and other power staff will not be more then one displayed on the top status line of tablets and mobile devices. The system itself has to work without any user assistance and completely autonomously. Root FS will be read only and minimal package staff will be installed. RPI Monitor is a perfect for development and testing purposes but it is not appropriate for production. Armbian Monitor is the right solution for getting needed status information which will be displayed by the only user GUI. Battery control, clean shut down etc. system functions will be supported by corresponding daemons and have to work autonomously.
kotc Posted June 1, 2016 Posted June 1, 2016 hello, here is an updated patch for 4.7.0-rc1: http://pastebin.com/raw/U0uWE0Yi
zador.blood.stained Posted June 1, 2016 Author Posted June 1, 2016 hello, here is an updated patch for 4.7.0-rc1: http://pastebin.com/raw/U0uWE0Yi I updated my patch for 4.6.0, but didn't push changes yet - waiting for 4.6 to become "stable" on kernel.org. Anyway, thanks, it may be useful to anyone who wants to use this with armbian dev branch (or for people who don't use Armbian at all ).
splite Posted June 15, 2016 Posted June 15, 2016 Hey, I would like to know if there is any fresh news about the battery management on vanilla Kernel ? I would like also to use the last kernel but I could not so far... Does the patch for 4.6 solve the issue ? Thanks
zador.blood.stained Posted June 16, 2016 Author Posted June 16, 2016 I would like to know if there is any fresh news about the battery management on vanilla Kernel ? Not yet, only AC input driver will be added soon AFAIK. Does the patch for 4.6 solve the issue ? Depends on your issue. Using battery for providing power to the board is more or less useable even with default settings.
splite Posted June 16, 2016 Posted June 16, 2016 Thanks Zador for replaying, I have basic need for the battery, I need to set the max capacity and the charging current. Currently in sun7i-a20-olinuxino-lime2.dtb theire is nothing about the battery setting, except this axp_ipsout { compatible = "regulator-fixed"; regulator-name = "axp-ipsout"; regulator-min-microvolt = <0x4c4b40>; regulator-max-microvolt = <0x4c4b40>; regulator-always-on; linux,phandle = <0x36>; phandle = <0x36>; }; How can I do this ?
zador.blood.stained Posted June 16, 2016 Author Posted June 16, 2016 axp_ipsout { compatible = "regulator-fixed"; regulator-name = "axp-ipsout"; regulator-min-microvolt = <0x4c4b40>; regulator-max-microvolt = <0x4c4b40>; regulator-always-on; linux,phandle = <0x36>; phandle = <0x36>; }; This is not for battery, this is describing "IPS" output of PMU and it doesn't have any configurable settings. Setting battery parameters in DT is not supported - as I said, there is no driver for battery charger part yet. Setting capacity is required only for estimating remaining time when charging/discharging, so you don't need to worry about it. Default charging current is 1200mA, so if it is acceptable for your battery, you don't have to worry about it either.
splite Posted June 16, 2016 Posted June 16, 2016 Setting battery parameters in DT is not supported - as I said, there is no driver for battery charger part yet. Ok, DT is not really clear for me yet, do you have any links where I can fellow the developpement ? Setting capacity is required only for estimating remaining time when charging/discharging, so you don't need to worry about it. That would have been quite nice to estimate the battery percentage as I need to show how full/empty is the battery... From your point of view, there is no way to damage the battery if those settings are not set ? My battery is 3.7v 7800mAh...http://fr.farnell.com/ansmann/2447-3034/batt-li-ion-rechargeable-3-7v/dp/2484233?ost=2484233
zador.blood.stained Posted June 16, 2016 Author Posted June 16, 2016 Ok, DT is not really clear for me yet, do you have any links where I can fellow the developpement ? Here you can find patches sent for review before they are included into kernel. Here is the overall progress for mainlining sunxi-related drivers. That would have been quite nice to estimate the battery percentage as I need to show how full/empty is the battery... Reading status (%) is possible in current Armbian kernel (manually, from command line, or in RPi-Monitor web UI). By "estimated time" I meant things like "battery will be fully charged in 10 minutes" or "remaining time before full discharge is 40 minutes" - this is calculated based on battery capacity (in mAh). From your point of view, there is no way to damage the battery if those settings are not set ? My battery is 3.7v 7800mAh...http://fr.farnell.com/ansmann/2447-3034/batt-li-ion-rechargeable-3-7v/dp/2484233?ost=2484233 Datasheet characteristics (charging current, target charging voltage and maximum discharge current) look OK for default settings, and it says that battery pack has internal protection board, so it should be safe. Just make sure you are using default PMU values (disconnect all power sources from the board and wait ~10 minutes before connecting power to board again).
splite Posted June 20, 2016 Posted June 20, 2016 Thanks Zador for the links, I will keep an eye the mailing list Reading status (%) is possible in current Armbian kernel (manually, from command line, or in RPi-Monitor web UI). By "estimated time" I meant things like "battery will be fully charged in 10 minutes" or "remaining time before full discharge is 40 minutes" - this is calculated based on battery capacity (in mAh). I can read status (% remaining), but it seems to be wrong...How does the AXP knows about the mAh available in the battery ?
zador.blood.stained Posted June 20, 2016 Author Posted June 20, 2016 I can read status (% remaining), but it seems to be wrong...How does the AXP knows about the mAh available in the battery ? It doesn't know about mAh, it can only read voltage and current, and provide estimated status (%) based on voltage (3.0V = empty, 4.2V = full). Other parameters should be calculated by driver based on readings from PMU.
PaceyIV Posted October 30, 2016 Posted October 30, 2016 Where I can find the results of this topic? I've change kernel to valina and I re-install rpimonitor. I don't find a config file that use the work of this topic.
PaceyIV Posted November 3, 2016 Posted November 3, 2016 Yeah, with the new version the value changes and looks interesting. Current idea: Use /etc/armbianmonitor/datasources/battery_charge symlinked to /sys/power/axp_pmu/battery/charge and /etc/armbianmonitor/datasources/battery_peak that contains the battery/charge peak value from the last charge cycle. Therefore battery_peak will be maintained by a daemon and remains always at the highest value when discharging starts. And then I try to use a simple forumula to calculate percentage: I have manually create all the datasources and the templates (I've tried to use armbianmonitor-daemon without success with also the commands . /etc/init.d/armhwinfo query and env) but I don't find any information about how to create and maintain battery_peak. I've just made a link to /etc/armbianmonitor/datasources/battery_charge so I don't see the undefined value to battery. There is a tutorial with all the stuff in one place?
technik007_cz Posted March 21, 2018 Posted March 21, 2018 I have got Lime connected on big battery pack. Therefore charging takes long time. Do you have an idea how to increase charging current on 4.X kernel ?
zador.blood.stained Posted March 21, 2018 Author Posted March 21, 2018 Charging current can be set to 1200 mA maximum by changing the bits 3-0 in register 0x34 0x33: https://linux-sunxi.org/images/8/89/AXP209_Datasheet_v1.0en.pdf Currently the only way to adjust this is via i2cget/i2cset commands, this property is not exposed via the sysfs interface.
technik007_cz Posted March 26, 2018 Posted March 26, 2018 I checked the datasheet and not register 0x34 but 0x33 is responsible for charging current. However it has been already set to maximum value 1200mAh. To get status of register I run command i2cget -y -f 0 0x34 0x33. Because the value 1001 for bit 0-3 has been reported back, there was nothing to adjust to get higher charging current. binary 1001 => decimal 9, 9*100mAh + 300mAh=1200mAh I found useful script, see link below, reporting charging values and status of both registers 0x33 and 0x34 (default values: 0xCX and 0x45). https://gist.github.com/tstellanova/b726545cc9bd2a01bb553f34509a5c96
technik007_cz Posted March 26, 2018 Posted March 26, 2018 What is strange that script reports if dc in is NOT present: Battery discharge current = 0mA Battery charge current = XXXmA Secondly BOINC manager do not register system is running on battery.
Recommended Posts