Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<cladamw>
xiangfu, this command "echo 3 | sudo tee /sys/bus/usb/drivers/usb/usb2/../companion", do we need to concern it alway or forget it ?
<xiangfu>
forget it.
<cladamw>
xiangfu, so if i am right, this was to let usb speed to be a full-speed one instead high speed when we were not sure the root cause suffered from nor corruption. so we can now definitely use 1.8 usb cable @ high speed without any reflash problems. Can we?
<xiangfu>
cladamw, yes. use 1.8 usb cable @ high speed will be ok.
<cladamw>
wpwrak, one thing I forgot to ask. When you were doing reliable testing on nor corruption, were you always using usb high speed mode to access ?
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<wolfspraul>
xiangfu (and Adam): the issue was between full-speed and low-speed, not between full and high
<wolfspraul>
(ah, wrong :-))
<wolfspraul>
I got confused. this was the jtag cable, and indeed between full and high...
<xiangfu>
yes. and now it's not an issue anymore. since Werner have make sure that the RC4 fix the NOR problem.
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
mumptai [mumptai!~calle@brmn-4db70a16.pool.mediaWays.net] has joined #milkymist
<GitHub68>
[autotest-m1] xiangfu pushed 1 new commit to master: http://git.io/nd8L6Q
<GitHub68>
[autotest-m1/master] MIDI: clean RX before start test - Xiangfu Liu
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
xiangfu [xiangfu!~xiangfu@61.49.252.40] has joined #milkymist
<wolfspraul>
cladamw: hi there ;-)
<wolfspraul>
almost finished the week - how is everything going?
<wolfspraul>
I saw you made lots of edits in the wiki, I'm waiting for that to settle down before I start studying the news :-)
<cladamw>
xiangfu, i just saw back log. Although Werner did fix nor corruption issue. But still not clarify my question about full-speed and high-speed. :-)
<wolfspraul>
yes I also think the two are unrelated, but we can start using the (normal) high-speed and see how it goes
<wolfspraul>
otherwise we drag all sorts of fear with us, without knowing what the actual problem is
<wolfspraul>
we have crc checks etc nowadays, I trust that
<cladamw>
xiangfu wolfspraul so if Werner tell us that he was _always_ used high-speed mode to access/do experiments then i think that we can definitely say _yes_ we solved this. ?
<wolfspraul>
no 'solved'. we started using full-speed simply to rule out a high-speed problem.
<cladamw>
I don't know actually. :-) so I hope someone can really tell me. :-)
xiangfu_ [xiangfu_!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<wolfspraul>
yes, i tell you. forget the full-speed thing now.
<wolfspraul>
just use (normal) high-speed with the jtag-serial cable
<cladamw>
wolfspraul, aha. okay. because i just thought Werner's experiments is extremely reliable, so I asked what speed he used. :-)
<cladamw>
wolfspraul, i just took back 0x74 from minbo
<wolfspraul>
but the issues are completely independent
<wolfspraul>
the reason we went from high-speed to full-speed on the jtag-serial reflashing was because we ran into this 1 board once where we thought high-speed caused a problem
<wolfspraul>
that is unrelated to nor fixes
<wolfspraul>
but we can also go back to high-speed now, and see what happens
<wolfspraul>
we have crc checks, we have a more stable nor circuit
<wolfspraul>
we cannot forever continue with the full-speed jtag-serial hack simply because "we once had a problem"
<wpwrak>
cladamw: naw, jtag speed was a dead end. i always used the default, which should be high-speed
<cladamw>
wpwrak, ha... great ! That's that i'd like to know. thanks !
<wolfspraul>
yes, good :-)
<wolfspraul>
so... when can we make the final rc3 report?
<cladamw>
wolfspraul, i did tried to clean up 'failure classification' wiki this morning.
<wolfspraul>
the one and only mega report that will answer all questions once and for all? :-)
<wolfspraul>
cladamw: very good!
<cladamw>
so I think next week I can list them.
<wolfspraul>
I think we should soon come to a final rc3 report
<cladamw>
since we still have three remaining boards. :-)
<wolfspraul>
ok, good. then work on those of course.
<wpwrak>
what should be in report #42 ?
<cladamw>
0x42?
<wolfspraul>
rc3 production results
<wolfspraul>
yield
<wolfspraul>
which types of problems we ran into and what size they had
<wolfspraul>
after that report I don't want to spend any more time on rc3, then it's 100% focus on rc4
<wpwrak>
cladamw: "42" the answer it took millions of years to compute. (from the hitchhiker's guide to the galaxy :)
<cladamw>
wpwrak, what's your meaning of "#42"?
<wolfspraul>
so we (mostly Adam) should finish all rc3 work before that
<wolfspraul>
it sounds like we can be there in a week or two maybe?
<wpwrak>
after that report, we'll probably have run out of rc3 problems anyway ;-)
<wolfspraul>
I am just patiently waiting, I know adam has the right priorities and will try to finish this asap.
<cladamw>
oah...man! All such stuffs were totally caused by me though ! surely. ;-)
<wpwrak>
well, hardware problems. still have plenty left to do on the sw side
<wolfspraul>
yes but then onto rc4
<wolfspraul>
dvi-i, and so on
<wolfspraul>
more usb! :-)
<wolfspraul>
leds
<wolfspraul>
what not
<wpwrak>
yeah. M1 now wants usb ;-)
<cladamw>
wolfspraul, yes. after send out report, then go for else you listed above.
<wolfspraul>
ok but let's give Adam the remaining time he needs to properly finish rc3 first
<wolfspraul>
cladamw: yes sure, I think we are in agreement. first completely finish rc3.
<wolfspraul>
full report, yield, list problems, etc.
<wolfspraul>
we have excellent data in the wiki, just needs to be cleaned up and summarized
<wolfspraul>
and the remaining boards too...
<wpwrak>
sure. us westerners are slowed down by xmas anyway :)
<cladamw>
0x74 was removed fpga chip, so today I brought back.
<wolfspraul>
I have no comment now, there were lots of edits and I need to study all this a bit, the various boards and findings etc.
<wpwrak>
cladamw: why was it removed ? was there any visible/measurable defect on the chip ?
<cladamw>
and the others are 0x67 & 0x6d
<wpwrak>
(replacing large bgas to me has a bit of a ring of "kamikaze" to me :)
<wpwrak>
hmm, one "to me" will suffice. still need to get my morning caffeine.
<cladamw>
wpwrak, at that time we ( I and minbo) thought a short might be under fpga, so we removed it out. Before that I still have had 5 set of 'short' rc3.
<wpwrak>
cladamw: ah, so probably just another flux victim. good. these are easier to understand than fpga failures ;)
<wolfspraul>
cladamw: ok, so you are fully on track with rc3?
<wolfspraul>
you know what to do and how to finish stuff etc? do you need any help or anything from me?
<cladamw>
so we picked one short (0x74) firstly. then decided if there's no short condition on the bottom side of chip and also measured without still 'short' then we illiminute fpga reason.
<cladamw>
then we found even removed fpga, so still short. so I decided to stop remove fpga from else 'short' board.
<wolfspraul>
let's set a realistic goal for rc4:
<wolfspraul>
100% yield
<wolfspraul>
:-)
<wolfspraul>
1 day testing for Adam, done
<cladamw>
then just found all else short boards shorted by unqualified usb transceiver. :(
<wolfspraul>
yes another sourcing problem
<wolfspraul>
I want to source rc4 with boom and much more over digikey
<wpwrak>
no more shopping trips to chinese backyards ;-)
<cladamw>
wolfspraul, next Tuesday I'll go for ultrasonic cleaner visit, then I know how's going on the other two boards. :-)
<wpwrak>
were those fake chips actually bought in taiwan ? (as the place of the merchant-sharism interface) or did you find them in china ?
<cladamw>
wpwrak, do you think what else functions of boom we can still improve in the future? Since i know you're not on this way now. :-)
<wpwrak>
i'm very curious about how that ultrasound thing goes. i'm also still puzzled about minbo not having it. i wonder how they clean their boards after smt. i can't imagine they just leave all of them "dirty"
<cladamw>
in china
<wpwrak>
(china) mail order ? wolfgang sounded as if he knew those people personally. seems strange to me that he'd go shopping, then mail it to taiwan, though
<wolfspraul>
sure we know them personally, several visits also with Adam etc.
<wpwrak>
(boom) hmm, lots of things to do there :-( starting with the core logic
<cladamw>
wpwrak, well... i would say that since i issued rework firstly then i also reworked then puzzled my works too. :-)
<wolfspraul>
we will learn and improve
<cladamw>
core logic?
<wpwrak>
cladamw: okay, with your rework, it's more understandable. you don't have the infrastructure for proper cleaning. so there's always a risk that you miss something.
<wolfspraul>
I am 100% certain though that if we source 'everything' (that's not the plan anyway) from digikey, we will run into problems there as well
<wpwrak>
wolfspraul: (learn and improve) sure. i'm just curious how the whole story connects. it's a nice story to tell to people :)
<wolfspraul>
cladamw: let me just confirm again: you are clear about the remaining rc3 tasks? do you need any help?
<wolfspraul>
please let me know when you think you are slowly coming to an end...
<wpwrak>
cladamw: boom is currently written in Perl, weak syntax checking, slow operations.
<cladamw>
this rc3 run, we made stupid way ourself, and without good verification then reworks more ... etc.
<wolfspraul>
yes but we are not supply bound :-)
<wpwrak>
aren't you case-limited now ? :)
<wolfspraul>
(cladamw - what I mean with "supply bound" is that even though the production process is slow and with painful realizations, we are not sold out)
<cladamw>
this time with wpwrak's participation, we survived though. Or can't imagine. :-)
<wpwrak>
btw, if you're low on cases, that may be an opportunity to set some boards aside for developer discounts. rc4 will get a new case anyway
<wolfspraul>
only one new sideboard I think
<wolfspraul>
I'm not worried about developer discounts
<wpwrak>
cladamw: naw, you found most of the problems yourself :)
<wolfspraul>
what m1 needs is a real killer attractive marketing story, a story overall
<wpwrak>
aye
<wolfspraul>
that's my opinion and hasn't changed and we all work on that
<wolfspraul>
it's very unattractive right now, still
<wolfspraul>
if any serious developer comes along we will find the discount needed to satisfy that developer
<wpwrak>
i think the "VJ instrument" story carries nicely. just needs better software. plus, the "hardware" overhaul sebastien is working on should also help quite a bit
<wolfspraul>
but the lines in front of our store are not exactly very long ;-)
<wolfspraul>
cladamw: are you clear about rc3? need help?
<wolfspraul>
I just wanted to confirm since it's a friday and going into the weekend etc.
<wolfspraul>
want to make sure all is good on your side :-)
<cladamw>
phew~ i should take a picture with all packed M1 retailed box which setting at my desk like a large building. :(
<wolfspraul>
yes, but where are the lines in front of your building?
<cladamw>
oah..yes I'll try to fix this 0x74 firstly.
<wolfspraul>
you can shoot a photo down from your window showing the empty street :-)
<wpwrak>
i think there are three groups now: 1) developers who find the platform sexy but are scared by the price tag. 2) VJs who would find it cool but who don't see a workflow yet and who probably haven't heard of it yet anyway. 3) people with fringe needs who'll jump on any chance to get someone to solve their problem.
<cladamw>
wolfspraul, joking...
<wpwrak>
for 1), we can just make discounts. solved.
<wpwrak>
most of the marketing successes so far seem to be in the are of 3), which worries me, because there lies the risk of lack of focus.
<wpwrak>
for 2), i think we need to go to places where VJs hang out. fora, clubs, etc.
<wpwrak>
and we need to be able to show M1 the instrument they will use. not as a technology demo.
<wpwrak>
s/M1/M1 as/
<cladamw>
wolfspraul, "are you clear about rc3? need help?" --> clear and no help needed now, thanks !
<wolfspraul>
ah ok, good
<wolfspraul>
then I just wish you a good weekend now, relax a little, and be happy about your Milkymist work!
<wpwrak>
wolfspraul: (empty street) step 1: stock. step 2: have room in the street for the crazy crowd of customers. step 3: launch product that makes crazy customer crowd camp in the street for a week pre-launch. so we're already 67% done ;-)
<cladamw>
oah ~ thanks ! and also wish (westerners and easterners even all ) happy xmas anyway.
<wpwrak>
hehe, thanks ! still lots of things to do there. today, it's infrastructure checks and tests ... (mainly the missile delivery systems)
<wpwrak>
(missiles) in argentina, there are fireworks on the 24th
<cladamw>
wpwrak, one quick question. :-) What's the most size of passive parts in ATUSB & ATBEN? 0402? 0603?
<cladamw>
xiangfu_, thanks ! I saw you updated the new test.bin. ;-)
<roh>
hm. about workflow...
<roh>
the mm can do 'texture mapping', right?
<roh>
so we could do 'mapping' also? means clipping and doing transformations on geometry to 3dimensional stuff being a 'useable surface'
<cladamw>
wpwrak, just git cloned ben-wpen, it's 0402. good. :-)
<cladamw>
xiangfu_, okay. I'll try it. :-)
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
lekernel [lekernel!~lekernel@g225040160.adsl.alicedsl.de] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
wolfspra1l [wolfspra1l!~wolfsprau@p5B0AF7F7.dip.t-dialin.net] has joined #milkymist
<cladamw>
In last time I tried to find what part caused 'short' so that removed all passive parts(49pcs)3.3V rail decoupling cap. and beads one by one. now needs to on by one soldering them back and measure. phew~
<cladamw>
but I definitely not did like that. so I needed to accumulate like said 5 ~ 10 sets rc3 board with full functions tested, then prepared folding retail box and else etc. :-)
<wolfspra1l>
"The current thinking is that by removing the ability for this software to be upgraded, we can effectively treat the wireless networking hardware as a circuit, and importantly, not a malicious circuit that can be upgraded."
<wolfspra1l>
no wonder the FSF has lost any and all credibility and momentum to lead
<wolfspra1l>
may they be happy in their non-free minds... :-)
wolfspraul [wolfspraul!~wolfsprau@p5B0AF7F7.dip.t-dialin.net] has joined #milkymist
wolfspraul [wolfspraul!~wolfsprau@p5B0AF7F7.dip.t-dialin.net] has joined #milkymist
wolfspraul [wolfspraul!~wolfsprau@p5B0AF7F7.dip.t-dialin.net] has joined #milkymist
<kristianpaul>
non-free minds, heheh
aeris- [aeris-!~aerith@home.aerith.fr] has joined #milkymist
Artyom [Artyom!~chatzilla@84.23.63.183] has joined #milkymist
<Artyom>
kristianpaul: hello
<kristianpaul>
Hi !
<Artyom>
kristianpaul: I finally could update s3e port to the final version of MM SoC. I switched off all modultes that I don't need (like video in/out, midi, usb and so on). And I could test debugging with GDB. Everything works fine. So now I will try to port my program
<kristianpaul>
oh, nice !
<kristianpaul>
btw in you program, do you check for new data? i guess all start by looking and accumt int, the wait tic occur and then check new data?
<kristianpaul>
the clear some flags, load values to registers again, print data and wait for accum int..
<Artyom>
yes, you are right. I use polling of accum_int now. (I also played with reading status from memory but finally decided to use accum_int polling as it was in my old program)
<kristianpaul>
and the gold code per satellite taken from namuru datasheet right
<kristianpaul>
btw had you tested tracking for all of then?
<Artyom>
yes - initial value for shift register is taken from namuru datasheet.
<Artyom>
Right now I have again problems with acquisition ;) I don't know the reason for now. May be I forgot something to change in namuru-port (Previously I used 80 MHz clock for correlator and now only 48 MHz).
<kristianpaul>
yeah, better to make correlator frecuency a constant inside the correlator code so the ecuation get update easilly
<kristianpaul>
i noticed i have to calcultate again some values too..
<kristianpaul>
Btw then a TIC occuured means the a measure is going to start or had finished?
<kristianpaul>
acyually i think i just should care about accumt int itself plus new data not TIC
<kristianpaul>
as TIC seems to be in sync with accum int correct?
<Artyom>
hm... I think TIC is just a local time-signal.... It is used to synchronously lock chanles pseudoranges... Anaway it's the task for distant future...
<kristianpaul>
ok
<kristianpaul>
cause i was confusing with accumt int in some way :)
<Artyom>
yes, TIC and accum_int are synchronous because the are generated from the same clock.
<Artyom>
What has confused you with accum int?
<kristianpaul>
acually more with TIC
<kristianpaul>
but as you said, dont care for it now
<Artyom>
:)
Gurty [Gurty!~princess@ALyon-256-1-177-206.w109-213.abo.wanadoo.fr] has joined #milkymist
Artyom_ [Artyom_!~chatzilla@84.23.63.183] has joined #milkymist
<Artyom>
kristianpaul: bye ;)
<kristianpaul>
chao
<kristianpaul>
bye
elldekaa [elldekaa!~hyviquel@83.158.203.15] has joined #milkymist
elldekaa [elldekaa!~hyviquel@83.158.203.15] has joined #milkymist
antgreen [antgreen!~user@70.50.66.113] has joined #milkymist
Gurty [Gurty!~princess@ALyon-256-1-177-206.w109-213.abo.wanadoo.fr] has joined #milkymist
<kristianpaul>
""Use automake, always." Nobody wants to deal with the details of writing makefiles. Automake is ugly, but the ugliness can be ignored; like democracy, it is messy but it is still the best system we have. "