#milkymist IRC log for Friday, 2011-12-16

cladamw( rc3, 0x32 full pass ) After test, it finally passed with f/w existed earlier. Now yield reaches up to 80pcs. There's another four sets passed with latest f/w but crc/midi/phy id tests. So I think yield soon will go to 84 sets.02:15
cladamw( rc3, cases ) The _last_ case will be run out today. :-)02:17
cladamwxiangfu, just git pull autotest-m1 and make done. Did it include crc check already?02:23
xiangfucladamw, no.02:24
cladamwxiangfu, so 54662a8e is not the final. Isn't it?02:26
xiangfuwhat '54662a8e'?02:28
cladamwchecksum i think. "CRC32 (boot.bin): 54662a8e" after 'make'. Is it?02:30
xiangfucladamw, every build the CRC (boot.bin) is different.02:34
xiangfuwhen you run this boot.bin the fist line will display which commit you using. and if there are code modify not commit.02:35
cladamwah  ~ so this number is commit # we're using not checksum. okay ... tks!02:36
xiangfucladamw, it's like "*** Built: Dec 16 2011 at 10:34:43 (rev 50d40bb)"02:40
xiangfubuild date and which commit you using.02:40
xiangfuif there are code modified. there are '+' at the end of 'rev'02:41
cladamwphew ~ I'm the last one to know the this. :-)02:45
cladamwxiangfu, btw~ if final image is done, let me know. Thanks a lot! :)02:46
xiangfuthe crc32 check in test boot.bin. only fault at standby.fpg.03:40
xiangfuworks fine with other images.03:41
xiangfucladamw, now we can know the image check only fault at standby.fpg.03:47
cladamwxiangfu, hmm. sounds bad. Well, I just finished assembling out last light blue case, no case more here. :-)04:05
wpwrakcladamw: (0x32, flux) wow, amazing find ! congratulations !07:25
cladamwwpwrak, he :) not precisely confirmed if flux but almost and indeed that BTN2 level is neither full hi nor low, so fpga can be placed in unknown situation though to activate bootup or else. :-)07:33
wpwrakyes, button at weird levels could explain it. maybe the flux produced that "crosstalk" from flash signals.07:38
cladamwyeah... from clear evidences we just guessed likes in such way. Now surely BTN2 level is purely when pressing it. And heat air let flux under fpga to get well-protected on each ball.07:41
wpwrakremember that we once discussed an ultrasound bath, for cleaning such things ? did you ever go searching for one ?07:42
cladamwi remembered, Not get it yet.07:44
cladamware you trying to say using ultrasound mechanism to decompose flux in the future?07:45
cladamwthe idea of discussing to use ultrasound bath was to clean "bits and small pieces" after tearing off films while assembling m1 with case.07:49
wpwrakit should work very well for flux, too. particularly for the "water-soluble" kind07:52
wpwrakand even more so if the bath can be heated :)07:52
wpwrakwhen they did the rework at the factory, did they clean off the flux ?07:53
cladamwI guessed not.07:54
wpwrakthey should be able to do better :)07:54
cladamwthat time they also heavily have load at that moment. Since I can see the board surface so that I can surely they didn't do clean that area of 'reset circuit'.07:55
cladamwoah ~ yes07:55
wpwrakxiangfu: i think you got caught by our NULL pointer checks ;-))07:56
xiangfuwpwrak, oh. added recently?07:57
wpwrakcladamw: heavy load is a poor excuse. cleaning off the flux should about as optional as using it in the first place ;-)07:57
cladamwin other words, this failure was caused by on my site own. and also the area is too nearby fpga. And unfortunately that area(BTN2 ball under fpga) is also nearby rework circuit. :-)07:57
wpwrakxiangfu: many weeks ago :)07:57
xiangfuwpwrak, I update the makefile a little. try to always follow the 80 rules. :)07:57
xiangfuwpwrak, hmm... where is the NULL pointer checks code?07:58
wpwrakxiangfu: (makefile) yes, i've seen it. very nice ! thanks !07:58
wpwrakxiangfu: in "hardware", the FPGA :)07:58
wpwrakxiangfu: the first ~512 kB should be "forbidden"07:58
xiangfuwpwrak, even read07:58
wpwraksegfault-on-read catches a LOT of problems :)07:59
xiangfuScopeuk, Hi07:59
xiangfuyou have saw the DMX fixture video. just double check. since you ask me about the DMX update. :)07:59
Scopeuki havent no i missed it08:00
Scopeukgot the link?08:00
wpwrakcladamw: maybe they used "no clean" flux and thought that one really doesn't have to clean it. i've once made that mistake, too ;-)08:00
xiangfuwpwrak, what should I do? disable CRC check on standby.fpg temporary?08:00
cladamwwpwrak, the idea of ultrasound bath (or 'water-souble') is definitely my top job before rc4 to prepare/study.08:01
xiangfuScopeuk, http://www.youtube.com/watch?v=Bn1DO_4BTOs and http://www.youtube.com/watch?v=mDiq9gyFg6o08:01
wpwrakcladamw: ultrasound should also work for other types of flux. also, you can use pretty much any liquid that doesn't explode or attack steel. so .. no strong acids and go easy on the nitroglycerine :) but demineralized/distilled water, alcohol, flux remover, etc., should be fine08:02
cladamwwpwrak, I would like to ask minbo or else manufacturers to know how they dealt with larger production if many bga chips on boards.08:02
wpwrakxiangfu: we (sebastien and some other folks) discussed having some kind of switch to turn the NULL pointer trap on, so it would be off by default and get enabled in the BIOS. not sure if this bit was implemented, though, or if the trap is permanent08:04
wpwrakxiangfu: so yes, for now, i'd just skip the standby check. if you get to the point of checking, you can be pretty certain that standby is okay anyway ;-)08:05
cladamwwpwrak, they must have smarter way to clean quickly includes bath with liquid.08:05
wpwrakcladamw: i've read of some baths with hot water under pressure. kinda like a dishwasher, but more intense. (and without the nasty chemicals you use in a dishwasher)08:06
cladamwwpwrak, under pressure?08:07
wpwrakcladamw: but ultrasound should also be popular. the good ones (designed for electronics) vary the frequency, so that you don't get resonances that could damage the chips08:07
wpwrak(pressure) water jets getting sprayed on the circuit. like in a dishwasher :)08:08
wpwrak(but don't try to use a dishwasher :)08:08
cladamwwpwrak, oah~ thanks now understood your pressure words. :-) yeah... the frequency knowledge you taught me then.08:09
cladamwwpwrak, i think that i need to find other factory who "unlocked manufacturer knowledge".08:10
wpwraknone of this should be much of a secret :)08:12
Scopeuklooks good xiangfu08:16
cladamwwpwrak, i'm doing with the same way to another board. Good luck to me. :)08:17
wpwrakhehe, we have a yield problem now. it's too high ! ;-)08:17
cladamwwpwrak, hey... Did you check my 0x2f pre-rc4 board?08:18
cladamwthat board was my _first_ during rc3 production. All through hole type of connectors I soldered not by reflow machine. So its bottom side is super ugly and also not clean. :)08:19
cladamwwpwrak, cause smt machine was still running, so diy.08:20
GitHub175[autotest-m1] xiangfu pushed 3 new commits to master: http://git.io/B_lEMw08:25
GitHub175[autotest-m1/master] follow the 80 characters rule - Xiangfu Liu08:25
GitHub175[autotest-m1/master] Put the -lbase to the end, give error sometimes - Xiangfu Liu08:25
GitHub175[autotest-m1/master] Ignore CRC check on Standby.fpg, because the 'NULL pointer checks' under FPGA - Xiangfu Liu08:25
xiangfucladamw, please use this test boot.bin : http://milkymist.org/updates/2011-11-29/for-rc3/boot.crc.be5b0e7.bin08:27
xiangfucladamw, I just build. disable CRC check on standby.fpg.08:28
xiangfuScopeuk, I am think about if we need a 'DMX_CHAIN' variable in patch language.08:28
xiangfuand when we switch a DMX patch to an NON-DMX patch. all DMX output will became 0. so those DMX fixture will off. :(08:29
xiangfuwe maybe matter keep those DMX values.08:29
cladamwxiangfu, ha ~ thanks a lot !08:30
lekernelxiangfu: you can check the standby using the non-cacheable address space, which won't trigger the NULL pointer detection08:38
xiangfulekernel, by apply this patch: http://dpaste.com/674148/08:50
xiangfulekernel, it still hang the system. :(08:50
cladamwxiangfu, Did PHY ID being fixed? I still got the same Id : 0045.12:01
wpwrakcladamw: (M1pre-rc4) i'm just setting it up :)12:03
cladamwwpwrak, will it go for counting now? :)12:05
wpwrakcladamw: very soon :)12:11
wpwrakcladamw: first, i'll try if plugging my USB devices can still crash it (inrush current)12:12
cladamwwpwrak, how will you measure it? Putting a current meter in serial with DC jack's input or VBUS?12:13
wpwrakcladamw: oh, for now i'll simply plug them in one after the other and see if the M1 survives ;-)12:19
wpwrakcladamw: later, i'll monitor the 5V rail for voltage drops. but that's after torturing the NOR for a few days.12:20
cladamwwpwrak, got it.12:21
wpwrakfirst, i gave it a bit of case modding. see the mail i just sent to the list12:25
cladamwwpwrak, phew ~ great works your cartonero !12:34
wpwrakthanks ! :) maybe we can use that idea for the future, too. make a replacement rear wall with a hole that goes with the jtag board12:36
wpwrakand it boots. yay !! :)12:43
xiangfucladamw, PHY ID : https://github.com/milkymist/bugs/issues/912:44
cladamwwpwrak, he :)12:46
cladamwxiangfu, yes. I saw lekernel pointed in email with bug link, but didn't know what it means. :(12:48
wpwrakah ! USB will need software support to turn on power. that's why nothing works at the moment :)12:55
cladamwwpwrak, what you mean? By default supposedly it should always ON, isn't it?12:56
wpwrakis it ? hmm. then there is a problem12:56
wpwrakdid any USB devices work for you ?12:56
wpwrak(on that M1pre-rc4)12:57
cladamwsure. worked here.12:57
cladamwbut i tried four mouse.12:57
cladamwhow about use another mouse?12:58
wpwrakhmm, i tried my whole collection of gadgets. some receive power but not all. nothing seems to be able to communicate.12:58
wpwrakmaybe some loose contacts. i noticed that the right port (B ?) loses power when the connector moves12:58
cladamwi recorded my four mouse tests under M1pre-rc4: http://en.qi-hardware.com/wiki/Milkymist_One_run_3_schedule#USB_Power_Switch_Circuit12:59
cladamwwpwrak, ( loose contacts ) it's possible.12:59
cladamwcheck their connection by meter firstly12:59
cladamwJ20(b-port) J16(a-port)13:00
wpwrak(reading your rework) wow, it's even crazier than it looks ;-)13:01
cladamwoah ~ yeah...i glued it.13:02
wpwraki need to un-crowd my bench a bit for a more serious analysis. i'll check that usb stuff next week, after the NOR torture13:02
cladamwalright...good luck...Measuring two VBUSs connections from AP4142A's pin7(OUT1 = usb -A port) and pin6(OUT2 = usb - B port) _before_ testing usb stuff. :-)13:06
wpwraktorture test is running13:30
wpwrakand USB works fine after i installed the ancient 2011-07-1313:31
wpwrakso maybe that was just some version mixup13:32
wpwrak(2011-07-13) i picked that old thing because of the known to be good test software, for image CRCs13:33
kristianpaulI think jon likes to drop some milkydrop effects between slidshows, so i wonder if  separate firmware will do the Job as Well13:36
kristianpaulbut lets him to answer :)13:36
wpwrakquite frankly, i have no clue what he's doing :)13:38
wpwrakfor slideshows with effects, perhaps it could be nice to have a means to run the effect processing in only a part of the screen, with the actual slide covering the rest13:39
wpwrakbut i don't know how well that would work in practice13:39
kristianpaulyeah, a video from the talk he gave will light us more13:40
kristianpaulignoring that res is still low fore presenteations, the other features he request still really that messy to implement?13:41
wpwrakyou mean better IR control ? no, that's fine. we should have a fully configurable input system anyway.13:46
wpwrakbut it's something that's a bit further down the road13:46
xiangfuwpwrak, when m1 do rendering. which hardware core is using?13:49
xiangfuwpwrak, http://www.openmobilefree.net/wp-content/uploads/2011/04/case-video-in-element-hole-4.jpg maybe we can sell 'DEBUG' slide to geeks. :D13:51
wpwraki have everything from 2011-07-13. the NOR problem shouldn't be affected by which version we use13:51
kristianpaulwpwrak: asign variables to slides is vry usefull, or that array you proposed so i guess back anf forward will be esier too13:52
xiangfuwpwrak, http://www.openmobilefree.net/?p=90413:52
wpwrak(low res) not sure about that. the title overlay (F1) looks okay. and you wouldn't want to use a much smaller font for slides anyway13:55
wpwrakxiangfu: eh, cool ! you already did it :)13:55
wpwrakyou should post that on the list13:56
xiangfuwpwrak, the case quality is pretty good. with the big 'aiguille' not break the plastic13:58
xiangfuwpwrak, all you need is a thick wood  when you drill the hole. :)13:58
wpwrakyeah. and you could even use a smaller drill13:59
wpwrakand the right position for the center :)13:59
xiangfuwpwrak, yes. that will be perfect.14:00
xiangfuwpwrak, I will reply you email.14:00
xiangfuwpwrak, I have another bigger hole on the top of the case.14:10
xiangfuwpwrak, I was thinking about it for the memcard. but after I drill the hole I found you can never plug a memcard though this hole :)14:10
wpwrakyou would need very thin and very flexible fingers ;-)))14:13
xiangfuwpwrak, if I have that fingers. I don't think I needs use those fingers. maybe mind-control works :)14:16
wpwrakyeah. while the rest of the industry is still excited about capacitative touch screens and multi touch, we should move on and explore telekinetic interfaces :)14:23
GitHub19[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/k7fUaw15:07
GitHub19[milkymist-ng/master] Pay a bit more attention to PEP8 - Sebastien Bourdeauducq15:07
GitHub23[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/39b7190334d7d19b0d19dd9299dc4a5ff94b212915:07
GitHub23[migen/master] Pay a bit more attention to PEP8 - Sebastien Bourdeauducq15:07
whitequarkXst: INFERNAL_ERROR:1:main.cpp:476918:54
lekernelinfernal? :)19:04
wpwraknow we're getting to the poodle's core :)19:06
whitequarklekernel: :D19:06
whitequarkit's the _correct_ reading of xst's errors19:07
lekernelwhitequark: screenshot :)19:07
wpwrakbtw, 1078 cycles and counting. that's already 1.5-2x the average time to failure with M1rc3. i'll do a lock bit check at 5000. then add another 5000.19:08
whitequarklekernel: that's not a real error message. just my interpretation, albeit more correct in regards to debugging them.19:08
lekernelwhitequark: you should try migen fhdl - it should only generate code patterns that do not crash the xst parser :)19:18
lekernelplus it will force you to build a synchronous circuit19:18
lekernelmemories aren't supported yet, but if you know a tad of python, it shouldn't be hard19:19
whitequarklekernel: well, I know python, and I hate it19:20
whitequarkbesides my personal preference, I don't see a need in another layer19:21
lekernelamong other things, you can at least build soc interconnect this way: https://github.com/milkymist/milkymist-ng/blob/master/top.py19:22
lekernelif you compare it to the little mess in milkymist's system.v and conbus, I trust you'll at least recognize some value in it.19:22
lekernelthe TMU is another area that can largely benefit from that other layer19:23
whitequarkoh yes, reminds me of my pipeline19:24
whitequarkwell, the idea is nice19:25
whitequarkstill, python isn't something I will use in my own project. for milkymist, fine, if everyone does, I'll do too19:25
lekernelwhat's your argument against python?19:26
whitequarkit wasn't designed -- more of "tangled up" (examples are everywhere: print, global functions, strange functions in stdlib, confusing array accessors, etc.); 3.x fixes a lot of that, but also introduces a lot of incompatibility. I heard even 2.7/2.5 has incompatible changes. It does not have some really good features which have proved their usefulness (proper lambdas), it has a _completely braindead_ C API (Py_INCREF(Py_None); and so on), an19:32
whitequarkI'm not saying that Python is bad for migen, even through I'd rather see it in any other language.19:34
whitequark(about udev: I think not anymore. I've did that ~year ago, and it was a hard build and runtime dependency of some of its components (extras?). They're fixed that AFAIK, but that still sucked a lot. Python in embedded...)19:35
wpwrak_any_ other language ? like, brainfuck ? :)19:35
whitequarkwpwrak: any other appropriate language. There is no other one I dislike as much as Python. The problem with snakeish thing is more social than technical.19:36
whitequarkand brainfuck is just an interesting challenge to build a processor with modern features, but not too complex to take months19:36
whitequarkgiven the background of a lot of people here: has FSO stack been rewritten in C because Python was too cpu, memory energy hungry?19:37
wpwraknaw, python isn't *that* evil. it's not a language i feel terribly comfortable with either, though. it has a certain "designed for beginners" feel to it.19:38
whitequarkwpwrak: Guido (Python's author) is _explicitly against optimizations_19:38
whitequarkjust think about it19:39
whitequarkthey allocate every number literal on heap19:39
whitequark(and destroy it when it leaves scope)19:39
whitequarkpreallocating -1..100 has given a 30% boost in performance19:39
wpwrakthat encourages really good coding practices ;)19:40
whitequarkit just gives me an continuous facepalm when I try to write in it19:40
whitequarkback when I've used Ubuntu on my desktop19:41
whitequarkputting * * * * * killall -9 python in crontab has fixed all the problems with performance19:41
wpwrakwell, there are more things. like the use of \, the mandatory indentation that makes it hard to add instrumentation for debugging, then of course the changing of initializers, and so on. in the end, it will do what you want, but you feel dirty.19:41
whitequarkyes! exactly.19:41
whitequarkthe indentation thing is the least disturbing for me (it's also the most flamewar'd one, I think). I'm happy using other languages with mandatory indentation, like CoffeeScript. It's fine on its own (and when it is done properly)19:42
whitequarki.e. no spaces/tabs conflict, etc.19:42
whitequarkand no conflict with sed -i s,\s\+$,, *19:43
krispaulwhitequark: what about lua?, is used on this http://www.ohwr.org/projects/wishbone-gen mitgen for wishbone :)19:44
whitequarkkrispaul: my WM is based on Lua. it's a bit tedious to write in it, but at least it was explicitly designed in such a way, it is consistent and it's fine for its scope (embedding)19:45
krispaultedious yeah :/19:45
whitequarkmy personal preference is Ruby or Scheme19:45
whitequarkbut I doubt anyone here will select Scheme :)19:45
whitequarkthe two things I like most in Ruby are: a) its Lisp ancestry -- wide and appropriate/trivial use of lambdas and b) after you get a grasp of it, every next feature of language feels obvious -- it in almost all cases behaves just what you're expecting it to work19:47
wpwraklekernel: btw, how bad would the memory bandwidth impact be if we grew the OSD to the full size of the screen ? do you think we could use the present OSD mechanism but at full screen size, with the usual patches running underneath ? (full screen size = in rendering mode)19:54
wpwraklekernel: what i'm after is an overlay for configuration. so that you don't have to do things like go to the GUI just to adjust the audio sensitivity.19:55
lekernelwhy not a complete patch editor in overlay? :)20:15
lekernelthe "livecoding" button in the current patch editor20:16
wpwrak"livecoding" ?20:16
wpwrakyes .. but is this a real button i've never noticed or a hypothetical button ?20:17
lekernela hypothetical one20:18
wpwrakah :)20:18
lekernelregarding the overall speed of a full-screen overlay, I don't really know... try it20:18
wpwrakhehe, ok :)20:18
lekernelif memory bandwidth is a problem, disabling semi transparency should help20:19
lekernelbut then you can't use antialiased fonts20:19
wpwrakwhich may look suckish. hmm. let's hope for the best then :)20:19
lekernelwithout semi transparency, the TMU is fairly efficient. it won't read-modify-write the destination framebuffer but use the DRAM's byte masking signals instead.20:21
lekernelso you get only one write instead of a read, a bus turnaround, and a write20:22
wpwrakah, nice20:22
wpwrakwell, with the increased color depth, it would be one bus word at a time anyway20:22
lekernelthe DRAM bus is 64-bit20:22
lekerneland it'll be 128 with the increased resolution ;)20:23
wpwrakhuh ? how ?20:24
lekernelit's DDR at the system frequency, so it reads two 32-bit words in one cycle, which are then serialized/deserialized in one 64-bit word per cycle20:25
lekernelI plan to switch to DDR at twice the system frequency20:25
lekerneland 1:4 serialization20:25
wpwrakoh. our DDR can handle this already ?20:25
lekernelyes, 160MHz shouldn't be a problem20:26
lekernelactually it can do 200MHz at 2.6V20:26
wpwrakdouble the memory bus speed, with just a few verilog changes. mimic that, intel and amd ! ;-)20:27
lekernelthe problem is it's not 'a few'20:27
lekernelotherwise I'd have done that already :)20:27
wpwraka few here, a few there, ... we all know how such things build up :)20:28
whitequark.>IHB KA@CLC20:28
whitequarkoops, sorry.20:28
GitHub184[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/c7b9dfc203218a200601ff83acb68f719432a12520:34
GitHub184[migen/master] fhdl: simpler syntax - Sebastien Bourdeauducq20:34
GitHub8[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/FxaJpQ20:34
GitHub8[milkymist-ng/master] Support the new FHDL syntax - Sebastien Bourdeauducq20:34
wpwrakclick-click ... 1510 ... click-click ... 1511 ...21:22
wpwraki love it when machines do this sort of mind-numbing testing for me ;-)21:24
GitHub122[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/ee6ca729a224b5b67bbfc1843237c0f33dd354ad21:29
GitHub122[migen/master] verilog: user-definable reset and clock - Sebastien Bourdeauducq21:29
GitHub128[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/8eIy7g21:29
GitHub128[milkymist-ng/master] Proper reset generation - Sebastien Bourdeauducq21:29
whitequarkwpwrak: what's clicking? a relay?21:56
wpwrakyup. of labsw. i'm torture-testing the M1's NOR behaviour21:58
whitequarkwtf is GitHub*?22:02
whitequarkno namechanges, no join/leaves and nothing in nickname list22:02
lekernelI set the channel in "outside messages accepted" to limit the github bot visual pollution22:03
lekernelit posts without joining the channel22:03
krispaulboo? :)23:07
krispaulwpwrak: are you going up to resnder or just testing powercycle so far?23:09
wpwrakphew. took me a while to decode that ;-)23:20
wpwrakwhat i do is that i boot into performance mode and have "tunnel" render for ~4 seconds23:20
krispaulgot it, thanks :)23:22
wpwraktotal time from boot out of standby to power cut is 15 seconds23:23
whitequark5760 times per 24 hours23:25
whitequarkthat is, 5760 power cycles and 1 Werner gone insane from the continuous clicking.23:26
wpwrakclose :) there are also 3 seconds for power cycling23:26
whitequark4800, then23:27
wpwraki've had that thing click on me some 50'000 times already. i think i can't possibly get any more insane from it at this point :)23:27
whitequarkdoes it work, eh, around _two weeks_?!23:27
wpwrakplus any delays the shell and the commands invoked may have :)23:27
wpwrakthe real number i get is about 4600 per 24 hours23:28
wpwrakthe 50k weren't in a single run. but yes, i had that stuff run for weeks23:28
wpwrak(in total)23:28
whitequarkdo you have a wife or children (yet)?23:29
whitequarkjust curious23:29
whitequarkI'd rather kill myself after fifth hour23:29
wpwrak(subjects interfering with hacking) new :)23:29
whitequarkhaha :)23:30
wpwrak(5th hour) it's all automated. very enjoyable to watch, and to think that adam did that manually. for some 500 cycles per run.23:30
whitequarkyes, I think that first five hours or so I'd just watch it work23:31
whitequarkand then I'd try to do something different23:31
whitequark*head asplodes*23:31
wpwrakhmm, when i reach 10k cycles, i'll have a 1:1.6M chance of the bug still being there and just not having happened yet23:31
wpwrakyou grow used to it after a day or two :)23:32
Action: whitequark drops a pen on the floor23:32
whitequarkit has a non-zero probability of tunneling straight through it23:33
whitequarkit just has not happened before23:33
whitequarksigh. failed this time, too :/23:33
whitequarkwhat's the outcome of the possible bug?23:34
whitequarkNOR suicide?23:34
wpwrakif i add another day, the probability would be around 1:2000M :-)23:35
wpwrakcorruption of some NOR content. can be a few bits in a data word or, perversely, also a lock bit23:35
whitequarkit, ehh, _corrupts the NOR content perversely_?23:36
wpwrakcorruption of the lock bit prevents further corruption of data23:36
whitequarkah, got it23:36
whitequarkwhy does that happen? ringing on the control lines?23:37
wpwrakthat is, unless the lock bit is corrupted back to unlocked. which theoretically could also happen23:37
krispaulah, wait so this was with locking i  tought that wasnt necesary after the reset fixes..23:38
wpwrakthe hypothesis is that it's FPGA core power going down faster than the power supply of FPGA I/O and NOR. so when the core dies, it may send out some random noise, which gets amplified by the still operational I/O section and is seen by the NOR.23:38
wpwrakevery once in a while, on of those bad patterns will be a valid write ...23:39
krispaulor may be i'm complery ignorant of this topic and is prety normal this locking feature23:39
wpwrakand even less often, it will be a valid NOR lock command23:39
whitequarkwpwrak: sounds like a zombie movie scenario23:40
whitequarkbesides that, how would you fix this? more caps on Vcore?23:40
wpwrakkrispaul: i was describing the behaviour without locking23:40
krispaulyes i noticed that23:40
krispaulvodoo caps :)23:41
wpwrakkrispaul: in theory, we could also get an uncommanded unlock. that would break the work-around we have now, namely that we lock the most susceptible areas of the NOR.23:41
wpwrakkrispaul: but the probability of this happening is pretty low. you probably break off the power socket first, assuming that the normal way of power-cycling is by unplugging power23:42
krispaulyeah, eve lock corruption and all the fun with it:)23:42
wpwrakwhitequark: we have a reset circuit that holds the FPGA in reset when the rail ramps up or down. alas, it's referenced to the slower of the two rails. so, while it does its job when powering on, it has no effect when powering off23:43
wpwrakwhitequark: th two rails are fed from separate regulators that are supplied by a common input. the solution we're looking at now is to reference the reset circuit to the common input23:44
wpwrakthis means it will force a reset long before the rails (behind their own regulators) start dropping23:45
wpwrakand the cutoff point is set at the minimum input voltage of the regulator of the rail with the highest voltage23:46
whitequarkyeah, I see23:46
wpwrakwell, there is a bit of slack there. but that also happens to be the rail we already know to be "slow". so being a few mV off won't matter23:47
whitequarkwpwrak: what do you mean by "slack"?23:47
wpwrakthe lower end of the tolerance of the reset chip's threshold is below the upper end of the tolerance for the regulator's minimum input23:50
wpwrakwe had to go a bit low because the system would get too trigger-happy and also kill itself if you connected some USB device23:51
whitequarkwon't bigger capacitors on VBUS also help?23:52
wpwrakBIG capacitors ;-)23:53
whitequarkis that a problem?23:54
wpwrakwe're adding a current-limiting switch, just in case23:54
wpwrakmonster caps are inconvenient and can get expensive23:54
wpwrakno, the current-limiting switch is the appropriate solution for the inrush current problem23:54
whitequarkdoes the voltage past these two main regulators also fall too low?23:55
whitequarkI guess no...23:55
wpwrakwell, the scenario is that power is removed from the system. so everything goes down.23:56
wpwrakadam made a nice diagram showing what happens: http://en.qi-hardware.com/wiki/File:M1rc2_powerOnOff_sequences_manuscript.jpg23:56
whitequarkINIT_B is a bit strange23:58
whitequarkis that 260ms the fpga configuration loading time?23:58
--- Sat Dec 17 201100:00

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