| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When | |
|---|---|---|---|
| *** | Architect changes his alias to Guest38991
Architect changes his alias to Guest657 | [23:16] | |
| ............................. (idle for 2h23mn) | |||
| Architect changes his alias to Guest8035 | [02:39] | ||
| ................. (idle for 1h20mn) | |||
| Architect changes his alias to Guest73450 | [03:59] | ||
| ...................................... (idle for 3h9mn) | |||
| Whoopie_ changes his alias to Whoopie | [07:08] | ||
| .... (idle for 19mn) | |||
| larsc | tnt: somebody though it was a good idea to put the differntial pmod connectors on a 3.3V bank | [07:27] | |
| tnt | larsc: yeah, but I thought that for input only that worked right ?
larsc: you can't use the internal diff_term though ... so you might have to change that and hope they put 100ohm termination externally.
| [07:29] | |
| larsc | yes, exactly | [07:39] | |
| *** | Guest61649 changes his alias to UukGoblin | [07:39] | |
| larsc | the Xilinx manual also recommends ac-coupling and dc-biasing on the fpga side | [07:40] | |
| tnt | well "recommends" ... :p | [07:44] | |
| ..................... (idle for 1h41mn) | |||
| mchehab | pinchartl, koike: actually the DMA engine may have 2 pads, if it is connected to the GPU directly | [09:25] | |
| ............ (idle for 58mn) | |||
| tnt | larsc: so is it not working with thos diff input ? | [10:23] | |
| larsc | tnt: CSI SR: c0010001 [ PP_FIFO_empty Pkt_FIFO_empty PP_running PHY_running ]
CSI ER: 00020000 [ phy_bad_ecc ] with internal termination on the 3.3V bank at least the clock is detected | [10:29] | |
| tnt | larsc: yeah, also must have detected the sync sequence to raise a bad_ecc. | [10:34] | |
| larsc | yep
lets see where I can go form here | [10:34] | |
| tnt | when I debugged this, I started by monitoring the phy_data signal.
(in my case I just routed them to other GPIO and monitored witha external logic analyzer, but chipscope would probably be easier, I just didn't have jtag at the time) | [10:36] | |
| larsc | I have neither right now | [10:37] | |
| tnt | Does the bad ecc always come back when you clear it ? | [10:38] | |
| larsc | not always
but that might either be no sync, or good data I'm going to add a status bit for sync detected | [10:38] | |
| tnt | you can disabled the PP (packet processor) and see if the Pkt fifo becomes not empty.
if the phy pushes packet and the processor doesn't read them, it will report overflow at some point. | [10:39] | |
| larsc | [ PP_FIFO_empty Pkt_FIFO_empty PHY_running ] | [10:41] | |
| tnt | yeah, not pushing anything then, so sync is probably just never detected.
you did notice the PHY_INV_CLK and PHY_INV_DATA right ? and put them to false ? | [10:42] | |
| larsc | are they true by default? | [10:44] | |
| tnt | yeah
a bit of oversight, they should be false by default really, but that was the config I needed for my first test. | [10:44] | |
| larsc | k, let me change that | [10:45] | |
| ....... (idle for 30mn) | |||
| tnt | larsc: so any progress ? | [11:15] | |
| larsc | waiting for the bitstream, made some changes to the core | [11:21] | |
| no more syncs
ok, by using the idealy i can get a sync | [11:27] | ||
| tnt | larsc: but still bad_ecc ?
It's weird, I never had to use the IDELAY ... (they were there just in case I needed them, but I never did). What frequency are you running the link at ? | [11:39] | |
| larsc | 108MHz | [11:41] | |
| tnt | weird, that's pretty slow, shoudln't be any issue. | [11:41] | |
| larsc | while it is reproduceable it only works at a single offset. that's a fairly small window | [11:46] | |
| tnt | larsc: did you connect the clock input to a gpio that's conencted to a regional clock buffer ? | [11:47] | |
| larsc | but the packet fifo overflows | [11:47] | |
| tnt | larsc: oh, so it finds valid ECC and packets, interesting. | [11:48] | |
| larsc | it takes a couple of seconds though | [11:50] | |
| tnt | larsc: do you have the PP running ? | [11:54] | |
| larsc | no | [11:54] | |
| tnt | ok, should be faster then, it doesn't have much space.
One thing I also did when debugging is just connect the output of the internal pkt fifo to a DMA ... so I could grab the raw packets that were generated by the PHY, but it's a pretty extensive mod. | [11:55] | |
| larsc | I guess the signal integrity might just be too bad at the moment | [11:57] | |
| tnt | larsc: which pins dod you use for the clock lane and data lane ?
(it's on a zedboard right ?) | [11:59] | |
| larsc | the pmod header | [12:02] | |
| tnt | yeah, but which one and which pin of that pmod. | [12:02] | |
| larsc | pmod d pins 1,2,3,4 | [12:04] | |
| tnt | damn, who's the idiot who did the zedboard design ... none of the differential pmod are connected to clock-capable IOs ...
what idelay value are you loading ? (and are you loading it for clk or data lane) | [12:05] | |
| larsc | a delay of 5 for the clock
but let be check sometimg something | [12:10] | |
| ok, this is slightly embarrassing, but I had the pin mappings for clock and data swapped | [12:21] | ||
| tnt | lol
does it work better ? Ah well, need to rebuild I guess. | [12:22] | |
| larsc | It now syncs for most delay settings
but I still get bad_ecc but it sees packets | [12:23] | |
| tnt | I mean with a single lane, I would expect some false positive sync detect which will yield a few bad_ecc at the beginning, but at some point, it should align itself to the packet stream and if you clear bad_edd it shouldn't come back. | [12:28] | |
| larsc | it's actually the other way around. In the begining I get a few good packets, but after a while bad_ecc is always asserted | [12:41] | |
| ok, no all is good
I cleared the wrong bits | [12:52] | ||
| tnt | larsc: and does the fifo go to overflow quickly ? | [12:57] | |
| larsc | yes | [12:59] | |
| tnt | I guess just need to grab the data now :p | [13:00] | |
| larsc | I get a bad ecc at around every 20ms
which is 50Hz so once per frame I guess | [13:06] | |
| tnt | could be that the during the vlank there is enough idle time to randomly get a false positive sync detect ...
if the rest of the packets are fine I guess you can live with that. Alternatively, use the external LP detect hw to get rid of it. I'm still not sure how you're using the internal diff term if the ban is 3.3v ... AFAICT that just shouldn't be allowed. | [13:13] | |
| larsc | I tell vivado that the voltage is 2.5 | [13:17] | |
| ..... (idle for 23mn) | |||
| I'm getting a lot of packets with either type 0x80 or 0x7f | [13:40] | ||
| .... (idle for 16mn) | |||
| tnt | larsc: those are not defined AFAIK ... | [13:56] | |
| larsc | yeah, I guess that happens during the LP phase | [13:56] | |
| tnt | but do you also get valid data ? | [13:57] | |
| larsc | otherwise I'm seeing 0x1e ( my data) and 0x11(blanking data) | [13:57] | |
| tnt | It's possible that with a single lane there is too much false positive ... with 2 lanes you need the two to have sync at the same time which is pretty unlikely.
If you have a few resistors laying around, you could try the LP detect hw. | [13:59] | |
| larsc | hm, I guess the code was just wrong, now all I see is 0x11 and 0x1e | [14:03] | |
| tnt | nice. Did you dump the data yet to see if it looks like an image ?
How are you looking at the packet types btw ? | [14:03] | |
| larsc | I just added a status register which holds the type for the last unkown packet | [14:04] | |
| tnt | Ah yeah good idea. I was also thinking of adding a few registers to the accepted data types instead of them being hardcoded. | [14:06] | |
| larsc | no more unkown packets. and now for the data | [14:17] | |
| .... (idle for 18mn) | |||
| tnt | larsc: looking forward to your first image :p | [14:35] | |
| you probably want to use raw mode of the video pipeline for now as the whole debayering or 10b unpacking process is useless in your case. | [14:40] | ||
| larsc | is that the default configuration? | [14:52] | |
| tnt | larsc: yeah.
vpcr = 0x00000000 ... | [14:55] | |
| ...... (idle for 25mn) | |||
| pinchartl | tnt, larsc: nice to see progress :-)
tnt: what's the license of the CSI receiver VHDL code ? (oh and please tell me it's VHDL, not verilog) | [15:20] | |
| tnt | pinchartl: GPL and it's VHDL yes | [15:21] | |
| pinchartl | nice | [15:22] | |
| ...... (idle for 28mn) | |||
| larsc | while I'm able to capture data using v4l, the data looks quite scramled | [15:50] | |
| tnt | larsc: and the vdma reports no issues ? | [15:53] | |
| larsc | I'm not using the vdma, but yeah dma works fine
the start of the dma is synchronized to sof so that seems to be detected | [15:54] | |
| tnt | and each packet (between tlast) is the expected length ?
larsc: mmm, turns out the VPCR is 00133930 by default ... larsc: try writing 0 instead. | [15:57] | |
| larsc | yep, just noticed that too
perfect! | [15:59] | |
| tnt | larsc: \o/ | [16:02] | |
| larsc | at least the test pattern looks ok | [16:05] | |
| tnt | larsc: hopefully real video works too :p | [16:14] | |
| larsc | no
that's the strange thing | [16:14] | |
| tnt | larsc: damn :(
how does it fail ? | [16:15] | |
| larsc | this is the image I get when I tell the sensor to send the testpattern: http://metafoo.de/csi_testpattern.png | [16:22] | |
| this is what I get for real data: http://metafoo.de/csi_real.png (10 frames) | [16:27] | ||
| tnt | larsc: and do you get bad_ecc when that happens ? | [16:34] | |
| larsc | not more than usual as far as I can tell | [16:37] | |
| tnt | larsc: any unknown packets popping up ?
larsc: if it's 10 frames, then a lot of lines are completely missing it seems :( | [16:46] | |
| larsc | it's interlaced, so actually 20 frames
it looks a bit as if it is maybe loosing a clock cycle sometimes I'll try the external termination and see if it makes a difference but its all already working quite fine thanks | [16:51] | |
| tnt | btw, if you're not using the vdma, what are you using ? | [16:56] | |
| larsc | my dma | [16:56] | |
| theBear | don't accidentally clone yourself <grin>
sorry, couldn't resist | [16:57] | |
| ....... (idle for 30mn) | |||
| larsc | tnt: I have a suspicion that it detects a sync one the corrupted lines. the corruption always starts in the black bars, either on the left or the right
and if that happens we skip a few clock cycles because capture_1 goes to 0 | [17:27] | |
| tnt | larsc: nice catch !
larsc: indeed that if sync_detect = '1' should also validate that the current state is SOT | [17:30] | |
| larsc | and maybe add a timeout | [17:32] | |
| tnt | it can't stay stuck in HEADER or DATA, it will always fall back to IDLE at some point.
it can stay stuck in SOT .. which is why there is a 'FIXME' there, but that shouldn't happen if the link is working. (during vblank where it'd in LP you can actually stay on that state for a _very_ long time ... ie millions of cycles) | [17:32] | |
| larsc | ok, let me try to add that check | [17:35] | |
| I think the condition can be simplified to just checking whether we are in SOT | [17:40] | ||
| tnt | larsc: yup | [17:49] | |
| ......... (idle for 41mn) | |||
| larsc | ok, that's better http://metafoo.de/csi_real2.png except for regions with all 0x00
and no bad_ecc anymore | [18:30] | |
| tnt | larsc: nice :)
larsc: what ae the secton with white bars between frames ? blanking data ? | [18:35] | |
| pinchartl | I need to find time for VHDL development. it's fun when done sparingly | [18:36] | |
| larsc | tnt: I don't know. It might be that the camera sends one black line at the top and at the bottom of each full frame
the bars are not there when using the test pattern | [18:38] | |
| tnt | larsc: but it doesn't seem to be between every frame which is weird.
larsc: what did you do with the blanking data in the packet parser ? | [18:39] | |
| larsc | ignore | [18:40] | |
| tnt | larsc: oh yeah, it's interlaced ... just remembered now. | [18:41] | |
| larsc | yes | [18:41] | |
| tnt | The big green zones, that's just at startup ? or does it happen from time to time ? | [18:41] | |
| larsc | I think that might have been residual data in the packet fifo | [18:42] | |
| tnt | Ah yeah right, I usually reset the core first.
this resets the fifo. Then start the DMA, then the core, then the actual sensor. (so that everything is ready when data starts flowing) larsc: so beside this sync thing and the min/max for the # lanes, did you have to patch anything else ? | [18:42] | |
| larsc | I've updated the previous image with a clean capture
tnt: no, that's pretty much it | [18:48] | |
| tnt | larsc: now the question remains : what are you doing with an analog SD capture chip ? :p | [18:50] | |
| larsc | capture analog SD video ;)
its nice to now have a sane platform to test the chip. I previously used the freescale iMX and that's quite painful | [18:51] | |
| tnt | really ? why ? I mean it has a dedicated CSI interface controller, it must be much more capable that the basic interface I wrote. | [18:55] | |
| larsc | doesn't mean its sane
the drivers for those blocks is outoftree 100k or so lines code that uses non-standard APIs | [18:58] | |
| pinchartl | larsc: do you think you could write a subdev driver for that CSI2 receiver compatible with the Xilinx V4L2 framework ? | [19:00] | |
| larsc | maybe
there isn't too much to do other than enable and disable the core | [19:01] | |
| pinchartl | does it require any configuration, like width, height, VC number, data type ? | [19:03] | |
| tnt | pinchartl: you can crop if you want but by default, it will just tx whatever height / width it receives.
pinchartl: it also has some basic video stuff, like it can do a smple debayering to RGB or convert the packed to unpacked, .... currently data type is hardcoded ... he had to change it to YUV, in my version it accepted RAW8 and RAW10. but it's up to the app to know what the sensor sends and how to interpret, the core itself only uses it for sanity check of the packets. | [19:04] | |
| larsc | ideally the cropping and converting is factored out into a separate module
that's part of the image processing pipeline and not part of the interface you can re-use the same processing block with e.g. a different interface block | [19:08] | |
| .... (idle for 15mn) | |||
| tnt: do you think it is possible to relicense under LGPL. Right now you can't really distribute a bitstream that contains the core unless you have the ability to make all the other cores used in the design available under the GPL. | [19:23] | ||
| pinchartl | I agree about debayering, it doesn't really belong there
what would be interesting, though, is to have a configurable number of output fifos and support VC demultiplexing as well as data type demultiplexing/filtering | [19:36] | |
| larsc | that can also be done as a second stage
streaming axi busses have the option to include a ID for each beat of of data | [19:37] | |
| ..... (idle for 20mn) | |||
| pinchartl | right, but if you have to carry x bits for the VC + y bits for the DT, that can become quite costly in hardware | [19:57] | |
| .............. (idle for 1h9mn) | |||
| marcos_ | Hi
I have problems with a couple of capture devices I think they are bugs where should I ask for help or report the bugs | [21:06] | |
| tnt | larsc: yeah, that could be done.
pinchartl: err, the goal was to be simple and small :p I'm not even sure what multiple VC are used for tbh ... | [21:19] | |
| ........... (idle for 51mn) | |||
| pinchartl | tnt: transmitting a preview video stream and still images at the same time for instance | [22:11] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
