| 00:52.42 | Estel^ | kerio, I have everything set-up for u-boot. What was that 2 teerminal trick to flash thing from on-device? |
| 00:52.48 | Estel^ | (i got u-boot.bon file) |
| 00:52.56 | Estel^ | s/.bon/.bin/ |
| 00:53.41 | Estel^ | I know I could look at postinst script for any flasher package, I just don't get that 2 terminals thingie |
| 01:41.38 | Estel^ | hm, no idea how to flash u-bootlbin from on-device. Will flash it from desktop flasher3.5 tomorrow. |
| 02:20.30 | Estel^ | nvm, found out that you need to: |
| 02:20.32 | Estel^ | softupd -vv -s --local |
| 02:20.35 | Estel^ | in one terminal as root, and |
| 02:20.48 | Estel^ | flasher -k u-boot.bin -f |
| 02:20.50 | Estel^ | in another |
| 02:21.36 | Estel^ | it *seemed* to flash ok, but after reboot, device wasn't able to boot. Did the same thing (flasher3.5 -k u-boot.bin -f) from desktop, and it worked like charm, u-boot greeted me after reboot |
| 02:21.41 | Estel^ | *shrug* |
| 02:22.25 | Estel^ | works like charm, although noticed werido - if, instad from entries or default, I enter u-boot console, doing - as advertised - run emmcboot result in shitload of errors and no booting |
| 02:22.48 | Estel^ | same for run sdboot, even if proper .src and bootmenu.img.d/ are on sd card |
| 02:23.00 | Estel^ | will need to investigate how to boot from sd, really |
| 02:28.38 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 02:32.22 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 02:34.11 | *** join/#maemo-ssu discopig (~discopig@2001:5c0:1000:a::7f3) |
| 02:34.11 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 02:39.51 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 02:46.25 | *** join/#maemo-ssu wmarone_ (~wmarone@c-67-174-151-253.hsd1.ca.comcast.net) |
| 03:00.08 | *** join/#maemo-ssu PaulFertser (paul@2001:470:26:54b:250:70ff:fee7:41ec) |
| 03:36.02 | *** join/#maemo-ssu amiconn_ (quassel@rockbox/developer/amiconn) |
| 04:03.46 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 04:48.34 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@120.85.133.181) |
| 05:11.39 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 06:07.53 | *** join/#maemo-ssu futpib (~futpib@89.106.197.26) |
| 06:41.26 | *** join/#maemo-ssu jon_y (~enforcer@2002:af91:531b::af91:531b) |
| 06:58.16 | *** join/#maemo-ssu MohammadAG (~MohammadA@Maemo/community/contributor/MohammadAG) |
| 07:08.53 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@120.85.133.181) |
| 08:02.13 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 08:44.31 | *** join/#maemo-ssu Martix (~martix@4.177.broadband3.iol.cz) |
| 08:54.06 | *** join/#maemo-ssu futpib (~futpib@89.106.197.82) |
| 09:10.46 | *** join/#maemo-ssu NIN101 (~NIN@p5DD29764.dip0.t-ipconnect.de) |
| 10:17.10 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |
| 11:13.26 | *** join/#maemo-ssu MohammadAG_ (~MohammadA@Maemo/community/contributor/MohammadAG) |
| 11:15.34 | *** join/#maemo-ssu kolp (~quassel@212.255.239.94) |
| 11:32.09 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 11:45.51 | *** join/#maemo-ssu kolp (~quassel@212.255.239.94) |
| 13:18.39 | *** join/#maemo-ssu arcean (~arcean@aael75.neoplus.adsl.tpnet.pl) |
| 14:23.01 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 14:39.18 | *** join/#maemo-ssu arcean_ (~arcean@aaeq37.neoplus.adsl.tpnet.pl) |
| 14:54.08 | *** join/#maemo-ssu Estel_ (~Estel@d56-215.icpnet.pl) |
| 14:54.08 | *** join/#maemo-ssu Estel_ (~Estel@Maemo/community/contributor/Estel-) |
| 14:54.17 | *** join/#maemo-ssu lartza_ (~lartza@IP-62-216-127-116.telemail.fi) |
| 14:59.22 | Estel_ | Pali, wtf is with u-boot rc3-1 in maaemo repos being unable to voot 3.* kernels, and u-boot rc3-1 (same version) from your page having no problem with it? |
| 14:59.38 | Estel_ | again that freaking habit of changing shitte without bumping version number? |
| 15:00.36 | Estel_ | don't take it as disrespectful, I really appreciate your work, but it is 3th time I run into things from you that have 5467654567 different variants with *same*version number, that also, cause me to enter bootloop |
| 15:01.14 | Estel_ | it's getting on my nerves, and I really don't see any reasonable rationale for not bumping version number when changing things, so pretty please, cease and desist :P doing it this way |
| 15:01.44 | Estel_ | +/3th time/3th time in 2 days/ |
| 15:16.36 | *** join/#maemo-ssu NIN101 (~NIN@p5DD28540.dip0.t-ipconnect.de) |
| 15:25.07 | *** join/#maemo-ssu tg (~irc@2001:738:2001:2078:0:215:11:82) |
| 16:18.52 | *** join/#maemo-ssu aap (~drew@cpe-174-101-232-161.cinci.res.rr.com) |
| 17:06.40 | *** join/#maemo-ssu futpib (~futpib@89.106.197.82) |
| 18:24.11 | DocScrutinizer05 | I guess Nokia's versioning scheme of <year>-<week-of-year>-<build-in-this-week> (*-2010-36-198) got invented for a reason, isn't unique to Nokia, and most probably got implemented by some automatism that always creates correct numbering/versioning and ovoids any two builds "sharing" same version |
| 18:30.22 | Estel_ | agreed, and I just can't get why Pali repeatedly change things, releasing here and there same versions/name things, different internally |
| 18:31.20 | kerio | Estel_: hm, the .bin from the -bootimg in extras-devel and the -bootimg from his site have different md5s |
| 18:31.29 | kerio | but it could be because of the different build environments |
| 18:31.59 | Estel_ | last time it was kp52 with crucial change to rx51 module (despite resulting in bootloop, when bme-replacement was installed over "older" kp52), now it's u-boot that can't boot 3.*kernel is ine version, and doesn't have problems in another, same version... |
| 18:32.30 | Estel_ | kerio, I know it have different md5s, because there freaking different. -devel version breaks when booting any 3.*linux kernel |
| 18:32.34 | Estel_ | silently breaks, too |
| 18:32.46 | Estel_ | version from his site works flawlessly |
| 18:33.45 | Estel_ | another thing that would confuse me like hell and make into spending hours debugging perfectly fine bootmenu.src, if not for a spark of intuition. Later, I discovered that arch linux guys spent hours doing exactly that - debugging perfectly fine things... |
| 18:33.50 | kerio | DocScrutinizer05: what's the bq27k GPIO connected to? |
| 18:34.00 | DocScrutinizer05 | zilch |
| 18:34.07 | Estel_ | just to notice, at the end, that u-boot with same version in Pali's site works OK ;) |
| 18:34.17 | kerio | well, it's enabled |
| 18:34.25 | Estel_ | it was month ago, but, apparently, wasn't important enough to bump version number |
| 18:34.35 | Estel_ | <PROTECTED> |
| 18:38.55 | kerio | hm, i need a better name for convert_registers_units |
| 18:39.44 | kerio | alright, parse_registers |
| 18:46.48 | Estel_ | what are you cooking? |
| 18:59.41 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 19:01.12 | *** join/#maemo-ssu unclouded (~neil@2001:4428:200:80fc:e973:61cd:733:b07b) |
| 19:02.09 | kerio | Estel_: some sort of python library to get data from bq27k |
| 19:14.29 | DocScrutinizer05 | .ko |
| 19:15.38 | kerio | DocScrutinizer05: actually, the important part is parse_registers |
| 19:15.51 | kerio | and as long as you provide a registers dict, it'll work fine |
| 19:15.55 | *** join/#maemo-ssu BCMM (~user@unaffiliated/bcmm) |
| 19:15.58 | kerio | regardless of where it comes from |
| 19:16.14 | kerio | "Parse a dict of raw bq27k registers (with registers that are split into high/low already merged)" |
| 19:18.28 | DocScrutinizer05 | yeah, :-/ for the latter |
| 19:19.06 | DocScrutinizer05 | relies on a priori knowledge not supposed to be found on that level |
| 19:20.18 | kerio | fwiw, it relies on a priori knowledge already |
| 19:20.28 | kerio | because the dict you're supposed to pass has the cute names that come from the datasheet |
| 19:21.10 | kerio | and meh, i could change it and require "ARL" and "ARH" to be passed instead of "AR", but what's the point? |
| 19:29.42 | DocScrutinizer05 | the point is to at least _try_ and enable fixing this borked register dump that's not really a clean register dump to become one eventually - so nobody could argue "yeah, maybe it's not correct this way, but look, other apps already depend on it" |
| 19:30.52 | DocScrutinizer05 | the knowledge about meaning and semantics and properties of registers are meant to be *inside* your code, not included in the dump |
| 19:31.46 | DocScrutinizer05 | *all* properties, even such nonsense like "pairing" that's actually non-existent on a i2c register dump level |
| 19:32.03 | kerio | DocScrutinizer05: should i keep the names SEDVF and SEDV1 or change them to EDVFT and EDV1T (for Threshold)? |
| 19:33.09 | DocScrutinizer05 | I'd suggest you stick to the names in datasheet as close as possible |
| 19:33.36 | kerio | but S is for Scaled, and i'm unscaling them |
| 19:33.43 | kerio | but i can't call them EDVF and EDV1 because those are the flags |
| 19:34.16 | DocScrutinizer05 | are the flags named exactly identical to the threshold integers? |
| 19:34.23 | kerio | yep |
| 19:34.57 | DocScrutinizer05 | then that's shit, and I'd rather change the flags' names to flag-EDVF and flag-EDV! or sth like that# |
| 19:35.15 | DocScrutinizer05 | s/!/1/ |
| 19:35.20 | kerio | you're going to use the flags a lot more than the thresholds |
| 19:35.37 | kerio | also, there's GPIEN both in MODE and in PKCFG, i renamed the PKCFG one to GPIENP |
| 19:35.46 | kerio | (everything is well-commented, of course) |
| 19:35.55 | DocScrutinizer05 | since when we're chosing name length based on usage frequency? |
| 19:36.21 | kerio | for for_loop_index in range(27): |
| 19:37.44 | kerio | DocScrutinizer05: anyway, the "correct" way would be to rename /both/ |
| 19:37.54 | kerio | EDV*F and EDV*T |
| 19:38.19 | DocScrutinizer05 | sure, go ahead |
| 19:38.48 | kerio | ...meh, i'll just leave them as SEDVF/SEDV1, which is the official name |
| 19:43.42 | DocScrutinizer05 | yes, since that's what DS does. I never seen a datasheet using ambiguous names for similar things |
| 19:44.26 | DocScrutinizer05 | there's only one EDV1 and that's the flag. There's a SEDV1 that's upper half of EDV1-threshold |
| 19:44.47 | DocScrutinizer05 | it's probably fair to keep this name for the normalized value |
| 19:45.09 | kerio | DocScrutinizer05: GPIEN is ambiguous :) |
| 19:46.14 | DocScrutinizer05 | how so? |
| 19:46.34 | kerio | it's a bit in FLAGS and in PKCFG |
| 19:46.37 | DocScrutinizer05 | ugh, right |
| 19:46.45 | kerio | er, a bit in MODE and PKCFG |
| 19:47.41 | DocScrutinizer05 | yeah, then it's fair to use a prefix for the read-only derived value, like PKCFG:GPIEN |
| 19:50.03 | DocScrutinizer05 | it's basically a constant here |
| 19:50.27 | DocScrutinizer05 | since you can't change it by any reasonable procedure |
| 19:51.00 | DocScrutinizer05 | and you usually don't even need to read it, since it's mostly irrelevant for anything you ever would want to code |
| 19:54.36 | DocScrutinizer05 | anyway, if you need to use a prefix for one bit in a word, then you should use same prefix for all bits in same word, and maybe you even should use similar prefixes for all bits in similar class of words (EEPROM) |
| 19:56.20 | DocScrutinizer05 | or actually use prefix "EEPROM" for all values in EEPROM |
| 19:59.28 | kerio | ooh, (v + 4) % 8 - 4 is how you do two's complement if v is a 3-bit value |
| 20:00.27 | kerio | DocScrutinizer05: meh, i'm already making up "AEE" as a name |
| 20:00.28 | DocScrutinizer05 | but then a value like EEPROM_SEDV1 would be 8bit mandatory. In that case better use EDV1_threshold for the normalized (*2^8) value |
| 20:00.49 | kerio | it's always TAPER[7] |
| 20:14.07 | DocScrutinizer05 | oops, SEDV1 = designed EDV1_threshold/8 - 256 |
| 20:14.49 | DocScrutinizer05 | not designed EDV1_threshold/2^8 |
| 20:18.07 | kerio | yeah, yeah :) |
| 20:18.59 | DocScrutinizer05 | yeah, I guessed/assumed ;-) |
| 20:19.50 | kerio | so EDV1_thr = 0b1-SEDV1--000 |
| 20:19.54 | DocScrutinizer05 | anyway I also guess, you want to export the normalized EDV1_threshold, not the raw register value? then you should use a different name than SEDV1 |
| 20:20.25 | kerio | DocScrutinizer05: yeah, i'm normalizing, converting and unpacking everything i can |
| 20:20.38 | DocScrutinizer05 | :nod:, sth like that (though I haven't evaluated your formula) |
| 20:20.55 | kerio | it's not a formula |
| 20:21.11 | kerio | 0b1[SEDV1, 8 bits]000 |
| 20:22.40 | DocScrutinizer05 | ooh |
| 20:22.50 | DocScrutinizer05 | i see |
| 20:23.58 | DocScrutinizer05 | well, since you're exporting *only* normalized values, you're probably safe to use SEDV1, since nobody expects to see a non-normalized value in that var |
| 20:25.18 | DocScrutinizer05 | doesn't matter how complex the normalization is, if it's just a factor like *3.57/20, or something like *8 + 256 |
| 20:25.45 | kerio | i'm afraid i've strayed from joergthon in this version :< |
| 20:25.48 | DocScrutinizer05 | err *8 + (258*8) |
| 20:33.12 | DocScrutinizer05 | btw making up names is a pretty poor idea. Devels should always have something to refer to, that they already know from the stuff they had to learn about in DS |
| 20:53.31 | kerio | DocScrutinizer05: why the hell is there an offset that goes in units of 2.45uV? |
| 20:53.41 | kerio | isn't that small beyond recognition? |
| 20:54.01 | kerio | every other voltage is bigger by at least 3 orders of magnitude |
| 20:59.34 | DocScrutinizer05 | kerio: where? |
| 20:59.43 | kerio | BOFF |
| 20:59.50 | DocScrutinizer05 | I'm absolutely sure you misinterpreted sth |
| 21:00.04 | kerio | maybe it's some specific sensor |
| 21:00.16 | DocScrutinizer05 | meh, offset-calibration |
| 21:00.31 | DocScrutinizer05 | that's for adjusting the ADC to 0.000000 |
| 21:01.05 | DocScrutinizer05 | it's not supposed to have an offset error of 50% of max range |
| 21:02.06 | DocScrutinizer05 | if the value range for that sensor is 0 .. 100, then the offset calibration is in the range of 0.0001 or sth |
| 21:02.43 | kerio | what i don't get is why 0.0001 would matter |
| 21:03.04 | DocScrutinizer05 | because it introduces an accumulating error |
| 21:03.22 | DocScrutinizer05 | it's like a constant small current flowing in or out of cell |
| 21:04.22 | DocScrutinizer05 | this would NAC make drift despite cell is not even connected to anything |
| 21:04.30 | kerio | i see |
| 21:04.43 | kerio | so you *really* want it to be 0 when it should be |
| 21:11.17 | DocScrutinizer05 | kerio: we got RS=20mOhm, a current of 1mA creates a voltage across RS of 20µV |
| 21:12.56 | DocScrutinizer05 | I'm actually amazed that the offset calibration granularity is that huge, I'd rather had expected sth like 0.0245µV |
| 21:13.48 | DocScrutinizer05 | btw that's most probably 2.54, not 2.45 |
| 21:15.20 | kerio | why? |
| 21:15.45 | DocScrutinizer05 | well, 0.1mA error seems a lot |
| 21:15.46 | kerio | ah yes, it is |
| 21:15.53 | kerio | no, i meant the 2.45 |
| 21:16.04 | DocScrutinizer05 | lol, because I feel that |
| 21:16.19 | kerio | no, wait, 4.9 *is* 2.45*2 |
| 21:16.24 | kerio | you feel wrong |
| 21:16.44 | DocScrutinizer05 | has closed the DS 10min ago :-S |
| 21:19.03 | DocScrutinizer05 | btw BOFF has 8 discrete values, I'd not bother 2s complement, rather use your beloved lists for that, here it seems quite right ;-) |
| 21:19.14 | DocScrutinizer05 | and yes, it's 2.45 |
| 21:19.46 | kerio | o rly |
| 21:20.01 | kerio | thanks, i would've never guessed that, /while reading the DS/ |
| 21:20.21 | DocScrutinizer05 | pfff ;-P |
| 21:24.01 | kerio | DocScrutinizer05: is it "right" to correct the datasheet? |
| 21:24.57 | kerio | 914 is clearly just 3.57 << 8 |
| 21:25.20 | kerio | even though it's 913.92 |
| 21:28.43 | kerio | and of course by 3.57 << 8 i mean 3.57 * (1 << 8) |
| 21:34.23 | kerio | 3.57 << 8 would be 18511595908343686758400.0 |
| 21:35.18 | kerio | http://pastebin.mozilla.org/2260579 |
| 21:35.24 | kerio | it's getting more and more ridiculous as time passes |
| 21:35.34 | DocScrutinizer05 | what makes you think 3.57 is more exact/autoritative than 914? |
| 21:37.34 | kerio | maybe 914 is authoritative |
| 21:37.44 | kerio | then it would have to be 3.5703 |
| 21:38.01 | kerio | 3.57 is just so much cuter :3 |
| 21:39.27 | kerio | anyway, it clearly states that ILMD is actually the high byte of ILMD, and if we go by that, it's silly to use 3.5703125 as the unit of the full ILMD when you use 3.57 everywhere else |
| 21:39.34 | DocScrutinizer05 | btw forget about my explanation regarding accumulative error and BOFF, the chip goes into "idle" mode when a certain minimum threshold on current in/out is not reached |
| 21:48.05 | kerio | DocScrutinizer05: do you understand the above code? |
| 21:48.19 | DocScrutinizer05 | > >The Digital Magnitude Filter (DMF) threshold can be set in EEPROM to indicate a threshold below which an ycharge or discharge accumulation is ignored. This allows setting a threshold above the maximum DSCC offse texpected from the IC and PCB combination, so that when no charge or discharge current is present, th emeasured capacity change by the bqJUNIOR is zero.<< |
| 21:48.47 | DocScrutinizer05 | kerio: I only looked cursory across it |
| 21:48.56 | DocScrutinizer05 | looks good to me |
| 21:49.01 | kerio | :D |
| 21:49.07 | kerio | comments are truly amazing |
| 21:49.34 | kerio | and i quite like the repeated divmod, more than the bit manipulation |
| 21:50.41 | DocScrutinizer05 | I've seen two divmod with identical parameter#2 of 1<<1 |
| 21:50.52 | DocScrutinizer05 | I suspect the 2nd to be a typo |
| 21:51.02 | DocScrutinizer05 | or rather c&p error |
| 21:51.31 | kerio | nope |
| 21:51.34 | kerio | read more closely |
| 21:51.35 | kerio | :) |
| 21:51.35 | DocScrutinizer05 | maybe it's exactly what you wanted though |
| 21:51.48 | kerio | both tcfix and dcfix are 1b |
| 21:58.57 | DocScrutinizer05 | int i = getsubbits(byte/int/word composedword, const int LSB, const int numofbits) |
| 22:01.09 | DocScrutinizer05 | return ( (composedword>>LSB) && (0xFF<<numofbits) ) |
| 22:01.44 | DocScrutinizer05 | err |
| 22:01.51 | DocScrutinizer05 | return ( (composedword>>LSB) && ~(0xFF<<numofbits) ) |
| 22:02.00 | DocScrutinizer05 | return ( (composedword>>LSB) && ~(0xFFFF<<numofbits) ) |
| 22:06.39 | DocScrutinizer05 | wait, didn't I see sth like that in some kernel code ;-D |
| 22:32.29 | *** join/#maemo-ssu wmarone (~wmarone@c-67-174-151-253.hsd1.ca.comcast.net) |
| 22:52.38 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 23:13.44 | kerio | freemangordon: what's the problem with libpulse0? |
| 23:28.33 | freemangordon | kerio: no problem, just that HAM in its eternal wisdom upgrades just half of the packages |