<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
***: Architect changes his alias to Guest657
<br> Architect changes his alias to Guest8035
<br> Architect changes his alias to Guest73450
<br> Whoopie_ changes his alias to Whoopie
larsc: <u>tnt</u>: somebody though it was a good idea to put the differntial pmod connectors on a 3.3V bank
tnt: <u>larsc</u>: yeah, but I thought that for input only that worked right ?
<br> <u>larsc</u>: you can't use the internal diff_term though ... so you might have to change that and hope they put 100ohm termination externally.
<br> http://forums.xilinx.com/t5/7-Series-FPGAs/LVDS-1-8-interface-in-Artix-7/m-p/522321#M6560
larsc: yes, exactly
***: Guest61649 changes his alias to UukGoblin
larsc: the Xilinx manual also recommends ac-coupling and dc-biasing on the fpga side
tnt: well "recommends" ... :p
mchehab: pinchartl, koike: actually the DMA engine may have 2 pads, if it is connected to the GPU directly
tnt: <u>larsc</u>: so is it not working with thos diff input ?
larsc: <u>tnt</u>: CSI SR: c0010001 [ PP_FIFO_empty Pkt_FIFO_empty PP_running PHY_running ]
<br> CSI ER: 00020000 [ phy_bad_ecc ]
<br> with internal termination on the 3.3V bank
<br> at least the clock is detected
tnt: <u>larsc</u>: yeah, also must have detected the sync sequence to raise a bad_ecc.
larsc: yep
<br> lets see where I can go form here
tnt: when I debugged this, I started by monitoring the phy_data signal.
<br> (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)
larsc: I have neither right now
tnt: Does the bad ecc always come back when you clear it ?
larsc: not always
<br> but that might either be no sync, or good data
<br> I'm going to add a status bit for sync detected
tnt: you can disabled the PP (packet processor) and see if the Pkt fifo becomes not empty.
<br> if the phy pushes packet and the processor doesn't read them, it will report overflow at some point.
larsc: [ PP_FIFO_empty Pkt_FIFO_empty PHY_running ]
tnt: yeah, not pushing anything then, so sync is probably just never detected.
<br> you did notice the PHY_INV_CLK and PHY_INV_DATA right ? and put them to false ?
larsc: are they true by default?
tnt: yeah
<br> a bit of oversight, they should be false by default really, but that was the config I needed for my first test.
larsc: k, let me change that
tnt: <u>larsc</u>: so any progress ?
larsc: waiting for the bitstream, made some changes to the core
<br> no more syncs
<br> ok, by using the idealy i can get a sync
tnt: <u>larsc</u>: but still bad_ecc ?
<br> 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 ?
larsc: 108MHz
tnt: weird, that's pretty slow, shoudln't be any issue.
larsc: while it is reproduceable it only works at a single offset. that's a fairly small window
tnt: <u>larsc</u>: did you connect the clock input to a gpio that's conencted to a regional clock buffer ?
larsc: but the packet fifo overflows
tnt: <u>larsc</u>: oh, so it finds valid ECC and packets, interesting.
larsc: it takes a couple of seconds though
tnt: <u>larsc</u>: do you have the PP running ?
larsc: no
tnt: ok, should be faster then, it doesn't have much space.
<br> 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.
larsc: I guess the signal integrity might just be too bad at the moment
tnt: <u>larsc</u>: which pins dod you use for the clock lane and data lane ?
<br> (it's on a zedboard right ?)
larsc: the pmod header
tnt: yeah, but which one and which pin of that pmod.
larsc: pmod d pins 1,2,3,4
tnt: damn, who's the idiot who did the zedboard design ... none of the differential pmod are connected to clock-capable IOs ...
<br> what idelay value are you loading ?
<br> (and are you loading it for clk or data lane)
larsc: a delay of 5 for the clock
<br> but let be check sometimg
<br> something
<br> ok, this is slightly embarrassing, but I had the pin mappings for clock and data swapped
tnt: lol
<br> does it work better ?
<br> Ah well, need to rebuild I guess.
larsc: It now syncs for most delay settings
<br> but I still get bad_ecc
<br> but it sees packets
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.
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
<br> ok, no all is good
<br> I cleared the wrong bits
tnt: <u>larsc</u>: and does the fifo go to overflow quickly ?
larsc: yes
tnt: I guess just need to grab the data now :p
larsc: I get a bad ecc at around every 20ms
<br> which is 50Hz
<br> so once per frame I guess
tnt: could be that the during the vlank there is enough idle time to randomly get a false positive sync detect ...
<br> 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.
<br> 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.
larsc: I tell vivado that the voltage is 2.5
<br> I'm getting a lot of packets with either type 0x80 or 0x7f
tnt: <u>larsc</u>: those are not defined AFAIK ...
larsc: yeah, I guess that happens during the LP phase
tnt: but do you also get valid data ?
larsc: otherwise I'm seeing 0x1e ( my data) and 0x11(blanking data)
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.
<br> If you have a few resistors laying around, you could try the LP detect hw.
larsc: hm, I guess the code was just wrong, now all I see is 0x11 and 0x1e
tnt: nice. Did you dump the data yet to see if it looks like an image ?
<br> How are you looking at the packet types btw ?
larsc: I just added a status register which holds the type for the last unkown packet
tnt: Ah yeah good idea. I was also thinking of adding a few registers to the accepted data types instead of them being hardcoded.
larsc: no more unkown packets. and now for the data
tnt: <u>larsc</u>: looking forward to your first image :p
<br> 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.
larsc: is that the default configuration?
tnt: <u>larsc</u>: yeah.
<br> vpcr = 0x00000000 ...
pinchartl: tnt, larsc: nice to see progress :-)
<br> <u>tnt</u>: what's the license of the CSI receiver VHDL code ?
<br> (oh and please tell me it's VHDL, not verilog)
tnt: <u>pinchartl</u>: GPL and it's VHDL yes
pinchartl: nice
larsc: while I'm able to capture data using v4l, the data looks quite scramled
tnt: <u>larsc</u>: and the vdma reports no issues ?
larsc: I'm not using the vdma, but yeah dma works fine
<br> the start of the dma is synchronized to sof so that seems to be detected
tnt: and each packet (between tlast) is the expected length ?
<br> <u>larsc</u>: mmm, turns out the VPCR is 00133930 by default ...
<br> <u>larsc</u>: try writing 0 instead.
larsc: yep, just noticed that too
<br> perfect!
tnt: <u>larsc</u>: \o/
larsc: at least the test pattern looks ok
tnt: <u>larsc</u>: hopefully real video works too :p
larsc: no
<br> that's the strange thing
tnt: <u>larsc</u>: damn :(
<br> how does it fail ?
larsc: this is the image I get when I tell the sensor to send the testpattern: http://metafoo.de/csi_testpattern.png
<br> this is what I get for real data: http://metafoo.de/csi_real.png (10 frames)
tnt: <u>larsc</u>: and do you get bad_ecc when that happens ?
larsc: not more than usual as far as I can tell
tnt: <u>larsc</u>: any unknown packets popping up ?
<br> <u>larsc</u>: if it's 10 frames, then a lot of lines are completely missing it seems :(
larsc: it's interlaced, so actually 20 frames
<br> it looks a bit as if it is maybe loosing a clock cycle sometimes
<br> I'll try the external termination and see if it makes a difference
<br> but its all already working quite fine
<br> thanks
tnt: btw, if you're not using the vdma, what are you using ?
larsc: my dma
theBear: don't accidentally clone yourself <grin>
<br> sorry, couldn't resist
larsc: <u>tnt</u>: 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
<br> and if that happens we skip a few clock cycles because capture_1 goes to 0
tnt: <u>larsc</u>: nice catch !
<br> <u>larsc</u>: indeed that if sync_detect = '1' should also validate that the current state is SOT
larsc: and maybe add a timeout
tnt: it can't stay stuck in HEADER or DATA, it will always fall back to IDLE at some point.
<br> it can stay stuck in SOT .. which is why there is a 'FIXME' there, but that shouldn't happen if the link is working.
<br> (during vblank where it'd in LP you can actually stay on that state for a _very_ long time ... ie millions of cycles)
larsc: ok, let me try to add that check
<br> I think the condition can be simplified to just checking whether we are in SOT
tnt: <u>larsc</u>: yup
larsc: ok, that's better http://metafoo.de/csi_real2.png except for regions with all 0x00
<br> and no bad_ecc anymore
tnt: <u>larsc</u>: nice :)
<br> <u>larsc</u>: what ae the secton with white bars between frames ? blanking data ?
pinchartl: I need to find time for VHDL development. it's fun when done sparingly
larsc: <u>tnt</u>: 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
<br> the bars are not there when using the test pattern
tnt: <u>larsc</u>: but it doesn't seem to be between every frame which is weird.
<br> <u>larsc</u>: what did you do with the blanking data in the packet parser ?
larsc: ignore
tnt: <u>larsc</u>: oh yeah, it's interlaced ... just remembered now.
larsc: yes
tnt: The big green zones, that's just at startup ? or does it happen from time to time ?
larsc: I think that might have been residual data in the packet fifo
tnt: Ah yeah right, I usually reset the core first.
<br> this resets the fifo. Then start the DMA, then the core, then the actual sensor.
<br> (so that everything is ready when data starts flowing)
<br> <u>larsc</u>: so beside this sync thing and the min/max for the # lanes, did you have to patch anything else ?
larsc: I've updated the previous image with a clean capture
<br> <u>tnt</u>: no, that's pretty much it
tnt: <u>larsc</u>: now the question remains : what are you doing with an analog SD capture chip ? :p
larsc: capture analog SD video ;)
<br> its nice to now have a sane platform to test the chip. I previously used the freescale iMX and that's quite painful
tnt: really ? why ? I mean it has a dedicated CSI interface controller, it must be much more capable that the basic interface I wrote.
larsc: doesn't mean its sane
<br> the drivers for those blocks is outoftree 100k or so lines code that uses non-standard APIs
pinchartl: <u>larsc</u>: do you think you could write a subdev driver for that CSI2 receiver compatible with the Xilinx V4L2 framework ?
larsc: maybe
<br> there isn't too much to do other than enable and disable the core
pinchartl: does it require any configuration, like width, height, VC number, data type ?
tnt: <u>pinchartl</u>: you can crop if you want but by default, it will just tx whatever height / width it receives.
<br> <u>pinchartl</u>: it also has some basic video stuff, like it can do a smple debayering to RGB or convert the packed to unpacked, ....
<br> currently data type is hardcoded ... he had to change it to YUV, in my version it accepted RAW8 and RAW10.
<br> 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.
larsc: ideally the cropping and converting is factored out into a separate module
<br> that's part of the image processing pipeline and not part of the interface
<br> you can re-use the same processing block with e.g. a different interface block
<br> <u>tnt</u>: 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.
pinchartl: I agree about debayering, it doesn't really belong there
<br> what would be interesting, though, is to have a configurable number of output fifos and support VC demultiplexing
<br> as well as data type demultiplexing/filtering
larsc: that can also be done as a second stage
<br> streaming axi busses have the option to include a ID
<br> for each beat of of data
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
marcos_: Hi
<br> I have problems with a couple of capture devices I think they are bugs
<br> where should I ask for help or report the bugs
tnt: <u>larsc</u>: yeah, that could be done.
<br> <u>pinchartl</u>: err, the goal was to be simple and small :p I'm not even sure what multiple VC are used for tbh ...
pinchartl: <u>tnt</u>: transmitting a preview video stream and still images at the same time for instance