**** BEGIN LOGGING AT Fri Sep 25 02:59:59 2015
Sep 25 04:27:43 <DocScrutinizer05> https://github.com/TI-OpenLink/firmwares/commit/d726804dbc8dad88587b6be17716714cd91ed86c
Sep 25 04:34:46 <DocScrutinizer05> do NOT update wl1251-nvs.bin!
Sep 25 04:42:07 <DocScrutinizer05> nevermind, at least on *my* N900 the firmware is already "up to date" - strange the last commit was Felipe Balbi on Oct 2, 2013
Sep 25 05:11:07 <KotCzarny> doc, does that mean every n900 has unique firmware or just specific version for n900-device
Sep 25 05:12:35 <DocScrutinizer05> this means every wl1251 device seems to use same firmware as N900. even the NVS calibration
Sep 25 05:13:43 <DocScrutinizer05> and I checked on t900 (my devel device that's basically still on PR1.2) - same firmware and nvs there, dates 2010
Sep 25 05:14:32 <DocScrutinizer05> so it seems Felippe Balbi checked in to github in 2013 what been shipped with N900 since 2009
Sep 25 05:15:07 <DocScrutinizer05> anyway interesting stuff maybe: http://linuxwireless.org/en/users/Drivers/wl12xx/calibrator/
Sep 25 11:18:54 <Wizzup> ~flashing
Sep 25 11:18:54 <infobot> somebody said maemo-flashing was http://wiki.maemo.org/Updating_the_tablet_firmware, or - on linux PC - download&extract http://maemo.cloud-7.de/maemo5/patches_n_tools/maemo-my-private-workdir.tgz, cd into it, do sudo ./flash-it-all.sh
Sep 25 11:19:04 <Wizzup> ~emmc
Sep 25 11:19:04 <infobot> well, emmc is is http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22YHFSICNA/--LID--FiRe1275051276916/AE98ED9D_RX-51_2009SE_10.2010.13-2.CENTRAL-EUROPE_PR_EMMC_MR0_ARM.bin or see ~emmc2
Sep 25 11:19:13 <Wizzup> ~emmc2
Sep 25 11:19:14 <infobot> it has been said that emmc2 is http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22FGDOJCSI/--LID--FiRe1275064390175/163EC1AE_RX-51_2009SE_10.2010.13-2.IBERIA_PR_EMMC_MR0_ARM.bin, or http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22VHGOMWUG/--LID--FiRe1274862877184/E3AD4912_RX-51_2009SE_10.2010.13-2.SEAP_PR_EMMC_MR0_ARM.bin, or see emmc3
Sep 25 11:19:28 <KotCzarny> o.O
Sep 25 11:19:34 <Wizzup> hm?
Sep 25 11:19:43 <KotCzarny> ~listkeys emmc
Sep 25 11:19:44 <infobot> Factoid search of 'emmc' by key (6): #maemo emmc ;; emmc #DEL# ;; emmcinfo ;; emmc ;; #maemo emmc2 ;; #maemo emmc3.
Sep 25 11:19:47 <Wizzup> hehe
Sep 25 11:19:53 <Wizzup> What was the other part/image that you need to flash
Sep 25 11:19:58 <KotCzarny> thought it will list images for every region
Sep 25 11:19:58 <Wizzup> (I'm helping someone else get the images)
Sep 25 11:20:07 <KotCzarny> wizzup, just use the doc's script
Sep 25 11:20:11 <KotCzarny> ./flash-it-all.sh
Sep 25 11:20:18 <Wizzup> ack
Sep 25 11:20:19 <KotCzarny> it will do everything automatically
Sep 25 11:20:39 <KotCzarny> also it will ask if you need flashing emmc too
Sep 25 11:21:10 <Wizzup> ok, but it doesn't contain the images
Sep 25 11:21:14 <KotCzarny> it does
Sep 25 11:21:18 <Wizzup> I just downloaded it
Sep 25 11:21:22 <KotCzarny> run it
Sep 25 11:22:45 <Wizzup> right, the script fetches them
Sep 25 11:23:03 <KotCzarny> if not present already
Sep 25 11:23:15 <Wizzup> well, the tar is 54k
Sep 25 11:23:19 <Wizzup> clearly they are not :P 
Sep 25 11:23:22 <Wizzup> thx.
Sep 25 11:42:42 <jon_y> ~listkeys extras
Sep 25 11:42:44 <infobot> Factoid search of 'extras' by key (13): extras-devel ;; extras-devel #DEL# ;; said extras ;; extras ;; extras-devel-light ;; extras-uploading ;; extras-product ;; uploading-extras ;; hildon-extras ;; upload-extras ;; fortune-mod-extras ;; extras-upload ;; extras-testing.
Sep 25 11:43:03 <jon_y> ~extras-devel
Sep 25 11:43:04 <infobot> it has been said that extras-devel is http://wiki.maemo.org/Extras-devel
Sep 25 22:28:00 <Maxdamantus> Almost done translating bq27200.sh to C.
Sep 25 22:37:41 <ShadowJK> ehh.. Pali did that kinda for the kernel version of it?
Sep 25 22:38:27 <Maxdamantus> Kernel version as in a userspace program that reads /sys/class/power_supply/bq27200-0/registers ?
Sep 25 22:39:12 <Maxdamantus> or kernel version as in the module that provides that directory in sysfs?
Sep 25 22:41:07 <Wizzup> The mainline kernel has that build in yeah
Sep 25 22:41:11 <Wizzup> afaik
Sep 25 22:41:14 <Wizzup> built*
Sep 25 22:41:15 <Wizzup> merged and all
Sep 25 22:42:31 <Maxdamantus> Actually, I don't think the mainline kernel provides as much information.
Sep 25 22:43:07 <Maxdamantus> and the module in the N900 kernel doesn't provide all that information textually. It just provides a "registers" file that you can interpret from userspace.
Sep 25 22:43:24 <Maxdamantus> along with common things like mAh, capacity, etc in separate files.
Sep 25 22:44:12 <Maxdamantus> (by the mainline kernel not providing that much information, I mean I don't think it provides that "registers" file, so you can't gather all that information)
Sep 25 22:47:51 <Maxdamantus> https://gist.github.com/Maxdamantus/3b4f2fbcb2c49fc663f9
Sep 25 22:48:51 <DocScrutinizer05> why do you need that in C?
Sep 25 22:49:09 <Wizzup> Maxdamantus: have you tried mainline?
Sep 25 22:49:32 <Maxdamantus> Wizzup: yes, and iirc, I observed what I described.
Sep 25 22:49:54 <Maxdamantus> DocScrutinizer05: because it's a waste of CPU creating a sed process to read it.
Sep 25 22:50:07 <Wizzup> DocScrutinizer05: he doesn't like the UNIX philosophyt :) 
Sep 25 22:50:08 <DocScrutinizer05> hmm
Sep 25 22:51:19 <Maxdamantus> Actually, I don't think sed is the expensive part in my modified bash part .. it's just the fact that it's doing all the arithmetic in bash.
Sep 25 22:51:34 <Maxdamantus> which involves converting strings to ints and back again.
Sep 25 22:51:59 <Maxdamantus> and doing normal bash reduction on strings.
Sep 25 22:52:23 <DocScrutinizer05> I can't find a sed invocation in bq27200.sh
Sep 25 22:52:55 <Maxdamantus> `user    0m0.234s` vs. `user    0m0.000s`
Sep 25 22:52:57 <ShadowJK> The i2cget calls use most of the cpu
Sep 25 22:53:03 <ShadowJK> or whatever it was named
Sep 25 22:53:17 <Maxdamantus> Yeah, I replaced the i2cget calls with something that reads an array produced by sed.
Sep 25 22:53:33 <DocScrutinizer05> huh?
Sep 25 22:54:06 <ShadowJK> DocScrutinizer05: more like the version you had for freerunner, I think?
Sep 25 22:54:15 <DocScrutinizer05> prolly
Sep 25 22:54:30 <Maxdamantus> https://gist.githubusercontent.com/Maxdamantus/0e743d419ccf8b38c278/raw/3d8cf7b691dd87147de89c500c0133ce13a137d1/gistfile1.txt
Sep 25 22:54:35 <Maxdamantus> eval "$(sed 's/^/registers[$((/; s/=/))]=/' </sys/class/power_supply/bq27200-0/registers)"
Sep 25 22:54:37 <DocScrutinizer05> using the /dump aka /registers sysfs node I guess
Sep 25 22:54:38 <Maxdamantus> ./i2cget (){ echo "${registers[$(($4))]}"; }
Sep 25 22:56:04 <Maxdamantus> Also, the C version looks a lot cleaner.
Sep 25 22:56:15 <DocScrutinizer05> aha
Sep 25 22:56:25 <DocScrutinizer05> well, whatever pleases you :-)
Sep 25 22:56:54 <Maxdamantus> even though most of it was translated with sed.
Sep 25 22:58:27 <DocScrutinizer05> http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27k-detail-perl  http://maemo.cloud-7.de/maemo5/patches_n_tools/bq27k.py
Sep 25 22:59:54 <DocScrutinizer05> from a resources POV the I2C queries to the bq27200 schip are eating more energy than the CPU processing this stuff in whatever source language
Sep 25 23:00:11 <DocScrutinizer05> chip*
Sep 25 23:01:11 <Maxdamantus> unless it's bash.
Sep 25 23:01:40 <DocScrutinizer05> and probably i2cdump or /sys/*/*/*/(registers|dump) is using less energy than reading the chip's registers one by one
Sep 25 23:02:09 <DocScrutinizer05> no, even with bash the CPU energy use is way smaller than what's eaten by I2C bus
Sep 25 23:02:27 <DocScrutinizer05> my guess
Sep 25 23:02:56 <DocScrutinizer05> CPU can actually do an insane amount of calculations with very low energy
Sep 25 23:03:17 <DocScrutinizer05> IO via GPIOs otoh eats electric energy by design
Sep 25 23:16:20 <Maxdamantus> Anyway, https://gist.github.com/Maxdamantus/ada1412f3ef6ae1c440e
Sep 25 23:19:38 <Maxdamantus> The excessive brackets are the reminants of the bash notation.
Sep 25 23:27:11 <DocScrutinizer05> http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27k-detail2 ;-)
Sep 25 23:28:38 * Maxdamantus doesn't have anything matched by that `find`
Sep 25 23:29:27 <DocScrutinizer05> that find is for FreeRunner
Sep 25 23:29:35 <Maxdamantus> Ah.
Sep 25 23:30:16 <DocScrutinizer05> could easily get adapted to also work on N900, when bq27xx kernel module loaded (which is only the case with power kernel and BME replacement afaik)
Sep 25 23:30:16 <Maxdamantus> and that `s3c24xx_pwm.0` presumably has a different set of registers.
Sep 25 23:30:52 <DocScrutinizer05> no, the registers are all the same, the chip is bq27000 on freeRunner
Sep 25 23:31:47 <DocScrutinizer05> the structure of /sys/*/dump is slightly different to N900's /sys/*/registers though, I guess
Sep 25 23:32:21 <DocScrutinizer05> s3c24xx is the SoC of Freerunner
Sep 25 23:34:07 <DocScrutinizer05> HDQ is the 1wire protocol of BQ27000
Sep 25 23:38:33 <DocScrutinizer05> other than I2C vs HDQ interface, the Bq27200 and BQ2700 chips are identical
Sep 25 23:42:56 <DocScrutinizer05> but your c binary has one huge advantage: can get set suid, so normal unprivileged user may use it as well
Sep 25 23:43:26 <Maxdamantus> You can read the `registers` file from sysfs without root ime.
Sep 25 23:43:32 <Maxdamantus> maybe that's why it's not in mainline.
Sep 25 23:43:38 <Maxdamantus> (again, iirc)
Sep 25 23:44:30 <DocScrutinizer05> hmm, yeah for that sysfs registers node that's OK. However for normal users we don't have that and you need to revert to i2cget or i2cdump, and that for sure needs root permissions
Sep 25 23:45:19 <DocScrutinizer05> and no, there's nothing wrong with /sys/*/registers being world readable
Sep 25 23:45:59 <Maxdamantus> wouldn't reading it constantly use more power than a busy loop?
Sep 25 23:46:06 <Maxdamantus> unless it's throttled by the kernel module.
Sep 25 23:46:11 <DocScrutinizer05> sorry?
Sep 25 23:46:29 <Maxdamantus> dunno if it does the commands over i2c every time it's read.
Sep 25 23:46:47 <DocScrutinizer05> shouldn't afaik
Sep 25 23:47:03 <DocScrutinizer05> but that's err, what's the point?
Sep 25 23:47:06 <Maxdamantus> I remember looking at the source code for it, can't remember what I found.
Sep 25 23:47:24 <Maxdamantus> if it uses lots of power issuing commands over i2c, as you said earlier.
Sep 25 23:47:46 <DocScrutinizer05> still don't get the "wouldn't reading it constantly use more power than a busy loop?"
Sep 25 23:48:00 <Maxdamantus> 11:02:09 < DocScrutinizer05> no, even with bash the CPU energy use is way smaller than what's eaten by I2C bus
Sep 25 23:48:03 <Maxdamantus> 11:02:56 < DocScrutinizer05> CPU can actually do an insane amount of calculations with very low energy
Sep 25 23:48:06 <Maxdamantus> 11:03:17 < DocScrutinizer05> IO via GPIOs otoh eats electric energy by design
Sep 25 23:48:36 <DocScrutinizer05> where do I mention a busy loop there?
Sep 25 23:49:36 <Maxdamantus> You're saying that the computations involved in handling the results of the i2c reads are going to use less power than the i2c reads themselves.
Sep 25 23:49:46 <DocScrutinizer05> yes
Sep 25 23:50:20 <Maxdamantus> so if someone intentionally or accidentally drained power using a busy loop, it wouldn't be as effective as draining the power using a busy i2c reading loop.
Sep 25 23:50:40 <DocScrutinizer05> err, yes
Sep 25 23:51:10 <DocScrutinizer05> for whatever reason somebody would want to do that, the mere statement is correct
Sep 25 23:51:35 <Maxdamantus> Right, and that might be something mainline would be concerned about.
Sep 25 23:51:44 <DocScrutinizer05> why?
Sep 25 23:51:49 <DocScrutinizer05> and how?
Sep 25 23:52:09 <Maxdamantus> because the ability to use computing power is a given for userspace.
Sep 25 23:52:26 <Maxdamantus> as well as power involved in hardware it has access to through /dev etc
Sep 25 23:52:40 <Maxdamantus> both of those things can be controlled using already well-undestood means (ulimit, file permissions)
Sep 25 23:52:58 <Maxdamantus> if you can waste power just by reading files in /sys, it's kind of weird and unexpected.
Sep 25 23:53:10 <DocScrutinizer05> err, really?
Sep 25 23:53:13 <Wizzup> uh
Sep 25 23:53:16 <Maxdamantus> I imagine so.
Sep 25 23:53:17 <Wizzup> that stuff is on-demand
Sep 25 23:53:27 <Wizzup> it's not all reading-from-kernel-structures
Sep 25 23:53:32 <Maxdamantus> tar -c /sys >/dev/null
Sep 25 23:53:33 <Wizzup> that's what /proc is mostly
Sep 25 23:53:46 <Wizzup> Maxdamantus: ... those are nodes
Sep 25 23:53:52 <Wizzup> wait, no, that's dev.
Sep 25 23:54:07 <Maxdamantus> dev isn't special.
Sep 25 23:54:21 <Wizzup> Please don't take what I say out of context
Sep 25 23:54:23 <Maxdamantus> sys and proc are special, and it's up to the implementors of the files.
Sep 25 23:54:40 <Wizzup> My train of thought was that tax simply takes the nodes from dev, without reading the contents.
Sep 25 23:54:47 <Wizzup> was that tar*
Sep 25 23:54:57 <Wizzup> but I wrongly applied that to /sys
Sep 25 23:55:06 <Maxdamantus> Ah, right.
Sep 25 23:55:12 <DocScrutinizer05> what about access to storage, via "while :;do ls -R /;done"? even more effective wasting power on interface to a subsystem than I2C access via /sys
Sep 25 23:55:25 <Maxdamantus> Yes, because /dev isn't special, it just has normal device files, which aren't read by tar.
Sep 25 23:55:31 <Wizzup> yes
Sep 25 23:55:51 <Wizzup> I believe that not all info in /sys is "just ready", I would be surprised if it is, at least. Reading said files invokes kernel functions, some of them may do comms
Sep 25 23:56:29 <Maxdamantus> Wizzup: I'd intuitively expect it not to waste too much power doing it.
Sep 25 23:56:34 <Wizzup> also, tar on /sys raises a lot of errors, so the time it takes may not be too proper
Sep 25 23:56:45 <Maxdamantus> since part of the point of /sys is that the user should be able to look through it and guess the interfaces.
Sep 25 23:57:02 <Wizzup> stat is not the same as read/open, though
Sep 25 23:57:13 <Maxdamantus> so if there's some information there that's expensive to retrieve, the kernel module providing it should be caching it or something.
Sep 25 23:57:18 <DocScrutinizer05> guessing is a rather difficult to implement algorithm
Sep 25 23:57:34 <DocScrutinizer05> I tried it with "find"
Sep 25 23:57:43 <Wizzup> Maxdamantus: or ... fetch it every x ms? that may waste more time
Sep 25 23:57:54 <Wizzup> if it's only an on demand value, better let userspace figure that out
Sep 25 23:58:01 <Wizzup> but yeah, IDN. I'd have to look at the source.
Sep 25 23:58:04 <Wizzup> bedtime. :) 
Sep 25 23:58:41 <Maxdamantus> I figured out how to control the status light by looking through /sys
Sep 25 23:58:45 <DocScrutinizer05> this went far off original topic, anyway
Sep 25 23:58:56 <Maxdamantus> at least, how to set it to particular colours, not program it.
Sep 25 23:59:17 <Wizzup> Maxdamantus: yes - I found them on mainline as well. wrt programming: depending on what you mean, you can use the led trigger system
Sep 25 23:59:23 <Wizzup> or alt. just write to the files
Sep 25 23:59:44 <Wizzup> for example, you can hookup usb activity to leds using the proper trigger
Sep 25 23:59:51 <Maxdamantus> Wizzup: I mean loading and executing code understood by the LED controller, whatever it's called.
Sep 25 23:59:58 <Wizzup> Ah.
Sep 26 00:00:03 <Maxdamantus> the stuff in /etc/mce.ini
Sep 26 00:00:13 <Wizzup> there's a program for it as well
Sep 26 00:00:21 <DocScrutinizer05> there's no reason why a world readable sysfs node particularly for bq27xx should cause any concerns in upstream or anywhere
Sep 26 00:00:23 <Wizzup> (a gui to edit led patterns)
Sep 26 00:00:36 <Wizzup> DocScrutinizer05: grsec hides most of /sys for non root though
Sep 26 00:00:38 <Wizzup> but yeah. generally.
Sep 26 00:00:41 <Maxdamantus> 4000257f06ff7f0041000000
Sep 26 00:01:09 <Maxdamantus> that's a program to pulsate the light orange without a break.
Sep 26 00:01:56 <DocScrutinizer05> meh, it only gets interesting with a program calculating primes ;-)
Sep 26 00:02:19 <Maxdamantus> It can't do that. It's not as powerful as perl's regex.
Sep 26 00:02:30 <DocScrutinizer05> which the LP5523 actually can do
Sep 26 00:03:02 <Maxdamantus> Hm.
Sep 26 00:03:41 <DocScrutinizer05> it has 2 or 3 8bit vars and a complete set of math and conditional branching commands
Sep 26 00:04:35 <DocScrutinizer05> and I seen somebody claiming he wrote a program that calculates primes on LP5523
Sep 26 00:06:45 <DocScrutinizer05> https://lkml.org/lkml/2015/6/22/207
Sep 26 00:13:43 <DocScrutinizer05> can't find the blog article(?) that wrote about that little hack on LP5523
Sep 26 00:26:36 <DocScrutinizer05> or i2ctools otoh (actually for i2c dev node) it's pretty clear why root permissions are needed. you actually could nuke your hardware with it
Sep 26 00:26:51 <DocScrutinizer05> for*
**** ENDING LOGGING AT Sat Sep 26 02:59:59 2015