| 00:45.36 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-95-239.residential.rdsnet.ro) |
| 12:22.04 | *** join/#maemo-ssu infobot (ibot@69-58-76-73.ut.vivintwireless.net) |
| 12:22.04 | *** topic/#maemo-ssu is Maemo Community Seamless Software Update "CSSU" channel, http://wiki.maemo.org/Community_SSU | Known bugs: http://j.mp/communityssu-bugs | Channel logs: http://mg.pov.lt/maemo-ssu-irclog/ | Sources: https://github.com/community-ssu | Latest version: Testing(2015-04-11): 21.2011.38-1Tmaemo11; Stable(2014-09-03): 21.2011.38-1Smaemo7 |
| 12:22.04 | *** mode/#maemo-ssu [+v infobot] by ChanServ |
| 12:22.24 | Pali | getboostate and preinit now should work even if they do not have special nokia /sys and /proc and /dev files |
| 12:22.46 | Pali | if raw file /proc/atags is provided, getboostate parse it and read information from that |
| 12:23.11 | Pali | if even if /proc/atags is not there, then default values are used (bootmode=normal, bootreason=powerkey, etc) |
| 12:23.33 | Pali | sane default values instead MALF |
| 12:24.18 | Pali | MALF is when kernel provides interface to read data && data are bad |
| 12:40.36 | kerio | do i yolo upgrade |
| 12:40.40 | kerio | i don't think i yolo upgrade |
| 12:40.51 | kerio | meh whatever |
| 12:40.52 | kerio | YOLO |
| 12:57.42 | Sicelo | thanks pali. will test :) |
| 13:14.55 | kerio | Pali: how can i add an entry to the uboot menu to power off? |
| 13:15.16 | Pali | kerio: uboot does not have code to power off rx51 board |
| 13:15.24 | kerio | ...but i did "reset" and it powered it off |
| 13:15.31 | Pali | if you have time, you can implement power of function |
| 13:15.42 | Pali | reset just reset board |
| 13:16.01 | kerio | i swear to god it's powered off |
| 13:16.08 | kerio | i can turn it on with the button |
| 13:16.11 | kerio | it does the light thing |
| 13:16.20 | Pali | maybe nolo decided to poweroff after reboot |
| 13:16.46 | kerio | fucking magnets |
| 13:16.49 | kerio | how do they work |
| 13:17.09 | kerio | Pali: haven't tested r&d mode but recovery console and backupmenu are both accessible |
| 13:17.15 | Pali | ok |
| 13:17.31 | kerio | fuck i lost the time |
| 13:22.20 | Sicelo | loose battery? |
| 13:23.29 | kerio | no, resetting uboot :> |
| 13:23.58 | Sicelo | has never happened to me .. with reset |
| 13:27.01 | Pali | so... who is going to implement power off in uboot? :-) |
| 13:27.16 | Pali | just need to reuse code from linux kernel... |
| 13:27.33 | Pali | it is some i2c call to twl4030 chip |
| 13:39.07 | Sicelo | points at Pali :D |
| 14:17.12 | drathir | Pali: nice gz... |
| 14:39.51 | DocScrutinizer05 | Pali: uboot knows to do I2C, no? even from "commandline" |
| 14:40.10 | Pali | yes, uboot support i2c |
| 14:40.18 | Pali | do not know if from cmdline |
| 14:40.31 | DocScrutinizer05 | how's "charging" implemented? |
| 14:40.38 | Pali | but code from linux kernel should be easily to reused |
| 14:40.45 | Pali | no charging is implemented |
| 14:40.49 | DocScrutinizer05 | duh! |
| 14:41.04 | Pali | just I do not have time for it |
| 14:41.11 | kerio | i don't think we need charging in uboot |
| 14:41.19 | kerio | beyond the basic flatbat recovery |
| 14:41.26 | Pali | both should be simple, just i2c_read i2c_write |
| 14:41.31 | DocScrutinizer05 | flatbat recovery is in hw |
| 14:41.36 | kerio | exactly |
| 14:41.54 | DocScrutinizer05 | it doesn't fix the no-flashing deadlock |
| 14:42.06 | kerio | yeah but if your uboot is working you can load rescueOS from a µsd |
| 14:42.16 | DocScrutinizer05 | thus proper charging in uBoot would be extremely nice |
| 14:42.30 | DocScrutinizer05 | yes, that's a comlicated but working method |
| 14:42.50 | kerio | now, ACT_DEAD fully implemented in uboot would be cool |
| 14:43.52 | kerio | Pali: does your uboot load a script from microsd if the emmc is hosed? |
| 14:43.54 | DocScrutinizer05 | uBoot already is 95% "ACT_DEAD" |
| 14:44.12 | kerio | DocScrutinizer05: no alarms, though |
| 14:44.18 | DocScrutinizer05 | yep |
| 14:45.01 | DocScrutinizer05 | an alarm elapsing durning uBoot active might go unnoticed |
| 14:45.30 | kerio | Pali: also, can uboot do stuff in the background? |
| 14:45.43 | kerio | or would the charging thing be a separate boot entry |
| 14:46.14 | DocScrutinizer05 | good point, does uBoot "OS" support multitasking? |
| 14:46.32 | kerio | DocScrutinizer05: it's kind of irrelevant, though |
| 14:46.46 | kerio | if you *are* booting something, you'll lose control over bq24k very quickly |
| 14:46.53 | DocScrutinizer05 | yep |
| 14:46.55 | kerio | if you're not, you don't need the charging to be backgrounded |
| 14:47.01 | DocScrutinizer05 | :nod: |
| 14:47.34 | DocScrutinizer05 | anyway afaik uBoot *can* do "multitasking" at least to tickle watchdog |
| 14:48.00 | kerio | now... should the behaviour of uboot started in ACT_DEAD mode be to start charging, or to boot linux? |
| 14:48.47 | DocScrutinizer05 | define >>uboot started in ACT_DEAD mode<< |
| 14:48.55 | kerio | charger plugged in |
| 14:49.24 | kerio | as opposed to pressing the power button |
| 14:49.30 | DocScrutinizer05 | charger plug in should not invoke uBoot menu automatically |
| 14:50.02 | kerio | so still pretend that uboot doesn't exist and boot the default OS? alright |
| 16:23.36 | Pali | kerio: bootmenu script is loaded only from MyDocs eMMC, but if there is no bootmenu script, uboot will pre-generate some menu entries to boot some uboot scripts or kernels from uSD and emmc |
| 16:24.14 | kerio | alright, close enough |
| 16:24.24 | Pali | DocScrutinizer05: do not know if uboot support normal multitasking, but there is something which "force" uboot to call watchdog function |
| 16:24.32 | Pali | which periodically kick watchdog |
| 16:24.48 | kerio | Pali: how powerful is uboot scripting? |
| 16:25.03 | Pali | so for charging, this function can be extended to reset also bq timer |
| 16:25.06 | kerio | can it do a for loop? |
| 16:25.31 | Pali | kerio: it is hush shell |
| 16:26.01 | Pali | IIRC there is while |
| 16:32.53 | DocScrutinizer05 | Pali: similar "watchdog" function would suffice for charging |
| 16:33.54 | DocScrutinizer05 | actually it's the watchdog timer in bq24150 that needs some handling, the rest is pretty simple |
| 16:42.11 | kerio | don't you need actual math |
| 16:42.43 | DocScrutinizer05 | nope, zilch |
| 16:43.52 | DocScrutinizer05 | http://talk.maemo.org/showthread.php?p=658278#post658278 |
| 16:45.53 | DocScrutinizer05 | while sleep 15; do i2cset -y -m 0x80 2 0x6b 0x00 0x80; done |
| 16:46.23 | DocScrutinizer05 | plus a few lines init before that |
| 16:46.42 | DocScrutinizer05 | init by const values |
| 17:00.22 | kerio | oh, is that just a slowish charge up to not quite full battery |
| 17:02.38 | *** join/#maemo-ssu RedW (~redw@89-73-179-171.dynamic.chello.pl) |
| 17:57.28 | DocScrutinizer05 | that depends on init data |
| 17:58.36 | DocScrutinizer05 | i'd recommend 500mA USB current limit and a 4.1V batt end voltage and no charge termination current threshold |
| 18:01.54 | DocScrutinizer05 | unlress uBoot charging was a dedicated mode that can't accept any further commands, in which case I'd use the standard charge end threshold, and check for battery-full with "while [ $(i2cget -y 2 0x6b 0x00) = 0x90 ]..." then boot to linux after that, or shutdown |
| 18:04.17 | DocScrutinizer05 | particularly smart: check statuscode with $(i2cget -y 2 0x6b 0x00) and boot to linux when battery-full, shut down when other "error" caused stop of charging |
| 18:05.07 | DocScrutinizer05 | (other error) e.g. removal / unplug of charger |
| 18:26.12 | *** join/#maemo-ssu sparetire_ (~sparetire@unaffiliated/sparetire) |
| 19:51.03 | *** join/#maemo-ssu LauRoman|Alt (~LauRoman@5-14-95-239.residential.rdsnet.ro) |
| 22:13.01 | *** join/#maemo-ssu APic (apic@apic.name) |