<aw>
xiangfu, i noticed that's usb B port having 'run time err'. do you know exactly how it means and what's its purpose? so that i can easily know what part/chip i need to check. ;-)
<xiangfu>
you can see " Control transfer failed:" that mean M1 send 'control message' to usb. but m1 can not get any reply.
<aw>
xiangfu, alright, tks. ;-)
<xiangfu>
the USB core is software, I saw the CRC test on image are OK.
<aw>
oah~yes, so that means i only need to see if those connections between U17 (Universal Serial Bus Transceiver) port B and fpga.
<aw>
so far i can only microscope U17's all pins though. :)
<xiangfu>
from the log the USB-A have problem.
<aw>
hmm...no
<xiangfu>
first you can try switch the USB device on USB-A and USB-B
<aw>
i tried to switch them
<aw>
when i switched, it shows: USB: HC: Device disconnect on port B
<aw>
USB: HC: Low speed device on port A
<aw>
USB: HC: VID: 0E6A, PID: 6001
<aw>
USB: HC: Found keyboard
<aw>
port A didn't show 'run time err', only shows up when I plugged keyboard in port B.
<xiangfu>
ok
<aw>
sorry that it's 'RX timeout error'
<xiangfu>
" so that means i only need to see if those connections between U17 (Universal Serial Bus Transceiver) port B and fpga." yes.
<aw>
0x4e and 0x72: the audio codec circuit doesn't function is because L1's pad soldering not well. The root cause it that the footprint design from rc1 is 0603, and current we use a 0402 with zero ohm, from a more quantity run that we got this err : http://en.qi-hardware.com/wiki/File:M1_rc3_0x4e_L1-1.png
<aw>
so let's use 0402 footprint for L1 in rc4 then we fix this. ;-)
<aw>
0x4e: the U17's TP25 impedance is about 240 ohm which should be 17M ohm (I measured/compared to U16).
<aw>
this is good condition that if I still get failure after resoldering, then I can take apart U17, then if the impedance of TP25 to gnd is still low, this definitely means that ball soldering under fpga is bad.
<aw>
good news also bad news that this caused by micrel parts, the impedance of TP25 is M ohm level after I took apart U17. :(
<wolfspraul>
I think that's good news. I wouldn't want to find any number of bga ball problems under the fpga. remember there are still pins we don't test, such as the expansion header.
<wolfspraul>
if it's isolated on some external part, we fix it and done :-)
<roh>
hey guys.. how are the boards doing? sounds bad
<roh>
just finished packing the second shipment
<wolfspraul>
not bad
<wolfspraul>
well, if you look from the SMT date, and you imagine how it could be, then it's bad :-)
<wolfspraul>
but if in the end we have 60 or 70 or even more 100% perfect and super tested boards, I don't consider the run bad. Maybe a little 'tough' ;-)
<roh>
wolfspraul: heh... well.. its much more complex than the 20 boards we hacked together some evening on the weekend
<wolfspraul>
we are making mistakes, but man I just don't know how to work on something as complex as this without making mistakes.
<wolfspraul>
if someone can, step up and do it
<roh>
even there we needed lots of manual work to get them atleast powered up properly (lots of bridges after soldering
<wolfspraul>
so the fake TI parts was bad, yeah. shiny new replacement parts from Mouser will arrive on Friday...
<wolfspraul>
now some Micrel failueres (it seems), well, just replace
<wolfspraul>
small discoverise like the 0402 part on a 0603 footprint :-)
<wolfspraul>
here's my current rc3 bottom line, as of today:
<wolfspraul>
1) the process from SMT date to having plenty of 100% good boards is slower than it should be
<roh>
hm. weird.. the length of the usb shouldnt matter at all..given within regular limits
<wolfspraul>
2) we are making many good discoveries that will help us on rc4 and future products
<roh>
maybe the cable is very thin and there is some ground loop?
<wolfspraul>
3) we are still on track to having an acceptable yield for a 3rd run, after a lot of work. Let's say 60 or 70 100% good boards.
<roh>
thus it gets to noisy to use or so (high R is common for thin, cheap cables)
<wolfspraul>
that's the current status
<wolfspraul>
but don't tell Adam now, I think he has 4 boards in 100% pass condition right now :-)
<wolfspraul>
not 70
<roh>
hrhr
<wolfspraul>
well yeah, "should be"
<wolfspraul>
but that doesn't help
<roh>
i see (lists).. nice progress
<wolfspraul>
Adam has switched to a shorter cable to avoid running into too much noise
<wolfspraul>
and we need to consider switching the longer one, bad choice
<roh>
maybe somebody could think up a nice sw to help manage such logistics and tracking tasks
<wolfspraul>
so the run is not like a Christmas present, indeed
<wolfspraul>
but other than that, well, I think in the end we have plenty of sellable boards
<roh>
special workflow management.. maybe even to help with sourcing/stock management
<wolfspraul>
I think doing that manually is most effective right now. Adam has a spreadsheet and it helps keep things documented and tracked.
<roh>
need something similar here.. quite a mess of 'stuff' we got here in the lab
<roh>
wolfspraul: sure. i was just thinking that exactly that works for one person, but not if you let 2 or more work in parallel ;)
<wolfspraul>
I stand corrected. 3 in 'available' state right now.
<wolfspraul>
but that's because the Mouser parts that are arriving on Friday hold up 30-40 most likely passing right away.
<wolfspraul>
we'll get there
<wolfspraul>
roh: also need to keep in mind, our test regime is much stricter than in rc2, in a number of areas. for example adam is doing 10 power cycles now, on each board, and render 30 seconds each time.
<wolfspraul>
maybe we will also add a 1h rendering test for each board, we'll see
<wolfspraul>
so of course, the more you test, the more you find
<wolfspraul>
eventually there's always something unexpected happening, and then the board falls out of the 100% pass category right away
<wolfspraul>
having 90 boards in one place is a great opportunity to fix bugs on the hardware/software boundary
<wolfspraul>
which may otherwise be dismissed as 'whatever' once the boards are in the field
<wolfspraul>
I just realized that we are not yet testing the expansion header :-)
<wolfspraul>
(but no worries, we won't add it. the expansion header is officially untested...)
<roh>
;)
<roh>
well.. some things you cant test without a rig to press buttons and play/recieve signals and automated procedures
<wolfspraul>
I think the test setup is pretty good now, of course it will improve more as we learn
<roh>
after all.. if you already tested 50 boards and find a new error class you have to start over and retest the 'done' 50 again (well.. only that one test, but that would be a optimisation already)
<wolfspraul>
yes correct, that can happen
<wolfspraul>
oh, I also forgot the little scare at the beginning with the reset ic circuit
<wolfspraul>
that required 2 days of debugging and a rework on all boards
<wolfspraul>
rc4 can only get better :-)
<roh>
i havent understood why yet.. did nobody test the new circuit before doing the gerber?
<wolfspraul>
(which we will say until the day rc4 boards come back from the smt shop :-))
<wolfspraul>
we tested it, 1000 times even
<wolfspraul>
but the test was wrong
<wolfspraul>
so we fooled ourselves successfully, 1000 times in a row
<wolfspraul>
it's always easy to look back and say "oh, so stupid". But at the time you don't notice. it slips.
<wolfspraul>
and in hardware you cannot just rebuild, reboot
<wolfspraul>
you will eat through the mistakes you made in the past, one by one
<roh>
heh
<wolfspraul>
our list of improvements for rc4 grows, I think that's a good sign
<wolfspraul>
we are still fighting back
<roh>
yeah. battle is not lost. just annoyingly long
<wolfspraul>
the jury is still out on which part is the last one
<wolfspraul>
amazingly enough the various delays cancel each other out
<wolfspraul>
but if your first package arrives early next week, it's not going to be the cases
<wolfspraul>
there were some nasty delays with the boxes as well, they had to be redone once or twice
<wolfspraul>
I think we can expect them in Taipei early next week as well
<wolfspraul>
so... next week is the big week. if all goes perfect then we finally have _everything_ in one place :-)
<roh>
wolfspraul: :) nice that you can stay so optimistic
<wolfspraul>
roh: the first package still shows a very early tracking status. not even at "parcel center of origin" yet
<wolfspraul>
if all goes well it's in Taipei early next week I think
<wolfspraul>
otherwise later in the week :-)
<wolfspraul>
optimistic, well. we chose this path. Let's make it a full product, a great and polished starting place whether you want to take it into a hacking or performance direction.
<wolfspraul>
that's a very different path from "let's make a hacker board", and we go through that now
<wolfspraul>
roh: you stayed optimistic when gluing the buttons too, right? :-)
<wolfspraul>
or fatalistic?
<aw>
xiangfu, is there possible that we can use test image to help on testing for records into flash rom for 10 times when I press middle btn to boot up and some where that gui can let me save after rendering 30 seconds?
<xiangfu>
aw, sorry. what you mean on "records into flash rom for 10 times"?
<aw>
xiangfu, Rendering - Boot-to-Rendering step and keeps rendering at least 30 seconds 10 times. i.e. power on -> reconfiguration -> press middle button -> boot up -> rendering (30 seconds) -> power off, be noticed that power-cycle (from power off to power on) is roughly 3 ~ 5 seconds.
<wolfspraul>
the main reason we are doing those 10 boot-to-render cycles was to verify fix2
<aw>
there's another extended header, can we let fpga to detect one pin of it so that s/w can record how many times I tested successfully?
<wolfspraul>
but I do think you found 1 or 2 boards where you ran into a problem after X cycles, right?
<wolfspraul>
aw: no that's all too difficult I think. let's keep our test software simple.
<wolfspraul>
rather reduce the number of power cycles to 5
<aw>
hmm..too bad  though. alright
<wolfspraul>
aw: you found some boards that failed after X cycles, right?
<aw>
wolfspraul, yes
<aw>
I'll back to see if my rework was bad. so replacing a diode or c238 220pF to test again.
<wolfspraul>
like 5C
<wolfspraul>
very strange
<wolfspraul>
failed on 9th power cycle
<aw>
yup..I'll back to check that one. ;-)
<wolfspraul>
also 0x63 0x85
<wolfspraul>
strange stuff
<xiangfu>
aw, if we want 'Rendering' we have to do it in Flickernoise.
<wolfspraul>
and we don't want to switch from a cold power cycle to a software reset either
<wolfspraul>
the test should first test cold power cycle, software reset is a different test (and not important now imho)
<lekernel>
I hope you will make that stupid supplier pay for those crappy TI parts they sold
<lekernel>
including the massive time wastage and delays they caused
<wolfspraul>
no, because it's not the suppliers fault
<wolfspraul>
but we will not buy those parts from there anymore (all suppliers are in the wiki btw)
<wolfspraul>
I do not know a magic way to avoid this kind of problem, it's nothing to be worked up about.
<wolfspraul>
you cannot just try to 'play safe', there is no such path and then you cannot produce anything anymore
<wolfspraul>
but we learn, another thing that will be improved in rc4
<wolfspraul>
I personally visited that supplier several times, it's not their fault. They were mislead about this as well.
<wolfspraul>
misled
<wolfspraul>
I think the sourcing lesson learnt here is this: If a part is easily and even cheaper available outside of China, then by all means don't buy from inside China :-)
<wolfspraul>
that's all
<wolfspraul>
we didn't apply this simple rule for the rc3 sourcing, but we will for rc4, guaranteed
<wolfspraul>
every time so far when a problem popped up with a part we sourced inside China, a quick digikey lookup showed that we actually paid more on the Chinese spot market than on digikey!
<wolfspraul>
one day I will try to find out the reasons why that is so, but in the meantime we just need to source smarter, and buy such parts (even cheaper!) from digikey/arrow/mouser/etc.
<wolfspraul>
Adam has already moved to other troublemakers now...
<Alarm>
Is it possible to learn how to program the FPGA with the card Milkymist?
<wolfspraul>
Alarm: don't understand what you mean. You mean programming the fpga (bitstream)?
<wolfspraul>
"Milkymist" is the name of the SoC (system on a chip), the lowest level of what is programmable on Milkymist One (that's the name of the video synthesizer built on top of the Milkymist SoC)
<wolfspraul>
you can program the Milkymist SoC in a language called Verilog, the microkernel (RTEMS) and application (Flickernoise) can be programmed in C
<wolfspraul>
does that answer your question?
<Alarm>
I rephrase my question: "is it possible to create a function with verilog for beginners?
<wolfspraul>
you could probably move functions into the fpga, yes. but I'm not aware of a good 'verilog hello world' example in conjunction with Milkymist
<wolfspraul>
kristianpaul went through some realizations as part of his GPS stack, so he may have some good starting points or code snippets at hand
<wolfspraul>
but when he's online later he may point you to some small starting snippets to dive into the Milkymist SoC
<wolfspraul>
unless lekernel has an idea for you, of course
<wolfspraul>
I agree there should be starting points for people, the whole SoC is probably overwhelming. I think about 40,000 lines of Verilog code.
<wolfspraul>
Alarm: but if you are interested in that, you most likely still want to download the sources and start reading :-) Reading is king in that case.
<wolfspraul>
eventually it will dawn on you where and how to start putting your own stuff in
<Alarm>
:) A small project of a few line of code verilog please me well
<Fallenou>
kristianpaul: it's in the lm32 arch pdf anyway
<Alarm>
Is there a difference in performance between VHDL and verilog?
<lekernel>
no
<lekernel>
xiangfu, yes, plus cmdline.txt and initrd.bin
<larsc>
actually youd don't need cmdline.txt anymore
<larsc>
xiangfu: you also need to change the size of the rootfs to 4MB
<kristianpaul>
Fallenou: (pdf) yeah, just finished reading it :)
<kristianpaul>
what i need is to wipeout the memcard and see if the bug about no boot.bin is gone :)
<mwalle>
larsc: from what i understand on the lengthy discussion about the gcc bug, the only real solution is to do the syscall with hand written assembly code
<mwalle>
lekernel: after pinging the patch again, i got one acked-by by gerd hoffmann
<mwalle>
but still no merge by anthony, but i havent seen any mail from him today
<mwalle>
so he might be ooo
<larsc>
mwalle: but our workaround works, or doesn't it?
<mwalle>
by chance
<mwalle>
for now it seems to work, but there seems to be no connection between the register constraint and the actual inline asm
<mwalle>
larsc: i would chance anything for now, there are many difference proposals. so as long as it works.. :)
<mwalle>
s/would/wouldnt
<larsc>
mwalle: do you want to apply your irqflags patch?
<mwalle>
if you agree
<larsc>
have you seen my relpy?
<mwalle>
yes
<larsc>
the only situation i can think of where behaviour changes is, for example if we have to spinlocks A and B and the following sequence lock A, lock B, unlock B, unlock A