#milkymist IRC log for Wednesday, 2011-08-03

kristianpaulin theory is same signal coming from a core03:20
kristianpaulbut different pin03:20
kristianpaulin the fppa03:20
kristianpaulthis behavior is familiar to you lekernel ?03:20
awxiangfu, http://downloads.qi-hardware.com/hardware/milkymist_one/production/rc3/test_results/4E-results03:59
awxiangfu, 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. ;-)04:00
xiangfuyou can see " Control transfer failed:" that mean M1 send 'control message' to usb. but m1 can not get any reply.04:02
awxiangfu, alright, tks. ;-)04:03
xiangfuthe USB core is software, I saw the CRC test on image are OK.04:03
awoah~yes, so that means i only need to see if those connections between U17 (Universal Serial Bus Transceiver) port B and fpga.04:05
awso far i can only microscope U17's all pins though. :)04:05
xiangfufrom the log the USB-A have problem.04:06
xiangfufirst you can try switch the USB device on USB-A and USB-B04:06
awi tried to switch them04:06
awwhen i switched, it shows: USB: HC: Device disconnect on port B04:07
awUSB: HC: Low speed device on port A04:07
awUSB: HC: VID: 0E6A, PID: 600104:07
awUSB: HC: Found keyboard04:07
awport A didn't show 'run time err', only shows up when I plugged keyboard in port B.04:09
awsorry that it's 'RX timeout error'04:10
xiangfu" so that means i only need to see if those connections between U17 (Universal Serial Bus Transceiver) port B and fpga." yes.04:10
aw0x4e 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.png05:17
awso let's use 0402 footprint for L1 in rc4 then we fix this. ;-)05:17
aw0x4e: the U17's TP25 impedance is about 240 ohm which should be 17M ohm (I measured/compared to U16).05:42
awthis 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.05:44
awgood news also bad news that this caused by micrel parts, the impedance of TP25 is M ohm level after I took apart U17. :(06:27
wolfspraulI 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.06:35
wolfspraulif it's isolated on some external part, we fix it and done :-)06:35
rohhey guys.. how are the boards doing? sounds bad07:04
Action: roh just finished packing the second shipment07:04
wolfspraulnot bad07:07
wolfspraulwell, if you look from the SMT date, and you imagine how it could be, then it's bad :-)07:07
wolfspraulbut 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' ;-)07:08
rohwolfspraul: heh... well.. its much more complex than the 20 boards we hacked together some evening on the weekend07:08
wolfspraulwe are making mistakes, but man I just don't know how to work on something as complex as this without making mistakes.07:08
wolfspraulif someone can, step up and do it07:08
roheven there we needed lots of manual work to get them atleast powered up properly (lots of bridges after soldering07:09
wolfspraulso the fake TI parts was bad, yeah. shiny new replacement parts from Mouser will arrive on Friday...07:09
wolfspraulnow some Micrel failueres (it seems), well, just replace07:09
wolfspraulsmall discoverise like the 0402 part on a 0603 footprint :-)07:09
rohsome socket?07:10
wolfspraulno a usb phy07:10
rohi see.. defective part?07:10
wolfspraulhard to say sometimes07:10
wolfspraulthen we have discoveries like the now longer USB cable causing problems with JTAG flashing07:11
wolfspraulnever noticed before07:11
wolfspraulor Adam's testing VGA connector wearing out from all the connect cycles07:11
wolfspraulroh: look here. 0402 part on 0603 footprint :-) http://en.qi-hardware.com/wiki/File:M1_rc3_0x4e_L1-2.png07:13
wolfspraulhere's my current rc3 bottom line, as of today:07:15
wolfspraul1) the process from SMT date to having plenty of 100% good boards is slower than it should be07:15
rohhm. weird.. the length of the usb shouldnt matter at all..given within regular limits07:16
wolfspraul2) we are making many good discoveries that will help us on rc4 and future products07:16
rohmaybe the cable is very thin and there is some ground loop?07:16
wolfspraul3) 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.07:16
rohthus it gets to noisy to use or so (high R is common for thin, cheap cables)07:16
wolfspraulthat's the current status07:16
wolfspraulbut don't tell Adam now, I think he has 4 boards in 100% pass condition right now :-)07:16
wolfspraulnot 7007:17
wolfspraulwell yeah, "should be"07:17
wolfspraulbut that doesn't help07:17
rohi see (lists).. nice progress07:17
wolfspraulAdam has switched to a shorter cable to avoid running into too much noise07:17
wolfsprauland we need to consider switching the longer one, bad choice07:17
rohmaybe somebody could think up a nice sw to help manage such logistics and tracking tasks07:17
wolfspraulso the run is not like a Christmas present, indeed07:18
wolfspraulbut other than that, well, I think in the end we have plenty of sellable boards07:18
rohspecial workflow management.. maybe even to help with sourcing/stock management07:18
wolfspraulI think doing that manually is most effective right now. Adam has a spreadsheet and it helps keep things documented and tracked.07:19
rohneed something similar here.. quite a mess of 'stuff' we got here in the lab07:19
rohwolfspraul: sure. i was just thinking that exactly that works for one person, but not if you let 2 or more work in parallel ;)07:19
wolfspraulI stand corrected. 3 in 'available' state right now.07:21
wolfspraulbut that's because the Mouser parts that are arriving on Friday hold up 30-40 most likely passing right away.07:21
wolfspraulwe'll get there07:21
wolfspraulroh: 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.07:26
wolfspraulmaybe we will also add a 1h rendering test for each board, we'll see07:27
wolfspraulso of course, the more you test, the more you find07:27
wolfsprauleventually there's always something unexpected happening, and then the board falls out of the 100% pass category right away07:27
wolfspraulhaving 90 boards in one place is a great opportunity to fix bugs on the hardware/software boundary07:28
wolfspraulwhich may otherwise be dismissed as 'whatever' once the boards are in the field07:28
wolfspraulI just realized that we are not yet testing the expansion header :-)07:29
wolfspraul(but no worries, we won't add it. the expansion header is officially untested...)07:30
rohwell.. some things you cant test without a rig to press buttons and play/recieve signals and automated procedures07:37
wolfspraulI think the test setup is pretty good now, of course it will improve more as we learn07:37
rohafter 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)07:38
wolfspraulyes correct, that can happen07:38
wolfsprauloh, I also forgot the little scare at the beginning with the reset ic circuit07:39
wolfspraulthat required 2 days of debugging and a rework on all boards07:39
wolfspraulrc4 can only get better :-)07:39
rohi havent understood why yet.. did nobody test the new circuit before doing the gerber?07:39
wolfspraul(which we will say until the day rc4 boards come back from the smt shop :-))07:39
wolfspraulwe tested it, 1000 times even07:39
wolfspraulbut the test was wrong07:39
wolfspraulso we fooled ourselves successfully, 1000 times in a row07:40
wolfspraulit's always easy to look back and say "oh, so stupid". But at the time you don't notice. it slips.07:41
wolfsprauland in hardware you cannot just rebuild, reboot07:41
wolfspraulyou will eat through the mistakes you made in the past, one by one07:41
wolfspraulour list of improvements for rc4 grows, I think that's a good sign07:42
wolfspraulwe are still fighting back07:42
rohyeah. battle is not lost. just annoyingly long07:47
wolfspraulthe jury is still out on which part is the last one07:47
wolfspraulamazingly enough the various delays cancel each other out07:48
wolfspraulbut if your first package arrives early next week, it's not going to be the cases07:48
wolfspraulthere were some nasty delays with the boxes as well, they had to be redone once or twice07:49
wolfspraulI think we can expect them in Taipei early next week as well07:49
wolfspraulso... next week is the big week. if all goes perfect then we finally have _everything_ in one place :-)07:50
rohwolfspraul: :) nice that you can stay so optimistic08:02
wolfspraulroh: the first package still shows a very early tracking status. not even at "parcel center of origin" yet08:03
wolfspraulif all goes well it's in Taipei early next week I think08:03
wolfspraulotherwise later in the week :-)08:03
wolfsprauloptimistic, 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.08:05
wolfspraulthat's a very different path from "let's make a hacker board", and we go through that now08:06
wolfspraulroh: you stayed optimistic when gluing the buttons too, right? :-)08:08
wolfspraulor fatalistic?08:08
awxiangfu, 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?08:12
xiangfuaw, sorry. what you mean on "records into flash rom for 10 times"?08:13
awxiangfu, 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.08:14
wolfspraulthe main reason we are doing those 10 boot-to-render cycles was to verify fix208:16
awthere'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?08:16
wolfspraulbut I do think you found 1 or 2 boards where you ran into a problem after X cycles, right?08:16
wolfspraulaw: no that's all too difficult I think. let's keep our test software simple.08:17
wolfspraulrather reduce the number of power cycles to 508:17
awhmm..too bad  though. alright08:17
wolfspraulaw: you found some boards that failed after X cycles, right?08:18
awwolfspraul, yes08:18
awI'll back to see if my rework was bad. so replacing a diode or c238 220pF to test again.08:19
wolfspraullike 5C08:19
wolfspraulvery strange08:19
wolfspraulfailed on 9th power cycle08:19
awyup..I'll back to check that one. ;-)08:20
wolfspraulalso 0x63 0x8508:21
wolfspraulstrange stuff08:22
xiangfuaw, if we want 'Rendering' we have to do it in Flickernoise.08:30
wolfsprauland we don't want to switch from a cold power cycle to a software reset either08:32
wolfspraulthe test should first test cold power cycle, software reset is a different test (and not important now imho)08:33
lekernelI hope you will make that stupid supplier pay for those crappy TI parts they sold08:48
lekernelincluding the massive time wastage and delays they caused08:48
wolfspraulno, because it's not the suppliers fault08:49
wolfspraulbut we will not buy those parts from there anymore (all suppliers are in the wiki btw)08:49
wolfspraulI do not know a magic way to avoid this kind of problem, it's nothing to be worked up about.08:49
wolfspraulyou cannot just try to 'play safe', there is no such path and then you cannot produce anything anymore08:50
wolfspraulbut we learn, another thing that will be improved in rc408:51
wolfspraulI personally visited that supplier several times, it's not their fault. They were mislead about this as well.08:51
wolfspraulI 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 :-)08:55
wolfspraulthat's all08:55
wolfspraulwe didn't apply this simple rule for the rc3 sourcing, but we will for rc4, guaranteed08:55
wolfspraulevery 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!08:56
wolfspraulone 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.08:57
wolfspraulAdam has already moved to other troublemakers now...08:58
AlarmIs it possible to learn how to program the FPGA with the card Milkymist?08:58
wolfspraulAlarm: don't understand what you mean. You mean programming the fpga (bitstream)?08:59
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)09:00
wolfspraulyou can program the Milkymist SoC in a language called Verilog, the microkernel (RTEMS) and application (Flickernoise) can be programmed in C09:00
wolfsprauldoes that answer your question?09:01
AlarmI rephrase my question: "is it possible to create a function with verilog for beginners?09:09
wolfspraulyou could probably move functions into the fpga, yes. but I'm not aware of a good 'verilog hello world' example in conjunction with Milkymist09:11
wolfspraulkristianpaul went through some realizations as part of his GPS stack, so he may have some good starting points or code snippets at hand09:12
AlarmI found the realization of kristianpaul: http://en.qi-hardware.com/wiki/GPS_Free_Stack09:25
wolfspraulthat's the whole project09:25
wolfspraulbut when he's online later he may point you to some small starting snippets to dive into the Milkymist SoC09:25
wolfspraulunless lekernel has an idea for you, of course09:26
wolfspraulI agree there should be starting points for people, the whole SoC is probably overwhelming. I think about 40,000 lines of Verilog code.09:26
wolfspraulAlarm: 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.09:27
wolfsprauleventually it will dawn on you where and how to start putting your own stuff in09:27
Alarm:) A small project of a few line of code verilog please me well09:36
lekernelAlarm, https://github.com/sbourdeauducq/paltest09:49
Alarm:) Thank you, I will test :)09:58
Fallenouoh you connect CVBS to the red connector ?10:00
FallenouI thought you would have to connect to the green one10:00
Fallenou(README of paltest)10:00
AlarmCVBS is yellow on the tv?10:06
FallenouI have an Analog Device ADV7403 video input chip here, and I have to connect CVBS to the green input to make it work (composite)10:13
Alarmi guess it must install the Xilinx tools?10:26
FallenouAlarm: you have to install ISE Webpack10:26
Fallenouto get Xst10:26
Fallenouyou won't have to use theur GUI in theory, you can use the makefiles10:26
Alarmok thank10:32
lekernelFallenou, this repository is about CVBS _output_10:37
lekernelthrough the VGA connector10:37
kristianpaulpaltest looks interesting to look at Alarm11:17
kristianpaulyeah, i started printing all datahseets, also core documnetation and reading11:17
kristianpaulno matter if you understand at first11:17
kristianpaulbrain catch later for sure, but read read !11:17
kristianpauleasy way is CSR bus, a good starting point for _very_ basic stuff11:18
kristianpaulonce you learn about take a look and time to wishbone specs is very important11:18
kristianpauland of course in parellel stufy verilog and digital design and computer arcquitecture is not bad11:19
kristianpaulactually thats a book from MIT i think11:19
kristianpaulbut there are plenty of good free sources in the internet11:20
kristianpauland please, take a lot of care of clock domains... i lost lot of time because dont doint it..11:20
kristianpaulFallenou: hi11:20
kristianpaulFallenou: Had, you a rought idea of how to handle mico32 interrupts11:21
kristianpaul(note, i dint looked at milkymist demo yet)11:21
lekernelreport integer'image(to_integer(unsigned(count)));11:33
lekernelvhdl die11:33
Alarmkristianpaul: Thank you for your counsel12:27
Fallenoukristianpaul: nop, but they are re designing it here (milkymist)13:43
xiangfuHi 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'?13:47
Fallenoukristianpaul: it's in the lm32 arch pdf anyway13:48
AlarmIs there a difference in performance between VHDL and verilog?14:53
lekernelxiangfu, yes, plus cmdline.txt and initrd.bin16:33
larscactually youd don't need cmdline.txt anymore16:40
larscxiangfu: you also need to change the size of the rootfs to 4MB16:42
kristianpaulFallenou: (pdf) yeah, just finished reading it :)18:30
kristianpaulwhat i need is to wipeout the memcard and see if the bug about no boot.bin is gone :)18:32
mwallelarsc: 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 code19:52
mwallelekernel: after pinging the patch again, i got one acked-by by gerd hoffmann19:56
mwallebut still no merge by anthony, but i havent seen any mail from him today19:56
mwalleso he might be ooo19:56
larscmwalle: but our workaround works, or doesn't it?19:58
mwalleby chance20:00
mwallefor now it seems to work, but there seems to be no connection between the register constraint and the actual inline asm20:00
mwallelarsc: i would chance anything for now, there are many difference proposals. so as long as it works.. :)20:03
larscmwalle: do you want to apply your irqflags patch?20:17
mwalleif you agree20:21
larschave you seen my relpy?20:22
larscthe 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 A20:23
GitHub70[linux-milkymist] mwalle pushed 1 new commit to master: https://github.com/milkymist/linux-milkymist/commit/00a52b0c1baac629016d18cf9d6da81199ac8f5020:24
GitHub70[linux-milkymist/master] lm32: simplify irq handling even more - Michael Walle20:24
mwallelarsc: but only on smp?20:24
larscbut that should result in undefined behaviour anyway20:24
larscuhm, i meant lock A, lock B, unlock A, unlock B20:25
larscwill clear EIE and BIE20:26
mwallethis would break other architectures too, afaik, microblaze restores its whole status register20:28
mwallelarsc: btw does this have any consequences on the generic atomic instructions20:29
larscyes, they are optimal now20:30
larsckernel size in general shrunk quite a bit20:31
mwallelekernel: framebuffer is working for me21:44
mwalledid you select CONFIG_FRAMEBUFFER_CONSOLE ?21:45
lekernelyes, it was working last time I tried, but I remember someone reporting problems on IRC21:46
lekernelmight be only a misunderstanding21:46
mwallenice, /dev/mem wont work for address 0..22:09
mwallelarsc: my my busbox/kernel seems to be not very stable22:11
mwalleatm the kernel hangs in do_wait_thread, http://paste.debian.net/125026/22:11
larsccan you send me your rootfs?22:16
larsci'm still busy with work atm. but i'll try to take a look at it later or tomorrow22:18
mwalleits a initramfs ;)22:19
mwallehttp://paste.debian.net/125027/ << heres another backtrace with an error i see more often22:20
mwallewrites to 0x1cc and 0x14422:20
mwalleseem like the current is NULL22:27
larschm, some check missing user_mode() check?22:28
larschm, some missing user_mode() check?22:29
--- Thu Aug 4 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!