| 01:00.18 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 01:17.05 | *** join/#maemo-ssu Estel_ (~Estel@d56-215.icpnet.pl) |
| 01:17.09 | *** join/#maemo-ssu Estel_ (~Estel@Maemo/community/contributor/Estel-) |
| 02:12.11 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@120.85.133.181) |
| 02:12.29 | *** join/#maemo-ssu kolp_ (~quassel@212.255.224.9) |
| 02:58.41 | *** join/#maemo-ssu futpib (~futpib@89.106.197.110) |
| 03:34.47 | *** join/#maemo-ssu unclouded (~neil@2001:4428:200:80fc:e973:61cd:733:b07b) |
| 03:37.00 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 04:03.58 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 04:08.08 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 04:38.26 | *** join/#maemo-ssu discopig (~discopig@2001:5c0:1000:a::7f3) |
| 04:38.26 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 04:49.18 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 06:06.52 | *** join/#maemo-ssu discopig (~discopig@2001:5c0:1000:a::7f3) |
| 06:06.52 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 06:38.49 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 07:24.17 | *** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
| 08:19.25 | *** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 08:50.20 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 08:58.25 | *** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 09:51.38 | 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? |
| 10:01.16 | kerio | ShadowJK: why is the conversion of ILMD done with 913920 instead of 914000? |
| 10:14.31 | kerio | oh i see, it's not really 914uVh, it's the high byte of 3.57uVh |
| 10:18.31 | *** join/#maemo-ssu jon_y (~enforcer@175.145.83.27) |
| 10:21.17 | *** join/#maemo-ssu futpib (~futpib@89.106.197.40) |
| 10:45.12 | *** join/#maemo-ssu NIN101 (~NIN@p5DD28CE6.dip0.t-ipconnect.de) |
| 10:57.04 | *** join/#maemo-ssu futpib_ (~futpib@89.106.197.40) |
| 11:05.26 | kerio | ah what the hell, "°" isn't ascii? |
| 11:05.46 | DocScrutinizer05 | man ascii |
| 11:07.50 | DocScrutinizer05 | man iso_8859-1 |
| 11:07.59 | DocScrutinizer05 | 260 176 B0 ° DEGREE SIGN |
| 11:08.52 | kerio | so... it's not ascii :P |
| 11:09.03 | kerio | anyway, i'm parsing EEPROM too now |
| 11:09.37 | kerio | is TAPER 102.8mA realistic? |
| 11:14.23 | DocScrutinizer05 | http://privatepaste.com/b9d424a14d |
| 11:16.20 | DocScrutinizer05 | haha, I been lazy and haven't decoded TAPER/AEE |
| 11:16.30 | kerio | yeah >:c |
| 11:16.33 | kerio | is it called AEE? |
| 11:16.58 | kerio | it doesn't have a shorthand in the datasheet |
| 11:18.45 | kerio | i also don't know what to do with MODE and CTRL |
| 11:20.13 | DocScrutinizer05 | mode and ctrl are really status registers only needed for writing to chip |
| 11:21.05 | DocScrutinizer05 | you could e.g. reset the chip via those registers |
| 11:22.03 | DocScrutinizer05 | but we have simpler methods for that ;-P |
| 11:23.50 | kerio | there's WRTNAC that seems useful |
| 11:24.22 | DocScrutinizer05 | you'll have to study the datasheet to learn about the last secrets of bq27200 ;-) |
| 11:25.03 | DocScrutinizer05 | yeah, WRTNAC could be very useful |
| 11:25.35 | DocScrutinizer05 | dunno why I never investigated it. ShadowJK iirc said it doesn't work, I don't believe that |
| 11:26.16 | DocScrutinizer05 | of course you need to stop bme before you do anything like that |
| 11:27.07 | DocScrutinizer05 | because of conflicting I2C access and the commands to write to bq27200 mustn't get interrupted by bme reading from chip |
| 11:31.59 | *** join/#maemo-ssu arcean (~arcean@aaes60.neoplus.adsl.tpnet.pl) |
| 11:53.54 | 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 |
| 12:06.44 | DocScrutinizer05 | (programming bq27k EEPROM) you need 20..22V for that, applied for 10..100ms to pin10. Current needed: 15mA :-o |
| 12:08.20 | DocScrutinizer05 | attention! EEPROM can get programmed only TEN times! |
| 12:09.13 | DocScrutinizer05 | so a hw mod to integrate a prommer is probably a rather nonsensicel execise ;-) |
| 12:12.57 | kerio | ShadowJK: why doesn't WRTNAC work? |
| 12:28.23 | ShadowJK | wrtnac? |
| 12:28.53 | kerio | in bq27k MODE |
| 12:29.10 | kerio | like, write new NAC to AR, set WRTNAC bit in MODE, set CTRL to magic number |
| 12:29.58 | ShadowJK | yeah, I've done that |
| 12:30.01 | kerio | does it work? |
| 12:31.00 | ShadowJK | ya |
| 12:31.30 | ShadowJK | nac gets the value from ar, rsoc/csoc is set to 100 and vdq goes high |
| 12:33.49 | kerio | "high"? |
| 12:34.14 | ShadowJK | 1 |
| 12:34.29 | kerio | so it's basically something that you do right once you finish charging? |
| 12:34.35 | kerio | or... no, actually not |
| 12:34.42 | kerio | you can do it wherever |
| 12:34.55 | kerio | just do a calib cycle right afterwards |
| 12:37.45 | ShadowJK | yes |
| 12:42.41 | 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 |
| 12:44.07 | DocScrutinizer05 | that's what you get if you buy surplus chips left over from a really huge customer |
| 12:44.10 | kerio | haha |
| 12:44.19 | kerio | well, the easiest way to fix that is to make a 2Ah bl-5j |
| 12:44.22 | kerio | :P |
| 12:44.28 | DocScrutinizer05 | :-D |
| 12:44.36 | kerio | is there no restriction on learn-up? |
| 12:44.52 | DocScrutinizer05 | according to datasheet, there's none |
| 12:45.09 | kerio | why do people always have problems when calibrating those dual batteries? |
| 12:45.11 | DocScrutinizer05 | which makes sense |
| 12:45.25 | DocScrutinizer05 | nfc |
| 12:45.32 | DocScrutinizer05 | do they? |
| 12:46.01 | DocScrutinizer05 | I guess that's about bme "calibration" |
| 12:48.24 | kerio | ShadowJK: could you confirm or deny? |
| 12:48.39 | 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 |
| 12:50.11 | 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) |
| 12:50.23 | kerio | #48? |
| 12:50.28 | DocScrutinizer05 | yeah |
| 12:50.32 | kerio | what's 48? |
| 12:50.42 | DocScrutinizer05 | nonexistent XP |
| 12:50.45 | kerio | better question, what's 48 in hex? |
| 12:51.03 | DocScrutinizer05 | meh, maybe it been 0x48 |
| 12:51.19 | DocScrutinizer05 | numbers made up, see? |
| 12:51.20 | kerio | still RESERVED |
| 12:51.32 | DocScrutinizer05 | no, this been of bq24150 |
| 12:51.39 | kerio | i see |
| 12:51.46 | DocScrutinizer05 | which actually has only 6 or 8 registers |
| 12:51.59 | kerio | nice |
| 12:52.01 | DocScrutinizer05 | iirc they wrap around |
| 12:52.18 | DocScrutinizer05 | incomplete addr decoder |
| 12:52.47 | DocScrutinizer05 | but that's probably no guaranteed property of the chip |
| 12:54.19 | DocScrutinizer05 | usually with 6 registers, you have 0x0 .. 0x5 defined, 0x6 and 0x7 undefined, and 0x8 == 0x0 a.s.o |
| 12:55.35 | DocScrutinizer05 | anyway with a patched i2c.ko we traced all bq24150 access, and bme accessed a register way out of the existing addr range |
| 12:58.15 | DocScrutinizer05 | Nokia trusting this crap more than community driven efforts to do a bme replacement is pretty embarrassing |
| 12:58.31 | DocScrutinizer05 | for Nokia, for us it's an insult |
| 13:00.16 | 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 |
| 13:09.25 | kerio | hmm, will setting NAC also set LMD? |
| 13:11.26 | DocScrutinizer05 | most likely not |
| 13:11.45 | kerio | but is NAC used when calibrating? |
| 13:11.55 | DocScrutinizer05 | which is what relativates the usefulness |
| 13:12.04 | kerio | otherwise, that WRTNAC is kinda useless |
| 13:12.10 | kerio | even from a manifacturer's point of view |
| 13:13.03 | DocScrutinizer05 | I guess it's meant to get used for batteries with multicells with balanced charging, or sth like that |
| 13:13.50 | DocScrutinizer05 | you could adjust the N900 bq27200 to match the real current capacity of a newly inserted battery |
| 13:14.24 | DocScrutinizer05 | given you know what capacity this battery is at right at this moment |
| 13:15.38 | 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 |
| 13:15.47 | kerio | oic |
| 13:15.51 | DocScrutinizer05 | s/with/which/ |
| 13:15.58 | DocScrutinizer05 | meh, no |
| 13:18.09 | DocScrutinizer05 | wait, what did ShadowJK say? |
| 13:18.33 | DocScrutinizer05 | <ShadowJK> nac gets the value from ar, rsoc/csoc is set to 100 and vdq goes high |
| 13:19.41 | 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 |
| 13:20.21 | kerio | but will it use the NAC you set as a starting point? |
| 13:20.58 | DocScrutinizer05 | yes, starting point of rsoc/csoc to calculate TTE and % |
| 13:21.38 | DocScrutinizer05 | after reaching EDV1 it will adjust due to measured coloumb that the battery delivered |
| 13:23.11 | 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 |
| 13:24.25 | DocScrutinizer05 | while setting NAC to 3000mAh will cause your device shutdown at capacity-display=60% |
| 13:25.28 | DocScrutinizer05 | or rather, it first will jump from 60% to 0% at reaching EDV1, then it completes learning cycle, then it may shut down |
| 13:26.05 | DocScrutinizer05 | kerio: all roger? |
| 13:26.30 | kerio | yeah |
| 13:26.47 | DocScrutinizer05 | fine |
| 13:26.48 | kerio | it's still unclear to me if that can be used to get around the learn-down limits |
| 13:26.59 | DocScrutinizer05 | no it can't |
| 13:28.29 | 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 |
| 13:29.14 | DocScrutinizer05 | at least that's my take on it |
| 13:29.53 | DocScrutinizer05 | iirc there is NO way to store a new arbitrary value to LMD |
| 13:30.14 | DocScrutinizer05 | except copy ILMD from EEPROM to register |
| 13:30.31 | kerio | but you can only program the EEPROM 10 times :( |
| 13:30.42 | DocScrutinizer05 | yep |
| 13:31.26 | DocScrutinizer05 | the bq27x00 are meant for integration into battery pack. Nokia abused them |
| 13:32.18 | DocScrutinizer05 | and if their EE were alert, they had programmed ILMD to 100 |
| 13:32.54 | DocScrutinizer05 | but probably they simply didn't care since the whole thing been meant to read out voltage and current-now only |
| 13:33.39 | DocScrutinizer05 | they simply thought the rest of data was useless in that particular circuit anyway |
| 13:34.47 | DocScrutinizer05 | but then they could've saved the buffer capacitor at BRI X-P |
| 13:36.58 | DocScrutinizer05 | well, even Nokia EE are not inerrant |
| 13:42.34 | ShadowJK | or then they really meant to use a bigger battery |
| 13:44.16 | 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 |
| 13:45.21 | kerio | how about just using the chip for what it was, instead? :s |
| 13:47.31 | DocScrutinizer05 | that would have required an alternative battery to the BL-5J |
| 13:47.55 | DocScrutinizer05 | with bq27000 integrated |
| 13:48.13 | DocScrutinizer05 | see openmoko gta02 smartbattery |
| 13:48.38 | DocScrutinizer05 | *we* (openmoko) were able to pull that off |
| 13:49.03 | DocScrutinizer05 | Nokia obviously been reluctant |
| 13:49.51 | kerio | maybe it was a good thing, though |
| 13:50.03 | kerio | BL-5Js are used in quite a lot of nokia phones |
| 13:50.17 | kerio | the 5800 is quite popular |
| 13:57.36 | DocScrutinizer05 | http://maemo.cloud-7.de/share-service/20130329_001.jpg DAMN! |
| 13:58.08 | kerio | haha |
| 13:58.11 | DocScrutinizer05 | btw it's fully compatible to bp-5c |
| 13:58.17 | kerio | you trolly you |
| 13:58.28 | kerio | also, 1200mAh? |
| 13:58.30 | DocScrutinizer05 | Nokia could've done same for BL-4J |
| 13:58.35 | kerio | it's... smaller than bl-5j, isn't it |
| 13:58.37 | DocScrutinizer05 | err BL-5J |
| 13:59.02 | DocScrutinizer05 | way smaller, that's why I uttered "DAMN" |
| 13:59.16 | kerio | i meant capacity-wise |
| 13:59.23 | kerio | the current bl-5js are 1400 |
| 13:59.35 | DocScrutinizer05 | 1200mAh, bq27000 integrated, mechanically compatible to Nokia BP-5C |
| 14:00.14 | *** join/#maemo-ssu jon_y (~enforcer@2002:af91:531b::af91:531b) |
| 14:00.29 | DocScrutinizer05 | well, that GTA02 battery is like 5 years old |
| 14:01.09 | DocScrutinizer05 | and it actually had ~1200mAh, according to LMD |
| 14:02.55 | ShadowJK | bl-5c started out as 800mAh, iirc, and technolgy improvements have taken it further since :) |
| 14:04.08 | *** join/#maemo-ssu kolp (~quassel@212.255.224.9) |
| 14:06.14 | DocScrutinizer05 | http://wiki.openmoko.org/wiki/Battery_Questions_and_Answers#Do_other_BL-5.2F6C_compatible_batteries_fit.3F |
| 14:09.05 | kerio | i have no good way of doing two's complement in python :( |
| 14:09.12 | kerio | i need a 3-bit-wide datatype |
| 14:11.10 | DocScrutinizer05 | huh? |
| 14:11.19 | kerio | to parse BOFF |
| 14:11.31 | kerio | (in python) |
| 14:11.45 | DocScrutinizer05 | how about basic integer math and boolean? |
| 14:12.15 | kerio | ...i know how to do that, i didn't /want/ to if there was a better way |
| 14:12.24 | DocScrutinizer05 | hehe |
| 14:12.50 | DocScrutinizer05 | sure there is (dunno if in python though): enum |
| 14:12.51 | kerio | i don't think there's a good way that lets you avoid checking the sign bit |
| 14:13.34 | DocScrutinizer05 | you just need to normalize/mask the relevant bits out of your original 8/16bit value |
| 14:14.46 | DocScrutinizer05 | If python can't do boolean AND / OR, you're probably in a pinch |
| 14:15.05 | kerio | don't be silly |
| 14:15.06 | kerio | it's not lua |
| 14:15.12 | DocScrutinizer05 | you have to do integer math then, which becomes nasty |
| 14:15.46 | kerio | [0, 1, 2, 3, -4, -3, -2, -1][(bq27k["PKCFG"] & 0b00011100) >> 2] |
| 14:15.46 | kerio | :D |
| 14:15.55 | DocScrutinizer05 | lua? meh! don't know lua to make sense of what you said |
| 14:16.07 | kerio | lua has a single "number" type |
| 14:16.16 | kerio | and it's float |
| 14:16.24 | DocScrutinizer05 | great |
| 14:16.26 | kerio | "In the interest of simplicity" |
| 14:16.32 | DocScrutinizer05 | idiots |
| 14:17.00 | DocScrutinizer05 | well, maybe they have a byte or word type then |
| 14:17.27 | kerio | nope |
| 14:18.01 | DocScrutinizer05 | ypur codeline above is puzzling |
| 14:18.34 | kerio | access the ((bq27k["PKCFG"] & 0b00011100) >> 2)th element of the [0, 1, 2, 3, -4, -3, -2, -1] list |
| 14:18.36 | DocScrutinizer05 | I gather that's some special list operation stuff in python? |
| 14:18.46 | kerio | list access is hardly special |
| 14:18.48 | DocScrutinizer05 | yeah |
| 14:19.30 | DocScrutinizer05 | well, the only lists I ever use are linked lists ;-D |
| 14:19.59 | DocScrutinizer05 | single or double linked |
| 14:20.01 | kerio | fun fact: "list" in python is, internally, an auto-resizing array |
| 14:20.07 | DocScrutinizer05 | yeah |
| 14:20.14 | DocScrutinizer05 | think I heard about that |
| 14:20.29 | kerio | the only linked list i can think of in python is collections.deque |
| 14:22.44 | DocScrutinizer05 | I seem to recall lists in python perform like my ass with obstipation |
| 14:22.51 | kerio | when doing what? |
| 14:23.23 | DocScrutinizer05 | when doing usual list operations like instantiate, append, insert, delete |
| 14:23.40 | kerio | insert and delete aren't usual array operations |
| 14:25.45 | 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 |
| 14:26.45 | kerio | wrong datatypes tend to do that, yeah |
| 14:27.13 | kerio | also, when you have dict, everything *does* look like a hashmap |
| 14:28.20 | DocScrutinizer05 | but anyway, for this particular project it doesn't matter I guess |
| 14:32.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%.<< |
| 14:34.19 | *** join/#maemo-ssu _rd (~rd@p57B4916E.dip0.t-ipconnect.de) |
| 14:35.41 | DocScrutinizer05 | kerio: ^^^ is a scheme that's probably adoptable to bme-replacement shutdown-threshold-detection as well |
| 14:36.44 | DocScrutinizer05 | at very least it gives a hind about minimum guard time to be used for that detection in bme-repl |
| 14:36.49 | DocScrutinizer05 | hint* |
| 14:37.24 | DocScrutinizer05 | minimum guard time is 30s |
| 14:40.49 | 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.<< |
| 14:41.58 | *** join/#maemo-ssu arcean_ (~arcean@aael75.neoplus.adsl.tpnet.pl) |
| 14:47.59 | *** join/#maemo-ssu futpib_ (~futpib@89.106.197.119) |
| 14:49.03 | 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 |
| 14:50.38 | DocScrutinizer05 | see "figure 4" |
| 14:57.31 | kerio | hrmpf, how should i store DCOFF? |
| 15:09.14 | DocScrutinizer05 | what's DCOFF? |
| 15:09.35 | DocScrutinizer05 | nm |
| 15:18.25 | DocScrutinizer05 | what do you mean by "how to store"? |
| 15:18.39 | kerio | it's a value that can be 0, C/2, C/4, C/8 |
| 15:18.45 | DocScrutinizer05 | yes |
| 15:18.59 | kerio | i decided that i'm lazy and i'm actually storing it as 0, 1, 2, or 3 |
| 15:19.58 | DocScrutinizer05 | I'd store it as 0, 0.5, 0.25, 0.125 |
| 15:20.25 | DocScrutinizer05 | or at very least as 1,2,3,8 |
| 15:21.09 | DocScrutinizer05 | err |
| 15:21.16 | DocScrutinizer05 | pretty inconvenient |
| 15:21.45 | DocScrutinizer05 | let's put this straight: it's the current above which CAC starts to differ from NAC |
| 15:22.37 | DocScrutinizer05 | it's calculated as percent of LMD, in ampere |
| 15:23.48 | DocScrutinizer05 | there are the possible values 0%, 12.5%, 25%, 50% |
| 15:25.41 | kerio | clearly it's a job for fractions.Fraction |
| 15:26.19 | kerio | but actually no, floats represent binary fractions exactly :) |
| 15:28.00 | kerio | The equation for programming the value is: |
| 15:28.00 | kerio | TOFF[3:0] = Design Temp Compensation Offset (°K) – 273 |
| 15:28.01 | kerio | dafuq |
| 15:28.11 | kerio | so... Design Temp Compensation Offset (°C) then |
| 15:28.33 | DocScrutinizer05 | so for AI > LMD * ^^^DCOFF%, the compensated AI gets calculated as CAI = AI + ((AI - (AI * DCOFF%)) * (0.39% * DCGN)) |
| 15:29.04 | kerio | it's 0 for the n900, isn't it? |
| 15:29.26 | DocScrutinizer05 | for me DCOFF is 6 |
| 15:29.55 | DocScrutinizer05 | and DCGN is 25 |
| 15:30.03 | kerio | oh |
| 15:30.33 | DocScrutinizer05 | sorry |
| 15:30.44 | DocScrutinizer05 | DCOF is 2 |
| 15:31.32 | DocScrutinizer05 | and my formula above seems also not quite correct |
| 15:32.32 | DocScrutinizer05 | so for AI > LMD * ^^^DCOFF%, the compensated AI gets calculated as CAI = AI + ((AI - (LMD * DCOFF%)) * (0.39% * DCGN)) |
| 15:33.45 | DocScrutinizer05 | the term AI - (LMD * DCOFF%) never must be negative |
| 15:34.47 | DocScrutinizer05 | this is guaranteed by applying the compensation only when AI > LMD * ^^^DCOFF% |
| 15:39.42 | kerio | DCOFF 0.25, DCGN 6.25% |
| 15:39.57 | DocScrutinizer05 | if [ ${AI} -ge $(( LMD * DCOFF_IN_permille / 1000 )) ]; then CAI = ... |
| 15:39.59 | DocScrutinizer05 | yes |
| 15:40.21 | DocScrutinizer05 | so I'd store it like 250 to DCOFF_IN_permille |
| 15:40.43 | kerio | nope, 0.25 is perfectly fine :) |
| 15:40.54 | kerio | or maybe percentage, like everything else |
| 15:41.41 | DocScrutinizer05 | err btw why 6.25% DCGN? |
| 15:41.59 | DocScrutinizer05 | ~66/4 |
| 15:41.59 | infobot | 16.5 |
| 15:41.59 | kerio | DCGN[5:0] = 2.56 * Design discharge compensation gain % |
| 15:42.05 | kerio | ~66/2.56 |
| 15:42.05 | infobot | 25.78125 |
| 15:42.09 | kerio | wat |
| 15:42.26 | kerio | ~25/2.56 |
| 15:42.26 | infobot | 9.765625 |
| 15:42.33 | kerio | i don't know why 6.25% DCGN |
| 15:42.35 | DocScrutinizer05 | ummm |
| 15:43.23 | DocScrutinizer05 | 66=0b01100110 |
| 15:43.28 | DocScrutinizer05 | >>2 |
| 15:43.45 | DocScrutinizer05 | 0b00011001 |
| 15:44.09 | DocScrutinizer05 | 9+16=25 |
| 15:44.21 | DocScrutinizer05 | ~25*0.39 |
| 15:44.22 | infobot | 9.75 |
| 15:45.35 | DocScrutinizer05 | <PROTECTED> |
| 15:45.58 | kerio | that's split in two |
| 15:46.31 | DocScrutinizer05 | BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT 0 |
| 15:46.32 | DocScrutinizer05 | NAME DCGN[5] DCGN[4] DCGN[3] DCGN[2] DCGN[1] DCGN[0] DCOFF[1] DCOFF[0] |
| 15:46.41 | DocScrutinizer05 | thus >>2 |
| 15:47.23 | DocScrutinizer05 | DCGN[5:0]=0b00011001 |
| 15:47.53 | DocScrutinizer05 | =0x19=25 |
| 15:48.10 | kerio | 66 == 0b01000010 |
| 15:48.21 | DocScrutinizer05 | WUT? |
| 15:48.32 | DocScrutinizer05 | dang!! |
| 15:48.44 | DocScrutinizer05 | I need more coffee |
| 15:49.07 | DocScrutinizer05 | of course you're right |
| 15:49.19 | kerio | ~kerio |
| 15:49.20 | infobot | it has been said that kerio is <DocScrutinizer05> kerio is right |
| 15:51.34 | DocScrutinizer05 | ~19*0.39 |
| 15:51.34 | infobot | 7.41 |
| 15:53.46 | DocScrutinizer05 | I really need more coffee |
| 15:54.25 | DocScrutinizer05 | and a better calculator, kcalc is da crap |
| 15:57.14 | DocScrutinizer05 | so finally 0x7e:66 means DCGN=16dez |
| 15:57.27 | DocScrutinizer05 | ~16*0.39 |
| 15:57.27 | infobot | 6.24 |
| 15:59.37 | DocScrutinizer05 | so finally 0x7e:66 means DCOFF=1dez which maps to C/2 aka 50% |
| 16:00.07 | kerio | DCOFF = 2 which maps to C/4 |
| 16:00.37 | DocScrutinizer05 | yes, again |
| 16:01.02 | DocScrutinizer05 | a pair value can't have LSB=1 |
| 16:01.18 | DocScrutinizer05 | seems I should go back to my bed |
| 16:02.29 | kerio | hm, i'm missing the energy stuff in the output |
| 16:02.59 | DocScrutinizer05 | *shrug* |
| 16:03.12 | DocScrutinizer05 | it's a simple multiplication I'd guess |
| 16:03.25 | kerio | they're stored in separate registers though |
| 16:03.27 | kerio | SAE and AP |
| 16:03.35 | DocScrutinizer05 | yeah sure |
| 16:04.06 | kerio | but yeah, it's a multiplication |
| 16:04.08 | DocScrutinizer05 | ~1245 mAh / 4 |
| 16:04.14 | DocScrutinizer05 | ~1245 / 4 |
| 16:04.14 | infobot | 311.25 |
| 16:04.16 | kerio | "The host system has read-only access to this register pair." |
| 16:04.21 | kerio | if only |
| 16:04.57 | kerio | i2cset a trillion joules |
| 16:05.06 | kerio | and solve the energy crisis |
| 16:06.14 | kerio | ok, let's check for joergthon compatibility |
| 16:06.17 | kerio | DocScrutinizer05: http://pastebin.mozilla.org/2256926 |
| 16:06.56 | *** join/#maemo-ssu _rd (~rd@p57B4916E.dip0.t-ipconnect.de) |
| 16:07.10 | DocScrutinizer05 | kerio: moeoeoep :o) 0x7C: 67 PKCFG Pack Configuration Values |
| 16:07.44 | DocScrutinizer05 | DCFIX Fixed discharge compensation == 1 |
| 16:09.00 | 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. << |
| 16:09.34 | kerio | also, my PKCFG is 67, not 66 |
| 16:10.09 | DocScrutinizer05 | 0x7E: 66 DCOMP Discharge Rate Compensation Constants, |
| 16:10.12 | kerio | what the hell, why is my TCFIX set |
| 16:10.19 | DocScrutinizer05 | 0x7C: 67 PKCFG Pack Configuration Values |
| 16:10.47 | kerio | oic |
| 16:11.14 | kerio | yeah but don't get distracted, check for SyntaxComplicated |
| 16:17.29 | DocScrutinizer05 | well, your bq27k["DCOFF"] will probably fail for 0% |
| 16:18.46 | DocScrutinizer05 | well, maybe not |
| 16:19.51 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 16:23.24 | DocScrutinizer05 | anyway DCFIX = 1 means 0x7e is an identification byte only, which makes me start to wonder what ID "66" means |
| 16:29.50 | DocScrutinizer05 | kerio: s/ # registers for us/ # registers for us, which actually is a rather nonsensical thing but done anyway/ |
| 16:31.29 | DocScrutinizer05 | kerio: otherwise, this code makes me love python |
| 16:32.48 | DocScrutinizer05 | I'd actually be temped to do what I always do: "steal" it and hack in my nasty little tweaks |
| 16:33.21 | DocScrutinizer05 | but then, it's based on sysfs nodes so basically useless for my purposes |
| 16:39.19 | DocScrutinizer05 | W*T*F?!! |
| 16:39.47 | 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! |
| 16:41.16 | DocScrutinizer05 | so we need to compensate this by CCYCT = CYCT / LMD * ILMD |
| 16:41.27 | kerio | no we don't |
| 16:41.50 | kerio | while a cycle counter might be cute to have, bq27k will still use the real CYCL |
| 16:42.17 | 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 |
| 17:09.59 | DocScrutinizer05 | WAAAAIIIT |
| 17:12.10 | 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 |
| 17:13.27 | ShadowJK | oh? |
| 17:13.29 | 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 |
| 17:13.35 | ShadowJK | can we change edv1 :) |
| 17:13.43 | kerio | :O |
| 17:13.46 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 17:14.08 | kerio | DocScrutinizer05: chip reset, or full reset? |
| 17:14.18 | ShadowJK | You mean you hope it's got sram, and copies eeprom to sram on start? |
| 17:14.49 | ShadowJK | instead of always reading from eeprom |
| 17:15.09 | 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 |
| 17:16.04 | DocScrutinizer05 | if it works for one read, why should it fail for 2nd read? |
| 17:16.18 | DocScrutinizer05 | ShadowJK: exactly |
| 17:16.19 | kerio | why "read data from X"? |
| 17:16.33 | DocScrutinizer05 | because it's written in datasheet |
| 17:17.01 | kerio | just read it once? or read and check that it's the written one? |
| 17:17.23 | kerio | anyway, /me will not risk his only n900 |
| 17:17.28 | DocScrutinizer05 | see p.23 "Programming the EEPROM" |
| 17:17.32 | kerio | DocScrutinizer05: use your 74th n900 maybe |
| 17:18.18 | DocScrutinizer05 | DANG!! |
| 17:18.34 | DocScrutinizer05 | chip does POR on leaving programming mode |
| 17:20.26 | 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 |
| 17:21.59 | *** join/#maemo-ssu futpib__ (~futpib@89.106.197.102) |
| 17:23.36 | 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 |
| 17:25.39 | DocScrutinizer05 | btw there's a huge range of "RESERVED" register addr that might (and actually do) hold valuable data and might even be writable |
| 17:26.13 | kerio | DocScrutinizer05: well, nothing *can* go wrong, right? |
| 17:26.22 | kerio | at worst you unplug the battery and wait some time |
| 17:28.18 | 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$") |
| 17:29.11 | DocScrutinizer05 | nevertheless, act on own peril, no warranties |
| 17:31.24 | 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 |
| 17:32.17 | kerio | DocScrutinizer05: was your idea to change eeprom parameters and then do a full reset? |
| 17:32.48 | DocScrutinizer05 | no |
| 17:33.04 | kerio | how is the chip supposed to "reload" the parameters then? |
| 17:33.31 | DocScrutinizer05 | a full reset restores EEPROM parameters to ram, and we can't change EEPROM values without applying VPP |
| 17:34.11 | DocScrutinizer05 | while normal operation would most likely use the ram register copies of the values |
| 17:34.25 | kerio | hm |
| 17:34.32 | DocScrutinizer05 | for ILMD that's rather useless anyway |
| 17:34.35 | kerio | i was hoping that the ram copies would persist until a power off |
| 17:34.55 | DocScrutinizer05 | since ILMD gets used only when doing a full reset |
| 17:35.05 | DocScrutinizer05 | AAAAND for cycle calculation ;-D |
| 17:35.41 | DocScrutinizer05 | kerio: power off *is* the usual cause for a full reset |
| 17:35.55 | kerio | there is a real full reset |
| 17:36.02 | kerio | write the appropriate bits to MODE and CTRL |
| 17:36.10 | DocScrutinizer05 | yeah, but what for?? |
| 17:36.30 | kerio | because we could hope it's less full than removing power to the chip :) |
| 17:36.39 | DocScrutinizer05 | meh, it isn't |
| 17:36.55 | DocScrutinizer05 | why the heck do you want to reset anyway? |
| 17:37.13 | kerio | because you just "wrote" a new ILMD, maybe :D |
| 17:38.02 | DocScrutinizer05 | heck!!! ILMD is only useful for full reset aka power-off. We don't need it for anything else (except cycle calculation) |
| 17:38.27 | DocScrutinizer05 | and for cycle calculation I guess we don't need any reset to make a change in ILMD get effective |
| 17:38.41 | kerio | battery swapping? |
| 17:38.41 | DocScrutinizer05 | shakes head |
| 17:39.14 | DocScrutinizer05 | WHAT?? why? what are you trying to get done? |
| 17:39.18 | ShadowJK | i thought cycles were counted against lmd |
| 17:39.29 | DocScrutinizer05 | no, ILMD :-S |
| 17:39.47 | kerio | DocScrutinizer05: write known LMD and NAC right after you inserted the new battery |
| 17:40.08 | 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! |
| 17:40.12 | kerio | "live" battery swap with correct-ish capacity measurement |
| 17:40.55 | DocScrutinizer05 | why bother about LMD when swapping battery? |
| 17:41.50 | DocScrutinizer05 | and how's that related to ILMD? |
| 17:42.02 | DocScrutinizer05 | which evidently we can't change for battery swap |
| 17:44.26 | 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 |
| 17:44.27 | DocScrutinizer05 | keep this bit set or cleared as desired when other bits i nthis register are set.<< |
| 17:44.48 | DocScrutinizer05 | ^^^ useless (for this purpose) |
| 17:45.25 | DocScrutinizer05 | (but actually I think chip does no full reset on exiting prog mode. I confused stuff here) |
| 17:45.43 | kerio | where's that status bit? MODE? |
| 17:46.19 | 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.<< |
| 17:46.48 | DocScrutinizer05 | ^^^ most probably including reading back EEPROM values to RAM |
| 17:48.49 | 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 |
| 17:49.53 | DocScrutinizer05 | I bet those are the complete memory of that microcontroller mapped to I2C addresses |
| 17:50.25 | DocScrutinizer05 | incl timer, auxiliary registers, PC, SP, stack and all |
| 17:51.24 | kerio | why would they be i2c-writable? |
| 17:52.37 | DocScrutinizer05 | because nobody bothered to make them r/o, if we're lucky |
| 17:54.08 | 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 |
| 17:56.16 | 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"? |
| 18:00.34 | ShadowJK | probably temporary storage for calculations and stuff |
| 18:05.28 | kerio | clearly we should port uClinux to the bq27200 |
| 18:22.19 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 18:43.52 | *** join/#maemo-ssu kolp (~quassel@212.255.224.9) |
| 19:02.00 | *** join/#maemo-ssu andre__ (~andre@wikimedia/aklapper) |
| 19:07.56 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |
| 19:22.38 | *** join/#maemo-ssu Estel^ (~Estel@d56-215.icpnet.pl) |
| 19:22.38 | *** join/#maemo-ssu Estel^ (~Estel@Maemo/community/contributor/Estel-) |
| 19:22.55 | Estel^ | ShadowJK, kerio, DocScrutinizer05, there is a limit for capacity-up learning |
| 19:23.06 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 19:23.21 | 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... |
| 19:23.37 | Estel^ | and, after certain ammount of Mah spent or time in 6%, vdq got spoiled to 0 |
| 19:23.52 | Estel^ | thats why people calibrating for dual batteries need to go by steps |
| 19:24.28 | 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) |
| 19:24.40 | Estel^ | from ~1300, one may jump to ~2300 max |
| 19:25.01 | Estel^ | er, in fact it might have been 1300->1800->2300, so 500 mA gain |
| 19:25.36 | Estel^ | haven't done it for some time, usually I'm jumping from 2048 mAh to ~3400 mAh in 2 or 3 cycles |
| 19:26.00 | Estel^ | well, two, as it's definitelly possible to go from 2000 mAh to 2800 mAh |
| 19:26.37 | 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 |
| 19:26.47 | Estel^ | definitelly iot's higher than learn-down limit, but it's there too, for 100% |
| 19:27.23 | Estel^ | best wishes to some responsible chanop, that keeps my main registered nick (Estel_) at +q state, btw. Kudos. |
| 19:27.56 | Estel^ | waves and goes for some pleasant RL |
| 19:53.32 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 20:11.18 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 20:14.44 | *** mode/#maemo-ssu [+o DocScrutinizer05] by ChanServ |
| 20:15.01 | *** mode/#maemo-ssu [-b Estel_!*@*] by DocScrutinizer05 |
| 20:15.31 | *** mode/#maemo-ssu [-q Estel_!*@*] by DocScrutinizer05 |
| 20:15.38 | *** mode/#maemo-ssu [-o DocScrutinizer05] by ChanServ |
| 20:49.46 | *** join/#maemo-ssu unclouded (~neil@2001:4428:200:80fc:e973:61cd:733:b07b) |
| 20:51.08 | Estel^ | <#maemo-ssu> [21:15] DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) changed mode: -b Estel_!*@* |
| 20:51.12 | Estel^ | <#maemo-ssu> [21:15] DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) changed mode: -q Estel_!*@* |
| 20:51.24 | Estel^ | how funny. you're luycky, that I have sense of humour and self-distance ;) |
| 20:51.30 | Estel^ | lucky, even |
| 20:52.37 | 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 |
| 20:53.36 | 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... |
| 20:53.41 | DocScrutinizer05 | listen buddy, if you got something to complain no matter what I'm doing, then i happily will revert everything |
| 20:54.08 | DocScrutinizer05 | pathetic troll |
| 20:54.13 | Estel^ | DocScrutinizer05, sorry, in my mind -b was +b |
| 20:54.25 | Estel^ | so i took it for -q +b, which would be quite funny |
| 20:54.27 | Estel^ | apologies. |
| 20:55.37 | Estel^ | doesn't need to call names, really *gives DocScrutinizer05 some sweet pink flowers with Satan inside* |
| 20:55.47 | *** join/#maemo-ssu zogg_ (~zoggrules@bzq-79-179-170-78.red.bezeqint.net) |
| 20:57.03 | 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 |
| 20:57.08 | Estel^ | to call for it |
| 20:57.35 | DocScrutinizer05 | ever wondered how often you suffer from similar distortions of your reality and nobody helps you out on it? |
| 20:57.39 | Estel^ | as for u-boot image flashed to nand, I'll do it either from device or from desktop flasher, that part is clear |
| 20:58.11 | Estel^ | DocScrutinizer05, all perceived reality is a disortion of our brain ;) |
| 20:58.56 | 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 ;) |
| 20:59.16 | Estel^ | people mean well, pink flowers, etc. |
| 21:00.32 | 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 |
| 21:01.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 |
| 21:01.04 | kerio | and then u-boot-update-bootmenu |
| 21:01.23 | Estel^ | thanks, sounds simple enough. And if I mind it? |
| 21:01.42 | kerio | then your best bet is to edit away the part that adds the attachboot entry in /ust/bin/u-boot-update-bootmenu |
| 21:02.15 | Estel^ | ok, device will boot normally, and show u-boot menu only when what? keyboard slided-out? |
| 21:02.24 | DocScrutinizer05 | or edit the original file, instead of patching the editor |
| 21:02.26 | DocScrutinizer05 | ;-P |
| 21:02.38 | Estel^ | resulting file, you mean? After editor creates it? |
| 21:03.24 | 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 |
| 21:03.38 | Estel^ | =never used it, in reality |
| 21:03.45 | 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 |
| 21:03.59 | DocScrutinizer05 | bunch even |
| 21:04.14 | Estel^ | well, used it to get into backupmenu, but that doesn't count, as it doesn't flash nand |
| 21:04.19 | Estel^ | ough |
| 21:04.40 | DocScrutinizer05 | ~trout kerio |
| 21:04.40 | infobot | ACTION slaps kerio around a bit with a large trout! |
| 21:05.20 | kerio | DocScrutinizer05: it's not my fault pali hasn't upstreamed my patch yet |
| 21:05.23 | 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)? |
| 21:05.28 | DocScrutinizer05 | hehehe |
| 21:05.29 | Estel^ | kerio, I agree |
| 21:05.34 | Estel^ | btw |
| 21:05.59 | Estel^ | hey, maybe I shgould just use your patched u-boot-update-bootmenu |
| 21:06.10 | kerio | nah, it's awful |
| 21:06.13 | Estel^ | christ, my typos. *should |
| 21:06.20 | Estel^ | what's is so awful about it?:P |
| 21:06.21 | kerio | it needs a better way to detect if there's actually an attached kernel |
| 21:06.44 | Estel^ | whatever, gimme it to me *gollum's face* |
| 21:06.51 | kerio | nope |
| 21:06.53 | Estel^ | gimme it, even |
| 21:07.19 | Estel^ | gimme it, or I will dig up the link that you've posted some weeks ago, which contain exactly thaT :p |
| 21:07.28 | kerio | that would involve 0 effort on my part |
| 21:07.31 | kerio | i'm ok with that |
| 21:07.34 | Estel^ | hehe |
| 21:07.58 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 21:08.30 | 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 |
| 21:08.46 | Estel^ | sustainable economy, etc |
| 21:09.13 | 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?... |
| 21:09.30 | kerio | the menu appears when the keyboard is open as you boot |
| 21:09.46 | 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' |
| 21:09.51 | Estel^ | OK |
| 21:10.32 | 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 |
| 21:10.32 | Estel^ | likes the idea |
| 21:10.46 | kerio | i hope you realize that you can just leave the kbd slider open |
| 21:10.55 | Estel^ | sure |
| 21:11.02 | Estel^ | that's why I've said ''exercise for sake of exercise'' |
| 21:11.17 | Estel^ | +10 k20 coolnes of using N900 when you slide out just in time |
| 21:11.28 | Estel^ | egoboost |
| 21:12.36 | 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? |
| 21:12.45 | Estel^ | how it will know what is default and what isn't? |
| 21:13.01 | Estel^ | I suppose ln -s /etc/bootmenu.d/*power* /etc/default/bootmenu.item is default |
| 21:13.16 | Estel^ | s/is default/define default thing/ |
| 21:13.36 | Estel^ | so how about non-default one, that should get available from u-boot menu? |
| 21:13.46 | kerio | yeah, the non-default ones will be available from the uboot menu |
| 21:13.52 | kerio | as will the default one |
| 21:14.03 | Estel^ | so /etc/bootmenu.d/ things are considered by u-boot-update-menu? |
| 21:14.03 | kerio | if there's no default, the default is the first one |
| 21:14.13 | kerio | if you leave the attachboot entry in, that's the first one |
| 21:14.24 | kerio | otherwise, it's the first in alphabetical order of the uboot entries in /etc/bootmenu.d |
| 21:14.42 | 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 |
| 21:15.32 | 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? |
| 21:15.42 | Estel^ | mkimage and such things can go screw themselves? |
| 21:16.34 | Estel^ | ... Whoa, shitload of things in my /etc/bootmenu.d/, that are nto actual |
| 21:16.45 | Estel^ | not* |
| 21:16.55 | Estel^ | including backupmenu, which shouldn't sit there, methinks? |
| 21:17.52 | kerio | Estel^: that's right, as a user you shouldn't be aware of the existance of mkimage |
| 21:18.04 | kerio | and that directory is shared by fanoush's bootmenu |
| 21:18.26 | Estel^ | oh, great, so how to have famoush bootmenu things like backupmenu, and u-boot without broken entries, at the same time? |
| 21:20.40 | 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 |
| 21:20.47 | Estel^ | wtf? |
| 21:21.57 | Estel^ | now when it boots, "Warning: Unable to open initial console" |
| 21:22.14 | Estel^ | Console: Switching to colour frame buffer device 100x30 |
| 21:22.26 | Estel^ | Kernel panic - not syncing: Attempted to kill init |
| 21:22.38 | Estel^ | then shutdown. heh |
| 21:22.38 | kerio | idk |
| 21:23.11 | Estel^ | fun fact, if i bash "return" to use that split second when bootmenu works, device boots normally |
| 21:23.23 | kerio | so you have a bootmenu problem |
| 21:23.26 | Estel^ | yep. |
| 21:23.57 | kerio | apt-get install --reinstall getbootstate |
| 21:24.05 | 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 |
| 21:24.07 | kerio | apt-get install --reinstall bootmenu-n900 |
| 21:24.12 | kerio | er, sorry, bootmenu |
| 21:24.27 | Estel^ | iirc, when i managed to boot ok, all future boots will work OK. Strange things. If not, i'll try reinstalling, indeed |
| 21:29.51 | Estel^ | kerio, me wonders why u-boot bootimage adds file 30-U-Boot-2012.12-rc3-1.item to /etc/bootmenu.d/ |
| 21:30.09 | DocScrutinizer05 | ((<kerio> and that directory is shared by fanoush's bootmenu)) which is the great design mistake in that whole thing |
| 21:30.16 | kerio | because the bootimage is not what you want, really |
| 21:30.33 | Estel^ | kerio, I wanted bootimage to extraxt u-boot zimage from it and flash it to nand |
| 21:30.40 | kerio | why didn't you download the deb somewhere else |
| 21:30.49 | Estel^ | btw, what is potential use case to have u-boot item in bootmenu.d? |
| 21:30.55 | kerio | multiboot, probably |
| 21:31.06 | Estel^ | because I haven't expected it to do irrational things |
| 21:31.09 | Estel^ | lol |
| 21:31.23 | Estel^ | u-boot .item for multiboot sounds... fun. Just fun. |
| 21:31.56 | Estel^ | like using bicycle dynamo to power initial ignition of 2012 hybrid car |
| 21:32.31 | Estel^ | kerio, DocScrutinizer05, I agree that sharing directory with fanoush bootmenu sounds like basic design mistake |
| 21:32.49 | kerio | it's for backwards-compatibility with multiboot |
| 21:33.03 | kerio | which uses /etc/bootmenu.d and /etc/multiboot.d |
| 21:33.07 | 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 ? |
| 21:33.20 | kerio | Estel^: just ignore the errors u-boot-update-bootmenu gives you |
| 21:33.25 | kerio | (another design mistake) |
| 21:33.34 | Estel^ | ah, it will give errors? I thought it will make fubar entries to u-boot menu |
| 21:33.41 | kerio | no, no |
| 21:33.50 | kerio | it's kinda easy to distinguish between what has a kernel entry and what doesn't :) |
| 21:34.03 | Estel^ | 3th. why won't anyone fill a bug against that design mistakes to Pali? |
| 21:34.08 | Estel^ | yea |
| 21:34.28 | DocScrutinizer05 | I'd honestly patch u-boot-update-bootmenu to use *its* *own* directory, like /etc/uboot.d |
| 21:34.36 | Estel^ | well, I guewss I;'ll extract u-boot zimage, then aplt-get purge u-boot-bootmenu |
| 21:34.37 | kerio | DocScrutinizer05: and symlink the shit out of every -bootimg? |
| 21:34.48 | DocScrutinizer05 | then just _maybe_ copy etc/bootmenu to etc/uboot.d |
| 21:35.01 | kerio | and by symlink i mean dpkg-divert |
| 21:35.32 | Estel^ | hehe, I feel another kerio's fork is going to appear. Pali will just lvoe you ;-) |
| 21:35.37 | Estel^ | s/lvoe/love/ |
| 21:35.39 | Estel^ | ffs |
| 21:36.36 | Estel^ | this whole u-boot thing confused me enough, to try installing it without doing backup |
| 21:36.41 | Estel^ | *desperado mode on* |
| 21:36.49 | Estel^ | what can go wrong, in desperado mode, we're immortal ;) |
| 21:37.35 | Estel^ | erm, what was that thing, that need to sit on MyDocs, or something in u-boot won't work as it should? |
| 21:37.45 | kerio | bootmenu.src and bootmenu.d |
| 21:38.01 | kerio | they're the script and the directory that contains the uimages |
| 21:38.07 | Estel^ | w-what? bootmenu.d wasn't on /etc/bootmenu.d/?! |
| 21:38.19 | kerio | pay attention, this is MyDocs/bootmenu.d |
| 21:38.21 | Estel^ | or is it created by u-boot-update-menu automagically on mydocs? |
| 21:38.43 | kerio | which contains the automatically-created and automatically-converted uboot images of every kernel and initrd referenced by the .item files |
| 21:39.17 | 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 |
| 21:39.28 | kerio | if uboot doesn't know what to do, it gives you a console |
| 21:39.32 | Estel^ | would need to enter u-boot console and do all shit manually to boot from sd, eh? |
| 21:39.36 | Estel^ | hehe |
| 21:39.42 | Estel^ | see? desperado mode gives +100 to intuition |
| 21:39.48 | kerio | i'm not sure if anything is loaded automatically from the sd |
| 21:39.50 | DocScrutinizer05 | select bootimage_to_add in /boot/*-bootimg*; do install-uboot-entry $(basename $bootimage_to_add) $bootimage_to_add; done |
| 21:40.19 | kerio | DocScrutinizer05: 50% of the times, it works 100% of the times |
| 21:40.46 | 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? |
| 21:41.00 | Estel^ | internal/iternal/s/ or smth loike that |
| 21:41.03 | kerio | considering that linux hasn't even entered the picture at that point... |
| 21:41.34 | Estel^ | right. Well, rationale doesn't enter picture at point of intuitional feeling ;_P |
| 21:47.07 | *** join/#maemo-ssu wmarone__ (~wmarone@c-67-174-151-253.hsd1.ca.comcast.net) |
| 21:47.20 | 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)... |
| 21:47.32 | Estel^ | ...so we will have proper terminal instead of u-boot console and unified enviromnent (tm) |
| 21:47.41 | Estel^ | ;) |
| 21:52.25 | 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" ; |
| 21:52.53 | kerio | even then, it actually doesn't work |
| 21:53.07 | DocScrutinizer05 | meh! |
| 21:53.08 | kerio | to boot a kernel you need 1) a kernel, and 2) a cmdline |
| 21:53.17 | DocScrutinizer05 | then use asm! ;-P |
| 21:53.19 | kerio | and sometimes 3) an initrd |
| 21:53.58 | DocScrutinizer05 | an initrd? |
| 21:54.12 | kerio | an initrd! |
| 21:54.16 | DocScrutinizer05 | what for? filesystem not available in the kernel? |
| 21:54.49 | kerio | *coff coff rescueos coff coff* |
| 21:55.10 | DocScrutinizer05 | cofcoff not meant to ever get installed coffcoff |
| 21:55.16 | kerio | "meant" my ass |
| 21:55.19 | kerio | it works perfectly |
| 21:55.32 | DocScrutinizer05 | actually that's the only reason why it needs an initrd |
| 21:55.47 | kerio | and it's probably indistinguishable from when you boot it from flasher |
| 21:56.54 | DocScrutinizer05 | anyway nothing that couldn't get handled inside install-uboot-entry |
| 22:00.14 | kerio | also, it's quite untrivial to do something like that |
| 22:00.24 | kerio | because the uboot menu is a single monolithic uboot script |
| 22:03.30 | DocScrutinizer05 | *shrug* doesn't do update-bootmenu-foo exactly the same? |
| 22:04.15 | DocScrutinizer05 | just that it parses files in alien directories |
| 22:05.12 | DocScrutinizer05 | instead of using find and read to find out about actually installed bootimages and get input from user interactively |
| 22:09.17 | Estel^ | kerio, could you give me ls of your /lib/modules/current ? |
| 22:09.47 | Estel^ | in my case it contains only modules.alias modules.ccwmap and simillar things, which seems like source of my problems wikth bootmenu |
| 22:10.31 | kerio | /lib/modules/current points to the kp52 directory |
| 22:10.31 | Estel^ | as vanilla /sbin/preinit have Modules_path=/lib/modules/current, and later, things load watchdogs things by modprobe $module_path/twl_blabla |
| 22:10.40 | Estel^ | well, not here |
| 22:11.09 | Estel^ | her eit points to omap1 |
| 22:11.26 | Estel^ | /lib/modules/current -> 2.6.28-omap1 |
| 22:11.46 | Estel^ | considering that 2.6.28-omap1 doesn't exist here, troubles are clear :P |
| 22:11.50 | kerio | hm, reinstall kernel-power-modules i guess |
| 22:12.11 | Estel^ | funny, did it yesterday, due to Pali.s fiasco with changing things without boosting version number |
| 22:12.21 | Estel^ | will try it again |
| 22:12.40 | kerio | one of the kernel-power packages adds the fix to preinit that makes it use `uname -a` instead of current |
| 22:13.28 | Estel^ | ah |
| 22:13.36 | Estel^ | love binary file replacements |
| 22:13.49 | kerio | it's not a binary file |
| 22:13.49 | Estel^ | having kp installed, then removing multiboot, result in /sbin/preinit being reverted to vanilla |
| 22:13.57 | Estel^ | result in kp fix going into /dev/null |
| 22:14.02 | Estel^ | you know what i mean |
| 22:14.08 | Estel^ | divert should be used,. or smth like that |
| 22:14.11 | kerio | and yeah, it should be a getbootstate fix |
| 22:14.13 | kerio | which it probably is |
| 22:14.17 | Estel^ | if you remove multiboot, or smth like that, it just silently breaks |
| 22:14.31 | kerio | then clearly multiboot has to be purged from the repos |
| 22:14.52 | Estel^ | i'm not sure if kp postinst sed things into /sbin/preinit is right thing to do |
| 22:15.01 | Estel^ | shitload of circumstances may break it |
| 22:15.03 | Estel^ | silently |
| 22:15.09 | Estel^ | with suer scratching his head about wtf |
| 22:15.16 | Estel^ | user, even |
| 22:15.35 | Estel^ | Pali, ^ |
| 22:16.05 | Estel^ | and yes, kernel-power-modules does that sed into preinit |
| 22:16.13 | Estel^ | and symlink of current to kp52 |
| 22:16.23 | Estel^ | while the latter souns like OK, the sed leaves bad taste |
| 22:16.30 | Estel^ | we have fckin divert for a purpose, don't we? |
| 22:16.56 | Estel^ | DocScrutinizer05, any comment here? I may be talking bullshit, but i think sed'ing into crucial boot scripts during postinst script is fubar |
| 22:17.19 | Estel^ | too many ways to silently break it by other packages, or even worse, by removing other packages. Or shitload of other ways |
| 22:18.02 | Estel^ | now i wonder if any other kernel-power package does simillar thing and I should be reinstalling them, too? |
| 22:18.29 | Estel^ | or smth else may be silently broken and in 2-3 weeks i'll be scratching my head about why something is fubar |
| 22:19.56 | Estel^ | from a different barrel - anyone ahve idea what sh: can't access tty: job control turned off |
| 22:20.00 | Estel^ | may mean in practice"? |
| 22:20.05 | Estel^ | (and/or how to fix it) |
| 22:20.24 | Estel^ | it happens in recovery shell bundled manually into /sbin/preinit . doesn't seem to affect anything, but... |
| 22:22.39 | *** join/#maemo-ssu arcean (~arcean@aael75.neoplus.adsl.tpnet.pl) |
| 22:39.21 | *** join/#maemo-ssu Martix_ (~martix@4.177.broadband3.iol.cz) |
| 22:56.32 | Estel^ | you know what? I feel like writing CLI re-iplementing backupmenu's function into normal console, to make use of fbcon... |
| 22:56.38 | Estel^ | without that pesky text2screen thingie |
| 22:56.53 | Estel^ | and without bootmenu requiment |
| 22:57.44 | Estel^ | just a recovery shell from /sbin/preinit, with whole backupmenu started by invoking simple script (that runs cli interface) |
| 22:57.55 | kerio | aka pali's recovery console |
| 22:58.13 | Estel^ | MentalistTraceur's recovery console > Pali's recovery console (sorry, Pali) |
| 22:58.30 | kerio | rescueOS > MT's recovery console |
| 22:58.32 | Estel^ | sure, everythingh can be done by manuyal commands, but reintroducing it as CLi make it a) faster for casual execution |
| 22:58.38 | Estel^ | RescueOs is different beast |
| 22:59.18 | Estel^ | ...b) more friendly for noobs, and I *do* want noobs to make backups early and often |
| 23:00.02 | Estel^ | after all, MT's recovery console can be run from preinit on-device itself, while for restoring borked device (without u-boot), you need external device with flasher for rescue os |
| 23:00.25 | Estel^ | rescue os is super, but it's different use-case |
| 23:00.41 | kerio | why? |
| 23:01.13 | Estel^ | ant MT's recovery shell > Pali's recovery shell, due to Pali's recovery shell being pesky about requiments and excluding some, see bootmenu, multiboot, etc. MT"s one doesn't care about that at all |
| 23:01.30 | Estel^ | well, how woulds you run rescue-os on device without multiboot, that doesn't, well, boot? |
| 23:01.32 | Estel^ | at all? |
| 23:01.38 | Estel^ | due to borked root or whatever? |
| 23:01.44 | Estel^ | no bootmenu, no anything? |
| 23:01.58 | Estel^ | and without external device to run it from flasher? |
| 23:01.59 | kerio | i wouldn't touch multiboot with a 10-foot pole |
| 23:02.09 | Estel^ | s/without multiboot/without u-boot/ |
| 23:02.15 | kerio | why would i be without u-boot? |
| 23:02.24 | kerio | also, how will you run MT's recovery shell? |
| 23:02.27 | Estel^ | *rolleyes* cause you wouldn't have it installed? |
| 23:02.33 | Estel^ | from /sbin/preinit |
| 23:02.42 | kerio | no, the rootfs is borked, remember |
| 23:02.47 | Estel^ | borked = files there messed |
| 23:02.57 | kerio | so rescueOS is fine |
| 23:03.00 | Estel^ | not whoile filesystem, the latter is quite impossible to achieve on ubifs ;) |
| 23:03.10 | Estel^ | well, for really borked rootfs, you would need rescueos |
| 23:03.12 | Estel^ | or better |
| 23:03.14 | Estel^ | reflash ;P |
| 23:03.31 | Estel^ | or rescueOs and backup restore |
| 23:04.23 | Estel^ | for real life cases, thought, when borked package or typo or whjatever user error makes your device unbootable, MT's /sbin/preinit is enough to restore device - it loads at earliest possible stage, and doesn't require 2nd device/u-boot/bootmenu/whatever |
| 23:04.49 | kerio | oh fucking hell no |
| 23:04.52 | Estel^ | if one have u-boot, I would implement both MT's recovery shell (for quick access) and rescueOs on sd (for really fuckek up situations) |
| 23:04.54 | kerio | that's incredibly far from being the earliest possible stage |
| 23:05.26 | Estel^ | well, you know what I mean- earliest as first thing sourced (preinit) |
| 23:05.38 | Estel^ | I don't attack rescueOs, it's absolutely superb tool |
| 23:06.06 | *** join/#maemo-ssu RST38h (marat@wsip-184-180-40-182.ri.ri.cox.net) |
| 23:06.07 | kerio | this reminds me, i should put rescueOS on the uSD |
| 23:06.12 | Estel^ | it's just that it's overkill to run it for 99% of simple fixes, that are achievable by 12 lines MT's recovery shell |
| 23:06.30 | Estel^ | and trust me, as soon as I'll install u-boot, I'll customzie and put rescueOs on uSD |
| 23:06.32 | Estel^ | ;) |
| 23:06.47 | kerio | i'm not entirely sure why rescueOS is "excessive", considering that it's pretty much the same amount of effort to use it |
| 23:06.52 | Estel^ | now, motivate Pali to make 0xFFFF run-able from device |
| 23:07.05 | kerio | boot with slider open, select rescueOS with arrows, push enter |
| 23:07.18 | Estel^ | well, you're probably right, as soon as you have rescueOs setup ;) |
| 23:07.37 | Estel^ | Mt's things is easier to install for noobs, properly, that's why I would bundle CLI backupmenu there |
| 23:08.02 | Estel^ | I don't want to expect people to properly install u-boot before being able to do backups, and being independent of 2nd device at the same time |
| 23:08.33 | Estel^ | just package diverting sbin/preinit to contain MT's recovery shell, and putting some scripts (backupmenu-cli) into proper places |
| 23:08.55 | Estel^ | so people can get recovery shell and backupmenu cli by installing it, and hitting any key during device early boot stage |
| 23:09.06 | Estel^ | then, if one use u-boot (everyone should), rescueOs is a must |
| 23:10.03 | Estel^ | it's just that u-boot thing is for sure overhelming for noobs, so if I want to give them backupmenu-like experience from CLI, I would bundle it into Mt's console. Hell, it can be replicated inside rescueOs too, if anyone want it |
| 23:10.11 | Estel^ | brb, changing irc device |
| 23:25.25 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
