**** BEGIN LOGGING AT Thu May 11 03:00:02 2017
May 11 09:39:00 <ant_work> bluelightning, hello
May 11 09:41:38 <ant_work> I didn't bump PR after touching that couple of zaurus-utils
May 11 09:41:55 <ant_work> do you think I can just get rid of PR? Set a PV?
May 11 09:46:55 <VartiWork> hi ant_work
May 11 09:47:57 <VartiWork> I have mentioned you in this thread: http://www.oesf.org/forum/index.php?showtopic=34551&hl=
May 11 09:48:46 <VartiWork> I hope all I wrote about badblocks is correct
May 11 09:48:51 <ant_work> hi VartiWork, I'm very busy these days...
May 11 09:49:04 <VartiWork> np
May 11 09:49:31 <ant_work> I am trying to polish the ugly code in the updater.sh but this will take more time
May 11 09:49:40 <ant_work> I'll add just my new part at first
May 11 09:49:45 <VartiWork> ok
May 11 09:49:55 <ant_work> ..and I was thinking about adding a badblock-check menu
May 11 09:50:26 <ant_work> because there is badblock binary available
May 11 09:50:30 <VartiWork> that would be useful, so you won't have to boot into diag menu just to check this
May 11 09:51:12 <ant_work> normally the bad blocks are detected and marked as such in factory
May 11 09:51:55 <ant_work> in my experience with Zaurus I have never seen a new bad block appearing
May 11 09:51:56 <ant_work> fwiw
May 11 09:52:01 <VartiWork> are there tools to remap them under jffs2, on mtd1 and 2 which, if I understand correctly, aren't handled by the mtd driver?
May 11 09:52:19 <ant_work> iirc badblock was born for block devices like hdd
May 11 09:53:11 <ant_work> mtd1 / smf must be kept intact, it has its own management
May 11 09:53:36 <ant_work> the remapping routine takes badblocks in account
May 11 09:53:52 <ant_work> my 2 cents, don't touch it
May 11 09:54:10 <ant_work> mtd2 and mtd3 are managed by the normal nand driver
May 11 09:54:15 <VartiWork> well, holovector claims his badblocks are new ones, and I remember some threads of people with bad blocks in NAND soldering a new flash in place of the old one
May 11 09:54:22 <ant_work> both are under control of MTD subsytem
May 11 09:54:56 <VartiWork> ok
May 11 09:54:56 <ant_work> I have on the C860 one badblock in mtd1 and one in mtd2
May 11 09:56:16 <VartiWork> so, as I get it they are remapped as well?
May 11 09:56:16 <ant_work> https://wiki.archlinux.org/index.php/badblocks
May 11 10:00:58 <ant_work> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229103
May 11 10:00:59 <bluelightning> ant_work: if we bump PV we can get rid of PR yes
May 11 10:01:20 <ant_work> hi, they are versionless atm
May 11 10:03:33 <ant_work> VartiWork, with MTd there are subtle issues like bitflip and eccerrors with modern nand
May 11 10:04:25 <ant_work> http://www.linux-mtd.infradead.org/tech/mtdnand/x144.html
May 11 11:00:58 <ant_work> VartiWork, finally, "NAND memory apparently gets shipped with blocks that are already bad. The vendor just marks those blocks as bad, thus resulting in higher yield and lower per-unit cost. "
May 11 11:15:42 <ant_work> VartiWork, are you proficeint with busybox shell scripts?
May 11 11:50:29 <VartiWork> in the past I have done some shorter bach scripts, but nothing busybox specific
May 11 11:55:36 <ant_work> I am not used to that syntax, I come from an old era...
May 11 11:56:11 <ant_work> anyway, I am pretty sure the code can be cleaned
May 11 11:57:01 <ant_work> these refinements are not urgent however, maybe some friend on OESF can spend some time on it
May 11 11:57:19 <ant_work> I'll go beack trying to fix the kernel now
May 11 11:57:44 <ant_work> *beack = onomatopeic sound to express disgust thinking back at it
May 11 11:58:33 <ant_work> brb
**** ENDING LOGGING AT Fri May 12 03:00:02 2017