#milkymist IRC log for Saturday, 2011-10-22

wpwrakwolfspraul: you'll like this: my 20000+ cycles run finally corrupted flickernoise, so i had to stop it and set things up again manually (the script only auto-recovers the standby partition)08:58
wpwrakon that occasion, i checked the other partitions. guess what i found ? the first block had gotten locked, while the next four were unlocked. my lock setup script unlocks the first five blocks.08:59
wpwrakso either this script had made an error (seems unlikely, but who knows) and i didn't check the locks bits (i normally do this, but i don't know if i also did it in this case), or ...09:01
wpwrak... the bus noise has actually generated the block locking pattern ;-)09:01
wpwraksince the vast majority of corruptions happens in the first block, it then took a long time until the next hit in an unprotected partition09:05
wolfspraulcannot follow09:50
wolfspraulso the 'locking' our latest script is doing is believed to be effective or not?09:50
wolfspraulin your case it sounds like an unlocked block went to locked?09:50
rohheyho11:45
rohsimple question out of wondering.. why not use a modern flash chip which doesnt unlock so easy?11:45
wpwrakwolfspraul: 2x yes :) the locking seems to work very well. i.e., i've had not a single instance of corruption of a locked block. so the partitions we can lock are safe.12:01
wpwrakor rather, reasonably safe, because of the other problem12:02
wpwrakthe new observation is that an unlocked block seems to have gone to locked. i suspect, this is because the "random" pattern written to the NOR just happened to contain a lock command12:03
wpwraknow, an unlock command would have a similar probability of being randomly generated. i don't really know the probability. one sample just tells us that it's possible, but little else.12:04
wpwrakso there's a very low probability that murphy first concocts an unlock command (maybe with a 1-in-20000 probability), and then, in a later session, concocts a write to the unlocked block (maybe with a 1-in-500 probability)12:07
wpwraki'm not sure we really need to worry about this scenario. i'd consider it a mere curiosity. there must be other things that fail more often in real-life use12:08
wolfspraulroh: the answer is because of available resources and opportunity cost12:10
wolfspraullots of things can be improved on m1 (tons), but which first?12:10
wolfspraulwant to 'improve' the nor chip - go ahead ;-)12:10
rohwolfspraul: i am just seeing that you guys use _loads_ of time to fix that problems12:11
wolfspraulfind a suitable replacement, do a design verification, make sure software supports both old and new, make sure updates can still work with 1 binary or picking the right one12:11
roheh. i mean the 'corruption issue12:11
wolfspraulnot really. there is a specific bug, and Werner's approach is a little academic12:11
wpwrakroh: they all lock/unlock with more or less the same ease. it's just that ours stays locked/unlocked, while the others go back to a hardwired state after the next reset :)12:11
wolfspraulnobody can say that a more 'modern' nor chip would not show the same or other bugs12:12
rohwolfspraul: sure. but after all.. thats what i like about werner.. if you know something you know WHY you know and how sure  ;)12:12
wolfspraulfor 'modern', the one we have is pretty much latest-gen, I believe12:12
wolfspraulthere are 'others', yes12:12
wolfsprauland there is serial flash, and and and12:12
rohsure12:12
wolfspraulwerner doesn't want to apply all fixes we have in mind and see whether we can still reproduce the bug12:13
wolfspraulwhy?12:13
wolfspraulbecause he is worried that he cannot reproduce the bug anymore...12:13
rohi am not suggesting even changing the pinout... i was thinking about simply soldering a different chip12:13
wolfspraulWITHOUT (god forbid) understanding why it went away :-)12:13
wolfspraulwhich one?12:13
wolfspraulI think with Werner's overkill methods the lifetime of the nor corruption bug is very limited by now12:14
wolfspraulit's just a matter of starting the final attack12:14
wolfsprauland if we can still reproduce the nor corruption even after applying all currently known fixes, well, then we have something new indeed12:15
wpwraka chip with a different locking scheme would probably be more robust, making the NOR corruption happen a lot less often, even if the root cause is never solved. but ... it would still have a number of vulnerabilities that actually matter12:15
rohwpwrak: i see (not locking on reset) .. how did we get to that chip?12:15
wpwrakduno. i wasn't involved ;)12:15
rohwpwrak: just curious... i havent seen such behaviour yet12:16
wpwrakit seems to be the very "old school" kind of locking12:17
rohor to be exact.. i dont understand it... all chips i read the datasheet yet go to lock when reset12:17
wpwraki have a little concern that we may wear out the lock bits if reflashing often via jtag. but that's again a "special interest" problem12:18
rohwpwrak: sure. different issue12:18
rohi only wore out nor one time, and that was a dbox112:19
rohit took years of multiple flashing per week/day12:19
wpwrakthe wear may be a little worse in this case12:19
wpwrakyou're thinking of O(updates)12:20
wpwrakhere, it's O(updates*update_size)12:20
roheek12:20
wpwrak;-)12:20
wpwrakthat's because urtag does an unlock/lock cycle for each block, not taking into account that the unlock is global12:21
rohmeh. so we need to fix urjtag?12:21
wpwraknow, i'm not 100% sure whether erasing an erased NOR bit really counts as a full cycle for wear, but since NOR life is generally specified in erase cycles, it may be prudent to assume so12:22
wpwrakroh: it would at least not hurt12:23
wpwrakwolfspraul: the nice thing about the "academic approach": you get to know all sorts of strange critters that live at the end of the bell curve. it's the kind of gremlins that cause those "unthinkable" accidents.12:24
wpwrakas long as you don't run nuclear plants or equip airplanes, you may not worry about these so much. but then, there can be a shift in context that suddenly washes them towards the middle of the bell curve.12:26
wolfspraulwpwrak: just trying to explain the status quo to roh in the shortest way possible :-)12:37
wolfspraula casual observer might think we are lost or stuck on the nor bug, but I totally don't see it like that...12:37
wolfspraulit's more slowness by design :-)12:38
rohwolfspraul: i dont think the shortest way is the best ;)12:38
wolfsprauland of course, I agree, in the long run this approach is better, and we will surely reuse some of the tools we build today in the future12:38
rohack12:39
wpwrakroh: i actually tried the fast approch at the beginning. had a set of very nice results just after two days. then it tried to do one last confirmation run. and well, that run completely disagreed with what i had found before ...12:44
rohhrhr12:45
lekernelany ideas to push some power at high frequencies through a transformer?14:29
lekernel(e.g. single-transistor oscillators...)14:30
lekernelit's for powering up a circuit working on the spinning part of a VCR cylinder14:30
wpwrakmaybe ask DocScrutinizer over at #qi-hardware14:32
larscwhat am i missing. if i write 'if (x) if (y)' ise generates 'not ((not ((not x) and y)) or y)' and if i write 'if (x && y)' it generates '(x && y)'16:13
lekernelwhat do you mean, "ise generates" ?16:23
lekernelwhat output are you examining?16:23
larscthe ngr file16:27
--- Sun Oct 23 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!