| uvos | about cpcap/calibration data | 00:33 |
|---|---|---|
| uvos | theres no where to store it hw wise, except on the battery eeprom but motorola dident do that, and we dont know what the values on the eeprom mean so we cant just change them | 00:34 |
| uvos | motorola dident use the hw state of charge capabilities of cpcap at all | 00:34 |
| uvos | the reason why i dident merge that pr is, even though that is my pacakge | 00:38 |
| uvos | i dont have the rights to the git repo | 00:38 |
| uvos | and i gues it was forgoten that i requested that | 00:38 |
| uvos | Wizzup: ^^^ | 00:38 |
| uvos | easiest way to ensure battery callibration is for me this btw: let the device drain untill empy, boot the device by pluging in usb and wait for the battery display of charge mode, quickly unplug and replug the usb lead, press power to boot to normal mode, charge fully, shutdown (to ensure its saved because d4 is still a bit unstable and a sucessfull normal shutdown is required) | 00:42 |
| SuperMarioSF | OK my extra durable SD card arrived | 06:02 |
| SuperMarioSF | provisioning new device | 06:02 |
| SuperMarioSF | One of XT883 arrived. Wizzup | 06:11 |
| SuperMarioSF | Android 2.3.4, baseband n_14.18.16s , kernel 2.6.35.7-gf704d14 e6178c@zch68lnxdroid61 #1 | 07:34 |
| SuperMarioSF | Internal version: SLNCT-57.1.40 | 07:35 |
| SuperMarioSF | System version: 57.1.40.XT883.ChinaTelecom.cn.CN | 07:35 |
| SuperMarioSF | by the way, the rubber coating on the back cover is getting sticky... | 07:41 |
| SuperMarioSF | Charging up battery. The stock box came with 2 batteries inside. | 07:42 |
| Wizzup | uvos: I have the same smaller screen again | 10:54 |
| SuperMarioSF | btw, I'm still finding next XT883 available. | 12:09 |
| SuperMarioSF | current one seems working okay, just have some old degraded sticky rubber coating on the back cover. | 12:09 |
| Wizzup | :) | 12:12 |
| Wizzup | oh, my h-d is in the funny state again | 12:15 |
| Wizzup | https://wizzup.org/h-d-smaller.png | 12:17 |
| Wizzup | It doesn't look xrandr related, but just h-d related | 12:17 |
| Wizzup | tklock renders full screen | 12:17 |
| Wizzup | xdamage also seems off | 12:17 |
| Wizzup | uvos: ^^ | 12:18 |
| Wizzup | restarting hildon-desktop indeed hepls | 12:19 |
| Wizzup | (had to do it because I couldn't get the logs in any case) | 12:19 |
| Wizzup | started h-d in a screen now in case it happens again | 12:22 |
| uvos | really wierd | 12:29 |
| uvos | but yeah the screen size changeing loging in h-d has bugs | 12:30 |
| uvos | just go and change the resolution on hildon | 12:30 |
| uvos | probubly the same issue | 12:30 |
| Wizzup | maybe, but still weird, since it just ... happens over night | 12:30 |
| uvos | ok | 12:30 |
| uvos | hmm, not on rotation? | 12:30 |
| Wizzup | maybe h-d crashes at night on usb power and then it restarts like this? | 12:30 |
| Wizzup | not sure | 12:30 |
| uvos | maybe yeah | 12:30 |
| uvos | dmse logs when it restarts an app no? | 12:31 |
| Wizzup | could also be related to orientation | 12:31 |
| uvos | dsme | 12:31 |
| Wizzup | right | 12:31 |
| uvos | anyhow hildon for sure just calculates the sizes of surfaces wrong when the resolution changes at runtime | 12:31 |
| Wizzup | uvos: what repo do you want access to? (re: yesterday) | 12:31 |
| uvos | https://github.com/maemo-leste/droid4-battery-calibration | 12:31 |
| uvos | im supposidly maintainer of this | 12:32 |
| uvos | but have no access | 12:32 |
| Wizzup | done | 12:32 |
| lel | IMbackK closed a pull request: https://github.com/maemo-leste/droid4-battery-calibration/pull/1 (Correct the script path) | 12:32 |
| Wizzup | btw, bookworm seems to have a new-ish pipewire compared to bullseye, which we might eventually want (since it so far has been a drop in replacement for pulse for me) | 12:39 |
| uvos | Wizzup: yeah | 12:42 |
| uvos | Wizzup: please also kick droid4-battery-calibration | 12:43 |
| uvos | i assume giveing me the rights to do so is still to hard | 12:43 |
| Wizzup | let me look at fixing it now | 12:43 |
| SuperMarioSF | woah, the battery life on leste with droid4 is surprisingly good... | 12:45 |
| Wizzup | SuperMarioSF: it ought to get even better | 12:46 |
| SuperMarioSF | a day passed, not even used a half | 12:46 |
| Wizzup | you have a nice battery :) | 12:46 |
| uvos | i think the mapphones are the only mainline linux devices that correctly idle | 12:46 |
| uvos | (please do correct me if im wrong, id like to know about them :) ) | 12:46 |
| uvos | i gues the librem5 maybe? | 12:46 |
| SuperMarioSF | probably this is the key to the old "nokia level battery standby time" days | 12:47 |
| Wizzup | SuperMarioSF: what is 'this' ? | 12:47 |
| SuperMarioSF | early 2000s nokia dumb phone like standby time. | 12:47 |
| uvos | SuperMarioSF: so currently we can do about 90mW on idle, android can do 15mW so the hw is capable of at least this. | 12:48 |
| SuperMarioSF | usually last for few days without a single charge | 12:48 |
| uvos | i thin 2000s dumb phones did way better | 12:48 |
| Wizzup | SuperMarioSF: so what matters more than almost anything is the hw | 12:48 |
| Wizzup | omap is really good at pm, and we don't even hit the lowest idle modes yet | 12:48 |
| Wizzup | we can kind of hit them on the n900, but not with all the useful drivers loaded | 12:48 |
| SuperMarioSF | however keeping running at 15mW on android is almost imporssible for long term since the software side doesn't corporate. | 12:48 |
| uvos | thats not really true if you use android with out google services | 12:49 |
| uvos | no other stuff running | 12:49 |
| uvos | but yeah "sock android" no | 12:49 |
| uvos | *stock | 12:49 |
| SuperMarioSF | that is true, because there is a special case, that is "China's Mobile App EcoSystem" | 12:49 |
| SuperMarioSF | especially in early 2010s | 12:50 |
| SuperMarioSF | every damn software ask a long list of permission and start multiple background services just to keep them alive. | 12:50 |
| uvos | i mean yeah if you have 100 apps installed that all do telemetry | 12:50 |
| uvos | your battery is gona have a bad time :P | 12:50 |
| SuperMarioSF | that's why task management software these days are essential. | 12:50 |
| uvos | leste is way worse at task management than android btw | 12:51 |
| uvos | since leste relies on coperative battery mangament | 12:51 |
| uvos | and android more on a preemtive/permissions model | 12:51 |
| SuperMarioSF | but it actually standby very well, way better than the phone at the time in my memory. | 12:51 |
| SuperMarioSF | and of course better than today's. | 12:52 |
| SuperMarioSF | just for fun: do you know why China always made new phones with beefy specs first? | 12:53 |
| SuperMarioSF | because a software single handledly make this happen. | 12:53 |
| SuperMarioSF | Weixin, which had a global version called WeChat (not mixed with WeeChat) | 12:54 |
| SuperMarioSF | This thing can just occupy your half of battery life alone. | 12:55 |
| SuperMarioSF | And this thing is still going bigger, add more useless function and more telemetry. | 12:55 |
| SuperMarioSF | But we just can't let it go, because this is a "Super App" that basically every need to use. It almost became it's own OS at this point. | 12:56 |
| uvos | this may be true | 12:56 |
| uvos | but its hardly the fault of the os | 12:56 |
| SuperMarioSF | yes, it is not the fault of the OS | 12:56 |
| Wizzup | SuperMarioSF: yeah I had used wechat for some time in HK back in 2016 or 2017 or so | 12:57 |
| SuperMarioSF | that is the whole reason we always need to upgrade our phone in few years, just to keep up with that damn super app. | 12:57 |
| SuperMarioSF | older phone will be "outdated" by that thing, not from API level, from performance level. | 12:58 |
| uvos | mean while in EU they shutdown 3g to force us to upgrade :( | 13:01 |
| Wizzup | :( | 13:01 |
| SuperMarioSF | because older tech tend to use more power... | 13:05 |
| Wizzup | is that true? | 13:05 |
| uvos | for the same bandwith yes | 13:05 |
| uvos | but genneraly bandwith rises more than efficancy | 13:06 |
| SuperMarioSF | unless there is a special reason to keep certain tech online, the older one will eventually gone. | 13:06 |
| uvos | anyhow hsdpa+ is really close to shannon limit anyhow | 13:06 |
| uvos | so both lte and 5g really dont have mutch more bandwith in the same band | 13:07 |
| SuperMarioSF | China Mobile still operate 2G network because our own railway signaling system still using them. | 13:07 |
| SuperMarioSF | and their TD-SCDMA 3G network are long gone because unpopularity. | 13:08 |
| SuperMarioSF | the funny thing is China Mobile is the first operator to release VoLTE nationwide, because they don't have 2G for HD calling, and 3G network is gone. They have to use VoLTE. | 13:10 |
| SuperMarioSF | meanwhile China Unicom had WCDMA handling HD calling to this day. They support VoLTE later, but HD Calling on 3G still works. | 13:11 |
| SuperMarioSF | China Telecom, had already fully converted into 4G only, because they were using CDMA based network before. | 13:12 |
| SuperMarioSF | CDMA infrastructure still there, but when you see your network drop back into CDMA, you know there is basically "Out of service". | 13:13 |
| SuperMarioSF | btw my primary SIM is a China Telecom one, I have subscribed long before and still using that today. | 13:15 |
| Wizzup | uvos: is there any point to setting up daedalus as well in jenkins? | 13:16 |
| uvos | not atm i dont think | 13:16 |
| Wizzup | ok | 13:18 |
| buZz | so pretty https://space.nurdspace.nl/~buzz/flok-xmpp-maemo.png | 17:53 |
| buZz | (avatars work through the gabble link, both receiving and setting on server) | 17:54 |
| buZz | the 'save' of 'my settings' does seem to hang the first time you try it, always need to save twice to set it | 17:54 |
| buZz | SuperMarioSF: hahaha, i half considered just glueing a android to another device on the back, just for such 'YOU NEED THIS ONE APP OMG WTF BBQ' | 17:56 |
| SuperMarioSF | buZz OK I depleted my battery however it doesn't show "recharge battery" popup. It seems it just killed X server and just shutdown normally. | 18:37 |
| SuperMarioSF | I can see the status light goes off later than screen. | 18:38 |
| SuperMarioSF | Will this work for signaling to start battery calibration? | 18:38 |
| SuperMarioSF | btw this happend while battey icon show at least 50%. | 18:38 |
| SuperMarioSF | Android side show only 4% remaining | 18:39 |
| SuperMarioSF | after reboot the desktop won't even show up, it just shutdown even before desktop loaded. | 18:40 |
| SuperMarioSF | there is the file /var/lib/droid4-battery-calibration/charge_full , but have no content in it. | 18:44 |
| buZz | SuperMarioSF: killed X + turned on the white led when screen is off? | 18:45 |
| SuperMarioSF | yes | 18:45 |
| buZz | thats the lowpower shutdown , the popup was prior to that | 18:45 |
| SuperMarioSF | desktop just gone | 18:45 |
| SuperMarioSF | and white led keeps for a while, and power down after that | 18:45 |
| buZz | yes, its to signal to you its powering down for low power | 18:46 |
| SuperMarioSF | so this is okay for calibrate battery? | 18:46 |
| SuperMarioSF | I can see that file the script saves, but no content in it. | 18:46 |
| SuperMarioSF | it is a empty file | 18:46 |
| SuperMarioSF | I just connected to a 5v 2A USB charger, and turned it back on. | 18:47 |
| SuperMarioSF | it went into desktop. | 18:47 |
| buZz | did it boot with green led on? | 18:48 |
| buZz | if not, then it didnt enable the charger | 18:48 |
| SuperMarioSF | i guess so | 18:48 |
| buZz | why guess | 18:49 |
| buZz | it has a led, look at it, does it have a color? | 18:49 |
| SuperMarioSF | now the green LED and white LED flashs | 18:49 |
| buZz | eh | 18:49 |
| buZz | this is even a droid4? running leste? | 18:49 |
| SuperMarioSF | maybe white LED means power on | 18:49 |
| buZz | it does not on leste on a droid4 | 18:49 |
| SuperMarioSF | it is in leste | 18:49 |
| buZz | is it a droid4 ? | 18:49 |
| SuperMarioSF | yes | 18:49 |
| SuperMarioSF | and I'm ssh into it right now | 18:50 |
| buZz | i have never in my life seen leste on a droid4 'flash green and white led' | 18:50 |
| SuperMarioSF | oh | 18:50 |
| SuperMarioSF | it is green LED, but sometimes turn to white, and goes back to green. | 18:50 |
| buZz | a) there's no white led there, its red, green and blue, 'white' is all three on | 18:50 |
| SuperMarioSF | yes | 18:50 |
| buZz | flashing white ? O_o still, have never seen that | 18:50 |
| SuperMarioSF | usually it is green | 18:51 |
| buZz | its green solid when charger is charging | 18:51 |
| SuperMarioSF | yes | 18:51 |
| buZz | and white solid when 'power off because of low battery' | 18:51 |
| SuperMarioSF | most time it is green | 18:51 |
| buZz | i havent seen -any- other signalling from led | 18:51 |
| buZz | hmmmm | 18:51 |
| buZz | maybe you messed around with lestes 'led notification' in settings? | 18:52 |
| buZz | and enabled this white flashing? or maybe i did to remove it? | 18:52 |
| * buZz wonders | 18:52 | |
| SuperMarioSF | it should be default settings... | 18:52 |
| SuperMarioSF | green light, and about each 5 seconds, the white came on for 0.5 second and back to green | 18:52 |
| buZz | either way, do you see the file /sys/class/power_supply/battery/uevent? read it | 18:53 |
| SuperMarioSF | I checked my notification light, it was all checked | 18:53 |
| SuperMarioSF | https://paste.mozilla.org/61PumuT1 | 18:53 |
| buZz | IF you are actively doing a calibration 1) POWER_SUPPLY_CHARGE_NOW should be increasing and POWER_SUPPLY_CHARGE_FULL should be increasing when you approach 100% charge | 18:53 |
| SuperMarioSF | here is the result for uevent | 18:54 |
| buZz | POWER_SUPPLY_CURRENT_AVG=-147478 | 18:54 |
| buZz | negative means charging | 18:54 |
| buZz | POWER_SUPPLY_CURRENT_NOW=6000 | 18:54 |
| buZz | not negative ; mean you are using more power | 18:54 |
| buZz | so the battery cant charge | 18:54 |
| buZz | should be between -100000 and -200000 (for gprs online while charging on good cable + psu) | 18:55 |
| buZz | i havent seen more than -200000 , but i think it -is- capable of it | 18:55 |
| SuperMarioSF | the unit seems 0.000001 amps? | 18:56 |
| SuperMarioSF | if that is true so there is 1.3A charging in to battery | 18:56 |
| buZz | i have no clue what you mean by 'the unit' | 18:57 |
| buZz | POWER_SUPPLY_CURRENT_NOW=6000 <- that value above zero means YOU ARE NOT CHARGING | 18:57 |
| buZz | does POWER_SUPPLY_VOLTAGE_NOW increase? then its charging | 18:57 |
| SuperMarioSF | OK | 18:58 |
| SuperMarioSF | I guess I misread something before, | 18:58 |
| SuperMarioSF | voltage reading is shaky but slowly increasing overall. | 18:59 |
| SuperMarioSF | so I just keep it charging until no green light, and use it all day to do this again? | 19:00 |
| SuperMarioSF | what should I expect when battery fully charged about the file /var/lib/droid4-battery-calibration/? | 19:01 |
| SuperMarioSF | -> /var/lib/droid4-battery-calibration/charge_full | 19:02 |
| SuperMarioSF | some kind of number? | 19:02 |
| SuperMarioSF | currently it is just nothing, an empty file. reading /sys/class/power_supply/battery/charge_full returned "No data available" | 19:03 |
| buZz | 1moment | 19:04 |
| buZz | SuperMarioSF: https://paste.debian.net/1250052/ | 19:05 |
| buZz | thats what a fully calibrated (and almost fully charged) one looks like | 19:05 |
| buZz | (the uevent file just adds all those seperate files into a single file) | 19:05 |
| buZz | SuperMarioSF: yeah , the 1080017 would be in that file | 19:09 |
| buZz | those files* | 19:09 |
| SuperMarioSF | POWER_SUPPLY_CAPACITY, POWER_SUPPLY_CHARGE_FULL, POWER_SUPPLY_CHARGE_NOW | 19:09 |
| SuperMarioSF | those three will be there | 19:09 |
| SuperMarioSF | ok, then that file really don't have data there. I will wait unitl it is done. | 19:10 |
| buZz | i so dislike that its still POWER_SUPPLY_VOLTAGE_MAX_DESIGN=4200000 | 19:13 |
| buZz | while the battery is actually designed for 4350000 | 19:13 |
| buZz | meaning about 20-30% more capacity could be there | 19:13 |
| buZz | :( | 19:13 |
| sicelo | buZz: the led can go crazy once in a while, so SuperMarioSF's experience is ... possible | 19:26 |
| buZz | sicelo: oh, sure yeah, like when USB cable is poorly connected | 19:27 |
| buZz | i'm just telling about my experience, dont really have much more to go on (afaik we never documented all led meanings) | 19:27 |
| sicelo | i mean ... when it shows patterns you don't expect. in my case, a week or two ago, the green led was permanently on. messing with sysfs didn't help a bit | 19:36 |
| buZz | yeah no clue about 'patterns' | 19:38 |
| buZz | sicelo: i had 'green led permanent on, screen enabled, not responding to touch and buttons, not even to powerbutton' just a couple days ago | 19:38 |
| buZz | also , it was SUPERWARM , not doing any HV lipo charging, it was just in my bag, when i pulled it out, it was already in that mode | 19:39 |
| sicelo | Wizzup: do you think N900 can be made to idle with a running system, or unlikely? I hope/plan to look at this at some point with my limited skills, but if you think it's unlikely, maybe I should spend my energy elsewhere | 19:54 |
| Wizzup | sicelo: I think it's a worthy thing to work on, but might be hard without serial | 19:59 |
| sicelo | i bought a level converter to mc guyver a serial connection :-) | 20:01 |
| sicelo | just that life got extra busy as soon as it arrived, but i am hopeful that I'll have a bit more time after end of this month | 20:01 |
| sicelo | got this one, https://www.communica.co.za/products/hkd-8-chan-logic-level-convertor , which is based on https://www.ti.com/lit/ds/symlink/txb0108.pdf | 20:08 |
| sicelo | and also 2.4 and 2.7v zeners. i'll mostly use a circuit somewhat similar to sre's. the challenge will be pogo pins, but if i fail to find a reliable way, i'll just solder wires to the board :-D | 20:09 |
| Wizzup | I think it would be very useful to identify which drivers block idle | 20:14 |
| Wizzup | even if you don't have immediate code fixes for it | 20:14 |
| sicelo | i'll do that | 20:17 |
| sicelo | 2G/3G is luckily not an issue for me in next few years (the perks of living in 'Third World'), so dinosaurs like Droid 4 and N900 still have a bit of a future for me, and since for my use case, N900 modem is more reliable and predictable, i'm not letting go anytime soon | 20:20 |
| sicelo | Wizzup: i think you still never replied to tmlind's email regarding N900 OFF mode. guess you're also busy like everyone :-) | 20:21 |
| Wizzup | sicelo: unfortunately very busy, was just complaining about how busy to a friend :D | 20:25 |
| Wizzup | sicelo: was this about the sysctl for silencing the wakeups? | 20:25 |
| sicelo | or /proc ... compaction. | 20:28 |
| Wizzup | yeah, that | 20:28 |
| Wizzup | yeah, I think that's a case of no time yet :( | 20:28 |
| uvos | how would serial help you id what drivers block idle? | 21:14 |
| uvos | serial blocks idle | 21:14 |
| uvos | or is that different on omap3? | 21:14 |
| uvos | buZz: "meaning about 20-30% more capacity could be there" yeah no | 21:15 |
| buZz | well, >10% anyway , you saw my figures before :P | 21:16 |
| uvos | maybe 10% at absolute most | 21:16 |
| buZz | but the omap_hqd seems to hang a lot :( | 21:16 |
| uvos | and the caillibration is really inaccurate i would not take its numbers so seriously | 21:16 |
| buZz | its ~1000mAh without my IED mods, and ~1300mAh with | 21:16 |
| buZz | at least on the calibration | 21:16 |
| uvos | in a normal lipo theres about 10% over 4.0v | 21:16 |
| buZz | i mean, reliably ~1000 and ~1300 over several calibration cycles | 21:17 |
| buZz | yeah, check the curve here, HV is kinda cool ; https://www.grepow.com/blog/what-is-a-lithium-ion-polymer-high-voltage-lihv-battery/ | 21:18 |
| buZz | on that battery almost 25% above 4.0 | 21:19 |
| buZz | (talking about the 4.35V one, the 4.4 and higher ones they talk about i never used or seen :) ) | 21:20 |
| uvos | yeah but only 10% above 4.2 | 21:20 |
| uvos | thats jives with other datasheets | 21:20 |
| uvos | 30 dosent | 21:20 |
| uvos | that seams very wrong | 21:20 |
| buZz | either way, i still want to try to replace your constant with mine, to see if all that code works as-is to get 4.35v max_design , and then overwrite charge voltage with 4.35 and run it like that for ~2 months, like i did with my IED patches | 21:21 |
| sicelo | recent leste review video, https://www.youtube.com/watch?v=TlDiHf5zdRs | 21:27 |
| Wizzup | yeah I linked his blog post | 21:32 |
| Wizzup | (also reached out on twitter) | 21:32 |
| Wizzup | he's thinking of porting hildon to pmos (again) | 21:32 |
| Wizzup | well, again to get it back in | 21:33 |
| sicelo | oh nice | 21:36 |
| sicelo | is Camden here on irc? | 21:42 |
| Wizzup | he said he'd join | 21:44 |
| Wizzup | not sure if he is | 21:44 |
| uvos | buZz: sure just need to figure out a better way to id the chip | 21:50 |
| uvos | then you can do what you like | 21:50 |
| uvos | nice video but the ui seams really laggy on pp :( | 21:52 |
| uvos | we probubly should make a more serious demo when coversations and sphone works | 21:53 |
| buZz | uvos: did you see my suggestion that the last 8 characters are just a unique serial# per chip? | 21:56 |
| uvos | i did | 21:57 |
| buZz | doesnt explain why you have the exact same ID on multiple batteries though | 21:57 |
| uvos | i do for sure | 21:57 |
| buZz | but does explain why they increment so minimally | 21:57 |
| uvos | (i checked) | 21:57 |
| uvos | but im concerned that maybe this will cause false positives | 21:57 |
| buZz | yeah maybe, i was hoping to gather more unique ids in the github issue i made | 21:57 |
| buZz | but thusfar nobody did :) https://github.com/maemo-leste/bugtracker/issues/621 | 21:58 |
| buZz | btw, i found a third EB41, still need to hook it up, the flexpcb looks a bit busted | 21:58 |
| buZz | maybe its production date? | 22:01 |
| sicelo | uvos: the guy has a brief sphone review on his blog | 22:01 |
| uvos | buZz: we should check where the value even comes from | 22:01 |
| sicelo | uvos: any idea for idle/off on omap3 (without serial)? | 22:01 |
| uvos | its from the w1 subsystem | 22:01 |
| uvos | it might be concating several things | 22:01 |
| uvos | ie the 8 chars might relate to the host controller | 22:02 |
| uvos | buZz: or we can just go f**k it and use the first nvmem we get | 22:03 |
| buZz | 3a31240b as unix timestamp would be Fri Dec 08 2000 18:10:19 GMT+0000 | 22:03 |
| uvos | buZz: since its the only chip on that bus on d4 | 22:03 |
| buZz | i doubt this battery is 22 years old :D | 22:03 |
| uvos | buZz: but i dont like it | 22:03 |
| buZz | uvos: hehe , thats true, and i dont like that either :) | 22:03 |
| buZz | might cause issues later | 22:03 |
| buZz | tbh i saw very few systems with >1 1wire device | 22:03 |
| uvos | yeah but without checking every mapphone to make sure | 22:04 |
| uvos | .. not a great idea | 22:04 |
| buZz | right, well | 22:04 |
| uvos | as you say | 22:04 |
| buZz | we have a couple in this channel ^_^ | 22:04 |
| uvos | well no | 22:04 |
| uvos | theres lots of more exotic ones we dont have | 22:04 |
| buZz | i mean, just to identify the number their EB41 reports with current setup | 22:04 |
| uvos | sure but it needs to work on the 2 bionic bats the mz6xx ones and idealy it would work any mapphone battery | 22:05 |
| uvos | maybe we open every eeprom and grep for |motorola" | 22:05 |
| uvos | also not pretty but would work i gues | 22:06 |
| buZz | yeah CHARGEONLY or something :P hehe | 22:06 |
| buZz | uvos: also we just need to do it once i guess? | 22:06 |
| uvos | no | 22:06 |
| uvos | the kernel realy has no where to store state cross reboots | 22:06 |
| uvos | (also thats very frowned upon) | 22:07 |
| buZz | yeah i mean, once on boot | 22:07 |
| uvos | ofc yeah | 22:07 |
| uvos | sicelo: you mean to debug? | 22:07 |
| sicelo | yes | 22:07 |
| buZz | currently it seems its trying to reread the nvmem file all the time? | 22:07 |
| buZz | somewhat | 22:07 |
| uvos | sicelo: not really sorry, the idle blocking bits will give you some hint | 22:07 |
| uvos | other than that what Wizzup was doing is the best thing i know | 22:07 |
| uvos | (modprobe stuff one at a time) | 22:07 |
| uvos | buZz: it should not | 22:08 |
| buZz | uvos: -sometimes- the endpoints in /sys/bus/w1/devices disappear , and come back later | 22:08 |
| buZz | to me, that seems like something is still happening | 22:09 |
| uvos | hmm | 22:09 |
| uvos | thats wierd | 22:09 |
| buZz | also the continuous messages from omap_hdq in dmesg | 22:09 |
| uvos | sounds like buggynes | 22:09 |
| buZz | which sometimes go so fast that the whole devices locks up | 22:09 |
| buZz | right, ok | 22:09 |
| uvos | maybe the hdq dirver has had a regeression since i used it last | 22:10 |
| buZz | we could make 'all' the charger variables userspace? or module parameters? | 22:10 |
| uvos | lemmy probe it | 22:10 |
| uvos | sure you could make all the values wirteable in sysfs | 22:10 |
| buZz | then do identifying in userland through loading the omap_hdq driver, and unload it after grabbing the data | 22:10 |
| uvos | but generally the kernel shal not allow the user to distroy something from userspace | 22:10 |
| buZz | then some small tool that can analyze nvmem , identify values for charger, and then unload/reload the charger module with those vars, cache em to disk to use again next boot | 22:11 |
| buZz | unless /newbatterywhodid exists or something | 22:11 |
| uvos | thats unsafe | 22:11 |
| buZz | well, the omap_hdq step once can still be done to make it safer, indeed | 22:12 |
| uvos | on bionic there are 4.2 and 4.35v batterys | 22:12 |
| buZz | then /newbatterywhodid isnt needed | 22:12 |
| uvos | the user can switch | 22:12 |
| buZz | does unloading charger module work even? on a booted device | 22:12 |
| uvos | should be ok | 22:13 |
| buZz | well, if loading that with parameters could work, that would make this all workable, i think | 22:13 |
| uvos | not sure why you would need module parameters | 22:13 |
| buZz | i dont think we need to expose all the variables themselves, just a batterytype=x , 0=4.2v plain, 1=EB41 , etc | 22:14 |
| buZz | because it cannot autodetect it now | 22:14 |
| uvos | oh like that | 22:14 |
| uvos | yeah we could do that as a fallback | 22:14 |
| buZz | might be a simple method | 22:14 |
| buZz | and chargevoltage is already overwriteable through sysfs you said, i think? | 22:15 |
| uvos | yes | 22:15 |
| uvos | but its limited to max design | 22:15 |
| buZz | right | 22:17 |
| uvos | somethings wrong with omap_hdq fore sure | 22:17 |
| uvos | unloading it just hanged my device | 22:18 |
| buZz | hmhm | 22:18 |
| buZz | https://patchwork.ozlabs.org/project/linux-imx/patch/pull-1579896427-50330@atomide.com-3/ <- speaks about some interrupt configuration | 22:21 |
| buZz | maybe thats related to the bunch of interrupt errors from omap_hdq | 22:22 |
| buZz | oh, that patch was replied to by pavel (and wizzup?) so i guess we have that :P | 22:24 |
| uvos | i think i developed the cpcap_charger code in the 5.9 time frame | 22:40 |
| uvos | at the time it worked absolutly fine | 22:40 |
| uvos | so thats way after that patch | 22:40 |
| buZz | hmhm | 22:40 |
| uvos | buZz: so whats xxd -p /sys/bus/w1/devices/89-500029ba0f73/id for you | 22:45 |
| uvos | replace the 500029ba0f73 ofc | 22:45 |
| uvos | $ xxd -p /sys/bus/w1/devices/89-500029ba0f73/id => 89730fba290050be | 22:45 |
| buZz | 890b24313a0050ec | 22:46 |
| uvos | thats pretty close | 22:46 |
| uvos | (mine was a bw8x) | 22:46 |
| buZz | on 89-50003a31240b | 22:46 |
| uvos | i assume this is a eb41 | 22:46 |
| buZz | i only have EB41s | 22:46 |
| buZz | and one very dubious one | 22:46 |
| buZz | but not sure if i still have that or tossed it | 22:47 |
| uvos | iiuc correct id should be uid | 22:47 |
| uvos | but maybe its not on these chips ill check some more later | 22:47 |
| buZz | 'name' also has a long string | 22:48 |
| buZz | oh, derp | 22:48 |
| buZz | thats just 89-etx | 22:48 |
| uvos | right | 22:48 |
| uvos | i also have like a stack of eb41 somehwere | 22:48 |
| uvos | (i have like 6) | 22:48 |
| buZz | nice :) | 22:49 |
| uvos | well except i dont use a single eb41 anywhere :P | 22:49 |
| buZz | well, send me some? :P | 22:50 |
| uvos | sure i could post you a few | 22:50 |
| uvos | but they are all pretty pure cap wise | 22:50 |
| uvos | *poor | 22:51 |
| buZz | hmhm, they all arent 1750mAh anymore :P | 22:51 |
| uvos | i think most are <950 | 22:52 |
| uvos | one is around 1200 i think | 22:52 |
| buZz | nice, on 4.2v 1200 might be almost 1500 on 4.35 | 22:52 |
| uvos | looks like its the bionic batteries taht are allways 500029ba0f73 | 22:53 |
| uvos | hmm | 22:53 |
| uvos | well at least these 3 | 22:54 |
| buZz | maybe they got a cheaper manufacturer for the chip in battery, that couldnt do unique IDs per battery? | 22:57 |
| Wizzup | uvos: so I just thought of this, but I have like 20+ batteries for different mapphones at home ofc | 22:57 |
| uvos | who knows | 22:57 |
| buZz | maybe a simple arduino breakout could be made too, just to read out the 1wire chip storage | 22:58 |
| buZz | so we dont need to put them in phones even | 22:58 |
| uvos | Im sure Wizzup wants to install leste on all of his 50 d4 for this | 22:59 |
| uvos | Wizzup: btw did you get the lot of busted droid 4's | 22:59 |
| buZz | oh nice, i might want to salvage one of those ;) try to replace the hinges in this dailydriver droid4 of mine | 23:00 |
| buZz | hinges/sliders | 23:00 |
| uvos | whats wrong with your sliders? | 23:00 |
| uvos | (i also have 2 sets of sliders if you need them) | 23:02 |
| buZz | uvos: they feel slightly malhandled on one side, causing a kinda iffy slide, compared to my other one | 23:06 |
| buZz | maybe i should just switch over again | 23:06 |
| buZz | :D | 23:06 |
| buZz | ¯\_(ツ)_/¯ | 23:06 |
| uvos | or clean them | 23:06 |
| buZz | hmhm, yeah | 23:06 |
| uvos | i had issues after being at the beach | 23:06 |
| buZz | until you sent it swimming? :P | 23:06 |
| uvos | https://scatteredquotes.com/wp-content/uploads/2018/01/StarWars-AttackoftheClones-1.jpg | 23:07 |
| buZz | hehehe lol what, i can do a -1 month- simcard subscription for 8.50 , and get -15- euro discount as being a customer already | 23:07 |
| buZz | wonder what happens after cancelling after 1 month | 23:08 |
| buZz | or on day30 | 23:08 |
| buZz | (but, prices went up ~25% since my previous card, dangit) | 23:08 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
