wpwrak | things are looking good. something is coming, and it's from the local postal distribution center, merely some 10 blocks away. i hope it's the parcel, not just a note. | 12:17 |
---|---|---|
wpwrak | sb0: shipment received ! with no customs hassles at all that's how i like it :) | 15:43 |
sb0 | great! | 15:43 |
sb0 | so now be careful: no 5V | 15:43 |
wpwrak | who uses 5 V ? ;-) | 15:44 |
sb0 | I actually cut the 5V pins of my M1 so that I can't inadvertently plug the HDMI board into them | 15:44 |
sb0 | also used cardboard and double-sided tape on VGA/audio connectors to hold it in place during HDMI connections/disconnections | 15:45 |
wpwrak | (cut 5 V) nice :) | 15:48 |
wpwrak | lemme see how it fits .. | 15:48 |
sb0 | the 5V pins are those closest to the VGA/audio side | 15:48 |
sb0 | they should match the two unsoldered pads on the HDMI board | 15:49 |
wpwrak | looks good. lemme check the schematics, just to be sure | 15:52 |
wpwrak | it's actually kinda funny that the board says "Not 5V tolerant" right next to the connector that provides 5 V | 15:54 |
wpwrak | okay. all looks well regarding 5 V | 15:56 |
wpwrak | the HDMI connectors face towards LED/buttons/USB | 15:57 |
sb0 | yes | 15:57 |
sb0 | https://twitter.com/Milkymist_Labs/status/303535201139703809 | 15:57 |
wpwrak | perfect. where do you keep the schematics, gerbers, etc. of the mider board ? | 15:57 |
wpwrak | s/mider/mixer/ | 15:58 |
sb0 | http://milkymist.org/vmixext-5fev/ | 15:59 |
sb0 | I'll send you an updated http://lists.milkymist.org/pipermail/devel-milkymist.org/attachments/20130313/a4ba7f8f/attachment.py | 16:01 |
wpwrak | i'll also need to install migen and the rest of the development environment | 16:03 |
sb0 | python3 + mibuild + migen + ISE | 16:04 |
sb0 | yes | 16:04 |
sb0 | and milkymist-ng | 16:04 |
wpwrak | any preferred version of ISE ? | 16:05 |
sb0 | if you have one that worked for the old soc, it should still be fine | 16:06 |
sb0 | otherwise take the latest | 16:06 |
wpwrak | lost the old environment in one of those disk failures, so it'll all be fresh | 16:07 |
wpwrak | okay, layout is clear. ah, do you already decode HDMI and produce an image (on VGA) ? | 16:13 |
sb0 | no, the series of bugs irritated me beyond reasonable levels so I did something else for a while | 16:14 |
sb0 | will get back to it in a short while... | 16:15 |
wpwrak | so there are more bugs ? :) | 16:15 |
sb0 | I didn't touch the data interface since last time... | 16:15 |
sb0 | next step is to throw the raw data into the DRAM and see if I get something else than garbage | 16:16 |
sb0 | almost everything has semi-random behaviour ... | 16:16 |
wpwrak | kewl. if all else fails, you can sell it to the military as a high-entropy random number generator ;-) | 16:17 |
wpwrak | after all, if it's only sometimes random, that makes it more random, right ? :) | 16:18 |
wpwrak | ISE download, first stage, 2 hours left :-( | 16:51 |
larsc | 14.5? | 17:31 |
wpwrak | yup | 17:35 |
larsc | we couldn't get it to work so far | 17:36 |
larsc | I think they just break more and more things on purpose so everybody switches to vivado | 17:36 |
sb0 | only tried 14.4 ... | 17:39 |
wpwrak | vivado is non-free ? i actually ended up beginning to download vivado. it somehow appeared en route to webpack. | 17:39 |
sb0 | larsc, what's broken? | 17:40 |
wpwrak | okay, let's switch to 14.4 then. new download, new luck | 17:40 |
sb0 | vivado is free of charge, but when I tried it it was ludicrously slow | 17:40 |
sb0 | 'ludicrously' as in '15min compilation for a LED blinker' | 17:40 |
larsc | sb0: I only heard my college cursing, I think it was aborting with some obscure error when building the bistream | 17:41 |
wpwrak | larsc: your colleagues in germany ? | 17:42 |
larsc | well there is only one | 17:42 |
larsc | or did you mean colleague's | 17:43 |
wpwrak | ah. Mr. Macleod then :) | 17:43 |
larsc | who? | 17:43 |
wpwrak | hmm, he's been with you to romania then. so i can't make the joke that you heard the curses across hundreds of kilometers | 17:43 |
larsc | nope | 17:44 |
larsc | ah, the highlander | 17:44 |
wpwrak | "There can be only one" :) | 17:44 |
lekernel | wpwrak, emailed you the EDID tester source + a bitstream | 18:25 |
lekernel | (compatible with the new migen api) | 18:25 |
lekernel | it also blinks a LED on the pixel clock, you should be able to control the frequency with xrandr | 18:26 |
lekernel | the HDMI port is the one close to VGA/audio (left side when facing the connectors) | 18:27 |
wpwrak | thanks ! setting up the test PC ... | 18:29 |
wpwrak | ah, ubuntu is not happy with my streamlined system. well, that's not entirely unexpected. plan B then ... | 18:37 |
sb0 | tried archlinux? | 18:40 |
wpwrak | naw, it didn't come to that yet :) | 18:42 |
Hawk777 | Anyone else get a page not found just going to xilinx.com, hovering Products, and clicking Development Tools? | 18:59 |
Hawk777 | Or for that matter just clicking Products? | 18:59 |
sb0 | yes, same here | 19:01 |
sb0 | seems wpwrak started his download just in time :) | 19:02 |
wpwrak | whee, the autocrap family has a new member: autopoint | 19:09 |
wpwrak | the download still seems to be going well. except that it slowed down. now it's "7 hours left" :-( | 19:15 |
GitHub152 | [migen] sbourdeauducq pushed 3 new commits to master: http://git.io/HZ_YTQ | 19:18 |
GitHub152 | migen/master 692794a Sebastien Bourdeauducq: flow: use Module and new Record APIs | 19:18 |
GitHub152 | migen/master df1ed32 Sebastien Bourdeauducq: genlib/record/connect: add match_by_position | 19:18 |
GitHub152 | migen/master 6ce8562 Sebastien Bourdeauducq: flow: match record fields by position | 19:18 |
wpwrak | to load top.bit ... pld load top.bit and then is it ready or do i need to do something else ? | 19:19 |
GitHub46 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/92lMug | 19:19 |
GitHub46 | milkymist-ng/master 950d3a4 Sebastien Bourdeauducq: framebuffer: use new flow API | 19:19 |
sb0 | then it's ready... plug the HDMI cable and it should show in xrandr | 19:19 |
wpwrak | drums ... | 19:20 |
sb0 | note that there might be problems if you plug it before the bitstream is loaded - the HPD pin is held permanently asserted due to lack of IO pins | 19:20 |
sb0 | it didn't cause major issues on my two nvidia cards - it keeps retrying EDID reads, but does not give up | 19:20 |
wpwrak | xrandr sees it | 19:21 |
sb0 | ok. now set a mode and the LED should be blinking, and I2C not working anymore. | 19:22 |
wpwrak | http://pastebin.com/YiTM1AkX | 19:22 |
wpwrak | let's see ... | 19:22 |
sb0 | looks good | 19:22 |
wpwrak | LED blinks happily | 19:23 |
wpwrak | after xrandr --output DVI-1 --mode 640x480 | 19:24 |
sb0 | is xrandr --verbose capable of displaying the EDID? | 19:24 |
sb0 | with the bug that would fail | 19:24 |
wpwrak | "DVI-1 disconnected" suggests that it may not ... | 19:24 |
sb0 | ok. so you can reproduce it. | 19:24 |
wpwrak | an no, no EDID in sight. only one from the other screen | 19:25 |
wpwrak | that much about "it only happens in the northern hemisphere" :) | 19:26 |
wpwrak | one signal looks pretty good on the M1 side, with bursts of ~4 x 10 cycles every few seconds. 4 Vpp, says my scope. to be verified. the other sits at 2 V, apparently without activity. | 19:37 |
wpwrak | lemme verify that i got the right ones ... | 19:38 |
sb0 | 4Vpp? | 19:39 |
sb0 | should be 3.3V ... | 19:40 |
sb0 | I got both SCL and SDA nicely with the saelae | 19:40 |
wpwrak | scope thinks it's 4 V. will check with a voltmeter in a moment. the HDMI connectors are good grounds, right ? | 19:41 |
sb0 | no, they aren't | 19:42 |
sb0 | the shells are connected to ground with a parallel RC circuit | 19:43 |
wpwrak | ah, i see. let's see what else i can use that's not too fragile ... | 19:45 |
wpwrak | USB looks good :) | 19:46 |
sb0 | soldering a row of 3 pins on top of the connector that goes to M1 works nicely | 19:46 |
sb0 | USB is also not a good ground | 19:47 |
wpwrak | ah, damn. the shield is RC'ed too | 19:48 |
wpwrak | ah, and the "4 V" was actually ~3.3 V. so far, so good. | 19:55 |
wpwrak | now let's see what's up with the other signal | 19:55 |
wpwrak | that was the wrong pin. makes sense then, too. now i see a nice and clean signal on the M1 side | 19:55 |
wpwrak | xrandr still thinks it's disconnected | 19:57 |
wpwrak | this is what the M1 side looks like: http://downloads.qi-hardware.com/people/werner/ming/edid/mix-scl-sda-m1-10us.png | 20:07 |
wpwrak | and here's the entire data block: http://downloads.qi-hardware.com/people/werner/ming/edid/mix-scl-sda-m1-200us.png | 20:09 |
GitHub103 | [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/4xeOOg | 20:15 |
GitHub103 | migen/master 1cc4c8e Sebastien Bourdeauducq: uio: remove Trampoline (Python 3.3 provides generator delegation instead) | 20:15 |
GitHub103 | migen/master 746acda Sebastien Bourdeauducq: ioo: move to genlib | 20:15 |
wpwrak | if i reload the bitstream, there's a rather extensive dialog, with signals that look just as nice | 20:19 |
larsc | does it look any different with and without hdmi on? | 20:25 |
wpwrak | how would the two states differ ? | 20:27 |
larsc | the amount noise supposedly | 20:28 |
wpwrak | no, i mean: what would i change in the system to be "without hdmi on" ? | 20:30 |
wpwrak | i think before the xrandr --mode, no video signal is output, if you mean that | 20:31 |
sb0 | xrandr --output xxx --off | 20:31 |
sb0 | yes | 20:31 |
sb0 | I think so | 20:31 |
wpwrak | let's try --off and a reconfiguration | 20:31 |
wpwrak | oh, now it came back. just with the --off | 20:33 |
wpwrak | before, i once tried and it stayed "disconnected" | 20:33 |
wpwrak | yeah, --off seems to work | 20:33 |
wpwrak | even without touching the fpga | 20:34 |
sb0 | same here | 20:38 |
wpwrak | the signals also look clean on the other side of the level converters | 20:41 |
wpwrak | not quite as lovely, but should be sufficiently good | 20:41 |
wpwrak | let's see what's happening with the pixel data | 20:44 |
wpwrak | the video side looks pretty dead | 20:50 |
wpwrak | i wonder if it could simply be an I2C/DDC request the M1 doesn't understand | 20:51 |
larsc | it's all the same | 20:57 |
larsc | or at least should be | 20:57 |
larsc | i2c read on address 0x50 | 20:57 |
sb0 | I remember seeing the M1 failing to ack the 0x50 address when the video is on | 20:59 |
wpwrak | here's a numeric dump at 100 ns/Sa, suitable for viewing with gnuplot: http://downloads.qi-hardware.com/people/werner/ming/edid/unanswered-scl-sda-100ns.gp.bz2 | 21:19 |
wpwrak | to visualize, plot "foo.gp" using 1:($2+4.5) with lines, "foo.gp" using 1:3 with lines | 21:19 |
wpwrak | now, let's decode it ... | 21:19 |
larsc | a couple of reads for 0x50 without an ack | 21:23 |
GitHub109 | [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/y4Mzqg | 21:27 |
GitHub109 | migen/master 4c9018e Sebastien Bourdeauducq: fhdl/visit: add TransformModule | 21:27 |
GitHub109 | migen/master 72ef4b9 Sebastien Bourdeauducq: ioo+pytholite: use new Module API | 21:27 |
sb0 | gn8 | 21:28 |
wpwrak | my decoder says S50WN. i think that means it agrees :) | 21:36 |
wpwrak | actually no. it's a write, according to my decoder. | 21:38 |
larsc | uhm yes | 21:39 |
larsc | it might want to read a certain subpage | 21:40 |
wpwrak | now, as i know sebastien, he probably didn't implement writes ... :) let's see ... | 21:40 |
larsc | it looks it if it ignores the read/write bit | 21:43 |
larsc | but always responds | 21:44 |
wpwrak | milkymist-ng/milkymist/dvisampler/edid.py:179 does indeed look a little suspicious | 21:44 |
wpwrak | i seems to consider the bit, but doesn't know what to do with a write | 21:44 |
larsc | hm, am I missing something or is the WAIT_START state not implemented? | 21:49 |
wpwrak | and 0x50 is indeed the EDID | 21:50 |
wpwrak | yeah, looks like it | 21:52 |
wpwrak | or maybe there's some default or such. can't quite make sense of it yet | 21:52 |
larsc | might be the for state in states at the bottom | 21:53 |
wpwrak | anyway, i think we have an explanation :) | 21:53 |
wpwrak | yeah, that could be some default clause. or maybe not ;) | 21:53 |
larsc | actually the code looks as if it should handle writes propertly | 21:54 |
larsc | but I think it is possible that it never leaves the READ, ACK_READ cycle | 21:57 |
wpwrak | isn't WAIT_START the wait for a start bit ? | 21:57 |
wpwrak | for a write, it would still have to receive the value | 21:57 |
larsc | it does | 21:58 |
larsc | RCV_OFFSET | 21:59 |
wpwrak | ah yes, line 134 | 21:59 |
larsc | but a stop condition should reset the fsm | 22:00 |
larsc | and there does not seem to be stop support | 22:00 |
larsc | basically | 22:02 |
larsc | stop = Signal() | 22:02 |
larsc | self.comb += stop.eq(scl_i & sda_rising) | 22:02 |
larsc | and then If(stop, fsm.next_state(fsm.WAIT_START)).Else(... for each state | 22:03 |
wpwrak | but doesn't a start the FSM as well ? | 22:05 |
larsc | ah, ok | 22:07 |
larsc | thats why it adds it to each state | 22:07 |
wpwrak | it should output the state on some unused pins. then it would be easy to monitor what's going on. | 22:12 |
wpwrak | hmm, since sebastien isn't around, i'll just post a summary of what we have so far on the list. maybe it already rings a bell. | 22:24 |
larsc | hm, if I simulate things, start is set whenever sda is falling, even if scl is low | 22:53 |
wpwrak | hmm. i think i should be able to see the pixel clock. let's look for it again ... | 22:54 |
larsc | ah, that was the 20 cycle delay line | 22:54 |
wpwrak | maybe it's the clock input cross-talking somewhere in the logic. the clock is very fast in comparison, 30+ MHz vs. ~40 kHz I2C clock | 23:14 |
wpwrak | 31.502 MHz, to be exact | 23:25 |
--- Thu Apr 11 2013 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!