| DocScrutinizer05 | I had even told user about that fact, if usage() been defined anywhere ;-) | 00:02 |
|---|---|---|
| kerio | help() | 00:02 |
| DocScrutinizer05 | obviously it's implicitly defined by import getopts | 00:02 |
| kerio | oh i misunderstood you | 00:02 |
| kerio | DocScrutinizer05: actually, no | 00:03 |
| kerio | that shit won't work | 00:03 |
| kerio | there should be a NameError whenever it reaches that point | 00:04 |
| DocScrutinizer05 | o.O | 00:04 |
| DocScrutinizer05 | nfc | 00:04 |
| DocScrutinizer05 | as mentioned above... "stolen" | 00:04 |
| DocScrutinizer05 | it did what I expected it to do | 00:04 |
| DocScrutinizer05 | CBa about the rest | 00:04 |
| *** _rd has quit IRC | 00:05 | |
| kerio | Die temperature: 571.4 C | 00:07 |
| kerio | ...hm | 00:07 |
| kerio | i dun goofd | 00:07 |
| DocScrutinizer05 | oooh, did I already mention that I have no clue about python? ;-P | 00:07 |
| *** jon_y has joined #maemo-ssu | 00:07 | |
| DocScrutinizer05 | o.O | 00:08 |
| merlin1991 | I could help | 00:08 |
| DocScrutinizer05 | >>registers["TEMP"] = registers["TEMP"] / 4 + 273.15<< looks about correct | 00:09 |
| DocScrutinizer05 | err nope, actually not ;-P | 00:09 |
| DocScrutinizer05 | registers["TEMP"] = registers["TEMP"] / 4 - 273.15 | 00:09 |
| kerio | /o\ | 00:09 |
| * kerio is most definetely *not* a physicist | 00:09 | |
| DocScrutinizer05 | hehe | 00:09 |
| DocScrutinizer05 | YAY, MT is alive! | 00:11 |
| DocScrutinizer05 | UGH! and has way too much time at hand to write too long tmo posts ;-P | 00:11 |
| merlin1991 | DocScrutinizer05: btw getopts is so oldfashioned | 00:16 |
| merlin1991 | the cool kids use argparse these days ;) | 00:16 |
| DocScrutinizer05 | mhm | 00:16 |
| DocScrutinizer05 | maybe that's caused by the code I "stole" is some years old | 00:17 |
| kerio | i'm not quite sure argparse is in 2.5.2 | 00:17 |
| kerio | nope, New in version 2.7. | 00:17 |
| merlin1991 | afaik it's a pure python module, so you should be able to distribute it with your script for < 2.7 :D | 00:18 |
| kerio | it was added for python 3.2, it's probably full of py3kisms | 00:19 |
| kerio | and it barely runs on 2.7 | 00:19 |
| merlin1991 | just adds to the fun ;) | 00:19 |
| *** phr3akDom has joined #maemo-ssu | 00:21 | |
| *** Phr3D has joined #maemo-ssu | 00:24 | |
| *** Phr3D has quit IRC | 00:24 | |
| *** unclouded has joined #maemo-ssu | 00:24 | |
| kerio | my name is Ozymandias, king of kings | 00:25 |
| kerio | look on my works, ye mighty, and despair! | 00:26 |
| kerio | http://pastebin.mozilla.org/2254958 | 00:26 |
| kerio | (merlin1991: yes, i'm using zip instead of izip - add python3 to the repos instead of complaining) | 00:27 |
| merlin1991 | oh shit | 00:27 |
| merlin1991 | that print is evil :D | 00:27 |
| merlin1991 | also not python3 save ;) | 00:27 |
| kerio | why? | 00:27 |
| kerio | ah right | 00:27 |
| kerio | 2to3 will take care of that :P | 00:28 |
| *** phr3akDom has quit IRC | 00:28 | |
| merlin1991 | actually building python3 should not be that hard | 00:28 |
| merlin1991 | at least I've built it in sb2 quite some times already :D | 00:28 |
| kerio | sharing is caring! | 00:29 |
| merlin1991 | wasn't for maemo though | 00:29 |
| kerio | maemo is caring! | 00:29 |
| kerio | merlin1991: http://pastebin.mozilla.org/2254959 fixed | 00:29 |
| kerio | DocScrutinizer05: real men print like ^this | 00:29 |
| merlin1991 | err you only added a comment | 00:30 |
| merlin1991 | and imported print_function | 00:30 |
| kerio | no, there's light green parentheses :) | 00:30 |
| merlin1991 | ah | 00:31 |
| merlin1991 | ninja parentheses | 00:31 |
| merlin1991 | but you're fucked anyways | 00:31 |
| merlin1991 | #!/usr/bin/env python2.7 | 00:31 |
| kerio | heh | 00:31 |
| kerio | can't quite fix that | 00:31 |
| merlin1991 | true that :/ | 00:32 |
| kerio | regardless of what archlinux says, python 3 should *not* be installed as /usr/bin/python | 00:32 |
| *** BCMM has joined #maemo-ssu | 00:34 | |
| *** BCMM has quit IRC | 00:44 | |
| *** xes has quit IRC | 00:49 | |
| *** NIN101 has quit IRC | 00:57 | |
| *** Pali has quit IRC | 00:59 | |
| *** jon_y has quit IRC | 01:09 | |
| *** Martix_ has quit IRC | 01:13 | |
| *** LauRoman has quit IRC | 02:37 | |
| *** M4rtinK has quit IRC | 02:46 | |
| *** unclouded has quit IRC | 02:55 | |
| *** sunny_s has quit IRC | 02:56 | |
| *** sunny_s has joined #maemo-ssu | 03:00 | |
| *** Estel^ has quit IRC | 03:16 | |
| *** Estel_ has joined #maemo-ssu | 03:17 | |
| *** Estel_ has quit IRC | 03:17 | |
| *** Estel_ has joined #maemo-ssu | 03:17 | |
| *** arcean has quit IRC | 03:36 | |
| *** LaoLang_cool has joined #maemo-ssu | 04:12 | |
| *** kolp_ has joined #maemo-ssu | 04:12 | |
| *** kolp has quit IRC | 04:15 | |
| *** LaoLang_cool has quit IRC | 04:18 | |
| *** futpib has joined #maemo-ssu | 04:58 | |
| *** nox- has quit IRC | 05:29 | |
| *** unclouded has joined #maemo-ssu | 05:34 | |
| *** amiconn_ has joined #maemo-ssu | 05:37 | |
| *** amiconn has quit IRC | 05:37 | |
| *** amiconn_ is now known as amiconn | 05:37 | |
| *** DocScrutinizer05 has quit IRC | 06:03 | |
| *** DocScrutinizer05 has joined #maemo-ssu | 06:03 | |
| *** Milhouse has joined #maemo-ssu | 06:08 | |
| *** discopig has quit IRC | 06:37 | |
| *** discopig has joined #maemo-ssu | 06:38 | |
| *** discopig has joined #maemo-ssu | 06:38 | |
| *** M13 has joined #maemo-ssu | 06:49 | |
| *** futpib has quit IRC | 06:56 | |
| *** discopig has quit IRC | 08:06 | |
| *** discopig has joined #maemo-ssu | 08:06 | |
| *** discopig has quit IRC | 08:06 | |
| *** discopig has joined #maemo-ssu | 08:06 | |
| *** kolp_ has quit IRC | 08:17 | |
| *** Pali has joined #maemo-ssu | 08:38 | |
| *** freemangordon has quit IRC | 09:16 | |
| *** freemangordon has joined #maemo-ssu | 09:24 | |
| *** Martix_ has joined #maemo-ssu | 10:19 | |
| *** LauRoman has joined #maemo-ssu | 10:50 | |
| *** Martix_ has quit IRC | 10:55 | |
| *** Martix_ has joined #maemo-ssu | 10:58 | |
| kerio | DocScrutinizer05: i'm not sure why i'm wasting time with this, but do you think that i should keep the raw registers somewhere, and store the converted data somewhere else? | 11:51 |
| kerio | ShadowJK: why is the conversion of ILMD done with 913920 instead of 914000? | 12:01 |
| kerio | oh i see, it's not really 914uVh, it's the high byte of 3.57uVh | 12:14 |
| *** jon_y has joined #maemo-ssu | 12:18 | |
| *** futpib has joined #maemo-ssu | 12:21 | |
| *** NIN101 has joined #maemo-ssu | 12:45 | |
| *** unclouded has quit IRC | 12:49 | |
| *** futpib_ has joined #maemo-ssu | 12:57 | |
| *** futpib has quit IRC | 12:58 | |
| kerio | ah what the hell, "°" isn't ascii? | 13:05 |
| DocScrutinizer05 | man ascii | 13:05 |
| DocScrutinizer05 | man iso_8859-1 | 13:07 |
| DocScrutinizer05 | 260 176 B0 ° DEGREE SIGN | 13:07 |
| kerio | so... it's not ascii :P | 13:08 |
| kerio | anyway, i'm parsing EEPROM too now | 13:09 |
| kerio | is TAPER 102.8mA realistic? | 13:09 |
| DocScrutinizer05 | http://privatepaste.com/b9d424a14d | 13:14 |
| DocScrutinizer05 | haha, I been lazy and haven't decoded TAPER/AEE | 13:16 |
| kerio | yeah >:c | 13:16 |
| kerio | is it called AEE? | 13:16 |
| kerio | it doesn't have a shorthand in the datasheet | 13:16 |
| kerio | i also don't know what to do with MODE and CTRL | 13:18 |
| DocScrutinizer05 | mode and ctrl are really status registers only needed for writing to chip | 13:20 |
| DocScrutinizer05 | you could e.g. reset the chip via those registers | 13:21 |
| DocScrutinizer05 | but we have simpler methods for that ;-P | 13:22 |
| kerio | there's WRTNAC that seems useful | 13:23 |
| DocScrutinizer05 | you'll have to study the datasheet to learn about the last secrets of bq27200 ;-) | 13:24 |
| DocScrutinizer05 | yeah, WRTNAC could be very useful | 13:25 |
| DocScrutinizer05 | dunno why I never investigated it. ShadowJK iirc said it doesn't work, I don't believe that | 13:25 |
| DocScrutinizer05 | of course you need to stop bme before you do anything like that | 13:26 |
| DocScrutinizer05 | because of conflicting I2C access and the commands to write to bq27200 mustn't get interrupted by bme reading from chip | 13:27 |
| *** arcean has joined #maemo-ssu | 13:32 | |
| DocScrutinizer05 | kerio: btw RBI is bq27200's "backup-battery", my early-morning math says: current <1nA, buffer C: 100nF => buffer time >>100s during which bq27200 holds register content when battery removed | 13:53 |
| DocScrutinizer05 | (programming bq27k EEPROM) you need 20..22V for that, applied for 10..100ms to pin10. Current needed: 15mA :-o | 14:06 |
| DocScrutinizer05 | attention! EEPROM can get programmed only TEN times! | 14:08 |
| DocScrutinizer05 | so a hw mod to integrate a prommer is probably a rather nonsensicel execise ;-) | 14:09 |
| kerio | ShadowJK: why doesn't WRTNAC work? | 14:12 |
| ShadowJK | wrtnac? | 14:28 |
| kerio | in bq27k MODE | 14:28 |
| kerio | like, write new NAC to AR, set WRTNAC bit in MODE, set CTRL to magic number | 14:29 |
| ShadowJK | yeah, I've done that | 14:29 |
| kerio | does it work? | 14:30 |
| ShadowJK | ya | 14:31 |
| ShadowJK | nac gets the value from ar, rsoc/csoc is set to 100 and vdq goes high | 14:31 |
| kerio | "high"? | 14:33 |
| ShadowJK | 1 | 14:34 |
| kerio | so it's basically something that you do right once you finish charging? | 14:34 |
| kerio | or... no, actually not | 14:34 |
| kerio | you can do it wherever | 14:34 |
| kerio | just do a calib cycle right afterwards | 14:34 |
| ShadowJK | yes | 14:37 |
| * DocScrutinizer05 curses insane ILMD - if they had chosen 100 instead 2000mAh, it could have learned-up to correct value during a single learning cycle. Restriction to 1/8 change is only for learn-down | 14:42 | |
| DocScrutinizer05 | that's what you get if you buy surplus chips left over from a really huge customer | 14:44 |
| kerio | haha | 14:44 |
| kerio | well, the easiest way to fix that is to make a 2Ah bl-5j | 14:44 |
| kerio | :P | 14:44 |
| DocScrutinizer05 | :-D | 14:44 |
| kerio | is there no restriction on learn-up? | 14:44 |
| DocScrutinizer05 | according to datasheet, there's none | 14:44 |
| kerio | why do people always have problems when calibrating those dual batteries? | 14:45 |
| DocScrutinizer05 | which makes sense | 14:45 |
| DocScrutinizer05 | nfc | 14:45 |
| DocScrutinizer05 | do they? | 14:45 |
| DocScrutinizer05 | I guess that's about bme "calibration" | 14:46 |
| kerio | ShadowJK: could you confirm or deny? | 14:48 |
| DocScrutinizer05 | stskeeps once told me he had a look at bme sourcecode and it made his eyes bleed and he felt an urge to kill himself. IIRC he also said Nokia has no inhouse competence regarding bme which would mean they outsourced it | 14:48 |
| DocScrutinizer05 | bme evidently accessing register #48 of the 6 registers ob bq is another indication about quality of bme code X-P (numbers made up) | 14:50 |
| kerio | #48? | 14:50 |
| DocScrutinizer05 | yeah | 14:50 |
| kerio | what's 48? | 14:50 |
| DocScrutinizer05 | nonexistent XP | 14:50 |
| kerio | better question, what's 48 in hex? | 14:50 |
| DocScrutinizer05 | meh, maybe it been 0x48 | 14:51 |
| DocScrutinizer05 | numbers made up, see? | 14:51 |
| kerio | still RESERVED | 14:51 |
| DocScrutinizer05 | no, this been of bq24150 | 14:51 |
| kerio | i see | 14:51 |
| DocScrutinizer05 | which actually has only 6 or 8 registers | 14:51 |
| kerio | nice | 14:51 |
| DocScrutinizer05 | iirc they wrap around | 14:52 |
| DocScrutinizer05 | incomplete addr decoder | 14:52 |
| DocScrutinizer05 | but that's probably no guaranteed property of the chip | 14:52 |
| DocScrutinizer05 | usually with 6 registers, you have 0x0 .. 0x5 defined, 0x6 and 0x7 undefined, and 0x8 == 0x0 a.s.o | 14:54 |
| DocScrutinizer05 | anyway with a patched i2c.ko we traced all bq24150 access, and bme accessed a register way out of the existing addr range | 14:55 |
| DocScrutinizer05 | Nokia trusting this crap more than community driven efforts to do a bme replacement is pretty embarrassing | 14:58 |
| DocScrutinizer05 | for Nokia, for us it's an insult | 14:58 |
| DocScrutinizer05 | maybe they got a contract with a subcontractor that includes full liability for any mass recall and killed users, so I'd maybe forgive them for not wanting to touch it | 15:00 |
| kerio | hmm, will setting NAC also set LMD? | 15:09 |
| DocScrutinizer05 | most likely not | 15:11 |
| kerio | but is NAC used when calibrating? | 15:11 |
| DocScrutinizer05 | which is what relativates the usefulness | 15:11 |
| kerio | otherwise, that WRTNAC is kinda useless | 15:12 |
| kerio | even from a manifacturer's point of view | 15:12 |
| DocScrutinizer05 | I guess it's meant to get used for batteries with multicells with balanced charging, or sth like that | 15:13 |
| DocScrutinizer05 | you could adjust the N900 bq27200 to match the real current capacity of a newly inserted battery | 15:13 |
| DocScrutinizer05 | given you know what capacity this battery is at right at this moment | 15:14 |
| DocScrutinizer05 | look, you got a spare battery with you that you know is 100% charged. Swapping batteries would leave your bq27200 at 10% or 0% or whatever your depelted battery been at | 15:15 |
| kerio | oic | 15:15 |
| DocScrutinizer05 | s/with/which/ | 15:15 |
| infobot | DocScrutinizer05 meant: look, you got a spare battery which you that you know is 100% charged. Swapping batteries would leave your bq27200 at 10% or 0% or whatever your depelted battery been at | 15:15 |
| DocScrutinizer05 | meh, no | 15:15 |
| DocScrutinizer05 | wait, what did ShadowJK say? | 15:18 |
| DocScrutinizer05 | <ShadowJK> nac gets the value from ar, rsoc/csoc is set to 100 and vdq goes high | 15:18 |
| DocScrutinizer05 | means you set a certain NAC as 100% and start a valid learning cycle. Depleting your swappend in battery to EDV1 would learn the capacity of that new battery | 15:19 |
| kerio | but will it use the NAC you set as a starting point? | 15:20 |
| DocScrutinizer05 | yes, starting point of rsoc/csoc to calculate TTE and % | 15:20 |
| DocScrutinizer05 | after reaching EDV1 it will adjust due to measured coloumb that the battery delivered | 15:21 |
| DocScrutinizer05 | so e.g setting NAC to 100mAh will make your battery display drop to 0% rather rapidly, then it stays there for a long while til EDV1 is reached, and at that point LMD will get set to actual measured total capacity during last discharge aiui | 15:23 |
| DocScrutinizer05 | while setting NAC to 3000mAh will cause your device shutdown at capacity-display=60% | 15:24 |
| DocScrutinizer05 | or rather, it first will jump from 60% to 0% at reaching EDV1, then it completes learning cycle, then it may shut down | 15:25 |
| DocScrutinizer05 | kerio: all roger? | 15:26 |
| kerio | yeah | 15:26 |
| DocScrutinizer05 | fine | 15:26 |
| kerio | it's still unclear to me if that can be used to get around the learn-down limits | 15:26 |
| DocScrutinizer05 | no it can't | 15:26 |
| DocScrutinizer05 | learn-down linitation is during storing new LMD to LMD-register. It checks for old content and if that's way higher than new content, it will adjust new content to 7/8 of old content, then store it to LMD-register | 15:28 |
| DocScrutinizer05 | at least that's my take on it | 15:29 |
| DocScrutinizer05 | iirc there is NO way to store a new arbitrary value to LMD | 15:29 |
| DocScrutinizer05 | except copy ILMD from EEPROM to register | 15:30 |
| kerio | but you can only program the EEPROM 10 times :( | 15:30 |
| DocScrutinizer05 | yep | 15:30 |
| DocScrutinizer05 | the bq27x00 are meant for integration into battery pack. Nokia abused them | 15:31 |
| DocScrutinizer05 | and if their EE were alert, they had programmed ILMD to 100 | 15:32 |
| DocScrutinizer05 | but probably they simply didn't care since the whole thing been meant to read out voltage and current-now only | 15:32 |
| DocScrutinizer05 | they simply thought the rest of data was useless in that particular circuit anyway | 15:33 |
| DocScrutinizer05 | but then they could've saved the buffer capacitor at BRI X-P | 15:34 |
| DocScrutinizer05 | well, even Nokia EE are not inerrant | 15:36 |
| ShadowJK | or then they really meant to use a bigger battery | 15:42 |
| ShadowJK | or set it high enough that NAC would never reach 0, so that they could read nac once a minute to derive current now instead of reading AI every 5s | 15:44 |
| kerio | how about just using the chip for what it was, instead? :s | 15:45 |
| DocScrutinizer05 | that would have required an alternative battery to the BL-5J | 15:47 |
| DocScrutinizer05 | with bq27000 integrated | 15:47 |
| DocScrutinizer05 | see openmoko gta02 smartbattery | 15:48 |
| DocScrutinizer05 | *we* (openmoko) were able to pull that off | 15:48 |
| DocScrutinizer05 | Nokia obviously been reluctant | 15:49 |
| kerio | maybe it was a good thing, though | 15:49 |
| kerio | BL-5Js are used in quite a lot of nokia phones | 15:50 |
| kerio | the 5800 is quite popular | 15:50 |
| DocScrutinizer05 | http://maemo.cloud-7.de/share-service/20130329_001.jpg DAMN! | 15:57 |
| kerio | haha | 15:58 |
| DocScrutinizer05 | btw it's fully compatible to bp-5c | 15:58 |
| kerio | you trolly you | 15:58 |
| kerio | also, 1200mAh? | 15:58 |
| DocScrutinizer05 | Nokia could've done same for BL-4J | 15:58 |
| kerio | it's... smaller than bl-5j, isn't it | 15:58 |
| DocScrutinizer05 | err BL-5J | 15:58 |
| DocScrutinizer05 | way smaller, that's why I uttered "DAMN" | 15:59 |
| kerio | i meant capacity-wise | 15:59 |
| kerio | the current bl-5js are 1400 | 15:59 |
| DocScrutinizer05 | 1200mAh, bq27000 integrated, mechanically compatible to Nokia BP-5C | 15:59 |
| *** jon_y has quit IRC | 15:59 | |
| *** jon_y has joined #maemo-ssu | 16:00 | |
| DocScrutinizer05 | well, that GTA02 battery is like 5 years old | 16:00 |
| DocScrutinizer05 | and it actually had ~1200mAh, according to LMD | 16:01 |
| ShadowJK | bl-5c started out as 800mAh, iirc, and technolgy improvements have taken it further since :) | 16:02 |
| *** kolp has joined #maemo-ssu | 16:04 | |
| DocScrutinizer05 | http://wiki.openmoko.org/wiki/Battery_Questions_and_Answers#Do_other_BL-5.2F6C_compatible_batteries_fit.3F | 16:06 |
| *** Martix_ has quit IRC | 16:07 | |
| kerio | i have no good way of doing two's complement in python :( | 16:09 |
| kerio | i need a 3-bit-wide datatype | 16:09 |
| DocScrutinizer05 | huh? | 16:11 |
| kerio | to parse BOFF | 16:11 |
| kerio | (in python) | 16:11 |
| DocScrutinizer05 | how about basic integer math and boolean? | 16:11 |
| kerio | ...i know how to do that, i didn't /want/ to if there was a better way | 16:12 |
| DocScrutinizer05 | hehe | 16:12 |
| DocScrutinizer05 | sure there is (dunno if in python though): enum | 16:12 |
| kerio | i don't think there's a good way that lets you avoid checking the sign bit | 16:12 |
| DocScrutinizer05 | you just need to normalize/mask the relevant bits out of your original 8/16bit value | 16:13 |
| DocScrutinizer05 | If python can't do boolean AND / OR, you're probably in a pinch | 16:14 |
| kerio | don't be silly | 16:15 |
| kerio | it's not lua | 16:15 |
| DocScrutinizer05 | you have to do integer math then, which becomes nasty | 16:15 |
| kerio | [0, 1, 2, 3, -4, -3, -2, -1][(bq27k["PKCFG"] & 0b00011100) >> 2] | 16:15 |
| kerio | :D | 16:15 |
| DocScrutinizer05 | lua? meh! don't know lua to make sense of what you said | 16:15 |
| kerio | lua has a single "number" type | 16:16 |
| kerio | and it's float | 16:16 |
| DocScrutinizer05 | great | 16:16 |
| kerio | "In the interest of simplicity" | 16:16 |
| DocScrutinizer05 | idiots | 16:16 |
| DocScrutinizer05 | well, maybe they have a byte or word type then | 16:17 |
| kerio | nope | 16:17 |
| DocScrutinizer05 | ypur codeline above is puzzling | 16:18 |
| kerio | access the ((bq27k["PKCFG"] & 0b00011100) >> 2)th element of the [0, 1, 2, 3, -4, -3, -2, -1] list | 16:18 |
| DocScrutinizer05 | I gather that's some special list operation stuff in python? | 16:18 |
| kerio | list access is hardly special | 16:18 |
| DocScrutinizer05 | yeah | 16:18 |
| DocScrutinizer05 | well, the only lists I ever use are linked lists ;-D | 16:19 |
| DocScrutinizer05 | single or double linked | 16:20 |
| kerio | fun fact: "list" in python is, internally, an auto-resizing array | 16:20 |
| DocScrutinizer05 | yeah | 16:20 |
| DocScrutinizer05 | think I heard about that | 16:20 |
| kerio | the only linked list i can think of in python is collections.deque | 16:20 |
| DocScrutinizer05 | I seem to recall lists in python perform like my ass with obstipation | 16:22 |
| kerio | when doing what? | 16:22 |
| DocScrutinizer05 | when doing usual list operations like instantiate, append, insert, delete | 16:23 |
| kerio | insert and delete aren't usual array operations | 16:23 |
| DocScrutinizer05 | whatever, I seem to recall performance optimizations by factor 1000 over the whole program, by simply an experienced coder replacing some list crap in some newbie's python code by basic datatypes | 16:25 |
| kerio | wrong datatypes tend to do that, yeah | 16:26 |
| kerio | also, when you have dict, everything *does* look like a hashmap | 16:27 |
| DocScrutinizer05 | but anyway, for this particular project it doesn't matter I guess | 16:28 |
| DocScrutinizer05 | >> EDV detection has a dynamically adjusted delay of up to 21.5 s with RSOC ≥ 6% an ddown to 3 s when RSOC = 0%.<< | 16:32 |
| *** _rd has joined #maemo-ssu | 16:34 | |
| DocScrutinizer05 | kerio: ^^^ is a scheme that's probably adoptable to bme-replacement shutdown-threshold-detection as well | 16:35 |
| DocScrutinizer05 | at very least it gives a hind about minimum guard time to be used for that detection in bme-repl | 16:36 |
| DocScrutinizer05 | hint* | 16:36 |
| DocScrutinizer05 | minimum guard time is 30s | 16:37 |
| DocScrutinizer05 | kerio: FYI: >>measured LMD value (for a learning cycle) is determined by *measuring* the *capacity* *delivered* from the battery from NAC = LMD (aka "full") until VOLT = EDV1, plus LMD/16 to account for the 6.25% capacity remaining below the EDV1 threshold.<< | 16:40 |
| *** arcean_ has joined #maemo-ssu | 16:41 | |
| *** arcean has quit IRC | 16:41 | |
| *** futpib_ has quit IRC | 16:44 | |
| *** futpib_ has joined #maemo-ssu | 16:47 | |
| DocScrutinizer05 | kerio: actually LMD gets not calculated from NAC at all, there's obviously a dedicated computation register called Learning Count Register (LRC) for that | 16:49 |
| DocScrutinizer05 | see "figure 4" | 16:50 |
| *** _rd has quit IRC | 16:57 | |
| kerio | hrmpf, how should i store DCOFF? | 16:57 |
| *** sunny_s has quit IRC | 17:06 | |
| DocScrutinizer05 | what's DCOFF? | 17:09 |
| DocScrutinizer05 | nm | 17:09 |
| DocScrutinizer05 | what do you mean by "how to store"? | 17:18 |
| kerio | it's a value that can be 0, C/2, C/4, C/8 | 17:18 |
| DocScrutinizer05 | yes | 17:18 |
| kerio | i decided that i'm lazy and i'm actually storing it as 0, 1, 2, or 3 | 17:18 |
| DocScrutinizer05 | I'd store it as 0, 0.5, 0.25, 0.125 | 17:19 |
| DocScrutinizer05 | or at very least as 1,2,3,8 | 17:20 |
| DocScrutinizer05 | err | 17:21 |
| DocScrutinizer05 | pretty inconvenient | 17:21 |
| DocScrutinizer05 | let's put this straight: it's the current above which CAC starts to differ from NAC | 17:21 |
| DocScrutinizer05 | it's calculated as percent of LMD, in ampere | 17:22 |
| DocScrutinizer05 | there are the possible values 0%, 12.5%, 25%, 50% | 17:23 |
| kerio | clearly it's a job for fractions.Fraction | 17:25 |
| kerio | but actually no, floats represent binary fractions exactly :) | 17:26 |
| kerio | The equation for programming the value is: | 17:27 |
| kerio | TOFF[3:0] = Design Temp Compensation Offset (°K) – 273 | 17:28 |
| kerio | dafuq | 17:28 |
| kerio | so... Design Temp Compensation Offset (°C) then | 17:28 |
| DocScrutinizer05 | so for AI > LMD * ^^^DCOFF%, the compensated AI gets calculated as CAI = AI + ((AI - (AI * DCOFF%)) * (0.39% * DCGN)) | 17:28 |
| kerio | it's 0 for the n900, isn't it? | 17:29 |
| DocScrutinizer05 | for me DCOFF is 6 | 17:29 |
| DocScrutinizer05 | and DCGN is 25 | 17:29 |
| kerio | oh | 17:30 |
| DocScrutinizer05 | sorry | 17:30 |
| DocScrutinizer05 | DCOF is 2 | 17:30 |
| DocScrutinizer05 | and my formula above seems also not quite correct | 17:31 |
| DocScrutinizer05 | so for AI > LMD * ^^^DCOFF%, the compensated AI gets calculated as CAI = AI + ((AI - (LMD * DCOFF%)) * (0.39% * DCGN)) | 17:32 |
| DocScrutinizer05 | the term AI - (LMD * DCOFF%) never must be negative | 17:33 |
| DocScrutinizer05 | this is guaranteed by applying the compensation only when AI > LMD * ^^^DCOFF% | 17:34 |
| kerio | DCOFF 0.25, DCGN 6.25% | 17:39 |
| DocScrutinizer05 | if [ ${AI} -ge $(( LMD * DCOFF_IN_permille / 1000 )) ]; then CAI = ... | 17:39 |
| DocScrutinizer05 | yes | 17:39 |
| DocScrutinizer05 | so I'd store it like 250 to DCOFF_IN_permille | 17:40 |
| kerio | nope, 0.25 is perfectly fine :) | 17:40 |
| kerio | or maybe percentage, like everything else | 17:40 |
| DocScrutinizer05 | err btw why 6.25% DCGN? | 17:41 |
| kerio | DCGN[5:0] = 2.56 * Design discharge compensation gain % | 17:41 |
| DocScrutinizer05 | ~66/4 | 17:41 |
| infobot | 16.5 | 17:41 |
| kerio | ~66/2.56 | 17:42 |
| infobot | 25.78125 | 17:42 |
| kerio | wat | 17:42 |
| kerio | ~25/2.56 | 17:42 |
| infobot | 9.765625 | 17:42 |
| kerio | i don't know why 6.25% DCGN | 17:42 |
| DocScrutinizer05 | ummm | 17:42 |
| DocScrutinizer05 | 66=0b01100110 | 17:43 |
| DocScrutinizer05 | >>2 | 17:43 |
| DocScrutinizer05 | 0b00011001 | 17:43 |
| DocScrutinizer05 | 9+16=25 | 17:44 |
| DocScrutinizer05 | ~25*0.39 | 17:44 |
| infobot | 9.75 | 17:44 |
| DocScrutinizer05 | 0x7E: 66 DCOMP Discharge Rate Compensation Constants | 17:45 |
| kerio | that's split in two | 17:45 |
| DocScrutinizer05 | BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT 0 | 17:46 |
| DocScrutinizer05 | NAME DCGN[5] DCGN[4] DCGN[3] DCGN[2] DCGN[1] DCGN[0] DCOFF[1] DCOFF[0] | 17:46 |
| DocScrutinizer05 | thus >>2 | 17:46 |
| DocScrutinizer05 | DCGN[5:0]=0b00011001 | 17:47 |
| DocScrutinizer05 | =0x19=25 | 17:47 |
| kerio | 66 == 0b01000010 | 17:48 |
| DocScrutinizer05 | WUT? | 17:48 |
| DocScrutinizer05 | dang!! | 17:48 |
| DocScrutinizer05 | I need more coffee | 17:48 |
| DocScrutinizer05 | of course you're right | 17:49 |
| kerio | ~kerio | 17:49 |
| infobot | it has been said that kerio is <DocScrutinizer05> kerio is right | 17:49 |
| DocScrutinizer05 | ~19*0.39 | 17:51 |
| infobot | 7.41 | 17:51 |
| DocScrutinizer05 | I really need more coffee | 17:53 |
| DocScrutinizer05 | and a better calculator, kcalc is da crap | 17:54 |
| DocScrutinizer05 | so finally 0x7e:66 means DCGN=16dez | 17:57 |
| DocScrutinizer05 | ~16*0.39 | 17:57 |
| infobot | 6.24 | 17:57 |
| DocScrutinizer05 | so finally 0x7e:66 means DCOFF=1dez which maps to C/2 aka 50% | 17:59 |
| kerio | DCOFF = 2 which maps to C/4 | 18:00 |
| DocScrutinizer05 | yes, again | 18:00 |
| DocScrutinizer05 | a pair value can't have LSB=1 | 18:01 |
| DocScrutinizer05 | seems I should go back to my bed | 18:01 |
| kerio | hm, i'm missing the energy stuff in the output | 18:02 |
| DocScrutinizer05 | *shrug* | 18:02 |
| DocScrutinizer05 | it's a simple multiplication I'd guess | 18:03 |
| kerio | they're stored in separate registers though | 18:03 |
| kerio | SAE and AP | 18:03 |
| DocScrutinizer05 | yeah sure | 18:03 |
| kerio | but yeah, it's a multiplication | 18:04 |
| DocScrutinizer05 | ~1245 mAh / 4 | 18:04 |
| DocScrutinizer05 | ~1245 / 4 | 18:04 |
| infobot | 311.25 | 18:04 |
| kerio | "The host system has read-only access to this register pair." | 18:04 |
| kerio | if only | 18:04 |
| kerio | i2cset a trillion joules | 18:04 |
| kerio | and solve the energy crisis | 18:05 |
| kerio | ok, let's check for joergthon compatibility | 18:06 |
| kerio | DocScrutinizer05: http://pastebin.mozilla.org/2256926 | 18:06 |
| *** _rd has joined #maemo-ssu | 18:06 | |
| DocScrutinizer05 | kerio: moeoeoep :o) 0x7C: 67 PKCFG Pack Configuration Values | 18:07 |
| DocScrutinizer05 | DCFIX Fixed discharge compensation == 1 | 18:07 |
| DocScrutinizer05 | >>If this bit is set to 1, the device assumes a fixed value of 0x42 for DCOMP, giving a discharge rate compensation gain of 6.25% with a compensation threshold of C/4. << | 18:09 |
| kerio | also, my PKCFG is 67, not 66 | 18:09 |
| DocScrutinizer05 | 0x7E: 66 DCOMP Discharge Rate Compensation Constants, | 18:10 |
| kerio | what the hell, why is my TCFIX set | 18:10 |
| DocScrutinizer05 | 0x7C: 67 PKCFG Pack Configuration Values | 18:10 |
| kerio | oic | 18:10 |
| kerio | yeah but don't get distracted, check for SyntaxComplicated | 18:11 |
| *** M13 has quit IRC | 18:16 | |
| DocScrutinizer05 | well, your bq27k["DCOFF"] will probably fail for 0% | 18:17 |
| *** _rd has quit IRC | 18:18 | |
| DocScrutinizer05 | well, maybe not | 18:18 |
| *** M13 has joined #maemo-ssu | 18:19 | |
| DocScrutinizer05 | anyway DCFIX = 1 means 0x7e is an identification byte only, which makes me start to wonder what ID "66" means | 18:23 |
| DocScrutinizer05 | kerio: s/ # registers for us/ # registers for us, which actually is a rather nonsensical thing but done anyway/ | 18:29 |
| DocScrutinizer05 | kerio: otherwise, this code makes me love python | 18:31 |
| DocScrutinizer05 | I'd actually be temped to do what I always do: "steal" it and hack in my nasty little tweaks | 18:32 |
| DocScrutinizer05 | but then, it's based on sysfs nodes so basically useless for my purposes | 18:33 |
| DocScrutinizer05 | W*T*F?!! | 18:39 |
| DocScrutinizer05 | > >CYCT is the cycle count since a full reset. A full reset clears this register. Each count indicates a cumulativ edischarge equal to the Design Capacity (256 * ILMD). The host system has read-only access to this register pair.<< ILMD!!! Design capacity! | 18:39 |
| DocScrutinizer05 | so we need to compensate this by CCYCT = CYCT / LMD * ILMD | 18:41 |
| kerio | no we don't | 18:41 |
| kerio | while a cycle counter might be cute to have, bq27k will still use the real CYCL | 18:41 |
| DocScrutinizer05 | for a meaningful value to display to user we do, for sysfs nodes exposing raw register values we obviously don't since there's no CCYCT register anyway | 18:42 |
| DocScrutinizer05 | WAAAAIIIT | 19:09 |
| DocScrutinizer05 | reading thru "Programming the EEPROM" section, it occurs to me that you *can* overwrite values in EEPROM (like ILMD) with a new value. It needs the programming voltage pulse only for flashing that to EEPROM to make it persistent across chip resets | 19:12 |
| *** M13 has quit IRC | 19:13 | |
| ShadowJK | oh? | 19:13 |
| DocScrutinizer05 | maybe I hope for too much, but it *might* work to write a new value to e.g. ILMD just like to any other RAM register, and it *might* stay on that value until next chip reset | 19:13 |
| ShadowJK | can we change edv1 :) | 19:13 |
| kerio | :O | 19:13 |
| *** M13 has joined #maemo-ssu | 19:13 | |
| kerio | DocScrutinizer05: chip reset, or full reset? | 19:14 |
| ShadowJK | You mean you hope it's got sram, and copies eeprom to sram on start? | 19:14 |
| ShadowJK | instead of always reading from eeprom | 19:14 |
| DocScrutinizer05 | the recommended procedure to flashh EEPROM: "enable, write data to X, *read data from X*, apply flash pulse" suggests to me that the data is sticky in that location at least for one read | 19:15 |
| DocScrutinizer05 | if it works for one read, why should it fail for 2nd read? | 19:16 |
| DocScrutinizer05 | ShadowJK: exactly | 19:16 |
| kerio | why "read data from X"? | 19:16 |
| DocScrutinizer05 | because it's written in datasheet | 19:16 |
| kerio | just read it once? or read and check that it's the written one? | 19:17 |
| kerio | anyway, /me will not risk his only n900 | 19:17 |
| DocScrutinizer05 | see p.23 "Programming the EEPROM" | 19:17 |
| kerio | DocScrutinizer05: use your 74th n900 maybe | 19:17 |
| DocScrutinizer05 | DANG!! | 19:18 |
| DocScrutinizer05 | chip does POR on leaving programming mode | 19:18 |
| DocScrutinizer05 | it's neither defined in DS what happens when writing to the EEPROM locations without enabling programming mode, nor is there any warning that programming mode MUST get exited by > >Write data 0x00 t oaddress 0x6E<< or otherwise chip wouldn't work | 19:20 |
| *** futpib__ has joined #maemo-ssu | 19:21 | |
| *** futpib_ has quit IRC | 19:22 | |
| DocScrutinizer05 | so we can test 2 possible scenarios: try writing to ILMD without enabling prog mode by > >Write data 0xDD to address 0x6E<< and see if that changes anything. And second: > >Write data 0xDD to address 0x6E<< then write new value to ILMD or EDV1 and see how chip behaves when we do NOT > >Write data 0x00 t oaddress 0x6E<< after that | 19:23 |
| DocScrutinizer05 | btw there's a huge range of "RESERVED" register addr that might (and actually do) hold valuable data and might even be writable | 19:25 |
| kerio | DocScrutinizer05: well, nothing *can* go wrong, right? | 19:26 |
| kerio | at worst you unplug the battery and wait some time | 19:26 |
| DocScrutinizer05 | yes, that's what I think, unless you write to RESERVED registers and something terrible goes wrong inside chip (extremely unlikely, like "I would bet my life on it, when I could win a 1000$") | 19:28 |
| DocScrutinizer05 | nevertheless, act on own peril, no warranties | 19:29 |
| DocScrutinizer05 | if an aborted "programming" sequence, even without VPP applied, could go awry, the datasheet for sure should have a HUGE warning about that. And a pointer to the scientific report explaining that miracle | 19:31 |
| kerio | DocScrutinizer05: was your idea to change eeprom parameters and then do a full reset? | 19:32 |
| DocScrutinizer05 | no | 19:32 |
| kerio | how is the chip supposed to "reload" the parameters then? | 19:33 |
| DocScrutinizer05 | a full reset restores EEPROM parameters to ram, and we can't change EEPROM values without applying VPP | 19:33 |
| DocScrutinizer05 | while normal operation would most likely use the ram register copies of the values | 19:34 |
| kerio | hm | 19:34 |
| DocScrutinizer05 | for ILMD that's rather useless anyway | 19:34 |
| kerio | i was hoping that the ram copies would persist until a power off | 19:34 |
| DocScrutinizer05 | since ILMD gets used only when doing a full reset | 19:34 |
| DocScrutinizer05 | AAAAND for cycle calculation ;-D | 19:35 |
| DocScrutinizer05 | kerio: power off *is* the usual cause for a full reset | 19:35 |
| kerio | there is a real full reset | 19:35 |
| kerio | write the appropriate bits to MODE and CTRL | 19:36 |
| DocScrutinizer05 | yeah, but what for?? | 19:36 |
| kerio | because we could hope it's less full than removing power to the chip :) | 19:36 |
| DocScrutinizer05 | meh, it isn't | 19:36 |
| DocScrutinizer05 | why the heck do you want to reset anyway? | 19:36 |
| kerio | because you just "wrote" a new ILMD, maybe :D | 19:37 |
| DocScrutinizer05 | heck!!! ILMD is only useful for full reset aka power-off. We don't need it for anything else (except cycle calculation) | 19:38 |
| DocScrutinizer05 | and for cycle calculation I guess we don't need any reset to make a change in ILMD get effective | 19:38 |
| kerio | battery swapping? | 19:38 |
| * DocScrutinizer05 shakes head | 19:38 | |
| DocScrutinizer05 | WHAT?? why? what are you trying to get done? | 19:39 |
| ShadowJK | i thought cycles were counted against lmd | 19:39 |
| DocScrutinizer05 | no, ILMD :-S | 19:39 |
| kerio | DocScrutinizer05: write known LMD and NAC right after you inserted the new battery | 19:39 |
| DocScrutinizer05 | [2013-03-29 17:39:46] <DocScrutinizer05> > >CYCT is the cycle count since a full reset. A full reset clears this register. Each count indicates a cumulativ edischarge equal to the Design Capacity (256 * ILMD). The host system has read-only access to this register pair.<< ILMD!!! Design capacity! | 19:40 |
| kerio | "live" battery swap with correct-ish capacity measurement | 19:40 |
| DocScrutinizer05 | why bother about LMD when swapping battery? | 19:40 |
| DocScrutinizer05 | and how's that related to ILMD? | 19:41 |
| DocScrutinizer05 | which evidently we can't change for battery swap | 19:42 |
| DocScrutinizer05 | > >The POR status bit is set to 1 by the bqJUNIOR following a Power on Reset. This is a flag to th ehost that VCC was less than V(POR) and caused a reset. The bit is cleared to 0 by the bqJUNIO Rwhen a full charge condition is reached or it may be cleared by the host. The bit is also cleared to 0after exiting from EEPROM programming or ship. The host may set this bit, but it has no effect o nthe bqJUNIOR operation. The user should | 19:44 |
| DocScrutinizer05 | keep this bit set or cleared as desired when other bits i nthis register are set.<< | 19:44 |
| DocScrutinizer05 | ^^^ useless (for this purpose) | 19:44 |
| DocScrutinizer05 | (but actually I think chip does no full reset on exiting prog mode. I confused stuff here) | 19:45 |
| kerio | where's that status bit? MODE? | 19:45 |
| DocScrutinizer05 | > >Full reset. This command bit requests a full reset. A full reset reinitializes all RAM registers ,including the NAC, LMD, and FLAGS registers. This command is intended for manufacturing use.<< | 19:46 |
| DocScrutinizer05 | ^^^ most probably including reading back EEPROM values to RAM | 19:46 |
| DocScrutinizer05 | if you want to write new values to LMD (not ILMD) I bet you have to write to one of the RESERVED registers. If they are not write protected | 19:48 |
| DocScrutinizer05 | I bet those are the complete memory of that microcontroller mapped to I2C addresses | 19:49 |
| DocScrutinizer05 | incl timer, auxiliary registers, PC, SP, stack and all | 19:50 |
| kerio | why would they be i2c-writable? | 19:51 |
| DocScrutinizer05 | because nobody bothered to make them r/o, if we're lucky | 19:52 |
| DocScrutinizer05 | read-only just might mean that on next internal program cycle those registers are refreshed to a calculated/derived value and nobody cares about what you write to them | 19:54 |
| *** kolp has quit IRC | 19:55 | |
| DocScrutinizer05 | hey, this is I2C, drivers are supposed to act according to DS specs. Why would a chip manuf bother to spend work, chip real estate, money, yield, on implementing a write protection for registers marked "RESERVED"? | 19:56 |
| ShadowJK | probably temporary storage for calculations and stuff | 20:00 |
| kerio | clearly we should port uClinux to the bq27200 | 20:05 |
| *** arcean_ is now known as arcean | 20:12 | |
| *** Pali has quit IRC | 20:21 | |
| *** Pali has joined #maemo-ssu | 20:22 | |
| *** andre__ has quit IRC | 20:33 | |
| *** kolp has joined #maemo-ssu | 20:43 | |
| *** andre__ has joined #maemo-ssu | 21:02 | |
| *** M4rtinK has joined #maemo-ssu | 21:07 | |
| *** andre__ has quit IRC | 21:09 | |
| *** Estel_ has quit IRC | 21:21 | |
| *** Estel^ has joined #maemo-ssu | 21:22 | |
| *** Estel^ has joined #maemo-ssu | 21:22 | |
| Estel^ | ShadowJK, kerio, DocScrutinizer05, there is a limit for capacity-up learning | 21:22 |
| *** Vlad_on_the_road has joined #maemo-ssu | 21:23 | |
| Estel^ | if, for example, you would have ilmd as 100 mA, after 100 mA used capacity and vdq=1 would stay for some time/mAh spent... | 21:23 |
| Estel^ | and, after certain ammount of Mah spent or time in 6%, vdq got spoiled to 0 | 21:23 |
| Estel^ | thats why people calibrating for dual batteries need to go by steps | 21:23 |
| Estel^ | from my experience, capacity gain of 800 mAh is about ok for single cycle, duinno if it depends on LMD (so % of last discharge) | 21:24 |
| Estel^ | from ~1300, one may jump to ~2300 max | 21:24 |
| Estel^ | er, in fact it might have been 1300->1800->2300, so 500 mA gain | 21:25 |
| Estel^ | haven't done it for some time, usually I'm jumping from 2048 mAh to ~3400 mAh in 2 or 3 cycles | 21:25 |
| Estel^ | well, two, as it's definitelly possible to go from 2000 mAh to 2800 mAh | 21:25 |
| Estel^ | so it may be % related - 1300 allow only ~650 mAh gain, 2000 doesn't have problem with 1000 probably, I suspect (assumption) max 50% gain in caapcity, since vdq get spoiled | 21:26 |
| Estel^ | definitelly iot's higher than learn-down limit, but it's there too, for 100% | 21:26 |
| Estel^ | best wishes to some responsible chanop, that keeps my main registered nick (Estel_) at +q state, btw. Kudos. | 21:27 |
| * Estel^ waves and goes for some pleasant RL | 21:27 | |
| *** M13 has quit IRC | 21:31 | |
| *** futpib__ has quit IRC | 21:49 | |
| *** nox- has joined #maemo-ssu | 21:53 | |
| *** sunny_s has joined #maemo-ssu | 22:11 | |
| *** ChanServ sets mode: +o DocScrutinizer05 | 22:14 | |
| *** DocScrutinizer05 sets mode: -b Estel_!*@* | 22:15 | |
| *** DocScrutinizer05 sets mode: -q Estel_!*@* | 22:15 | |
| *** ChanServ sets mode: -o DocScrutinizer05 | 22:15 | |
| *** sunny_s has quit IRC | 22:38 | |
| *** unclouded has joined #maemo-ssu | 22:49 | |
| Estel^ | <#maemo-ssu> [21:15] DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) changed mode: -b Estel_!*@* | 22:51 |
| Estel^ | <#maemo-ssu> [21:15] DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) changed mode: -q Estel_!*@* | 22:51 |
| Estel^ | how funny. you're luycky, that I have sense of humour and self-distance ;) | 22:51 |
| Estel^ | lucky, even | 22:51 |
| Estel^ | kerio, following our conversation about u-boot - I'm all reeady for it, got rid of multiboot, ensured that /sbin/preinit is default one (well, with Mentalist's Traceur's recovery shell, but that's irrelevant here), got flash-ask installed, u-boot-tools, u-boot bootimage, ignore u-boot flasher | 22:52 |
| Estel^ | wanting to go the way you've described - only u-boot in nand, reading kernels. Now, i've been through documentation, but it's a mess, it speaks about writing own scripts for u-boot bootmenu, then, few lines later, warnj to nbot write own scripts... | 22:53 |
| DocScrutinizer05 | listen buddy, if you got something to complain no matter what I'm doing, then i happily will revert everything | 22:53 |
| DocScrutinizer05 | pathetic troll | 22:54 |
| Estel^ | DocScrutinizer05, sorry, in my mind -b was +b | 22:54 |
| Estel^ | so i took it for -q +b, which would be quite funny | 22:54 |
| Estel^ | apologies. | 22:54 |
| Estel^ | doesn't need to call names, really *gives DocScrutinizer05 some sweet pink flowers with Satan inside* | 22:55 |
| *** zogg_ has joined #maemo-ssu | 22:55 | |
| *** LauRoman has quit IRC | 22:56 | |
| Estel^ | going back to u-boot case - simple question, how to properly generate scripts for u-boot menu, that will make it boot my kp52 as default one without u-boot menu, and display u-boot menu only if <something> is done | 22:57 |
| Estel^ | to call for it | 22:57 |
| *** ZogG has quit IRC | 22:57 | |
| DocScrutinizer05 | ever wondered how often you suffer from similar distortions of your reality and nobody helps you out on it? | 22:57 |
| Estel^ | as for u-boot image flashed to nand, I'll do it either from device or from desktop flasher, that part is clear | 22:57 |
| Estel^ | DocScrutinizer05, all perceived reality is a disortion of our brain ;) | 22:58 |
| Estel^ | thats why we get along with some people very well, and some (me & you) just don't transmit on same frequency, no matter how hard trying. Keeping ZEN is only solution ;) | 22:58 |
| Estel^ | people mean well, pink flowers, etc. | 22:59 |
| Estel^ | I/m pretty sure that we would be in much better terms on IRc if you wouldn't have chanop to (ab)use, but that's different thing | 23:00 |
| kerio | Estel^: if you don't mind the "boot from attached kernel" entry that doesn't work in the menu, it's just a matter of doing ln -s /etc/bootmenu.d/*power* /etc/default/bootmenu.item | 23:01 |
| kerio | and then u-boot-update-bootmenu | 23:01 |
| Estel^ | thanks, sounds simple enough. And if I mind it? | 23:01 |
| kerio | then your best bet is to edit away the part that adds the attachboot entry in /ust/bin/u-boot-update-bootmenu | 23:01 |
| Estel^ | ok, device will boot normally, and show u-boot menu only when what? keyboard slided-out? | 23:02 |
| DocScrutinizer05 | or edit the original file, instead of patching the editor | 23:02 |
| DocScrutinizer05 | ;-P | 23:02 |
| Estel^ | resulting file, you mean? After editor creates it? | 23:02 |
| Estel^ | it was hiogh enough time to get rid of multiboot. My only excuse for wqaiting so long was that In fact, I have never ever used it to boot anything else than kernel already flashed in nand :P | 23:03 |
| Estel^ | =never used it, in reality | 23:03 |
| DocScrutinizer05 | honestly, feels like I'm supposed to write bund of sed scripts to create my letter, and if the result isn't like it should, then edit sed itself to fix that | 23:03 |
| *** Vlad_on_the_road has quit IRC | 23:03 | |
| DocScrutinizer05 | bunch even | 23:03 |
| Estel^ | well, used it to get into backupmenu, but that doesn't count, as it doesn't flash nand | 23:04 |
| Estel^ | ough | 23:04 |
| DocScrutinizer05 | ~trout kerio | 23:04 |
| * infobot slaps kerio around a bit with a large trout! | 23:04 | |
| kerio | DocScrutinizer05: it's not my fault pali hasn't upstreamed my patch yet | 23:05 |
| Estel^ | kerio, so, summing it up, u-boot menu is triggered by (what?) and otherwise device boots default thing which is (what?)? I need to keep that default thing - kp52 in (what directory)? | 23:05 |
| DocScrutinizer05 | hehehe | 23:05 |
| Estel^ | kerio, I agree | 23:05 |
| Estel^ | btw | 23:05 |
| Estel^ | hey, maybe I shgould just use your patched u-boot-update-bootmenu | 23:05 |
| kerio | nah, it's awful | 23:06 |
| Estel^ | christ, my typos. *should | 23:06 |
| Estel^ | what's is so awful about it?:P | 23:06 |
| kerio | it needs a better way to detect if there's actually an attached kernel | 23:06 |
| Estel^ | whatever, gimme it to me *gollum's face* | 23:06 |
| kerio | nope | 23:06 |
| Estel^ | gimme it, even | 23:06 |
| Estel^ | gimme it, or I will dig up the link that you've posted some weeks ago, which contain exactly thaT :p | 23:07 |
| kerio | that would involve 0 effort on my part | 23:07 |
| kerio | i'm ok with that | 23:07 |
| Estel^ | hehe | 23:07 |
| *** Vlad_on_the_road has joined #maemo-ssu | 23:07 | |
| Estel^ | pastebin /usr/bin/u-boot-update-bootmenu is slightly low effort... Think about it, We will save more Co2 if you do that simple command, instead of me waking up google advanced search to find it | 23:08 |
| Estel^ | sustainable economy, etc | 23:08 |
| Estel^ | ok, but I still don't get how u-boot menu is triggered. It appears always, or when keyboard is slided out, or bysome configurable thing, or?... | 23:09 |
| kerio | the menu appears when the keyboard is open as you boot | 23:09 |
| * Estel^ doesn't like idea of having some timeout menu on every boot, would rather like device to boot default kernel image, and show u-boot only, when requested 'somehow' | 23:09 | |
| Estel^ | OK | 23:09 |
| Estel^ | ah, so if I want exercise for sake of exercise, I may practice sliding keyboard out just after kernel gets loaded, to get backupmenu from bootmenu, but without getting u-boot menu | 23:10 |
| * Estel^ likes the idea | 23:10 | |
| kerio | i hope you realize that you can just leave the kbd slider open | 23:10 |
| Estel^ | sure | 23:10 |
| Estel^ | that's why I've said ''exercise for sake of exercise'' | 23:11 |
| Estel^ | +10 k20 coolnes of using N900 when you slide out just in time | 23:11 |
| Estel^ | egoboost | 23:11 |
| Estel^ | I hope you realize ammount of irony here :P anyway, now the ultimate question - when I decide to have possibility of running somwthing like arch linux or whatever, how to prepare "thing" and trigger u-boot-update-bootmenu to make it available from u-boot menu? | 23:12 |
| Estel^ | how it will know what is default and what isn't? | 23:12 |
| Estel^ | I suppose ln -s /etc/bootmenu.d/*power* /etc/default/bootmenu.item is default | 23:13 |
| Estel^ | s/is default/define default thing/ | 23:13 |
| infobot | Estel^ meant: I suppose ln -s /etc/bootmenu.d/*power* /etc/default/bootmenu.item define default thing | 23:13 |
| Estel^ | so how about non-default one, that should get available from u-boot menu? | 23:13 |
| kerio | yeah, the non-default ones will be available from the uboot menu | 23:13 |
| kerio | as will the default one | 23:13 |
| Estel^ | so /etc/bootmenu.d/ things are considered by u-boot-update-menu? | 23:14 |
| kerio | if there's no default, the default is the first one | 23:14 |
| kerio | if you leave the attachboot entry in, that's the first one | 23:14 |
| kerio | otherwise, it's the first in alphabetical order of the uboot entries in /etc/bootmenu.d | 23:14 |
| Estel^ | ...which wouldn't work, as I won't attach kernel to it, due to it having no sense, so surely, i'll kick attached from u-boot menu | 23:14 |
| *** Vlad_on_the_road has quit IRC | 23:15 | |
| Estel^ | so using u-boot is as simple as having proper things in /etc/bootmenu.d and matching images in approriate place, then, running u-boot-update-menu? | 23:15 |
| Estel^ | mkimage and such things can go screw themselves? | 23:15 |
| Estel^ | ... Whoa, shitload of things in my /etc/bootmenu.d/, that are nto actual | 23:16 |
| Estel^ | not* | 23:16 |
| Estel^ | including backupmenu, which shouldn't sit there, methinks? | 23:16 |
| kerio | Estel^: that's right, as a user you shouldn't be aware of the existance of mkimage | 23:17 |
| kerio | and that directory is shared by fanoush's bootmenu | 23:18 |
| Estel^ | oh, great, so how to have famoush bootmenu things like backupmenu, and u-boot without broken entries, at the same time? | 23:18 |
| Estel^ | "fire, fire, carrier under fire" - first of all, I got styrangte problems after uninstalling bootmenu, and while using backupmenu (which implies using bootmenu). When booting with keyboard slided out, my arrows works only for split second, then, I can't select anything in bootmenu (which is visible, though), and thing like "cannot open /dev/fbd0" spams my fbcon | 23:20 |
| Estel^ | wtf? | 23:20 |
| Estel^ | now when it boots, "Warning: Unable to open initial console" | 23:21 |
| Estel^ | Console: Switching to colour frame buffer device 100x30 | 23:22 |
| Estel^ | Kernel panic - not syncing: Attempted to kill init | 23:22 |
| Estel^ | then shutdown. heh | 23:22 |
| kerio | idk | 23:22 |
| Estel^ | fun fact, if i bash "return" to use that split second when bootmenu works, device boots normally | 23:23 |
| kerio | so you have a bootmenu problem | 23:23 |
| Estel^ | yep. | 23:23 |
| kerio | apt-get install --reinstall getbootstate | 23:23 |
| Estel^ | I would say some multiboot remnants fucked it up, but i vaguely remember smth like that happening one on device, where multiboot wasn't present at any point in time, just bootmenuy instalkled on vanilla system | 23:24 |
| kerio | apt-get install --reinstall bootmenu-n900 | 23:24 |
| kerio | er, sorry, bootmenu | 23:24 |
| Estel^ | iirc, when i managed to boot ok, all future boots will work OK. Strange things. If not, i'll try reinstalling, indeed | 23:24 |
| Estel^ | kerio, me wonders why u-boot bootimage adds file 30-U-Boot-2012.12-rc3-1.item to /etc/bootmenu.d/ | 23:29 |
| DocScrutinizer05 | ((<kerio> and that directory is shared by fanoush's bootmenu)) which is the great design mistake in that whole thing | 23:30 |
| kerio | because the bootimage is not what you want, really | 23:30 |
| Estel^ | kerio, I wanted bootimage to extraxt u-boot zimage from it and flash it to nand | 23:30 |
| kerio | why didn't you download the deb somewhere else | 23:30 |
| Estel^ | btw, what is potential use case to have u-boot item in bootmenu.d? | 23:30 |
| kerio | multiboot, probably | 23:30 |
| Estel^ | because I haven't expected it to do irrational things | 23:31 |
| Estel^ | lol | 23:31 |
| Estel^ | u-boot .item for multiboot sounds... fun. Just fun. | 23:31 |
| Estel^ | like using bicycle dynamo to power initial ignition of 2012 hybrid car | 23:31 |
| Estel^ | kerio, DocScrutinizer05, I agree that sharing directory with fanoush bootmenu sounds like basic design mistake | 23:32 |
| kerio | it's for backwards-compatibility with multiboot | 23:32 |
| kerio | which uses /etc/bootmenu.d and /etc/multiboot.d | 23:33 |
| Estel^ | anyway, any ideas how to have working backupmenu from fanoush's bootmenu (after kernel is loaded) and u-boot menu without broken entries, considering, that backupmenu.item sits in bootmenu.d ? | 23:33 |
| kerio | Estel^: just ignore the errors u-boot-update-bootmenu gives you | 23:33 |
| kerio | (another design mistake) | 23:33 |
| Estel^ | ah, it will give errors? I thought it will make fubar entries to u-boot menu | 23:33 |
| kerio | no, no | 23:33 |
| kerio | it's kinda easy to distinguish between what has a kernel entry and what doesn't :) | 23:33 |
| Estel^ | 3th. why won't anyone fill a bug against that design mistakes to Pali? | 23:34 |
| Estel^ | yea | 23:34 |
| DocScrutinizer05 | I'd honestly patch u-boot-update-bootmenu to use *its* *own* directory, like /etc/uboot.d | 23:34 |
| Estel^ | well, I guewss I;'ll extract u-boot zimage, then aplt-get purge u-boot-bootmenu | 23:34 |
| kerio | DocScrutinizer05: and symlink the shit out of every -bootimg? | 23:34 |
| DocScrutinizer05 | then just _maybe_ copy etc/bootmenu to etc/uboot.d | 23:34 |
| kerio | and by symlink i mean dpkg-divert | 23:35 |
| Estel^ | hehe, I feel another kerio's fork is going to appear. Pali will just lvoe you ;-) | 23:35 |
| Estel^ | s/lvoe/love/ | 23:35 |
| infobot | Estel^ meant: hehe, I feel another kerio's fork is going to appear. Pali will just love you ;-) | 23:35 |
| Estel^ | ffs | 23:35 |
| Estel^ | this whole u-boot thing confused me enough, to try installing it without doing backup | 23:36 |
| Estel^ | *desperado mode on* | 23:36 |
| Estel^ | what can go wrong, in desperado mode, we're immortal ;) | 23:36 |
| Estel^ | erm, what was that thing, that need to sit on MyDocs, or something in u-boot won't work as it should? | 23:37 |
| kerio | bootmenu.src and bootmenu.d | 23:37 |
| kerio | they're the script and the directory that contains the uimages | 23:38 |
| Estel^ | w-what? bootmenu.d wasn't on /etc/bootmenu.d/?! | 23:38 |
| kerio | pay attention, this is MyDocs/bootmenu.d | 23:38 |
| Estel^ | or is it created by u-boot-update-menu automagically on mydocs? | 23:38 |
| kerio | which contains the automatically-created and automatically-converted uboot images of every kernel and initrd referenced by the .item files | 23:38 |
| Estel^ | wonderful, I don't even want to ask what would happen, if I wouldn't have mydocs as /dev/mmcblk0p1, and would want to boot from sd, for example | 23:39 |
| kerio | if uboot doesn't know what to do, it gives you a console | 23:39 |
| Estel^ | would need to enter u-boot console and do all shit manually to boot from sd, eh? | 23:39 |
| Estel^ | hehe | 23:39 |
| Estel^ | see? desperado mode gives +100 to intuition | 23:39 |
| kerio | i'm not sure if anything is loaded automatically from the sd | 23:39 |
| DocScrutinizer05 | select bootimage_to_add in /boot/*-bootimg*; do install-uboot-entry $(basename $bootimage_to_add) $bootimage_to_add; done | 23:39 |
| kerio | DocScrutinizer05: 50% of the times, it works 100% of the times | 23:40 |
| Estel^ | my super-zipper-you-'re-not-a-david-bowie intution tells me, that u-boot console isn't full-fledged termijnal, just itnernal u-boot tool? | 23:40 |
| Estel^ | internal/iternal/s/ or smth loike that | 23:40 |
| kerio | considering that linux hasn't even entered the picture at that point... | 23:41 |
| Estel^ | right. Well, rationale doesn't enter picture at point of intuitional feeling ;_P | 23:41 |
| *** wmarone__ has joined #maemo-ssu | 23:47 | |
| Estel^ | now, we only need to convince good'old'lennart to write poette-boot, and push it to be used as one and only (tm) thing by every board manufacturers, that will contain whole linux substitute bundled in u-boot (poette-boot)... | 23:47 |
| *** wmarone_ has quit IRC | 23:47 | |
| Estel^ | ...so we will have proper terminal instead of u-boot console and unified enviromnent (tm) | 23:47 |
| Estel^ | ;) | 23:47 |
| DocScrutinizer05 | kerio: find /boot /mnt/mmc/boot -iname "*bootimg*" -exec "echo 'install uboot entry for' {} ' ? (^C for no, enter for this name, or enter an alternative text for menu entry):' read -i {} && install-uboot-entry $REPLY" ; | 23:52 |
| kerio | even then, it actually doesn't work | 23:52 |
| DocScrutinizer05 | meh! | 23:53 |
| kerio | to boot a kernel you need 1) a kernel, and 2) a cmdline | 23:53 |
| DocScrutinizer05 | then use asm! ;-P | 23:53 |
| kerio | and sometimes 3) an initrd | 23:53 |
| DocScrutinizer05 | an initrd? | 23:53 |
| kerio | an initrd! | 23:54 |
| DocScrutinizer05 | what for? filesystem not available in the kernel? | 23:54 |
| kerio | *coff coff rescueos coff coff* | 23:54 |
| DocScrutinizer05 | cofcoff not meant to ever get installed coffcoff | 23:55 |
| kerio | "meant" my ass | 23:55 |
| kerio | it works perfectly | 23:55 |
| DocScrutinizer05 | actually that's the only reason why it needs an initrd | 23:55 |
| kerio | and it's probably indistinguishable from when you boot it from flasher | 23:55 |
| DocScrutinizer05 | anyway nothing that couldn't get handled inside install-uboot-entry | 23:56 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!
