**** BEGIN LOGGING AT Fri Jan 17 02:59:58 2014
Jan 17 11:05:58 <ant_work> argh html G-Mail....
Jan 17 11:06:31 <ant_work> lumag_: tried to ping about the patches...550-Mailing lists do not accept HTML mail
Jan 17 11:06:35 <ant_work> heh
Jan 17 11:06:39 <ant_work> bluelightning: gm
Jan 17 11:07:22 <ant_work> bluelightning: for meta-hh   http://patchwork.openembedded.org/patch/64075/
Jan 17 11:07:51 <lumag_> ant_work, hello
Jan 17 11:08:06 <lumag_> There is a button in the gmail sending interface.
Jan 17 11:09:43 <ant_work> lumag_: I'd send this patch  http://pastebin.com/XFdGN4Dg. Do you think there are too many comments?
Jan 17 11:11:24 <ant_work> the guy back in 2007 wrote this: http://tinyurl.com/ln4vny5  but I doubt changes to mtd-abi.h will be accepted
Jan 17 11:11:51 <ant_work> so I'm transforming it in fixups
Jan 17 11:13:01 <lumag_> ant_work, I like your patch.
Jan 17 11:13:07 <lumag_> Is the delay really necessary?
Jan 17 11:13:17 <ant_work> good question..not in m y tests
Jan 17 11:13:28 <lumag_> And second question - do we really need two partitions?
Jan 17 11:13:34 <lumag_> Let's drop them alltogether.
Jan 17 11:13:55 <lumag_> I'd suggest to switch to single partition mode.
Jan 17 11:14:23 <ant_work> ok, don't you think we'll have any advantage?
Jan 17 11:14:39 <ant_work> i.e. rootfs is flashed mostly on first part so data remains on the second
Jan 17 11:14:53 <ant_work> (we have just 14MB..)
Jan 17 11:15:33 <ant_work> anyway, with one partition we could rule out more risks...
Jan 17 12:07:22 <bluelightning> hi ant_work, lumag_
Jan 17 12:10:22 <bluelightning> ant_work: fix pushed, thx
Jan 17 12:11:25 <ant_work> that was quick ;)
Jan 17 17:06:22 <ant_home> lumag: repartitioning to one single partition we need a fixup to disable features bit 9 (Simultaneous operations: extp->FeatureSupport&512)
Jan 17 17:06:28 <ant_home> :/
Jan 17 17:06:46 <ant_home> let me do mtd validation with 2
Jan 17 17:10:34 <lumag> I think bit 9 just won't be used, will it?
Jan 17 17:10:47 <ant_home> unfortunately it is
Jan 17 17:10:55 <ant_home> in a key loop
Jan 17 17:11:29 <ant_home> http://lxr.free-electrons.com/source/drivers/mtd/chips/cfi_cmdset_0001.c#L793
Jan 17 17:12:06 <ant_home> it tries to avoid an erase-suspend afaik
Jan 17 17:18:06 <ant_home> urgh  ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
Jan 17 17:18:06 <ant_home>   unsigned long mask;
Jan 17 17:18:15 <ant_home> little patch needed
Jan 17 17:18:56 <ant_home> btw the QRY 'fixup' is ugly... how can it be we get 0xffff ...
Jan 17 17:20:15 <ant_home> bluelightning: take the chance and boot that collie now to full-speed ;)
Jan 17 17:20:36 <ant_home> (patches flowing on github fork)
Jan 17 17:20:41 <bluelightning> ant_home: if I get the chance over the weekend I will
Jan 17 18:10:40 <lumag> ant_home, why does suspend cmd correlate with partitioning?
Jan 17 21:57:33 <ant_home> lumag: actual rework:  https://github.com/andrea-adami/meta-handheld
Jan 17 21:58:05 <bikerr> heya ant
Jan 17 21:58:17 <ant_home> hi bikerr
Jan 17 21:58:26 <bikerr> any plans for kexecboot 0.7?
Jan 17 21:59:02 <bikerr> i need to get all my ARM work from a qsd/MSM device over to a exynox device , some changes i'd like to make before 0.7
Jan 17 21:59:22 <ant_home> heh, once I move on to another device ;)
Jan 17 21:59:44 <bikerr> great :D
Jan 17 21:59:59 <ant_home> Jay7: do you have time to review/rework the patches in queue?
Jan 17 22:00:22 <bikerr> just as well this qsd8k device decided usb wasnt a connector it really needed :D got quite fed up with being stuck on pre 2.6.38 kernels
Jan 17 22:02:05 <ant_home> bikerr: we have some interesting patches here
Jan 17 22:02:05 <ant_home> https://github.com/kexecboot/kexecboot/network
Jan 17 22:02:45 <ant_home> actually, I didn't follow last kexec development but for arm should just work as before
Jan 17 22:03:19 <ant_home> bikerr: do you have signed kernels/modules ?
Jan 17 22:03:38 <bikerr> ah, i would be the pink one, threader
Jan 17 22:04:15 <ant_home> does exynos need the hardboot patch?
Jan 17 22:04:18 <bikerr> thankfully not, so far i've been using a fastbootable device, so bricking it is hard
Jan 17 22:04:37 <bikerr> unsure, havent found a kernel that will compile yet...
Jan 17 22:04:44 <bikerr> atleast not cleanly enough for me
Jan 17 22:05:10 <bikerr> found a kernel that seemed promising, but apparently it is maintained by idiots
Jan 17 22:05:47 <bikerr> loads of these people should never be allowed within KM's of a kernel source
Jan 17 22:05:59 <ant_home> :)
Jan 17 22:06:54 <bikerr> i think the S2 which i use as a dev platform now, wants signed boot images, it displays a triangle with a ! in it when booting, but that doesnt bother me
Jan 17 22:06:59 <bikerr> but its not a requirement
Jan 17 22:07:22 <bikerr> also i am hopelessly in need of a powered usb , since the TS dosnt work
Jan 17 22:08:08 <bikerr> so i guess everything has reached a screeching halt until i can muster up the courage to fix yet another kernel
Jan 17 22:08:23 <ant_home> ouch
Jan 17 22:09:13 <bikerr> or bother with replacing the usb on the qsd8k... which i am putting off right until the last seconds before the apocalypse
Jan 17 22:10:29 <bikerr> kexec worked ,  i could boot android, debian and whatever, but i had to use android to launch kexecboot, which was great, it meant i could launch adb and basically have a fully working linux booting in 2 seconds , but as soon as i launched android, i lost adb a bunch of services, i guess its not freeing up some resources when i launches
Jan 17 22:10:35 <bikerr> launch the new kernel*
Jan 17 22:10:55 <bikerr> apart from that kexec and kexecboot solved a load problem....
Jan 17 22:17:13 <lumag> ant_home,  why does suspend cmd correlate with partitioning?
Jan 17 22:18:33 <ant_home> if you have dualwork/simultaneous operations the flash can read without suspending an evtl erase
Jan 17 22:19:05 <ant_home> i.e. if the suspended sector is in part0 and the block to read is on part1
Jan 17 22:19:23 <ant_home> ubi bkg thread does lot of erase
Jan 17 22:19:55 <ant_home> is the wear leveling, sort of trim for SSD
Jan 17 22:20:01 <ant_home> ?
Jan 17 22:21:29 <ant_home> lumag: unfortunately the cfi code checks for a PWS register while in theory the status check should be done on each partition before write/erase
Jan 17 22:21:52 <ant_home> I have seen that adding those checks seems minimizing the erase-suspend
Jan 17 22:22:10 <ant_home> I'm doing mtd stresstest right now...
Jan 17 22:24:56 <lumag> ant_home, so you propose to leave two partitions so that we can have two simultaneous writes?
Jan 17 22:25:50 <ant_home> no, one single erase/write is allowed
Jan 17 22:26:43 <ant_home> you can read while the other partition is writing
Jan 17 22:26:47 <lumag> Ah.
Jan 17 22:26:54 <lumag> I get it now.
Jan 17 22:27:17 <ant_home> I think this is aimed at custom embedded devices
Jan 17 22:27:28 <ant_home> they talk about 'data' and 'code'
Jan 17 22:27:45 <lumag> Yes.
Jan 17 22:28:24 <ant_home> I really don't think we get great benefits...
Jan 17 22:28:53 <ant_home> opie has some benchmarks, maybe I'll try that
Jan 17 22:29:51 <lumag> Synthetic benchmarks might get synthetic results. The overall benefit would really depend on reading while writing.
Jan 17 22:53:26 <ant_home> hm... I'm seeing some sort of corruption
Jan 17 22:54:08 <ant_home> 'device (31, 3) is too small
Jan 17 22:54:23 <ant_home> so kexecboot does not show it...
Jan 17 22:54:38 <ant_home> this with ubi images, jffs2 is ok
Jan 17 22:59:29 <ant_home> strange, can mount/umount booting from CF
Jan 17 22:59:38 <ant_home> must be a bad cooked image ;)
Jan 17 23:19:51 <ant_home> do.. mtd_speedtest shows now slower read and faster write...
Jan 17 23:23:02 <ant_home> now survives to long mtd_stresstest :)
Jan 17 23:36:35 <lumag> ant_home, don't kill your flash
Jan 17 23:37:12 <ant_home> 100 runs...
Jan 17 23:37:24 <ant_home> now finishing torturetest
Jan 17 23:37:32 <ant_home> both were failing before
Jan 17 23:39:36 <ant_home> that one will be short... root@collie:~# modprobe mtd_torturetest eb=0 ebcnt=112 dev=2 cycles_count=5
Jan 17 23:40:21 <ant_home> anyway I think the best test is a real fs, with concurrent write/read
Jan 17 23:40:56 <ant_home> mtd_torturetest: finished after 5 erase cycles
Jan 17 23:42:54 <ant_home> now root@collie:~# modprobe mtd_stresstest dev=2 count=1000
Jan 17 23:46:29 <ant_home> (default is 10000)
Jan 17 23:49:15 <ant_home> mtd_stresstest: finished, 1000 operations done
Jan 17 23:49:22 <ant_home> lumag: enough?
Jan 17 23:49:54 <lumag> ant_home, I really fear that you will wear your flash once .
Jan 17 23:50:31 <ant_home> heh, the fun part is, on every ubiformat I forget to pass the -e XX so the erase counter is reset to 0
Jan 17 23:50:33 <ant_home> :/
Jan 17 23:51:02 <ant_home> probably the kernel has been flashed on mtd1 2-300 times
Jan 17 23:51:08 <ant_home> at least...
Jan 17 23:51:20 <ant_home> joking ;)
Jan 17 23:51:32 <lumag> I thin wearing level is about 10 or 100 thousand.
Jan 18 00:22:19 <ant_home> well, it seems that for ubifs in real use (not empty volume) one more fix is needed
Jan 18 00:23:12 <ant_home> rapid mount/umount -> stall
Jan 18 00:37:26 <ant_home> maybe I'm testing the wrong kernel...too late
Jan 18 00:37:29 <ant_home> gn
**** ENDING LOGGING AT Sat Jan 18 02:59:59 2014