#milkymist IRC log for Tuesday, 2012-05-22

cladamwgood morning.01:37
wpwraksilent night, rainy night ;-)01:40
cladamwwpwrak, according to 'Decoupling" in page 14 of http://download.micron.com/pdf/technotes/DDR/tn4614.pdf  there should have bypassing capacitors higher-frequency(0.01uF) and lower-frequency(0.22uF) noise.01:40
wpwrakyes, that's similar to what we have ... 10+100 nF vs. 10+220 nF. dunno if 10+100 is unusually close or not01:43
cladamwalso based on empirical experiments added 100nF after rc1 about noise integrity reduction, we know those extra-added 100nF and 100uF are good for stability of noise reduction.01:43
wpwraksome people also claim that mixing bypass caps like this actually doesn't work ;-)01:43
cladamwat least, 100nF+100uF is good.01:43
wpwrakyeah: x+1000*x sounds like a healthy difference :)01:43
cladamwthe micron's recommends are so much good idea but actually not for a MP idea i think, seems there's 5 VDDQ + 3 VDD, so a well design needs 2*8 bypassing capacitors, who will definitely and follow all in a real consumer product ?01:46
cladamwbtw, although now m1's 8 VDDx supplies comes either 100nF or 10nF, so let's make it symmetric during m1r4.01:48
wpwrak(not for MP) well, we now have 10 caps per chip. micron recommend 16. that's not such a huge difference.01:50
cladamwpin [1, 18, 33] are the VDD; pin [3, 9, 15, 55, 61] are for VDDQ.01:50
cladamwyeah ... we are not to add more. :-)01:51
cladamwjust balance it. :-)01:51
cladamweven "never change a working design" is a common rule, but no fun. :-)01:52
cladamwalso 100nF & 10nF are all the same package in 0402. :-)01:53
cladamw1uF too.01:54
cladamwpin 33 now has 100.01uF, i'd like to let U14.15 (C164) to be 100nF, then this balances to U15.15(C157, 100nF)01:58
cladamwU14.1 (C162) to be 10nF, then balance to U15.1(C159, 10nF)01:59
cladamwU14.18(C245) to be 1uF, then balance to U15.18(C156, 1uF)02:00
wpwraksince we currently don't seem to have stability issues, i would consider it likely that, when U14 and U15 use different values, either value will work02:00
cladamwi know this is not 100 completely followed micron's suggestions. :-)02:00
wpwraki'm kinda curious if sebastien will find issues with the new optimized DRAM interface. if he does, we'll know what to look for :)02:02
cladamwwpwrak, ah ... sounds you don't want to get magic/fun on this.02:03
wpwraki mean: if sebastien runs into trouble with m1rc3, then we'll know where to look for it :)02:03
cladamw(IBIS) ?02:04
wpwrakthat would be very sophisticated :)02:04
cladamwif let the IBIS model to be optimized on a unbalanced plateform, how you supposedly will get positive results ? :-)02:05
wpwrakhmm ? why would that affect the IBIS model ?02:07
cladamwi don't know, just intuitively judged.02:10
wpwrakthe IBIS model would come from the vendor. i'd hope they don't do this sort of nasty things ;-)02:15
wpwrakanyway, do we use IBIS anywhere ?02:15
cladamwdon't know. Although IBIS models is good for run a signal integrity simulation on the final routing, as run in m1rc3. my questions are that how we know the results from sebastien if he does is not affected from unbalanced filters ? maybe i asked wrong questions or nonsense.02:20
wpwrakyou mean sebastien's measurements with that high-end oscilloscope ?02:21
wpwrakso you're saying sebastien has done simulations based on that IBIS model ?02:22
cladamwno, i am not sure.02:23
wpwraki don't recall sebastien mentioning any simulations02:25
wpwrakJul 17 10:24:53 <lekernel> phew, that's complicated... you can find IBIS models of the FPGA I/Os at the Xilinx website if you want02:26
wpwraksounds pretty sceptical ;-)02:26
wpwrakMar 29 10:57:58 <lekernel> wpwrak: there are IBIS models published by the various chip vendors, but I don't know how they work internally02:26
wolfspraulwe have something that we know works today02:26
wolfsprauland on the other side we have recommendations about values02:27
wolfspraulcan't we just slowly move towards the recommended values, unless we know better?02:27
wpwraki think making both chips use the same values on the same pins is a step in that direction02:28
wolfspraulnot everything needs to be 100% understood before doing it. if we just carry our magic values forward then one day we will regret having lost the opportunity to carefully follow vendor recommendations. maybe from a more optimized memory controller, after a board layout change, after a switch to another ddr standard, etc.02:28
wolfspraulbut I have no thoughts on the exact values or in which way to clean them up02:28
wpwrakthere's of course always a risk. but it should be quite minimal.02:29
wpwrakyes, a more efficient memory controller and/or maximizing the memory clock would be the most likely ways to reveal bypassing issues02:30
wolfspraulyeah so let's cleanup now and go for what we believe is best, using the methods that are actually at our disposal02:31
wpwrakin general, i'm not against implementing exactly what micron recommend, e.g., 10+220 nF.02:31
wpwrakadam seems to be concerned about PCB space issues. not sure if he's also reluctant to add things now that the layout folks are already working on it.02:32
cladamwbut sounds you'd like to wait until a real new optimized DRAM interface came out on m1rc3 firstly ?02:32
cladamw(PCB spacing) no, i am not concerned it.02:33
wpwrakcladamw: naw, that wouldn't make sense. i think it will take a while before we have more extensive testing on m1rc3.02:33
cladamwwpwrak, the real thing is that IF we think and want to follow 10+220nF from micron, then we add them now to make symmetric, i still could let house to add them no matter what they want or not.02:37
wpwrakokay, that's good02:37
wpwrakthe way i read page 14 of http://download.micron.com/pdf/technotes/DDR/tn4614.pdf02:37
wolfspraulif there is a vendor recommendation, and we have no reason to override it, then the only reason being "it worked for us without following the vendor recommendation so far" is not enough imho02:37
wpwrak... micron recommend at least two caps per chip, not per pin02:38
cladamwso now we know what's the results will be after new optimized DRAM interface, we see later this.02:38
wpwrakso we should already have quite a good number. however, note that this is from 2006. they even mentioned electrolytic caps ! ;-)02:39
cladamwso now means we want to take risk to add/follow micron. :-)02:39
cladamwwpwrak, yeah ... as you know, we can 100% follow them but try at most. :-)02:39
wpwrakwait ... what i'm saying is that, as i understand what they write, this PDF (from 2006) says we need at least two caps per chip02:40
wpwrakwe already have ten caps per chip ...02:41
wpwrakoh, sorry. i mean at least FOUR caps per chip02:41
wpwrak(two for VDD, two for VDDQ)02:41
wpwrakthis should be fun to calculate: http://www.google.com/url?q=http://www.micron.com/~/media/Documents/Products/Technical%2520Note/DRAM/176TN4602.ashx&sa=U&ei=fvy6T6r_GoWc8QTDyKioCg&ved=0CBIQFjAA&usg=AFQjCNGBeOCG-7IO7Otxmjt0CQea74aFLQ02:42
cladamwyeah ... micron recommends FOUR per chip02:42
wpwrakso i'd say that, once we clean up the U14/U15 asymmetry, we should be in good shape02:43
cladamwnice, this technical note also be noted in tn4614.pdf02:44
cladamwso at least FOUR. then we need 10 nF and 220nF02:45
cladamwthose two 100uF (C240, C248) we can still keep them, seems as 1000 times as good.02:47
cladamwnow VDDs for pin [1, 18, 33]02:48
cladamwwpwrak, are you reading tn4602 ?02:49
wpwrak(100 uF) having a big silo around never hurts ;-)02:49
wpwrak(tn4602) not tonight :)02:50
cladamw1. let 100nF to be 220nF directly,02:54
cladamw2. pin 61 is still good on 10nF02:55
cladamwwpwrak, are you thinking table for capacitance ? :-)02:57
wpwrak(table) in fact,i was wondering if we shouldn't list the capacitance in the table :) it's a bit inconvenient to look up things: first go to the chip to see what the pin is, the go to the table to see what cap(s) it has, and finally go to the caps to find the value.03:02
wpwrakbut then, it's not as if this was done a lot of times. so ...03:02
lekernelwpwrak: I did IBIS simulations too08:05
lekernelbut I just threw them into some magic proprietary software...08:05
wpwraklekernel: (IBIS) oh, cool. pity about the proprietary stuff, though.10:13
GitHub178[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/-pcRIQ11:24
GitHub178[milkymist-ng/master] Clock frequency detection - Sebastien Bourdeauducq11:24
GitHub176[linux-milkymist] sbourdeauducq created ng (+1 new commit): http://git.io/GeCS4Q12:14
GitHub176[linux-milkymist/ng] Remove unsupported drivers - Sebastien Bourdeauducq12:14
lekernellarsc: can we access the DTS in arch/lm32/platforms/milkymist/time.c ?12:38
lekerneland early_printk (though the latter might be useful to debug DTS fuckups)12:39
GitHub11[linux-milkymist] sbourdeauducq pushed 1 new commit to ng: http://git.io/wRcE8g13:21
GitHub11[linux-milkymist/ng] new time/early_printk/uart drivers compiling, untested - Sebastien Bourdeauducq13:21
GitHub172[linux-milkymist] sbourdeauducq pushed 2 new commits to ng: http://git.io/u4OE2g15:24
GitHub172[linux-milkymist/ng] dts: remove timer - Sebastien Bourdeauducq15:24
GitHub172[linux-milkymist/ng] remove old config - Sebastien Bourdeauducq15:24
GitHub179[linux-milkymist] sbourdeauducq pushed 1 new commit to ng: http://git.io/t9-f0w16:04
GitHub179[linux-milkymist/ng] Enable timer interrupt correctly. Kernel now boots. - Sebastien Bourdeauducq16:04
FallenouLinux kernel boots on Milkymist-ng ? :)16:06
wpwraki'm afraid its YAOS aka nuttx16:06
wpwrakif sebastien goes on like this, M1 will be remembered in history as the platform that has more operating systems than users ;-)16:07
Fallenouhumm if it's in "linux-milkymist" I guess it's really linux16:07
wpwrakhmm. you may have a point there. so i'll eat my words. dunno what that nuttx thing was about then.16:08
FallenouI think he wants to try nuttx out, in case someone has the time to port it to M1 =)16:09
FallenouWill Nuttx have a nice usb stack ? :)16:10
Fallenouit seems to support a few usb things16:11
Fallenouthat would mean we don't need mmu anymore :"16:11
Fallenouif we port Nuttx16:12
lekernelFallenou: yes, it boots on -ng16:12
wpwraki daresay that, unless it rips out rather large portions of the Linux kernel, it won't come near matching its USB support16:12
lekernelhaven't tried userland yet but it should be ok16:12
lekernelcleaning up the irq code a bit, then try to see if the executable loader somewhat works or if we should use nuttx16:12
lekernelwpwrak: no USB on the next MM16:13
lekerneltoo much pain16:13
lekerneland it's not a distinctive feature, people take it for granted16:13
wpwraknuttx sounds like just another RTEMS-like dead end. perhaps prettier, but just as dead :)16:13
kristianpaulFallenou: question goes for milkymist first i think16:14
lekernelwhy is it dead?16:14
wpwrakby the time a MM that could sell without USB is ready, i think we'll have solved he USB issue as well :)16:14
lekernelif we had used linux, then nothing would probably work today16:14
kristianpauldead indeed16:14
Fallenou18:18 < lekernel> Fallenou: yes, it boots on -ng < congratulation !!16:15
wpwrak(dead) well, another niche development. small developer base, limited testing, etc.16:15
lekernelwe'd still be figuring out performance/bloat/GNU/autocrap/FDPIC/etc. problems16:15
wpwrakFUD FUD FUD ;-)16:15
lekerneland probably stability as well16:16
lekernelI remember larsc saying a while ago that the thing still crashed every 30 minutes or so16:16
wpwrakif you insist, you can make linux boot into a custom executable just as well as rtems and such16:16
lekernelthat's not the only problem16:16
wpwrakthat was to counter your autocrap argument :)16:17
lekerneland having a small FS and a loader is nice ...if it works without extreme hassle, which it does not16:17
wpwrakyou're too impatient :) sputnik didn't fly to mars. bah. let's forget about space exploration.16:18
lekernelpick your battles16:19
lekerneland I don't think RTEMS is responsible for many of the M1's problems16:19
lekernelbut you see, I'm considering linux16:20
wpwrakyes, that's good :)16:20
lekernelI did try to use it at the beginning, and little got done16:20
lekernelnow I'm evaluating it again16:20
lekernelI'm not holding my breath though16:21
wpwrakconsider linux as an enabler, not as a differentiator. it simply gives you a basis where a lot of nasty things (like USB) are solved for you by other people.16:21
lekernelUSB already has an easy solution: remove it completely16:21
wpwrakwhy stop there ? remove video out too and the task gets even easier ;-)16:22
lekernelif we keep USB, and even assuming we get all the pesky bugs fixed, then people will want high speed, 3.0, etc.16:22
lekernelit never ends16:22
lekerneland they'll even take it for granted16:23
wpwrakwhat would be life without a few challenges left for later ;-)16:24
lekernelalternative solution - throw in some proprietary chip with an existing driver in there and let other engineers care about the pestiferous details16:24
wpwraklike a little ARM SoC ? ;-)16:24
wpwrakand yes, there's something to be said for the "traditional approach"16:25
lekernelwell if opencores et al. didn't suck, we could copy the "traditional approach", only with FPGA cores16:26
wpwrakany chance of salvaging some bits of opencores that suck only a little ?16:27
lekernelevery single time I tried, it has been a waste of time16:28
FallenouUSB for keyboard/mouse problem can be solved with removing USB, but how would you support USB-MIDI devices ?16:28
lekernelMIDI will be unneccessary16:29
Fallenouohoh, next M1 will be a revolution then :)16:29
lekernelbesides, there is always the M1 to convince me (or not) than USB can be done properly :)16:29
Fallenoudon't forget to stick a white fruit on it :p16:29
wpwraka white fruit where somethings is wrong. after all, if it was tasty and not poisoned, it would have been eaten. so why just one bite ? did it not taste well ? did the eater come to harm ?16:34
Fallenouno you have it wrong16:38
Fallenouit comes pre-bitten by Apple16:38
FallenouApple tastes the fruit it sends you, before sending it to you16:38
Fallenouit's QA16:38
wpwrakhmm. so now that steve jobs is dead, apple products will ship without his Holy Saliva. oh dear, all the magic is gone.16:40
Fallenouthat's right :(16:40
Fallenouwe still can extract some DNA for cloning though16:40
wpwrakresurrection, 3rd millennium-style16:44
GitHub82[linux-milkymist] sbourdeauducq pushed 1 new commit to ng: http://git.io/6HiSoQ16:45
GitHub82[linux-milkymist/ng] Remove unnecessary IRQ ack functions - Sebastien Bourdeauducq16:45
GitHub93[openwrt-milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/openwrt-milkymist/commit/5e8886c85de1df6958e0e54bc3b2334aed63b06f17:04
GitHub93[openwrt-milkymist/master] Update config and description - Sebastien Bourdeauducq17:04
lekernelrootfs gets mounted, then it only does "init started: BusyBox v1.18.5 (2012-01-27 13:36:37 CET)"17:07
lekerneland nothing17:07
lekernelah, init=/bin/sh is more interesting :)17:08
wpwrakgood :)17:08
wpwrakso you have keyboard support17:08
wpwrakthat'll do :)17:09
lekernelthe openwrt fs seems pretty much screwed up though17:09
lekernelthat init issue plus things like17:09
lekernel/ # ls17:09
lekernelsh: can't execute 'ls': Permission denied17:09
lekernel~ # mount none /proc -t proc17:09
lekernelsh: can't execute 'mount': No such file or directory17:09
lekernelunless it's more kernel bugs... checking17:09
lekernelthat's from xiangfu's regular openwrt builds...17:10
wpwrakprobably doesn't get much testing17:10
lekernelah, no, it's probably memory corruption17:12
lekernelMemory available: 113852k/1179648k RAM17:12
wpwraknice ! the memory not only got faster, it also increased in size :)17:13
GitHub174[linux-milkymist] sbourdeauducq pushed 1 new commit to ng: http://git.io/Z51-cQ17:34
GitHub174[linux-milkymist/ng] Compute memory size correctly - Sebastien Bourdeauducq17:34
lekerneluserland is still fucked though...17:34
lekernelwpwrak: see what I mean with the linux problems?17:34
lekernel/ # ls17:35
lekernelsh: can't execute 'ls': Permission denied17:35
lekernel/ # /bin/ls17:35
lekernel/ #17:35
lekernel(but there is stuff in /)17:35
larsclooks like syscall problems17:35
lekernelhmm... let's try a fresh openwrt build then17:36
wpwrakyeah. almost a whole thirty minutes passed since first boot and it still doesn't work. scandalous ! that makes it quite obvious that linux sucks. quick, stop the press. remove the FB headlines, announce the imminent doom of linux ;-)17:37
wpwrakfor tracking down this sort of things, i often find it useful to put printks in the functions that seem to fail17:38
lekernel(printk) been doing that most of the day already *g*17:38
wpwrakexec is pretty complex. so the problem could come from a number of areas17:38
wpwrakheh, good ;-)17:38
larscit's most likely mmap17:45
larsclekernel: are you using the externel uclibc?17:49
larsclekernel: http://pastebin.com/SDSAEUaF17:51
lekernelI'm using the openwrt-lm32-root.ext4 from http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-openwrt.minimal-20120127-1251/17:53
larsctry a kernel with that patch17:53
lekernelwithout recompiling uclibc?17:54
larscthe patch is only necessary if uclibc tries to do a mmap syscall instead of doing the emulation in userspace using mmap217:56
lekernelstill the same17:56
lekerneltrying a fresh openwrt build now...18:00
wpwrakfor a long time i've been wondering whether it would be worth the effort to make linux also pass the origin of an errno value along with the error code. it's rather common to get an EINVAL or such from *somewhere* and it can be quite an exquisite pain to track that down.18:02
larsci wonder what would happen if you did something like #define EINVAL ({printk("Error: %s %s:%d", __func__, __FILE__, __LINE__); 11})18:07
lekernelthat's why exceptions were invented...18:11
wpwraklarsc: probably a lot of false positives of the  if (res == -EINVAL) return;  kind18:19
larscwpwrak: most likely yes18:20
kristianpaulpatch failed to apply http://paste.debian.net/170654/19:59
kristianpaulso then compilation after..20:00
Action: kristianpaul hold its atemtp use rtems and cotinues with baremetal apps20:37
lekernel_lazy lazy21:11
lekernelmaybe you should try nuttx. seems there are fewer places where such problems can happen.21:12
lekernel(of course, this implies: port it)21:12
kristianpauli'm LAZY ;-)21:20
kristianpaulperhaps try a better libc, but i prefere implement function i need in separate files :)21:20
kristianpaulor hack something with lua, why not :)21:23
qi-botThe OpenWrt build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-openwrt.minimal-20120522-2242/21:45
lekernelwtf... initrd is 46M21:48
lekernelah... seems it's the default21:51
lekernellarsc: still the same problem with a fresh openwrt build21:52
lekernelthose xiangfu images (kernel+root) also have it21:53
lekernel==> nuttx22:12
lekernelor rtems22:12
wpwrakadd printks ? :)22:43
lekernelthis kind of problems pops up every time with linux23:08
lekernelwaste of time23:08
lekerneland linux also enforces gcc23:08
wpwrak"every time" sounds as if you'd be using it a lot on M1 ;-)23:12
wpwrak(gcc) i'm not complaining ;-) besides, aren't the llvm folks aiming at gcc compatibility ? afaik, intel managed to compile the linux kernel with their (proprietary) cc. so it not an impossible objective.23:13
rohwpwrak: should be ok. linux uses some gcc extensions when it comes to c-dialect, but thats about it. nothing fancy or evil. just stuff to make code more readable23:19
roh but i'd agree thats using a full linux just for flickrnoise may be a bit over the top.23:21
rohwhat was the issue with rtems? ugly to debug?23:21
mischief6does milkymist have an mmu?23:23
rohmischief6: it will have soon23:24
rohbut its not needed for the use with flickrnoise23:24
wpwrak(rtems) dunno what triggered sebastien's current interest. maybe he wants to play with the MMU :)23:27
wpwrak(full linux) there's quite a lot of stuff you can drop if you don't need it. both in kernel and in user space.23:28
wpwrakand wouldn't it be nice to have a proper USB stack that doesn't fail with 50% of the HID devices on the market ?23:29
wpwrakand weren't there some DHCP issues as well ?23:29
wpwrakand there's probably a ton of stuff we'll find very useful to have, without awkward porting (and most likely forking)23:30
rohsure. no clue what stuff like nuttx uses as ipstack and usbstack23:52
rohi thought the dhcp problems are all just 'no mii reporting' or so, thus timing?23:53
--- Wed May 23 201200:00

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