<wpwrak>
yes, that's similar to what we have ... 10+100 nF vs. 10+220 nF. dunno if 10+100 is unusually close or not
<cladamw>
also 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.
<wpwrak>
some people also claim that mixing bypass caps like this actually doesn't work ;-)
<cladamw>
at least, 100nF+100uF is good.
<wpwrak>
yeah: x+1000*x sounds like a healthy difference :)
<cladamw>
the 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 ?
<cladamw>
btw, although now m1's 8 VDDx supplies comes either 100nF or 10nF, so let's make it symmetric during m1r4.
<wpwrak>
(not for MP) well, we now have 10 caps per chip. micron recommend 16. that's not such a huge difference.
<cladamw>
pin [1, 18, 33] are the VDD; pin [3, 9, 15, 55, 61] are for VDDQ.
<cladamw>
yeah ... we are not to add more. :-)
<cladamw>
just balance it. :-)
<cladamw>
even "never change a working design" is a common rule, but no fun. :-)
<cladamw>
also 100nF & 10nF are all the same package in 0402. :-)
<cladamw>
1uF too.
<cladamw>
pin 33 now has 100.01uF, i'd like to let U14.15 (C164) to be 100nF, then this balances to U15.15(C157, 100nF)
<cladamw>
U14.1 (C162) to be 10nF, then balance to U15.1(C159, 10nF)
<cladamw>
U14.18(C245) to be 1uF, then balance to U15.18(C156, 1uF)
<wpwrak>
since 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 work
<cladamw>
i know this is not 100 completely followed micron's suggestions. :-)
<wpwrak>
i'm kinda curious if sebastien will find issues with the new optimized DRAM interface. if he does, we'll know what to look for :)
<cladamw>
wpwrak, ah ... sounds you don't want to get magic/fun on this.
<wpwrak>
i mean: if sebastien runs into trouble with m1rc3, then we'll know where to look for it :)
<cladamw>
(IBIS) ?
<wpwrak>
that would be very sophisticated :)
<cladamw>
if let the IBIS model to be optimized on a unbalanced plateform, how you supposedly will get positive results ? :-)
<wpwrak>
hmm ? why would that affect the IBIS model ?
<cladamw>
i don't know, just intuitively judged.
jimmythehorn has joined #milkymist
<wpwrak>
the IBIS model would come from the vendor. i'd hope they don't do this sort of nasty things ;-)
<wpwrak>
anyway, do we use IBIS anywhere ?
<cladamw>
don'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.
<wpwrak>
you mean sebastien's measurements with that high-end oscilloscope ?
<wpwrak>
i don't recall sebastien mentioning any simulations
<wpwrak>
Jul 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 want
<wpwrak>
sounds pretty sceptical ;-)
<wpwrak>
Mar 29 10:57:58 <lekernel> wpwrak: there are IBIS models published by the various chip vendors, but I don't know how they work internally
<wolfspraul>
we have something that we know works today
<wolfspraul>
and on the other side we have recommendations about values
<wolfspraul>
can't we just slowly move towards the recommended values, unless we know better?
<wpwrak>
i think making both chips use the same values on the same pins is a step in that direction
<wolfspraul>
not 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.
<wolfspraul>
but I have no thoughts on the exact values or in which way to clean them up
<wpwrak>
there's of course always a risk. but it should be quite minimal.
<wpwrak>
yes, a more efficient memory controller and/or maximizing the memory clock would be the most likely ways to reveal bypassing issues
<wolfspraul>
yeah so let's cleanup now and go for what we believe is best, using the methods that are actually at our disposal
<wpwrak>
in general, i'm not against implementing exactly what micron recommend, e.g., 10+220 nF.
<wpwrak>
adam 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.
<cladamw>
but sounds you'd like to wait until a real new optimized DRAM interface came out on m1rc3 firstly ?
<cladamw>
(PCB spacing) no, i am not concerned it.
<wpwrak>
cladamw: naw, that wouldn't make sense. i think it will take a while before we have more extensive testing on m1rc3.
fpgaminer has quit [Remote host closed the connection]
fpgaminer has joined #milkymist
<cladamw>
wpwrak, 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.
<wolfspraul>
if 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 imho
<wpwrak>
... micron recommend at least two caps per chip, not per pin
<cladamw>
so now we know what's the results will be after new optimized DRAM interface, we see later this.
<wpwrak>
so we should already have quite a good number. however, note that this is from 2006. they even mentioned electrolytic caps ! ;-)
<cladamw>
so now means we want to take risk to add/follow micron. :-)
<cladamw>
wpwrak, yeah ... as you know, we can 100% follow them but try at most. :-)
<cladamw>
s/can/cannot
<wpwrak>
wait ... what i'm saying is that, as i understand what they write, this PDF (from 2006) says we need at least two caps per chip
<wpwrak>
we already have ten caps per chip ...
<wpwrak>
oh, sorry. i mean at least FOUR caps per chip
<wpwrak>
(two for VDD, two for VDDQ)
<wpwrak>
this 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-7IO7Otxmjt0CQea74aFLQ
<cladamw>
yeah ... micron recommends FOUR per chip
<wpwrak>
so i'd say that, once we clean up the U14/U15 asymmetry, we should be in good shape
<cladamw>
nice, this technical note also be noted in tn4614.pdf
<cladamw>
so at least FOUR. then we need 10 nF and 220nF
<cladamw>
those two 100uF (C240, C248) we can still keep them, seems as 1000 times as good.
<cladamw>
now VDDs for pin [1, 18, 33]
<cladamw>
wpwrak, are you reading tn4602 ?
<wpwrak>
(100 uF) having a big silo around never hurts ;-)
<wpwrak>
(tn4602) not tonight :)
<cladamw>
1. let 100nF to be 220nF directly,
<cladamw>
2. pin 61 is still good on 10nF
<cladamw>
wpwrak, are you thinking table for capacitance ? :-)
cladamw has quit [Quit: Ex-Chat]
<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.
<wpwrak>
but then, it's not as if this was done a lot of times. so ...
jimmythehorn has quit [Quit: jimmythehorn]
Zorro has joined #milkymist
Zorro is now known as Guest57495
Gurty` has quit [Ping timeout: 265 seconds]
hypermodern has joined #milkymist
cladamw has joined #milkymist
Jia has quit [Quit: Konversation terminated!]
Jia has joined #milkymist
cladamw has quit [Quit: Ex-Chat]
Jia has quit [Ping timeout: 246 seconds]
rejon_ has quit [Ping timeout: 246 seconds]
cladamw has joined #milkymist
jimmythehorn has joined #milkymist
jimmythehorn has quit [Quit: jimmythehorn]
mumptai has joined #milkymist
elldekaa has joined #milkymist
Martoni has joined #milkymist
mumptai has quit [Ping timeout: 265 seconds]
Jia has joined #milkymist
<lekernel>
wpwrak: I did IBIS simulations too
<lekernel>
but I just threw them into some magic proprietary software...
kyak has quit []
voidcoder has quit [Quit: See you next time]
voidcoder has joined #milkymist
kyak has joined #milkymist
methril has quit [Ping timeout: 276 seconds]
Jia has quit [Quit: Konversation terminated!]
methril has joined #milkymist
<wpwrak>
lekernel: (IBIS) oh, cool. pity about the proprietary stuff, though.
elldekaa has quit [Ping timeout: 245 seconds]
cladamw has quit [Quit: Ex-Chat]
elldekaa has joined #milkymist
methril has quit [Ping timeout: 246 seconds]
elldekaa has quit [Read error: Connection reset by peer]
elldekaa has joined #milkymist
xiangfu has quit [Ping timeout: 246 seconds]
voidcoder has quit [Read error: Connection reset by peer]
voidcoder has joined #milkymist
methril has joined #milkymist
lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: Something to do? Port NuttX to Milkymist SoC
rejon_ has joined #milkymist
<GitHub178>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/-pcRIQ
<GitHub178>
[milkymist-ng/master] Clock frequency detection - Sebastien Bourdeauducq
cladamw has joined #milkymist
<GitHub176>
[linux-milkymist] sbourdeauducq created ng (+1 new commit): http://git.io/GeCS4Q
<Fallenou>
Linux kernel boots on Milkymist-ng ? :)
<wpwrak>
i'm afraid its YAOS aka nuttx
<wpwrak>
if sebastien goes on like this, M1 will be remembered in history as the platform that has more operating systems than users ;-)
<Fallenou>
humm if it's in "linux-milkymist" I guess it's really linux
<wpwrak>
hmm. you may have a point there. so i'll eat my words. dunno what that nuttx thing was about then.
<Fallenou>
I think he wants to try nuttx out, in case someone has the time to port it to M1 =)
<Fallenou>
Will Nuttx have a nice usb stack ? :)
<Fallenou>
it seems to support a few usb things
<Fallenou>
that would mean we don't need mmu anymore :"
<Fallenou>
if we port Nuttx
<lekernel>
Fallenou: yes, it boots on -ng
<wpwrak>
i daresay that, unless it rips out rather large portions of the Linux kernel, it won't come near matching its USB support
<lekernel>
haven't tried userland yet but it should be ok
<lekernel>
cleaning up the irq code a bit, then try to see if the executable loader somewhat works or if we should use nuttx
<lekernel>
wpwrak: no USB on the next MM
<lekernel>
too much pain
<lekernel>
and it's not a distinctive feature, people take it for granted
<wpwrak>
nuttx sounds like just another RTEMS-like dead end. perhaps prettier, but just as dead :)
<kristianpaul>
Fallenou: question goes for milkymist first i think
<lekernel>
why is it dead?
<wpwrak>
by the time a MM that could sell without USB is ready, i think we'll have solved he USB issue as well :)
<lekernel>
if we had used linux, then nothing would probably work today
<kristianpaul>
oh
<kristianpaul>
dead indeed
<Fallenou>
18:18 < lekernel> Fallenou: yes, it boots on -ng < congratulation !!
<wpwrak>
(dead) well, another niche development. small developer base, limited testing, etc.
<lekernel>
we'd still be figuring out performance/bloat/GNU/autocrap/FDPIC/etc. problems
<wpwrak>
FUD FUD FUD ;-)
<lekernel>
and probably stability as well
<lekernel>
I remember larsc saying a while ago that the thing still crashed every 30 minutes or so
<wpwrak>
if you insist, you can make linux boot into a custom executable just as well as rtems and such
<lekernel>
that's not the only problem
<wpwrak>
that was to counter your autocrap argument :)
<lekernel>
and having a small FS and a loader is nice ...if it works without extreme hassle, which it does not
<wpwrak>
you're too impatient :) sputnik didn't fly to mars. bah. let's forget about space exploration.
<lekernel>
pick your battles
<lekernel>
and I don't think RTEMS is responsible for many of the M1's problems
Martoni has quit [Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120423130206]]
<lekernel>
but you see, I'm considering linux
<wpwrak>
yes, that's good :)
<lekernel>
I did try to use it at the beginning, and little got done
<lekernel>
now I'm evaluating it again
<lekernel>
I'm not holding my breath though
<wpwrak>
consider 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.
<lekernel>
USB already has an easy solution: remove it completely
<wpwrak>
why stop there ? remove video out too and the task gets even easier ;-)
<lekernel>
if we keep USB, and even assuming we get all the pesky bugs fixed, then people will want high speed, 3.0, etc.
<lekernel>
it never ends
<lekernel>
and they'll even take it for granted
<wpwrak>
what would be life without a few challenges left for later ;-)
<lekernel>
alternative solution - throw in some proprietary chip with an existing driver in there and let other engineers care about the pestiferous details
<wpwrak>
like a little ARM SoC ? ;-)
<wpwrak>
and yes, there's something to be said for the "traditional approach"
<lekernel>
well if opencores et al. didn't suck, we could copy the "traditional approach", only with FPGA cores
<wpwrak>
any chance of salvaging some bits of opencores that suck only a little ?
<lekernel>
every single time I tried, it has been a waste of time
<Fallenou>
USB for keyboard/mouse problem can be solved with removing USB, but how would you support USB-MIDI devices ?
<lekernel>
MIDI will be unneccessary
<Fallenou>
ohoh, next M1 will be a revolution then :)
<lekernel>
besides, there is always the M1 to convince me (or not) than USB can be done properly :)
<Fallenou>
don't forget to stick a white fruit on it :p
<wpwrak>
a 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 ?
kilae has joined #milkymist
<Fallenou>
no you have it wrong
<Fallenou>
it comes pre-bitten by Apple
<Fallenou>
Apple tastes the fruit it sends you, before sending it to you
<Fallenou>
it's QA
voidcoder has joined #milkymist
<wpwrak>
hmm. so now that steve jobs is dead, apple products will ship without his Holy Saliva. oh dear, all the magic is gone.
<Fallenou>
that's right :(
<Fallenou>
we still can extract some DNA for cloning though
<wpwrak>
resurrection, 3rd millennium-style
<GitHub82>
[linux-milkymist] sbourdeauducq pushed 1 new commit to ng: http://git.io/6HiSoQ
<lekernel>
hmm... let's try a fresh openwrt build then
jimmythehorn has joined #milkymist
<wpwrak>
yeah. 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 ;-)
elldekaa has quit [Remote host closed the connection]
<wpwrak>
for tracking down this sort of things, i often find it useful to put printks in the functions that seem to fail
<lekernel>
(printk) been doing that most of the day already *g*
<wpwrak>
exec is pretty complex. so the problem could come from a number of areas
<wpwrak>
heh, good ;-)
<larsc>
it's most likely mmap
<larsc>
lekernel: are you using the externel uclibc?
<larsc>
the patch is only necessary if uclibc tries to do a mmap syscall instead of doing the emulation in userspace using mmap2
<lekernel>
still the same
<larsc>
ok
<lekernel>
trying a fresh openwrt build now...
mumptai has joined #milkymist
<wpwrak>
for 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.
<larsc>
i wonder what would happen if you did something like #define EINVAL ({printk("Error: %s %s:%d", __func__, __FILE__, __LINE__); 11})
<lekernel>
that's why exceptions were invented...
<wpwrak>
larsc: probably a lot of false positives of the if (res == -EINVAL) return; kind
<larsc>
wpwrak: most likely yes
jimmythehorn has quit [Quit: jimmythehorn]
jimmythehorn has joined #milkymist
lekernel_ has joined #milkymist
lekernel has quit [Ping timeout: 276 seconds]
antgreen has quit [Read error: Connection reset by peer]
voidcoder has quit [Read error: Connection reset by peer]
<lekernel>
(mine)
voidcoder has joined #milkymist
<lekernel>
ah... seems it's the default
<lekernel>
larsc: still the same problem with a fresh openwrt build
<lekernel>
those xiangfu images (kernel+root) also have it
mumptai has quit [Quit: Verlassend]
<lekernel>
==> nuttx
<lekernel>
or rtems
<lekernel>
:)
<wpwrak>
add printks ? :)
<lekernel>
phew
<lekernel>
this kind of problems pops up every time with linux
<lekernel>
waste of time
<lekernel>
and linux also enforces gcc
<wpwrak>
"every time" sounds as if you'd be using it a lot on M1 ;-)
<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.
<roh>
wpwrak: 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 readable
<roh>
afaik
<roh>
but i'd agree thats using a full linux just for flickrnoise may be a bit over the top.
<roh>
what was the issue with rtems? ugly to debug?
<mischief6>
does milkymist have an mmu?
<roh>
mischief6: it will have soon
<roh>
but its not needed for the use with flickrnoise
<wpwrak>
(rtems) dunno what triggered sebastien's current interest. maybe he wants to play with the MMU :)
<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.
elldekaa has quit [Read error: Connection reset by peer]
<wpwrak>
and wouldn't it be nice to have a proper USB stack that doesn't fail with 50% of the HID devices on the market ?
<wpwrak>
and weren't there some DHCP issues as well ?
<wpwrak>
and there's probably a ton of stuff we'll find very useful to have, without awkward porting (and most likely forking)
<roh>
sure. no clue what stuff like nuttx uses as ipstack and usbstack
<roh>
i thought the dhcp problems are all just 'no mii reporting' or so, thus timing?