Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
<wpwrak>
anyone care to test this one ? the git versions look good. everything the latest.
<wolfspraul>
you mean the daily build?
<wpwrak>
yup
<wpwrak>
at least from the outside, it looks as if it should be as good as the binaries i've uploaded yesterday
<wpwrak>
well, actually even the ones from today :)
<wolfspraul>
I'm brave, flashing now
<wolfspraul>
I fully expect this to brick my m1 :-)
<wpwrak>
well, you already have all the files you need to unbrick it ;-)
<wolfspraul>
same as before, mouse doesn't work
<wpwrak>
funny
<wolfspraul>
and probably nothing else on usb
<wolfspraul>
we'll get to the bottom of it, don't worry
<wolfspraul>
maybe the bitstream comes out differently? different ise version?
<wpwrak>
hmm, that's one possibility
<wpwrak>
could also be that the softusb firmware didn't make it
<wpwrak>
that would be my main suspect
<wpwrak>
the source is in milkymist.git but then it travels into rtems
<wolfspraul>
going back to your binaries now with m1nor
<wpwrak>
now, rtems has its own obsolete copy of it, so it it doens't pick up the version from milkymist.git, things will go badly
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<wolfspraul>
back to your image - wors
<wolfspraul>
works
<wpwrak>
btw, does anyone need a ledm board for M1r4 development ? i have a second pcb (etched and tinned but not populated)
<wolfspraul>
the test software needs to test-enable all leds
<wpwrak>
oh, and now that it's dark outside ...
<wolfspraul>
other than that I don't have a need on my end right now
<wolfspraul>
the design should be verified, manufacturing implications should be minor
<wpwrak>
(enable all leds) easy: mfill 0xe0009000 255 0x60
<wolfspraul>
test software needs to be amended
<wolfspraul>
ok but it needs to be integrated into the pass/fail flow to be efficient
<wpwrak>
should it step through them or just turn them all on ?
<wolfspraul>
what kind of testing is enough? turn them all one at once?
<wpwrak>
or walk / ... ?
<wolfspraul>
what do we want to test?
<wolfspraul>
that all parts are soldered correctly
<wolfspraul>
imagine some of the resistors not being soldered correctly
<wpwrak>
if you have a short between columns or between rows, an "everything on" test wouldn't show it
<wolfspraul>
yes
<wpwrak>
also, if a LED is rotated, either nothing of the pair would come on
<wolfspraul>
so the test should catch faulty leds, and it should catch a soldering problem of any individual part in the circuit
<wpwrak>
it could send the LEDs running around the board. one at a time
<wolfspraul>
at the same time it should be efficient to walk through, and log its findings, or rather log the test results as input by the operator
<wpwrak>
phew. logging is tricky ;-)
<wpwrak>
input from the operator is easier :)
<wolfspraul>
nah, it's just one round, and then enter yes/no
<wolfspraul>
if you think that rotating through them one by one is enough to test the above cases, that's good then
<wolfspraul>
part can be missing, soldered badly, rotated, damaged or malfunctioning
<wolfspraul>
probably more
<wpwrak>
one problem with being so energy-efficient is also that it would be hard to measure whether a led is lit, since the long-term average current is just about 400 uA
<wolfspraul>
after smt is the first and best opportunity to test it all as a set
<wolfspraul>
no need to go to that level of automation
<wolfspraul>
a yes/no entry is perfectly fine
<wolfspraul>
if they go around the board and each is lit for what? 0.5 seconds? that's just 10 secsonds then
<wpwrak>
i think rotating should test all the things we can reasonably test
<wolfspraul>
no problem
<wpwrak>
yeah, half a second per led should be plenty
<wolfspraul>
should we turn them all on together at the end?
<wolfspraul>
just in case :-)
<wolfspraul>
3 seconds? :-)
<wolfspraul>
or maybe first turn them all one, then go through one by one?
<wpwrak>
for automated testing, the current could be increased to 6 mA for one led (limited by the resistor). maybe an option :)
<wolfspraul>
I think all-on first is good too
<wolfspraul>
do a little boundary testing, then go through one by one to make sure the grid is good
<wpwrak>
hmm yes, why not
<wpwrak>
an automated test may actually work. with the array going full blast, i see a clear increase
<wolfspraul>
measured how?
<wpwrak>
multimeter in the DC in path
<wolfspraul>
adam currently has a script on his notebook, which will feed serial output from the test software right into the log file which will end up on the server
<wolfspraul>
attaching more things to that would be difficult enough to not be worth it right now
<wpwrak>
a single led barely registers. but that's also because of the multiplexing.
<wolfspraul>
but I'm thinking about logging this
<wolfspraul>
it's not worth it for us right now
<wolfspraul>
adam keeps an eye on the current *all the time* out of survival thinking
<wpwrak>
fake non-multiplexed does provide a clear increase
<wolfspraul>
it's like his third eye constantly looking to the power supply
<wpwrak>
all this is with the M1 in a halfway normal configuration, ethernet and rii keyboard connected
<wpwrak>
so it's not super-quiescent
<wpwrak>
yeah. i think we can definitely do this
<wpwrak>
(current) the power supply itself should take care of that ;-)
<wpwrak>
i can set up mine to make quite a riot if things go above the threshold (in addition to the normal "overcurrent" beep)
<wolfspraul>
what do you want to do?
<wolfspraul>
Adam manually keeps an eye on current, by default
<wolfspraul>
we don't need to define an expected current pattern right now and then somehow match it to the test software that is goign through the peripherals - too much work for too little gain
<wpwrak>
i'm tempted to make an automated test. we can then let adam catch up.
<wolfspraul>
very bad return on investment
<wpwrak>
naw. once the test is made, it can be pulled out anytime
<wpwrak>
and eventually we want to automate such things anyway
<wolfspraul>
the power supply measurements would need to be matched with the flow of the test software coming in over serial in real-time
<wpwrak>
not necessarily :)
<wpwrak>
it can just detect whether the current is changing in the right way
<wolfspraul>
how is it connected to the test software?
<wpwrak>
the one running on the m1 ? not at all. you'd manually start the test and it would tell you if it sees the right pattern
<wpwrak>
integration can wait until we add more elements to this
<wpwrak>
but having one test that works would a) provide motivation to do this, and b) already provide several prerequisites
<wpwrak>
e.g., the ability to talk to adam's multimeter
<wolfspraul>
sounds like we are opening a can of worms without any need to do so right now
<wolfspraul>
in the long run I agree, of course. a programmable power supply that can follow test execution is great.
<wpwrak>
it's precisely this wall of fear i want to breach
<wolfspraul>
no fear
<wolfspraul>
just work
Gurty [Gurty!~princess@78.250.179.43] has joined #milkymist
<wolfspraul>
and very bad return on investment
<wolfspraul>
Adam will not use this, for sure
<wpwrak>
we're not doing it because it's scary. and we'll always be scared because we never dare to do it.
<wolfspraul>
he keeps an eye on the power supply, and that's better than any test software could ever do, after *A LOT* of tweaking and automating
<wpwrak>
oh, he might. it just has to be non-intrusive
<wolfspraul>
not scary at all
<wolfspraul>
just bad return
<wolfspraul>
very bad
<wolfspraul>
you are right - watching current is the #1 thing after smt and in testing
<wpwrak>
i wouldn't expect him to start adding test cases, but using semi-automated current tests shouldn't be something to be afraid of. it could even just run continuously and tell him what it sees
<wolfspraul>
and doing that under the control of a wise and powerful computer/software - great
<wolfspraul>
but the amount of work we need to put into that now until it even catches up with manually keeping an eye on the power supply - crazy
<wolfspraul>
it's not about afraid here, it's about waste of money
<wpwrak>
the thing is that he can't really see this on the power supply
<wolfspraul>
the human eye is better in that case, right now
<wpwrak>
he sees other things there. like the board going berserk. but these are small and rapid changes.
<wpwrak>
plus there's a pattern to them. the pattern has to be right, too. very hard for humans to see. pretty easy for computers, though.
<wolfspraul>
not worth it
<wpwrak>
you underestimate the value of giving adam advanced tools ;-)
<wolfspraul>
I know it won't be used, it's too difficult and uneconomical
<wolfspraul>
you don't spend 100 USD to create something that costs 80 USD
<wolfspraul>
I rather throw away the 80 USD loss
<wolfspraul>
later on I fully agree with you, also on importance etc.
<wolfspraul>
but we have so many things we don't test
<wolfspraul>
temperature
<wpwrak>
if we ever want to do current measurements, he'll have to do pretty much all the steps there anyway. like connecting the M1 through a multimeter. and connecting the multimeter to a pc.
<wpwrak>
and that's probably the bulk of the work
<wolfspraul>
trust me it's uneconomical. the actual fail cases you are hunting are too rare.
<wpwrak>
for the actual test, he'd just run the current monitor program. every once in a while, it would say "pattern detected", a bit later "X rounds okay", and then "pattern lost". that's all.
<wpwrak>
i'm not hunting so much for fail cases
<wolfspraul>
yeah I know what you want :-)
<wpwrak>
i want to bring adam closer to more reliable tests
<wolfspraul>
you can do it in your lab, but it won't be used in reality
<wolfspraul>
it's uneconomical
<wolfspraul>
I will not pay the losses
<wolfspraul>
if you want this to be used, you have to wire money to me
<wolfspraul>
it's not worth the effort
<wolfspraul>
conceptually I'm all in love with it of course
<wpwrak>
also the manual led test has lots of potential for human error. e.g., you can miss a change (the leds aren't evenly distributed, so it's not like a continuous movement). worse, if a led on the other side goes on when it shouldn't, you may not even see it.
<wolfspraul>
after a while you will, and for the remaining exotic cases, well, they will just go undetected
<wolfspraul>
in larger runs when you have more operators and changing operators and more people that know the board less, it may make more sense
<wpwrak>
yes, if you stare long enough at it, you will eventually spot the weird ones. it's also good if adam does some spotting, because there may be surprises we didn't think of
<wolfspraul>
oh totally
<wolfspraul>
2 seconds all on, after that rotate through each one for 0.5 seconds, enter pass/fail manually, log over serial, done
<wpwrak>
the thing is that we have zero automation on adam's side. so if anything comes up that needs a bit more sophisticated testing, he can't do it. or he has to spend a lot of time playing robot.
<wolfspraul>
zero automation? -> test software?
<wpwrak>
and we can't even trust his results entirely because of human error - which gets worse when playing robot
<wolfspraul>
in fact I think we are automated quite well
<wolfspraul>
you just try to rationalize the automated current watch now
<wolfspraul>
we can talk with adam about test time / board and where it's painful
<wolfspraul>
but in the last run, we have made a lot of improvements
<wolfspraul>
which is mostly in small details like a script here or there
<wolfspraul>
also we do a 1h rendering test now
<wolfspraul>
you propose to have a camera watch a screen (none attached right now), and compare with expected rendering? :-)
<wolfspraul>
our testing is great, when we add the leds we just add one more simple test case and fine
<wpwrak>
(automation) okay, there are some automated tests. but only of things that are basically inside the M1. nothing that involves outside observation.
<wolfspraul>
adams power supply is set to a strict maximum, that's 80% of what we need there :-)
<wpwrak>
rendering is tricky :) i've seen a lot of failure modes by now ...
<wolfspraul>
yes, but please not - any automation of that kind of testing just adds more uneconomical things
<wolfspraul>
it's not practical
<wolfspraul>
then we can sell each m1 for 5000 USD
<wolfspraul>
we have to be real
<wolfspraul>
it's like you make a bicycle, and at the end some worker makes a short test ride
<wolfspraul>
and done
<wpwrak>
i think you greatly overestimate the complexity of this
<wolfspraul>
and nobody will start to work on a bicycle-riding robot that will test each molecule of the structure to its guaranteed safe margins or whatever
<wolfspraul>
for you it's easy
<wolfspraul>
and I like it to be an independent system first, with pattern, which can then later be integrated
<wolfspraul>
all fine
<wolfspraul>
but at that point it will stop on my side
<wolfspraul>
it won't be used
<wolfspraul>
only in the buenos aires lab :-)
<wpwrak>
well, i like incremental development :)
<wolfspraul>
yes current is important, but by far the easiest for us is to watch it manually
<wolfspraul>
trust me
<wolfspraul>
I'm speaking for Adam, he will tell you after his holiday
<wolfspraul>
it's about economics
<wolfspraul>
the thing we are making is not worth thousands of dollars, it's not a pacemaker, it's not used in an airplane, and so on
<wpwrak>
you can't test the leds by watching current manually. at least not within a reasonable amount of time. if you want to spend ten minutes staring at the instrument and manually reconfiguring the leds, then yes.
<wpwrak>
and you may still miss something, because it's so repetitive
<wolfspraul>
how did we test the total of 6 leds we have right now (3 on m1, 3 on jtag-serial)?
<wolfspraul>
you zoom in on the wrong detail, imho
<wolfspraul>
we rotate through them, and done
<wpwrak>
what i'm saying is that, once you have covered the basics of monitoring current, then you can do a lot of things very easily.
<wolfspraul>
I don't even know whether the 3 leds we have right now have any test, because it will be apparent when booting and rendering whether they work or not
<wpwrak>
what i think you're afraid of is the cost of covering these basics
<wolfspraul>
you can, if it's economical
<wolfspraul>
no, my cost is 0
<wolfspraul>
it won't be used
<wolfspraul>
cost = 0
<wolfspraul>
:-)
<wpwrak>
so instead you accumulate inefficiency. each time there would be something you could do better if you had the basic ability, you decide it's too expensive to do it just for that.
<wolfspraul>
it's a tiny detail taken out of proportion
<wolfspraul>
you are worried about which case?
<wolfspraul>
a led with some malfunction that makes it suck up current?
<wpwrak>
so you build an inefficient process instead. repeat this a few times and you've paid a huge cost for inefficiency while still not having advanced towards a proper solution.
<wolfspraul>
go ahead and do it :-)
<wolfspraul>
manufacturing is about economics. a process that costs 10 USD to save 5 USD will be turned off very fast...
<wpwrak>
(go and do it0 that's the right attitude ! :)
<wolfspraul>
which case is it?
<wolfspraul>
the specific failure case you hope to catch...
<wpwrak>
naw, we're currently not into production economics. it's all about covering the basics.
<wolfspraul>
:-)
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<wolfspraul>
alright then
<wolfspraul>
I cannot even think of a led failure case where this could help
<wpwrak>
there are a lot of failure cases this can catch: basically all we listed before. (plus a few we didn't)
<wolfspraul>
we've had a number of current problems in rc3, maybe at least you wait until you hear from Adam where they came from
<wolfspraul>
certainly not the leds
<wpwrak>
but the key is that it does this in an automated way. no tired operator involved.
<wolfspraul>
it's unpractical and won't be used
<wolfspraul>
some shiny equipment standing in the corner
<wolfspraul>
happens sometimes, right? :-)
<wpwrak>
ah, i know that "wolfgang the pessimist" pattern already. remember #1024 ? ;-)
<wolfspraul>
ok I tried to make my point
<wpwrak>
naw, adam should already have the equipment. not very shiny, though. a bit of a capital injection into his lab wouldn't be amiss ... not for this case, but in general. with what he has, he's halfway blindfolded.
<wolfspraul>
the rc3 we have in stock are just fine
<wolfspraul>
testing is about economics, once you forget that you can stop testing right there
<wolfspraul>
I suggest you at least look for real current problems, not imagined ones like with the leds
<wpwrak>
sure. the economic objective is scalability, improved failure detection, and less time wasted on false alarms
<wolfspraul>
because there were quite a few in rc3 (all easily spotted manually)
<wpwrak>
plus, the ability to track down issues faster
<wolfspraul>
not worth it
<wolfspraul>
I will ask Adam when he's back, then we see
<wolfspraul>
I can only tell you my experience right now, and I focus on the economics
<wpwrak>
i remember someone spending a good amount of time at a certain factory in china trying to get remote access to their test line. you were happy then. remember those good days, not the misery that followed :)
<wolfspraul>
also I'd hate to invent test case on my own genius thoughts. instead, we ask how others are testing in mass-production (in Taipei), and then we know what makes sense
<wolfspraul>
I know
<wolfspraul>
I could imagine that in most cases, current consumption is not programmatically monitored
<wolfspraul>
I have never seen it. I can imagine that it does happen for very high-value products though.
<wpwrak>
what i need from adam is him to set up his multimeter such that it can be accessed from the pc. he probably hasn't done that yet. then i need to figure out how to talk to his model. may be easy, may be tricky. we'll see.
<wolfspraul>
waste of time and money, there is nothing to gain for us there.
<wpwrak>
if it's too hard, we have to postpone this until you get him better equipment
<wolfspraul>
he will tell you :-) (without me playing dirty tricks...)
<wolfspraul>
it's not worth it, no matter what equipment
<wolfspraul>
adam is a production guy
<wpwrak>
he's also an engineer. don't underestimate him :)
<wolfspraul>
if yield is bad, you have 2 options first: be smarter on testing and process *or* make more
<wolfspraul>
current problems are typically drastic, a short will typically burn through at least one chip
<wolfspraul>
there's no way you will not catch it later in the test process
<wpwrak>
yes, but in order to be smarter, you have to have the means to do so
<wolfspraul>
and they are too rare to justify being caught earlier, definitely for us right now
<wolfspraul>
it may not be worth to be smarter
<wpwrak>
and if you don't have them yet, then the day you have a yield problem is a bad time to start
<wolfspraul>
you can just make more boards, test quickly, discard the ones that don't pass (spare parts)
<wpwrak>
it's like thinking about an oil change only when your car stops working
<wolfspraul>
we are going in circles. I need specific cases.
<wolfspraul>
in rc3 we had current problems, but all caught easily manually
<wpwrak>
cases of what exactly ? i already told you that this can detect all the various led issues we've discussed
<wolfspraul>
and it would be very hard to automate the catching of those
<wolfspraul>
what is wrong with the led?
<wpwrak>
it could be missing, not soldered, shorted, rotated
<wolfspraul>
you will just see whether it's on or off
<wolfspraul>
missing - eye
<wolfspraul>
not soldered - eye
<wolfspraul>
shorted - eye
<wolfspraul>
rotated - ?
<wpwrak>
the traces leading to it could be interrupted or shorted (e.g., under the BGA)
<wpwrak>
rotated: wrong polarity
<wolfspraul>
you are trying to tell Adam (or me) what causes work in testing, but Adam is doing the work. he can tell you.
<wpwrak>
not soldered: sometimes very hard to see. in many cases something you only spot if you already know that there is a problem and where
<wolfspraul>
we improved testing a lot in rc3, for Adam, and it was mostly very small things that helped him a lot.
<wpwrak>
sure. you can do everything manually :-)
<wolfspraul>
and I will continue exactly along those lines - fix the real problems he has, not invent new problems for him from excessive testing systems
<wpwrak>
why even have M1 ? you can do it all with pencil and paper ;-)
<wolfspraul>
seriously we need knowledge of real problem cases before adding test cases
<wolfspraul>
everything else is crazy, we can improve testing forever
<wolfspraul>
we had 90*3 = 270 leds on rc3
<wolfspraul>
I am sure 0 problems (0 found problems)
<wolfspraul>
and even if there was an undetected problem somewhere, it's not worth to try to find it
<wpwrak>
well, none of the problems i mentioned are particularly uncommon
<wolfspraul>
another 600+ leds on the jtag-serial run
<wolfspraul>
let's just ask Adam. I will...
<wpwrak>
in other words, you think led testing is completely superfluous. now we're getting somewhere ;-)
<wolfspraul>
and if there are problems, we need to find the most economic test cases to catch them
<wolfspraul>
if there are no problems, we wait until we find a problem (and no, we cannot test everything to make sure we will never have a problem, that doesn't work)
<wolfspraul>
argh
<wolfspraul>
all-on, then rotate through
<wolfspraul>
sounds good to me
<wolfspraul>
the current discussion went too far for me
<wolfspraul>
I've done and overseen a lot of testing on the line
<wolfspraul>
I know when current is important - mostly right at the beginning before boot/bringup
<wolfspraul>
things that come later are isolated to some chips
<wpwrak>
the current monitoring would work with the above rotation. think of it as an automated version of the operator who chases around the m1, watching the leds.
<wolfspraul>
sure
<wolfspraul>
great concept
<wpwrak>
(current) wait .. it's not about the system massively overloading
<wolfspraul>
I think we are not too far apart actually. You are probably not suggesting uneconomic test steps either.
<wpwrak>
that's what adam is looking for. he doesn't want the board to go critical.
<wolfspraul>
a test step that doesn't find anything is to be removed
<wolfspraul>
sorry I gotta go sleep, only 4h left, then meetings here there, timezones, argh
<wpwrak>
the current test i'm talking about is more analytical. it tells us what the board is doing.
<wolfspraul>
my heart has to take 4-5 hours sleep and 0.5-1l coffee / day
<wolfspraul>
we may not need that testing in the run
<wpwrak>
awww ...
<wolfspraul>
it's design testing
<wpwrak>
nasty amount of coffee
<wpwrak>
no no, it's production testing ;-)
<wolfspraul>
yeah will reduce a little. but there's a burger king nearby that just has such great coffee, they got a brand new machine.
<wpwrak>
just for you ;-)
<wolfspraul>
trust me you are going too far with this, please let's ask adam
<wolfspraul>
I am going by actual real experience
<wolfspraul>
Adam can ask others that are making products with a combined millions of leds
<wolfspraul>
and then we do exactly as they do
<wolfspraul>
and you will be surprised :-) (or maybe not, you know China...)
<wpwrak>
design testing would be worrying about the difference whether i see 6.3 mA or 6.1 mA, and why. the production testing would be whether i see 0, 3, 6, or 12 mA :)
<wolfspraul>
let's see what cases exist
<wolfspraul>
not in theory, but in production reality
<wpwrak>
yeha, the chinese approach of just throwing people at a problem has its merits :)
<wolfspraul>
and then we see whether it's worth to hunt them down
<wpwrak>
but eventually, their salaries will go up, too :)
<wolfspraul>
if a led sucks up 12mA instead of 6, but is still on - so what?
<wpwrak>
that means there's another LED that's on, too
<wolfspraul>
if it appears to work it may just work
<wolfspraul>
how about that? :-)
<wpwrak>
no. there's somethign wrong.
<wolfspraul>
some late-night philosophy
<wolfspraul>
if it appears to work it works
<wolfspraul>
wrong is if the manufacturer goes out of business
<wpwrak>
if it appears to work, your tester isn't paying attention :)
<wolfspraul>
we are all human
<wpwrak>
or his training was deficient
<wolfspraul>
you can't get me now, I get my human untested sleep
<wolfspraul>
n8
<wpwrak>
hehe ;-) sweet dreams of chasing leds !
<wolfspraul>
nah. ask adam what others do, put smile on, do the same
<wpwrak>
i'm pretty sure they have current tests. it's a cheap, efficient, and versatile thing to have.
Gurty [Gurty!~princess@78.250.179.43] has joined #milkymist
<xiangfu>
wpwrak, I update the milkymist and flickernoise . but I can't compile any patch anymore. it always give me: "can initialize non-system variables only to zero near 'decay'"
<xiangfu>
"can initialize non-system variables only to zero near 'XXXX'"
<xiangfu>
I think I finish the fullscreen preview under Video-In. now test the code.
<xiangfu>
did I needs update the soc.fpg?
<xiangfu>
s/did/should
<wpwrak>
at which patch does it fail ?
xiangfu [xiangfu!~xiangfu@123.114.251.251] has joined #milkymist
<wpwrak>
at which patch does it fail ?
<xiangfu>
here is what I do. update m1 to rc3 images. include soc, bios, flickernoise
<xiangfu>
then update my local repo. milkymist and flickernoise.
<xiangfu>
compile and install the fpvm
<xiangfu>
compile flickernoise.
<xiangfu>
netboot flickernoise
<wpwrak>
the error means that something isn't right in one of your patches
<xiangfu>
then every patch fail at different line.
<wpwrak>
oh
<xiangfu>
then I try to compile one of them under 'Patch editor'
<xiangfu>
it give [line X can initialize non-system variables only to zero near 'XXXX']
<xiangfu>
ok. let me reflash the dailybuild and with the data partition
<xiangfu>
the dailybuild also build the data partition.
<xiangfu>
so I will just 'reflash_m1.sh --snapshot milkymist-firmware-01262012-2301 data' :)
<wpwrak>
kewl. let's hope for the best :)
<xiangfu>
yes. your images works fine.
<wpwrak>
victory !!! ;-))
<wpwrak>
now we have to figure out what breaks yours ...
<wpwrak>
#1: are you copying the sorfusb firmware from milkymist.git into rtems before building rtems ?
<xiangfu>
no.
<wpwrak>
something like this: cp ../../milkymist/software/libhal/softusb-input.h ../c/src/lib/libbsp/lm32/shared/milkymist_usbinput/softusb-input.h
<xiangfu>
no.
<wpwrak>
okay, that would explain why usb doesn't work :)
<xiangfu>
oh. yes.
<wpwrak>
we could also update the file in rtems, but given that softusb sometimes changes very rapidly, that doesn't look like a very convenient approach
<wpwrak>
so, best of the build process just gets the version from milkymist.git
<xiangfu>
yes. just finish modify the script makefile. testing now :)
xiangfu [xiangfu!~user@123.114.251.251] has joined #milkymist
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
Martoni [Martoni!~chatzilla@arc68-5-88-188-247-92.fbx.proxad.net] has joined #milkymist
lekernel [lekernel!~lekernel@g225044046.adsl.alicedsl.de] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<wolfspraul>
I indeed had some more led testing dreams/nightmares, but luckily forgot them
<wpwrak>
;-)))
<wpwrak>
pity. would be interesting to know what sort of things haunt your dreams :)
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
<GitHub99>
[scripts] xiangfu pushed 1 new commit to master: http://git.io/2Y3hHA
<GitHub99>
[scripts/master] cleanup help message and update email address - Xiangfu Liu
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<lekernel>
rejon: I guess that's you who posted "Open Hardware License. The open hardware movement received a boost when CERN published an Open Hardware License." on twitter
<lekernel>
the "funny" thing about that is that I posted about it on the mailing list MONTHS before it got noticed, and no one gave a shit. that's pretty depressing.
<Fallenou>
I guess CERN twitter account is more popular than Milkymist Mailing list !
<lekernel>
oh, yes, of course. but I'm just giving further reasons for my insisting on getting stuff posted on high-impact blogs and such.
<Fallenou>
yes you're right
<Fallenou>
It would be cool to have more and more posts about Milkymist on high-impact blogs/magazines
<Fallenou>
the article on Xilinx magazine was nice !
<Fallenou>
don't know if it's read by a lot of people though
<lekernel>
so far, it's been a complete failure, with exactly zero return
<Fallenou>
maybe open silicium/gnu linux mag reach more people
<Fallenou>
even if it's only frenchy stuff
<lekernel>
did that too, was slightly better, but not brilliant
<Fallenou>
at least geeks are reading it
<Fallenou>
Would Milkymist be a good platform for 2D games ? I mean PFPU/TMU , would they be usefull to draw things for a game ?
* Fallenou
trying to think about other field of applications than VJ
<wolfspraul>
the finnish reporter Thihi who has a review unit will be back in the channel here to talk about his review, thoughts, etc. next week
elldekaa [elldekaa!~hyviquel@vpn3.enssat.univ-rennes1.fr] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
Gurty [Gurty!~princess@78.250.170.22] has joined #milkymist
<GitHub91>
[flickernoise] xiangfu pushed 2 new commits to master: http://git.io/xjGAZw
<GitHub91>
[flickernoise/master] add default ip, gateway, dns - Xiangfu Liu
<GitHub91>
[flickernoise/master] save and restore the static network configure - Xiangfu Liu
<xiangfu>
lekernel, yes. it's under my TODO list. I just finish the chinese new year vocation. when I finish the fullscreen patch. I will work on that.
<xiangfu>
lekernel, sorry. I didn't reply your email. but I add it to my TODO list. :D
<wpwrak>
(softusb) perhaps the rtems device could just have an ioctl to load firmware provided by the caller ? that way, it could be in FN, which already shares code regularly with milkymist.git
<wpwrak>
pushing updates to rtems doesn't sound so good, because there's an inevitable lag, and some updates will need tight coordination among the participants
<wpwrak>
xiangfu: (network config) thanks ! i couldn't figure out from the code whether it does what i was looking for, but if it does, thanks a lot ! :-) i'll give it a try soonish
<wpwrak>
(softusb) or just copying it over from milkymist.git as we do now works too, of course. it's just not as elegant.
<xiangfu>
wpwrak. let me know if it not working.
<wpwrak>
oh, and do we really want to promote opendns.com ?
<wolfspraul>
if we need a default dns server somewhere, I suggest Google's 8.8.8.8
<xiangfu>
wpwrak, I think someone in qihardware mailing list suggest using opendns.
<xiangfu>
wpwrak, in fact I compare the opendns and google's 8888. google is faster then opendns.
<wpwrak>
i also find google cleaner. of course, some people hate google because it's google, but ...
<xiangfu>
I am using 8.8.8.8 everywhere. my server. my laptop. :)
<wpwrak>
hehe ;-)
<wpwrak>
me too
<wpwrak>
the problem with opendns.com isn't so much speed bu that it lies to you if a name can't be resolved. e.g., if you have a typo or the destination is down
<xiangfu>
wpwrak, read file needs much more code :D. (I plan read the fullscreen patch before)
<lekernel>
that's would be bad idea
wolfspra1l [wolfspra1l!~wolfsprau@p5B0AD3D2.dip.t-dialin.net] has joined #milkymist
<lekernel>
not because it needs more code, but because the binary is no longer self contained and has the dependency on this weird patch to get full screen support
<wpwrak>
yeah, depending on an external file to be around would be inconvenient
<GitHub26>
[migen/master] Remove explicit bus names and rely on the new automatic namer - Sebastien Bourdeauducq
<GitHub86>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/mTbo8Q
<GitHub86>
[milkymist-ng/master] Remove explicit bus names - Sebastien Bourdeauducq
<lekernel>
27 lines
<wpwrak>
:)
<mwalle>
lekernel: have you ever disassembled your beagle?
<lekernel>
the USB analyzer? yes, I had a quick look
<mwalle>
whats inside? a cypress ezusb + cpld?
<lekernel>
yes
* mwalle
wonders if the spi/i2c is the same hardware as the usb one
<lekernel>
something like that
<mwalle>
did you find anything about the protocol between the beagle and the host?
<lekernel>
yeah, it seems to be using some compression
<lekernel>
but I didn't insist
<lekernel>
I no longer have this device anyway... it was quite expensive and the software is mediocre (tons of malfunctions when you send broken USB packets? in a debug tool?) and proprietary
<mwalle>
sold it?
<lekernel>
returned it
<mwalle>
ah ok ;)
<lekernel>
you can probably do more with openbench/saelae/whatever and some scripts, which at least you can fix when they break
<wpwrak>
someone could turn M1 into a USB analyzer :)
<mwalle>
yeah at work we have a beagle spi/i2c analyzer
<mwalle>
although it seems to sample the bus, one cannot see any waveforms
<lekernel>
yeah, that's another thing which annoyed me with the usb one
<mwalle>
at least its easy to read download the firmware, maybe i find time to analyze it
<lekernel>
and when I asked them they answered it wasn't possible because the beagle used an USB PHY (which it does not)
* mwalle
wonders where the firmware is stored, i can't find any eeprom
<lekernel>
probably downloaded over USB
<mwalle>
nope, i have no driver, and it already has the right vid/pid (and firmware)
<lekernel>
maybe in the cpld?
<mwalle>
its a xc9572
<mwalle>
theres some soic8 chip i cant identify, but i guess thats serves for some usb protection