<kristianpaul> in theory is same signal coming from a core
<kristianpaul> but different pin
<kristianpaul> in the fppa
<kristianpaul> this behavior is familiar to you lekernel ?
<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 :-)
<roh> micrel?
<roh> some socket?
<wolfspraul> no a usb phy
<roh> i see.. defective part?
<wolfspraul> hard to say sometimes
<wolfspraul> then we have discoveries like the now longer USB cable causing problems with JTAG flashing
<wolfspraul> never noticed before
<wolfspraul> or Adam's testing VGA connector wearing out from all the connect cycles
<wolfspraul> roh: look here. 0402 part on 0603 footprint :-) http://en.qi-hardware.com/wiki/File:M1_rc3_0x4e_L1-2.png
<wolfspraul> cute
<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
<Alarm> I found the realization of kristianpaul: http://en.qi-hardware.com/wiki/GPS_Free_Stack
<wolfspraul> that's the whole project
<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
<Alarm> :) Thank you, I will test :)
<Fallenou> oh you connect CVBS to the red connector ?
<Fallenou> I thought you would have to connect to the green one
<Fallenou> (README of paltest)
<Alarm> CVBS is yellow on the tv?
<Fallenou> I have an Analog Device ADV7403 video input chip here, and I have to connect CVBS to the green input to make it work (composite)
<Alarm> i guess it must install the Xilinx tools?
<Fallenou> Alarm: you have to install ISE Webpack
<Fallenou> to get Xst
<Fallenou> you won't have to use theur GUI in theory, you can use the makefiles
<Fallenou> their*
<Alarm> ok thank
<lekernel> Fallenou, this repository is about CVBS _output_
<lekernel> through the VGA connector
<kristianpaul> paltest looks interesting to look at Alarm
<kristianpaul> yeah, i started printing all datahseets, also core documnetation and reading
<kristianpaul> no matter if you understand at first
<kristianpaul> brain catch later for sure, but read read !
<kristianpaul> easy way is CSR bus, a good starting point for _very_ basic stuff
<kristianpaul> once you learn about take a look and time to wishbone specs is very important
<kristianpaul> and of course in parellel stufy verilog and digital design and computer arcquitecture is not bad
<kristianpaul> actually thats a book from MIT i think
<kristianpaul> but there are plenty of good free sources in the internet
<kristianpaul> and please, take a lot of care of clock domains... i lost lot of time because dont doint it..
<kristianpaul> Fallenou: hi
<kristianpaul> Fallenou: Had, you a rought idea of how to handle mico32 interrupts
<kristianpaul> (note, i dint looked at milkymist demo yet)
<kristianpaul> bbl
<lekernel> report integer'image(to_integer(unsigned(count)));
<lekernel> vhdl die
<Alarm> kristianpaul: Thank you for your counsel
<Fallenou> kristianpaul: nop, but they are re designing it here (milkymist)
<xiangfu> Hi how I try openwrt in milkymist. just copy http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-milkymist.minimal-08032011-0953/simpleImage.milkymist_one to boot.bin then 'netboot'?
<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
<GitHub70> [linux-milkymist] mwalle pushed 1 new commit to master: https://github.com/milkymist/linux-milkymist/commit/00a52b0c1baac629016d18cf9d6da81199ac8f50
<GitHub70> [linux-milkymist/master] lm32: simplify irq handling even more - Michael Walle
<mwalle> larsc: but only on smp?
<larsc> but that should result in undefined behaviour anyway
<larsc> uhm, i meant lock A, lock B, unlock A, unlock B
<larsc> will clear EIE and BIE
<mwalle> this would break other architectures too, afaik, microblaze restores its whole status register
<mwalle> larsc: btw does this have any consequences on the generic atomic instructions
<larsc> yes, they are optimal now
<larsc> kernel size in general shrunk quite a bit
<mwalle> lekernel: framebuffer is working for me
<mwalle> did you select CONFIG_FRAMEBUFFER_CONSOLE ?
<lekernel> yes, it was working last time I tried, but I remember someone reporting problems on IRC
<lekernel> might be only a misunderstanding
<mwalle> kk
<mwalle> nice, /dev/mem wont work for address 0..
<mwalle> larsc: my my busbox/kernel seems to be not very stable
<mwalle> atm the kernel hangs in do_wait_thread, http://paste.debian.net/125026/
<larsc> can you send me your rootfs?
<larsc> i'm still busy with work atm. but i'll try to take a look at it later or tomorrow
<mwalle> its a initramfs ;)
<mwalle> http://paste.debian.net/125027/ << heres another backtrace with an error i see more often
<mwalle> writes to 0x1cc and 0x144
<mwalle> seem like the current is NULL
<larsc> hm, some check missing user_mode() check?
<larsc> hm, some missing user_mode() check?