| 01:38.28 | *** join/#maemo-ssu infobot (~infobot@rikers.org) |
| 01:38.28 | *** topic/#maemo-ssu is Maemo Community Seamless Software Update "CSSU" channel, http://wiki.maemo.org/Community_SSU | Known bugs: http://j.mp/communityssu-bugs | Channel logs: http://mg.pov.lt/maemo-ssu-irclog/ | Sources: http://gitorious.org/community-ssu/ | Latest version (testing): 21.2011.38-1Tmaemo5.1; (stable): 21.2011.38-1Smaemo4.1 |
| 01:38.28 | *** mode/#maemo-ssu [+v infobot] by ChanServ |
| 01:47.03 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 01:50.00 | *** join/#maemo-ssu Sicelo (Sicelo@gets.high.on.ircspeed.net) |
| 08:12.00 | *** join/#maemo-ssu infobot (~infobot@rikers.org) |
| 08:12.00 | *** topic/#maemo-ssu is Maemo Community Seamless Software Update "CSSU" channel, http://wiki.maemo.org/Community_SSU | Known bugs: http://j.mp/communityssu-bugs | Channel logs: http://mg.pov.lt/maemo-ssu-irclog/ | Sources: http://gitorious.org/community-ssu/ | Latest version (testing): 21.2011.38-1Tmaemo5.1; (stable): 21.2011.38-1Smaemo4.1 |
| 08:12.00 | *** mode/#maemo-ssu [+v infobot] by ChanServ |
| 08:55.28 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 09:02.58 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-102-207-166.net.upcbroadband.cz) |
| 09:04.23 | *** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm) |
| 09:08.25 | freemangordon | merlin1991: http://pastebin.com/1V7KmVFj |
| 09:08.40 | freemangordon | the code is at the end |
| 09:09.45 | merlin1991 | hm and what should I do now? :D |
| 09:09.55 | freemangordon | NFC |
| 09:10.08 | freemangordon | :D |
| 09:10.38 | freemangordon | runs away |
| 09:10.43 | freemangordon | :P |
| 09:11.02 | freemangordon | merlin1991: anyway, latest valgrind works almost like charm |
| 09:11.42 | freemangordon | so we can check all of the stuff in CSSU |
| 09:11.45 | tadzik | well, valgrind is usually going crazy on glib/gtk |
| 09:11.52 | tadzik | but yeah, this is exceptinoal :) |
| 09:12.10 | freemangordon | tadzik: hmm, this one is 3.81 |
| 09:12.33 | luf | freemangordon: where you get the code? |
| 09:12.40 | tadzik | I remember debugging my xmpp client with it. Gtk throwing up its own errors, glib its own, loudmouth and openssl as well... |
| 09:12.40 | freemangordon | and excluding the fact i had to revert libpuls0 to non-thumb, everything else works |
| 09:12.48 | freemangordon | luf: from their site |
| 09:12.57 | tadzik | even hello worlds from gnome site weren't free of valgrind errors :) |
| 09:13.06 | tadzik | I guess that has something to do with custom memory allocators that glib uses |
| 09:13.25 | freemangordon | G_SLICE=always-malloc G_DEBUG=gc-friendly |
| 09:13.42 | tadzik | oh, TIL :) |
| 09:13.52 | freemangordon | luf: ./configure, make |
| 09:14.28 | freemangordon | luf: though configure needs some trickery. I'll tar.gz and upload it later. /opt/valgrind that is |
| 09:15.15 | jon_y | freemangordon: cool, you have valgrind on the n900 working? |
| 09:15.43 | tadzik | hah. That'd be "slow" redefined :) |
| 09:16.42 | luf | jon_y: it's not so big problem. |
| 09:17.07 | luf | jon_y: I have also working valgrind on n900. |
| 09:19.52 | freemangordon | luf: 3.61? |
| 09:20.15 | freemangordon | the one in extras-devel? |
| 09:20.28 | luf | I don't remember the version. But I don't compile it. I find some leaks in obexd ... |
| 09:20.52 | luf | I'm sorry I don't remember. I think some newer. But maybe from repository. |
| 09:20.54 | freemangordon | when I find some time i'll fire it agains h-d and h-h |
| 09:21.30 | freemangordon | luf: it is 3.6.1 in repos |
| 09:21.59 | luf | freemangordon: and yes obexd and bluez is very slow under valgrind on N900 :) |
| 09:22.07 | merlin1991 | freemangordon: better prepare yourself for serious mindfuck when you do that :D |
| 09:22.23 | freemangordon | luf: I am sure it is |
| 09:22.44 | luf | I have valgrind 3.6.0 |
| 09:22.45 | freemangordon | merlin1991: didn't we have some bug raised agains pixman? |
| 09:22.56 | *** join/#maemo-ssu Timo (~timo@unaffiliated/tiempjuuh) |
| 09:22.57 | luf | Sorry 3.6.1 |
| 09:23.06 | luf | So from repos. |
| 09:23.12 | merlin1991 | freemangordon: lemme check |
| 09:23.35 | freemangordon | merlin1991: I am on my way to office, bbl |
| 09:25.59 | merlin1991 | freemangordon: couldn't find a bug on that |
| 09:27.05 | *** join/#maemo-ssu arcean (~arcean@aadb66.neoplus.adsl.tpnet.pl) |
| 09:30.20 | *** join/#maemo-ssu andre__ (~andre@ip-84-42-203-5.net.upcbroadband.cz) |
| 09:30.20 | *** join/#maemo-ssu andre__ (~andre@wikimedia/aklapper) |
| 09:44.42 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 10:19.48 | freemangordon | merlin1991: is pixman in CSSU at all? |
| 10:20.39 | merlin1991 | err I don't even know what pixam exactly is |
| 10:20.44 | merlin1991 | *pixman* |
| 10:21.02 | freemangordon | oops, sorry, libpixman |
| 10:23.31 | freemangordon | merlin1991: http://maemo.org/packages/package_instance/view/fremantle_sdk_free_i386/libpixman-1-0/0.16.2-5+0m5/ |
| 10:24.04 | merlin1991 | hm afaik we have no source package pixman |
| 10:24.37 | freemangordon | well, we'd better have one then :D |
| 10:25.39 | freemangordon | lemme try to find some repo |
| 10:27.08 | DocScrutinizer05 | mooo |
| 10:31.02 | merlin1991 | freemangordon: what's the bug to fix? |
| 10:31.10 | merlin1991 | DocScrutinizer05 aka "the cow" |
| 10:32.15 | merlin1991 | thinks new -testing will go out tonight |
| 10:32.22 | DocScrutinizer05 | ~moo |
| 10:32.22 | infobot | ACTION mooooooooo! I am cow, hear me moo, I weigh twice as much as you. I am cow, eating grass, methane gas comes out my ass |
| 10:32.51 | freemangordon | LOL |
| 10:33.03 | freemangordon | merlin1991: Invalid read of size 1 |
| 10:33.14 | freemangordon | at 0x48344E8: strncmp (mc_replace_strmem.c:547) |
| 10:33.25 | merlin1991 | DocScrutinizer05: isn't there a cow joke in apt aswell? |
| 10:33.52 | merlin1991 | yep apt-get moo exists :D |
| 10:34.02 | tadzik | and aptitude moo :) |
| 10:36.29 | Pali | aptitude moo |
| 10:36.31 | Pali | aptitude moo -v |
| 10:36.33 | Pali | aptitude moo -vv |
| 10:36.39 | Pali | aptitude moo -vvv |
| 10:36.49 | Pali | and add more 'v' :D |
| 10:37.30 | *** join/#maemo-ssu lizardo (lizardo@nat/indt/x-nbkuszczgmphfxkm) |
| 10:37.57 | merlin1991 | anybody know the origin of the moo joke? |
| 10:38.06 | merlin1991 | is too young to know |
| 10:41.42 | *** join/#maemo-ssu Martix (~martix@eduroam-183.fi.muni.cz) |
| 10:42.23 | freemangordon | merlin1991: pixman seems like upstream animal |
| 10:42.42 | freemangordon | http://cgit.freedesktop.org/pixman/refs/tags |
| 10:44.42 | merlin1991 | now we just have to compare the source from the sdk with the 0.16.2 tag |
| 10:46.49 | *** join/#maemo-ssu Martix (~martix@eduroam-183.fi.muni.cz) |
| 10:57.35 | *** join/#maemo-ssu Martix (~martix@eduroam-183.fi.muni.cz) |
| 10:58.11 | freemangordon | merlin1991: yeah |
| 10:59.12 | merlin1991 | and pray that it isn't a tarball + patches like some other packages in fremantle |
| 10:59.30 | merlin1991 | looks @ sqlite |
| 10:59.42 | freemangordon | merlin1991: I got the sources from maemo SDK repo, there is no debian/patches dir |
| 11:00.16 | freemangordon | hmm, maybe we can upgrade to lates |
| 11:00.18 | freemangordon | t |
| 11:01.32 | merlin1991 | hm if you're willing to check everything for regessions/api changes ;) |
| 11:04.26 | freemangordon | well, at least we can upgrade to 16.6 |
| 11:04.54 | merlin1991 | freemangordon: well basically, why? |
| 11:05.26 | freemangordon | i bet there is a bunch of NEON optimizations |
| 11:06.17 | merlin1991 | goes over the log |
| 11:06.25 | merlin1991 | or rather watches git clone |
| 11:06.37 | freemangordon | aah |
| 11:06.58 | merlin1991 | fsckd ath9k driver keeps failing hrere |
| 11:07.02 | merlin1991 | s/hrere/here/ |
| 11:10.07 | merlin1991 | hm apart from the assertion change the diff from 0.16.2 to 0.16.6 is minimal |
| 11:12.43 | freemangordon | merlin1991: is our bug fixed? |
| 11:13.05 | merlin1991 | I still didn't grasp what our bug is |
| 11:13.21 | freemangordon | merlin1991: invalid memory acces |
| 11:13.23 | freemangordon | s |
| 11:13.52 | merlin1991 | I've seen no changes related to that |
| 11:14.29 | merlin1991 | all there is is a change on handling of alphamaps |
| 11:16.23 | freemangordon | merlin1991: if (strncmp (plat, "v7l", 3) == 0) |
| 11:17.56 | freemangordon | that one makes an invalid memory access according to valgrind |
| 11:18.35 | merlin1991 | well that looks ok depending on where the fuck "plat" points |
| 11:26.49 | freemangordon | merlin1991: could be false alarm |
| 11:28.23 | freemangordon | http://old.nabble.com/valgrind%3A-r13019%3A-Implement-a-fake--proc-self-auxv-file-for-linux-systems.-td34515798.html |
| 11:32.43 | Pali | freemangordon, where is git repo of linux kernel for n900? |
| 11:33.23 | Pali | I want to boot some upstream kernel for maemo5 and test bme replacement |
| 11:38.40 | Pali | DocScrutinizer05, merlin1991, freemangordon, in /etc/event.d/rcS-late is code which writing some info to /sys/kernel/debug/panic_info_buff which is written to mtdoops when kernel crash |
| 11:39.01 | Pali | what do you think to patch it to write also 1) kernel version string and 2) CSSU version ? |
| 11:39.14 | Pali | now it writing only output of osso-product-info |
| 11:40.47 | *** join/#maemo-ssu Martix (~martix@ip-62-245-106-78.net.upcbroadband.cz) |
| 11:46.40 | freemangordon | Pali: what git repo? |
| 11:47.05 | Pali | freemangordon, 3.x kernel for maemo5 |
| 11:49.47 | freemangordon | Pali: have to ask Skry |
| 11:49.51 | Skry | I have 3.5 in github but that's not intended for maemo but the device itself for other os |
| 11:49.59 | freemangordon | Skry: yeah |
| 11:50.18 | freemangordon | Pali: my patches are on merlin1991's server |
| 11:50.32 | freemangordon | but maybe you don;t need them |
| 11:50.56 | freemangordon | ssi and sgx |
| 11:51.07 | Pali | ok |
| 11:51.50 | freemangordon | aiui you don't need X to test bqxxx |
| 11:52.08 | Pali | X will be good too :-) |
| 11:52.19 | Pali | hildon-status-menu for battery applet |
| 11:53.16 | Pali | freemangordon, what do you think about adding kernel & cssu version to panic info buffer? |
| 11:54.02 | freemangordon | Pali: well, not a bad idea. though i'll prefer kernel in CSSU first :) |
| 11:54.14 | Pali | ok |
| 11:55.52 | Pali | freemangordon, do you know how to get CSSU version string? |
| 11:56.16 | Pali | maybe that which is in about cssu dialog in control panel |
| 11:57.33 | freemangordon | Pali: NFC |
| 11:58.04 | merlin1991 | Pali: well cssu version is in mp-fremantle-community-pr |
| 11:58.24 | merlin1991 | you could ie use dpkg, though is /var/ mounted at that point? |
| 11:58.24 | Pali | ok, I found it: https://gitorious.org/community-ssu/libcpaboutcssu/blobs/master/src/libcpaboutcssu.c#line26 |
| 11:58.53 | Pali | /var/ ... /dpkg is in rootfs |
| 11:59.17 | merlin1991 | Pali: that call is overly complex xD |
| 11:59.48 | Pali | any other idea how to get that version string? |
| 12:00.04 | merlin1991 | I did find a call to dpkg to get the version |
| 12:00.08 | merlin1991 | checks logs |
| 12:00.17 | Skry | Pali: if you get charger working with upstream kernel could you notify me and perhaps send me some patches? I did try it something like a month ago and got it to a point where driver reports it's charging and something is definetely happening in background, but bq27xxx reports that battery is still discharging. |
| 12:00.51 | Pali | Skry, now charging and battery drivers was pushed to battery git tree |
| 12:01.13 | Pali | I need to write proper glue between isp and bq2415x drivers for charger type detection |
| 12:01.24 | Pali | and sent that patch to upstream kernel too |
| 12:01.53 | Pali | Skry, I will write to you |
| 12:03.15 | DocScrutinizer05 | Pali: ((write also 1) kernel version string and 2) CSSU version)) all thumbs up for that |
| 12:03.15 | Skry | Pali: ok, thanks. And in case you would like to test it out yourself I have some patches and .config for 3.7 if you happen to need such. |
| 12:03.17 | Pali | merlin1991, maybe this? $ dpkg-query -W -f \${Version} mp-fremantle-community-pr |
| 12:03.33 | merlin1991 | Pali: yep |
| 12:03.36 | merlin1991 | just found it myself :D |
| 12:04.12 | Pali | Skry, yes I'd like to use new version :-) |
| 12:04.21 | Pali | do you have git tree for that? |
| 12:05.43 | DocScrutinizer05 | sweet: cat /sys/kernel/debug/omap_gpio |
| 12:06.12 | Pali | and for kernel version, should I use? $ uname -a |
| 12:06.56 | DocScrutinizer05 | uname -a sounds like a good choice |
| 12:06.57 | Skry | Pali: only local for now, but it follows linux-omap. I have tested it with arch linux, it works but musb is currently not working, though I think it is fixed in upstream already. |
| 12:07.44 | Skry | I've had quite some lost of interest lately so haven't been that active with it |
| 12:08.22 | DocScrutinizer05 | Pali: please don't expect /var/*/dpks to be in rootfs |
| 12:08.40 | DocScrutinizer05 | users may and actually do optify it |
| 12:09.13 | DocScrutinizer05 | so at very least have a fallback for gentle fail-over |
| 12:09.21 | Pali | DocScrutinizer05, I will call dpkg-query command. if it fails (e.g. optified) then it will write empty string to panic buf |
| 12:09.31 | DocScrutinizer05 | fair enough |
| 12:09.42 | Skry | Pali: I'll rebase my tree to latest in linux-omap master and see if there's anything new, adapt my few patches and send them to you with config later today, ok? |
| 12:09.43 | Pali | but now I see that panic buf is filled after MOUNTS_OK |
| 12:09.58 | Pali | Skry, ok |
| 12:10.05 | DocScrutinizer05 | Pali: just make sure that script doesn't throw error in that case |
| 12:10.12 | Pali | Skry, can you merge your tree with battery tree? |
| 12:10.35 | Pali | DocScrutinizer05, now I'm going to fix that rcS-late script to work also on upstream kernel |
| 12:10.49 | Pali | (adding maemo-command || true) |
| 12:11.05 | DocScrutinizer05 | good :-) |
| 12:11.11 | Pali | we have upstart in cssu and rcS-late is in upstart |
| 12:11.16 | DocScrutinizer05 | use ||: |
| 12:11.30 | DocScrutinizer05 | shorter ;) |
| 12:12.06 | DocScrutinizer05 | (I hope that's no bash'ism |
| 12:12.07 | DocScrutinizer05 | ) |
| 12:12.34 | Skry | Pali: I'll try it out later today |
| 12:12.50 | Pali | Skry: http://git.infradead.org/battery-2.6.git/shortlog/HEAD |
| 12:12.55 | DocScrutinizer05 | well, messybox 'knows' `:` |
| 12:13.03 | DocScrutinizer05 | checked it |
| 12:13.16 | Pali | Skry, see patches for rx51_battery and bq2415x_charger and bq27x00_battery |
| 12:13.18 | DocScrutinizer05 | the totally empty command |
| 12:13.43 | Pali | nice :-) |
| 12:18.23 | DocScrutinizer05 | of course you could do sth like >> (dpk-query ... || echo "dpk faled, no info on cssu version. user optified /var/*/dpkginfo?") >>/sys/kernel/debug/panic_info_buff |
| 12:20.07 | Pali | DocScrutinizer05, that script is called after MOUNTS_OK |
| 12:20.12 | Pali | so when /opt is mounted |
| 12:20.37 | Pali | so if dpkg fail then system is in very very broken state or cssu is not installed |
| 12:20.50 | DocScrutinizer05 | you're free to edit the || echo string anyway |
| 12:20.56 | Pali | s/cssu/cssu metapackage/ |
| 12:21.52 | DocScrutinizer05 | or simply do dpkg 2>&1 ||: |
| 12:22.10 | Pali | we do not want very very long string in panic info buffer |
| 12:22.21 | DocScrutinizer05 | we don't? |
| 12:22.25 | DocScrutinizer05 | why notß |
| 12:22.29 | DocScrutinizer05 | ? |
| 12:22.33 | Pali | yes, because buffer is small |
| 12:22.46 | Pali | and it is written to mtdlog |
| 12:22.50 | DocScrutinizer05 | well, dunno it might have some 16k or sth |
| 12:23.05 | DocScrutinizer05 | and mtdlog is huuuge |
| 12:23.09 | Pali | I think "<unknown>" is ok |
| 12:23.20 | DocScrutinizer05 | whatever you like |
| 12:23.56 | Pali | I think that osso-product-info also write <unknown> when SW version in CAL is removed |
| 12:24.41 | DocScrutinizer05 | sure |
| 12:25.39 | DocScrutinizer05 | btw I gave a rant about a related topic in here, some weeks ago |
| 12:25.44 | DocScrutinizer05 | can't recall |
| 12:26.07 | DocScrutinizer05 | some file in /etc/* we ought fill with cssu-product-info |
| 12:26.53 | DocScrutinizer05 | found some reference to it in rcs-late or sth |
| 12:27.52 | Pali | /etc/event.d/rcS-late |
| 12:29.36 | DocScrutinizer05 | dafaq, seems busybox froze on :<cr> ?? |
| 12:29.36 | Pali | commited: https://gitorious.org/community-ssu/upstart/commits/master |
| 12:29.58 | DocScrutinizer05 | or my wifi ssh lags like hell |
| 12:30.59 | DocScrutinizer05 | sth odd with my iron900 wifi connection |
| 12:31.06 | Pali | AAAA, busybox grep does not have -R |
| 12:32.20 | Pali | only (small) -r |
| 12:32.32 | *** join/#maemo-ssu kolp (~quassel@212.255.44.208) |
| 12:34.37 | DocScrutinizer05 | preinit, line 197 |
| 12:34.48 | merlin1991 | Pali: why do we need the lowmem fix? |
| 12:34.49 | DocScrutinizer05 | release=`cat /etc/osso_software_version` |
| 12:35.28 | Pali | merlin1991, because lowmem is maemo extension |
| 12:35.59 | Pali | I want to boot some upstream kernel and that rcS-late script failing here... |
| 12:37.17 | Pali | /etc/osso_software_version -> I do not have this file |
| 12:37.17 | DocScrutinizer05 | I *think* every CSSU update should `echo 2011.38.1Tmaemo5 >/etc/osso_software_version` |
| 12:37.27 | DocScrutinizer05 | Pali: that's the point |
| 12:38.31 | DocScrutinizer05 | Pali: so it's relatively low risk to create it, with proper content |
| 12:38.32 | Pali | and there is something other: every cssu upgrade calling: osso-product-info -s OSSO_VERSION="RX-51_2009SE_21.2011.38-1_PR_MR0" 2> /dev/null || exit 0 |
| 12:38.48 | Pali | and it always write new string to CAL |
| 12:39.02 | Pali | and if is same, it write it too |
| 12:39.06 | Pali | this is bad |
| 12:39.49 | DocScrutinizer05 | no issues here with osso-product-info -s |
| 12:39.54 | DocScrutinizer05 | why do you think it' |
| 12:39.57 | DocScrutinizer05 | s bad? |
| 12:40.14 | Pali | useless CAL write |
| 12:40.39 | kerio | Pali: fix osso-product-info then :) |
| 12:40.40 | DocScrutinizer05 | hmmm |
| 12:40.53 | Pali | kerio, osso-procuct-info is closed |
| 12:40.58 | DocScrutinizer05 | I don't think it's useless |
| 12:41.05 | Pali | I will fix it in postinst |
| 12:41.15 | Pali | $ if test "$(osso-product-info -q OSSO_VERSION)" = "RX-51_2009SE_21.2011.38-1_PR_MR0"; then exit 0; fi |
| 12:41.48 | DocScrutinizer05 | actually I love 'history' in CAL |
| 12:42.42 | DocScrutinizer05 | I don't see why we're concerned about it |
| 12:42.53 | Pali | so above "if" fix writing to CAL same version string |
| 12:43.26 | DocScrutinizer05 | I love it writing even same string to CAL, where's the problem in it doing that? |
| 12:43.51 | Pali | mess in CAL |
| 12:43.57 | DocScrutinizer05 | lol |
| 12:44.17 | DocScrutinizer05 | your fix will only change that to another kind of mess |
| 12:44.32 | Pali | and also wear leveling... |
| 12:44.37 | DocScrutinizer05 | I don't see how's that new mess any better than the old |
| 12:44.45 | DocScrutinizer05 | oh well, wear leveling |
| 12:44.54 | Pali | if you upgrade CSSU metapackage for testing 1000000x cal can be damaged |
| 12:45.07 | DocScrutinizer05 | not really |
| 12:45.19 | DocScrutinizer05 | you need at least 10^5 times that |
| 12:45.36 | kerio | a million erases doesn't sound like much, over the whole mtd partition |
| 12:45.41 | DocScrutinizer05 | since not every write to CAL already does a page erase |
| 12:45.57 | Pali | do you trust libcal?? |
| 12:46.12 | Pali | I not |
| 12:46.28 | kerio | i trust libcal |
| 12:46.33 | DocScrutinizer05 | not a good rationale for a "fix" |
| 12:46.50 | kerio | can the onenand be repartitioned? |
| 12:47.04 | kerio | or is the layout static from something closed? |
| 12:47.07 | DocScrutinizer05 | yes. but NOLO and flasher can't |
| 12:47.18 | DocScrutinizer05 | the latter, kerio |
| 12:47.35 | DocScrutinizer05 | afaik |
| 12:47.40 | kerio | DocScrutinizer05: use initfs as cal from the kernel side, or something |
| 12:48.04 | kerio | NOLO only *reads* from cal, right? |
| 12:48.22 | DocScrutinizer05 | well, nope |
| 12:48.30 | DocScrutinizer05 | it writes flags there |
| 12:48.41 | kerio | oh, heh |
| 12:49.01 | kerio | i'm not sure i trust *that* actually |
| 12:49.24 | DocScrutinizer05 | anyway, there's no demand for any fixing regarding CAL yet |
| 12:49.48 | DocScrutinizer05 | neither for waer leveling nor for any other reason |
| 12:50.22 | DocScrutinizer05 | it's absolutely fine the way it works right now, in my book |
| 13:02.04 | Pali | NOLO has own mtd layout. it using CAL, kernel and initfs |
| 13:02.15 | freemangordon | Pali: we have libcal REed, look at it for how writes are handled |
| 13:02.26 | Pali | but kernel can use other layout |
| 13:02.42 | Pali | if you replace NOLO you can reparition as you want |
| 13:15.40 | DocScrutinizer05 | actually a NOLO binary patcher "repartitioner" would be a rather nice tool |
| 13:21.25 | Pali | DocScrutinizer05, I forgot that partition layout is stored in CAL |
| 13:21.40 | Pali | but problem is that format of layout is unknown |
| 13:21.43 | DocScrutinizer05 | really? |
| 13:21.46 | Pali | yes |
| 13:22.08 | Pali | but I do not know if NOLO using it |
| 13:22.11 | DocScrutinizer05 | that's kinda weird since CAL already starts at $random-addr in MTD |
| 13:22.38 | Pali | when I booted NOLO in qemu without kernel it shown me serial console |
| 13:22.39 | DocScrutinizer05 | so the partition with CAL contains info about own starting addr |
| 13:22.44 | Pali | and there is command to show mtdparts |
| 13:23.02 | Pali | and in nolo there was separate partitin for xloader and separate for nolo |
| 13:23.23 | Pali | but in /proc/mtd is only ONE partition for bootloader |
| 13:24.05 | Pali | $ calvaria -d mtd1dump -n part_table |
| 13:24.25 | Pali | CAL key for partition is "part_table" |
| 13:29.46 | kolp | Just curious, what's CAL? |
| 13:29.56 | *** join/#maemo-ssu Raimu-X (rmaunula@tuomi.oulu.fi) |
| 13:30.02 | *** join/#maemo-ssu mickname_ (luodemm1@lyta.org.aalto.fi) |
| 13:33.19 | *** join/#maemo-ssu chainsawbike_ (~chainsawb@unaffiliated/chainsawbike) |
| 13:33.46 | DocScrutinizer05 | ~cal |
| 13:33.46 | infobot | well, cal is a calendar. try $(cal 1752) |
| 13:33.52 | DocScrutinizer05 | dang |
| 13:34.16 | DocScrutinizer05 | IroN900:~# cat /proc/mtd |
| 13:34.18 | DocScrutinizer05 | dev: size erasesize name |
| 13:34.19 | DocScrutinizer05 | mtd0: 00020000 00020000 "bootloader" |
| 13:34.21 | DocScrutinizer05 | mtd1: 00060000 00020000 "config" |
| 13:34.28 | DocScrutinizer05 | config=CAL |
| 13:34.57 | DocScrutinizer05 | http://talk.maemo.org/showthread.php?t=20465 |
| 13:36.33 | DocScrutinizer05 | ~$(cal 1752) |
| 13:37.11 | DocScrutinizer05 | ~factinfo cal |
| 13:37.11 | infobot | cal -- created by cafuego <cafuego@caffeine.ipv6.cafuego.net> at Tue Jun 10 07:37:04 2003 (3452 days); it has been requested 9 times, last by DocScrutinizer05, 3m 25s ago. |
| 13:38.45 | DocScrutinizer05 | kolp: less -f /dev/mtd1ro |
| 13:39.21 | DocScrutinizer05 | part-table is very first entry |
| 13:40.22 | DocScrutinizer05 | alas quite obscure, and we know fremantle boots even when CAL got nuked (nandtester checked that for us ;-D ) |
| 13:41.20 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 13:41.23 | merlin1991 | I've got one n900 where cal seems to be fsckd |
| 13:41.31 | DocScrutinizer05 | strings /dev/mtd1ro|less; for beginners |
| 13:42.26 | kolp | DocScrutinizer05: ty |
| 13:42.30 | DocScrutinizer05 | yw |
| 13:42.53 | DocScrutinizer05 | kolp: NEVER think of writing to CAL! |
| 13:43.00 | DocScrutinizer05 | it's not restorable |
| 13:43.16 | DocScrutinizer05 | (first approach) |
| 13:43.39 | DocScrutinizer05 | (now for 2nd, advanced approach:) |
| 13:43.48 | kolp | Mkay, though I didn't intend to :) |
| 13:44.05 | DocScrutinizer05 | merlin1991: so why don't you try and nandwrite a copy of some other N900 to your nuked CAL? |
| 13:44.30 | DocScrutinizer05 | kerio will love to assist |
| 14:00.29 | *** join/#maemo-ssu Skry (~skry@81-175-148-124.bb.dnainternet.fi) |
| 14:10.41 | *** join/#maemo-ssu arcean (~arcean@aadb66.neoplus.adsl.tpnet.pl) |
| 14:39.48 | *** join/#maemo-ssu Timo (~timo@unaffiliated/tiempjuuh) |
| 14:54.34 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 14:56.59 | *** join/#maemo-ssu arcean_ (~arcean@aadb66.neoplus.adsl.tpnet.pl) |
| 14:57.20 | *** join/#maemo-ssu FIQ (~fiq@unaffiliated/fiq) |
| 15:05.10 | merlin1991 | hm actually I have 2 devices where osso-product-info mostly says "<unkown>" |
| 15:06.57 | *** join/#maemo-ssu Skry (~skry@81-175-148-124.bb.dnainternet.fi) |
| 15:28.40 | *** join/#maemo-ssu arcean (~arcean@aadb66.neoplus.adsl.tpnet.pl) |
| 15:35.13 | *** join/#maemo-ssu tg (~tg@irc.tgbit.net) |
| 15:49.48 | *** join/#maemo-ssu myuu_- (~miku@pool-108-27-193-212.nycmny.fios.verizon.net) |
| 15:51.34 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 16:32.00 | kerio | DocScrutinizer05: i'll most likely not love to assist >:c |
| 16:32.11 | kerio | moving a CAL from a n900 to another is probably a road to bricking |
| 16:32.49 | kerio | unless there are 0 bad blocks in the same partition on both N900s, and they have the same hw rev |
| 16:33.27 | kerio | i think that once you have a copy of cal, you can dump the *contents* and write them on the device to a brand-new CAL with libcal or the reverse engineered one |
| 16:34.42 | *** join/#maemo-ssu iDont (~iDont@dhcp-077-250-143-002.chello.nl) |
| 16:43.53 | DocScrutinizer05 | kerio: that's BS, we sorted that out, with nandwrite |
| 16:44.37 | DocScrutinizer05 | nadwrite is made to deal with bad blocks |
| 16:45.11 | DocScrutinizer05 | you're right about hw-rev though, would be nice if they'd match |
| 16:47.43 | DocScrutinizer05 | if your destination mtd partition has more bad blocks than your origin partition, then nandwrite will spit out a warning/error about image to write exceeds available space, that's all |
| 16:57.41 | *** join/#maemo-ssu NIN101 (~NIN@p5DD29401.dip0.t-ipconnect.de) |
| 17:08.29 | kerio | DocScrutinizer05: what's a bad block there, btw? |
| 17:08.39 | kerio | a full eraseblock? |
| 17:08.45 | kerio | if so, i doubt libcal will handle it |
| 17:09.55 | kerio | i mean, cal is a linked list, you have pointers to the next item |
| 17:10.02 | kerio | if you have a bad block and you skip that block... |
| 17:16.30 | *** join/#maemo-ssu NIN102 (~NIN@p5DD293C4.dip0.t-ipconnect.de) |
| 17:20.05 | *** join/#maemo-ssu corepl (~NIN@p5DD293F0.dip0.t-ipconnect.de) |
| 17:22.33 | *** join/#maemo-ssu toxaris (~toxaris@s83-180-246-172.cust.tele2.se) |
| 17:24.22 | *** join/#maemo-ssu toxarisswe (~toxaris@s83-180-246-172.cust.tele2.se) |
| 17:25.46 | *** join/#maemo-ssu l4m3rx (~l4m3rx@darknet.escom.bg) |
| 17:44.27 | DocScrutinizer05 | you can bet on libcal handling bad blocks |
| 17:45.38 | kerio | yeah but it *handles* bad blocks |
| 17:46.00 | kerio | it doesn't necessarily handle a nanddump of a written cal partition nandwritten on a different partition |
| 17:46.30 | kerio | freemangordon: would libcal handle that? |
| 17:46.30 | DocScrutinizer05 | hmm, valid concern |
| 17:49.01 | DocScrutinizer05 | btw a linked list would be about the worst data structure for CAL you could possibly think of |
| 17:49.24 | DocScrutinizer05 | I guess it's rather just scanning for labels, basically a grep |
| 17:50.16 | DocScrutinizer05 | since there's absolutely no use in changing the forward pointer in an existing record, on NAND |
| 17:51.41 | DocScrutinizer05 | unless, well... you could define all zeroes or all ones as a void pointer marking last element, and overwrite that with a pointer to new element on a rewrite |
| 17:51.47 | *** join/#maemo-ssu NIN101 (~NIN@p5DD293F0.dip0.t-ipconnect.de) |
| 17:52.17 | DocScrutinizer05 | still hardly any useful data structure |
| 17:53.00 | DocScrutinizer05 | simply have tags with magic numbers, grep for those, get the one with newest date, highest index, or whatever |
| 17:53.44 | DocScrutinizer05 | I mean, libcal isn't meant to be speed optimized |
| 17:54.11 | DocScrutinizer05 | check calvaria code if you're interested in details. I didn't |
| 17:54.31 | *** join/#maemo-ssu NIN102 (~NIN@p5DD2915A.dip0.t-ipconnect.de) |
| 18:00.30 | DocScrutinizer05 | kerio: see https://dev.openwrt.org/browser/packages/utils/calvaria/files/src/calvaria.c#L25, much like I expected |
| 18:01.19 | DocScrutinizer05 | #define HDR_MAGIC "ConF" |
| 18:01.31 | DocScrutinizer05 | already thought as much :-P |
| 18:02.04 | DocScrutinizer05 | actually that's how I manually parsed less -f /dev/mtd1 so far |
| 18:02.22 | kerio | DocScrutinizer05: i suppose they wanted to reduce writes as much as they could? idk |
| 18:02.24 | DocScrutinizer05 | without reading any calcaria.c code |
| 18:04.07 | kerio | how do they figure out where to write once the space is filled? |
| 18:06.14 | kerio | DocScrutinizer05: when do blocks become invalid? |
| 18:07.05 | DocScrutinizer05 | libcal will scan for an erase page that has no valid records, then erase that |
| 18:07.18 | kerio | oh so they're marked invalid at some point |
| 18:07.29 | kerio | when they're skipped |
| 18:07.37 | DocScrutinizer05 | well, for whatever 'marked as invalid' means |
| 18:07.51 | kerio | DocScrutinizer05: deleted record, or overwritten record |
| 18:08.55 | DocScrutinizer05 | https://dev.openwrt.org/browser/packages/utils/calvaria/files/src/calvaria.c#L279 |
| 18:09.23 | DocScrutinizer05 | basically a record is invalid if there's another more valid record for same label |
| 18:10.46 | DocScrutinizer05 | you could also purge a record by overwriting it without prior page erase |
| 18:11.12 | DocScrutinizer05 | mind you, writing 1s is possible while writing 0s needs page erase (or other way round) |
| 18:11.46 | kerio | what's wrong about erasing the page and rewriting it? |
| 18:12.03 | DocScrutinizer05 | takes time and wears out NAND |
| 18:12.16 | DocScrutinizer05 | takes really loooooooooong |
| 18:12.32 | kerio | really? :o |
| 18:12.41 | DocScrutinizer05 | like 20ms |
| 18:12.46 | DocScrutinizer05 | or 100 |
| 18:12.48 | DocScrutinizer05 | or 1 |
| 18:13.16 | DocScrutinizer05 | a time you could grep like 10000 CAL partitions for a label |
| 18:14.06 | DocScrutinizer05 | and actually it's the page erase that wears out NAND the most |
| 18:14.52 | DocScrutinizer05 | it's a really brute force physical event that clears nand ersase pages |
| 18:15.42 | kerio | oic |
| 18:16.14 | kerio | is it really a good idea to use a full eraseblock for each element then? |
| 18:16.43 | DocScrutinizer05 | do they do that? |
| 18:16.50 | kerio | idk, i hope not |
| 18:17.00 | DocScrutinizer05 | I wouldn't think they do |
| 18:17.30 | DocScrutinizer05 | I'd guess they pack some 10s to 100s of elements into one erase page |
| 18:19.18 | DocScrutinizer05 | btw they could as well do something nifty: if only two more erase pages left, they copy all valid elements from a completely filled erase page to an empty one, then erase that page as it's now free |
| 18:20.10 | DocScrutinizer05 | s/an empty one/ empty slots on partially used erase pages/ |
| 18:20.56 | DocScrutinizer05 | avoids fragmentation, and simplifies picking a erase page to free |
| 18:20.58 | kerio | DocScrutinizer05: i wonder what's the best way of implementing a nand-friendly hashtable |
| 18:21.53 | DocScrutinizer05 | I bet there are implementations for that already, probably done as master thesis |
| 18:22.08 | DocScrutinizer05 | I'd say: don't |
| 18:22.25 | kerio | at a phd level? :o |
| 18:22.28 | DocScrutinizer05 | you don't wanna use a hash table on NAND |
| 18:22.55 | kerio | it doesn't seem that difficult, you just have to minimize the writing of zeros everywhere |
| 18:23.26 | kerio | today's key word is UNDERSTATEMENT |
| 18:23.40 | DocScrutinizer05 | however with my initial suggestion of late writing of forward pointers, you could do. If you also implement a "deleted" flag for late tagging as purged |
| 18:25.18 | kerio | DocScrutinizer05: i suppose that the big problem here is that you have to be able to parse and write that format from NOLO |
| 18:25.33 | kerio | so you probably want to keep it simple |
| 18:25.47 | DocScrutinizer05 | at some level however, you'll have to revert to brute force forward scan/grep, as every hash table is incomplete at some point, and then you get no sort order for elements you add later on |
| 18:26.54 | DocScrutinizer05 | kerio: keep in mind NOLO even could load a complete linux to RAM to delegate some tasks like these |
| 18:27.02 | DocScrutinizer05 | depends on flasher only |
| 18:28.47 | DocScrutinizer05 | NOLO as well could expose a *very* basic API to handle NAND (CAL) rewrites, something like word read(addr), write(addr, word), erasepage(pagenumber) |
| 18:29.00 | DocScrutinizer05 | all the rest again up to flasher |
| 18:29.23 | DocScrutinizer05 | so... no problem with complexity of handling CAL rewrites in NOLO |
| 18:30.38 | DocScrutinizer05 | hell, NOLO could even export a simulated JTAG |
| 18:31.00 | kerio | DocScrutinizer05: usb mtd! |
| 18:31.04 | DocScrutinizer05 | JTAG has 4 pins |
| 18:31.54 | DocScrutinizer05 | flasher would implement an embedded JTAG programmer then |
| 18:32.16 | DocScrutinizer05 | we simply don't know |
| 18:35.52 | DocScrutinizer05 | ~wiki jtag |
| 18:38.55 | DocScrutinizer05 | actually JTAG is the smartest invention since intersil 4004 |
| 18:42.59 | DocScrutinizer05 | ooops, s/intersil/intel/ |
| 18:43.40 | DocScrutinizer05 | or rather, s/4004/IM6100/ |
| 18:57.30 | *** join/#maemo-ssu Martix (~martix@ip-62-245-106-78.net.upcbroadband.cz) |
| 19:22.05 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 19:23.21 | *** join/#maemo-ssu arcean (~arcean@aadb66.neoplus.adsl.tpnet.pl) |
| 20:21.53 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 20:49.02 | *** join/#maemo-ssu arcean (~arcean@aadb66.neoplus.adsl.tpnet.pl) |
| 21:29.05 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 21:29.12 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-102-207-166.net.upcbroadband.cz) |
| 21:32.58 | *** join/#maemo-ssu arcean (~arcean@aadb66.neoplus.adsl.tpnet.pl) |
| 21:45.21 | *** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
| 21:57.59 | *** join/#maemo-ssu peetah (~peetah@cha92-9-82-236-202-86.fbx.proxad.net) |
| 22:10.23 | kerio | anyway, weird idea: add /var/lib/apt, /var/cache/apt, /var/cache/dpkg to maemo-optify-whatever.conf |
| 23:18.10 | *** join/#maemo-ssu dedis6 (~dedis6@akw403.cs.yale.edu) |
| 23:23.41 | *** join/#maemo-ssu ekze (~nyan@bakaekze.ru) |
| 23:35.16 | *** join/#maemo-ssu wumpwoast (~jcassidy@63.251.248.156) |