| *** tpb has joined #timvideos | 00:00 | |
| CarlFK | mithro: I have been running the latest firmware, and it seems about the same as the other versions | 00:30 |
|---|---|---|
| CarlFK | v0.0.0-699-gb505665-dirty | 00:30 |
| CarlFK | and.. it seems good enough to use. | 00:30 |
| *** Bertl is now known as Bertl_zZ | 01:19 | |
| *** sb0 has joined #timvideos | 02:12 | |
| *** sb0 has quit IRC | 02:13 | |
| mithro | CarlFK: On the Opsis or the Atlys? | 03:20 |
| mithro | _florent_: ping me when you are around | 03:20 |
| mithro | tumbleweed: ping? | 03:23 |
| CarlFK | mithro: Opsis | 04:57 |
| mithro | CarlFK: does the same version work on the Atlys? | 04:57 |
| mithro | CarlFK: can you get me the full output of "version"? | 04:59 |
| CarlFK | mithro: http://paste.ubuntu.com/16590038/ | 05:00 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 05:00 |
| CarlFK | just a min, Ill check the Atlys | 05:00 |
| mithro | cr1901_modern: you wouldn't happen to be about? | 05:19 |
| CarlFK | mithro: Memtest failed: 532731/532736 words incorrect | 05:51 |
| CarlFK | BIOS> romboot ... git describe: v0.0.0-699-gb505665-dirty | 05:52 |
| CarlFK | 05:52 | |
| CarlFK | http://paste.ubuntu.com/16590582/ | 05:52 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 05:52 |
| CarlFK | mithro: input0: 0x0 - but something is hooked up | 05:59 |
| CarlFK | HDMI2USB>m 9 | 06:01 |
| CarlFK | Setting video mode to 1280x720 @60Hz | 06:01 |
| CarlFK | it didn't come back | 06:01 |
| CarlFK | mithro: I need to get to bed. and wake up, pack and be on a flight in 8 hours | 06:04 |
| CarlFK | oh great. powercycle, load ... romboot.. displays version info and doesnt' take me to a prompt | 06:10 |
| CarlFK | powercycle, load ... romboot now I am at a prompt | 06:10 |
| CarlFK | hmm. | 06:10 |
| CarlFK | oh well... I have a show to do.. this is my backup :p | 06:10 |
| cr1901_modern | mithro: Kinda around. Just woke up lol... what's up? | 06:53 |
| mithro | cr1901_modern: where are you at with that counter? Have you uploaded something that I could look at? | 06:54 |
| cr1901_modern | Sure, I can upload something for you to play with. But I haven't attached it to any HDMI devices yet. | 06:55 |
| cr1901_modern | all I've done thus far is generate a high freq signal on one board and feed it to another, and then check it in the MIgen BIOS | 06:55 |
| cr1901_modern | mithro: Proof it does work :P https://twitter.com/cr1901/status/732870052740009984 | 06:56 |
| mithro | cr1901_modern: uploading would be good | 06:57 |
| cr1901_modern | mithro: Give me 10 minutes please... just realized I never actually checked whether it works in HDMI2USB (it should, but I should check). Building a core takes about 4 minutes, so that should give me time if I screwed up. | 07:02 |
| cr1901_modern | mithro: Want me to upload a git format-patch instead of forking HDMI2USB so you can "just apply it" and test things out? | 07:05 |
| mithro | A git repo on github would be good | 07:05 |
| *** ssk1328 has joined #timvideos | 07:13 | |
| cr1901_modern | This doesn't make sense... "Unresolved clock domain: sys" Gah! | 07:20 |
| mithro | Hi ssk1328 | 07:22 |
| ssk1328 | mithro: Hi | 07:23 |
| mithro | ssk1328: so, you had a bunch of questions | 07:23 |
| ssk1328 | Yeah | 07:23 |
| mithro | ssk1328: I'd also like to chat about what you are working on and better ways to get started | 07:23 |
| ssk1328 | Yeah sure | 07:24 |
| ssk1328 | Past few days have been a bit slow | 07:24 |
| ssk1328 | So I am trying to figure out how the firmware C code works | 07:24 |
| ssk1328 | I started with hdmi_in | 07:24 |
| mithro | ssk1328: so, the best way to do something like "figure out how the firmware C code works" is to have some goal you are trying to achieve | 07:24 |
| mithro | ssk1328: Just "reading code" tends to be pretty unhelpful and easy to get distracted | 07:25 |
| ssk1328 | Yeah so my goal was to understand where exactly the linear mixer block will fit in this | 07:25 |
| ssk1328 | So I figured out that, hdmi_in and pattern stores the pixel value in predefined memory locations | 07:26 |
| mithro | ssk1328: I think that might be quite a big challenge to start with, I'd recommend trying something a lot simpler | 07:26 |
| ssk1328 | What do you recommend? | 07:27 |
| mithro | ssk1328: Where you working on the heart beat pixel thing? | 07:27 |
| ssk1328 | Yeah, I was but haven't been looking in that now | 07:27 |
| mithro | ssk1328: I think having a very simple goal like doing that would be a good way to get familiar with the firmware | 07:28 |
| ssk1328 | Ok | 07:28 |
| ssk1328 | But then again I need to figure the some parts of the code | 07:29 |
| mithro | ssk1328: but you can ignore a lot of the code now | 07:29 |
| ssk1328 | Yeah, there is a lot of timing stufff that tends to go over my head | 07:29 |
| mithro | ssk1328: what you are looking for now is code which gets triggered when an output device needs a new frame of data | 07:30 |
| ssk1328 | I guess hdmi_out is for that job | 07:31 |
| cr1901_modern | mithro: When I attempt to use my code in HMDI2USB, I'm getting a weird clock domain error that didn't exist previously (despite same source, just different imports). Debugging now | 07:31 |
| mithro | cr1901_modern: just upload something that isn't working | 07:32 |
| mithro | cr1901_modern: then fix it :P | 07:32 |
| ssk1328 | mithro: Also hdmi_out uses i2c functions to write to output hdmi device, I was confused about where exactly is this pixel data for output stored | 07:35 |
| mithro | ssk1328: For HDMI output, the I2C isn't really used | 07:36 |
| mithro | ssk1328: I2C is used for reading / providing configuration information | 07:36 |
| ssk1328 | Ohh, okay | 07:36 |
| mithro | This whole system could in theory work without any I2C stuff at all (but it wouldn't be Plug-n-Plug) | 07:37 |
| ssk1328 | Okay | 07:37 |
| mithro | ssk1328: ideally on a HDMI output, we should use I2C to read the data from the monitor and check that we are going to send it compatible data | 07:38 |
| ssk1328 | I was actually trying to find the part of code that takes pixel data from memory say 0x01000000 for hdmi_in, and takes it to hdmi_out | 07:38 |
| mithro | ssk1328: currently we just assume that monitor is going to work :P | 07:38 |
| ssk1328 | Okay | 07:39 |
| *** rohitksingh has joined #timvideos | 07:39 | |
| mithro | ssk1328: so, I believe (but you should check) there is a DMA hardware block which will read the data from the memory and send it to the hdmi_out core | 07:40 |
| mithro | ssk1328: have you seen https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/doc/architecture.png ? | 07:40 |
| tpb | Title: HDMI2USB-misoc-firmware/architecture.png at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 07:40 |
| ssk1328 | Yeah, a lot of times actually | 07:40 |
| mithro | ssk1328: Do you know what a DMA engine is / does? | 07:41 |
| ssk1328 | guessed direct memory access according to full form | 07:42 |
| ssk1328 | Not in detailed | 07:42 |
| mithro | A DMA engine is basically something which read from location X and then writes it to location Y | 07:43 |
| ssk1328 | Okay | 07:43 |
| mithro | Normally after reading from location X and writing to location Y it will then increment one or the other location | 07:44 |
| mithro | the locations are also sometimes "internal" to the DMA engine and not exposed | 07:44 |
| ssk1328 | Okay | 07:45 |
| ssk1328 | Is the function of dma identical at hdmi_in and hdmi_out locations in our case | 07:46 |
| mithro | A generic DMA engine can frequently be used to copy memory from one location to another memory location without the CPU having to be involved | 07:46 |
| mithro | ssk1328: I'm unsure, I know a lot more of the theory than how our system is actually implemented | 07:46 |
| cr1901_modern | mithro: https://github.com/cr1901/freq_count Look at this repo for changes. Right now, I've only uploaded the code I used for testing | 07:47 |
| tpb | Title: GitHub - cr1901/freq_count: Migen/MiSoC frequency counter, based on ideas from http://hamsterworks.co.nz/mediawiki/index.php/High_Speed_Frequency_Counter (at github.com) | 07:47 |
| ssk1328 | Point out if I am wrong, in our case cpu is involved in hdmi_in case for storing at appropriate locations, but not in hdmi_out and dma engine directly completes the task | 07:48 |
| cr1901_modern | mithro: Note that this uses the new Migen API- this is deliberate forwards compatibility :P (read: I developed this out-of-tree and I only have the new Migen API installed globally) | 07:49 |
| ssk1328 | mithro: I just readabout dma, cpu might be involved in initiating the memory transfer, and in the actual memory transfer cpu is not involved resulting in freeing of cpu resources. | 07:56 |
| mithro | ssk1328: no, in both the HDMI in and HDMI out case the CPU just "sets up the memory transfer" | 07:56 |
| ssk1328 | mithro: So my question is which function in the C firmware sets up the memory transfer for HDMI_OUT | 07:58 |
| cr1901_modern | mithro: How to use the frequency counter (this step is independent of Migen version): https://github.com/cr1901/freq_count/blob/master/minispartan6_new.py#L33-L36 | 07:59 |
| tpb | Title: freq_count/minispartan6_new.py at master · cr1901/freq_count · GitHub (at github.com) | 07:59 |
| mithro | ssk1328: so, what do you think you are looking for? | 07:59 |
| cr1901_modern | Line 36 is the part that fails when I try to put it into the HDMI2USB tree. I don't have a good reason why it shouldn't (kinda afk) | 08:00 |
| cr1901_modern | should* be failing | 08:00 |
| ssk1328 | mithro: So for the heartbeat thing I need to know, that the pixel I am copying is from which location of the image. (Because I need to change pixel values of some pixels in bottom right corer to beating red). | 08:04 |
| mithro | ssk1328: let's start with changing any pixel and then go with trying to figure out the bottom right corner | 08:04 |
| tumbleweed | mithro: pong | 08:04 |
| mithro | tumbleweed: so, I saw a lot of mention about SDI in the debconf-video channel | 08:05 |
| tumbleweed | yep | 08:05 |
| *** rohitksingh has quit IRC | 08:05 | |
| mithro | tumbleweed: I'm pretty sure that SDI is the wrong solution to your problems | 08:06 |
| ssk1328 | mithro: Yeah, lets start with that. How exactly can I do that using the C code? | 08:06 |
| tumbleweed | mithro: it seems to be the most convenient way to do vocto with the least number of computers (long SDI cable runs are easy) | 08:07 |
| mithro | tumbleweed: actually, "long SDI cable runs are easy" is going to bite you | 08:08 |
| mithro | tumbleweed: my biggest question is, "when the SDI cable doesn't work, what do you do?" | 08:08 |
| cr1901_modern | not "if" :P? | 08:09 |
| tumbleweed | what kind of failure mode are you talking about? | 08:09 |
| mithro | tumbleweed: you plug in the SDI cable and things are not working | 08:09 |
| tumbleweed | doesn't that eually apply to any other connection? | 08:09 |
| mithro | tumbleweed: well, if you were using Ethernet / Cat 5, I'm sure you have the ability to do some type of diagnostics | 08:10 |
| *** rohitksingh has joined #timvideos | 08:11 | |
| mithro | tumbleweed: also, at the last minute if you don't have enough SDI cables - can you get more quickly? | 08:12 |
| tumbleweed | mithro: for a physical cable, you can do similar diagnostics on coax. You just might not have the right gear at hand | 08:12 |
| mithro | tumbleweed: yeah, if you were a professional you'd have a "SDI cable tester" or something | 08:12 |
| tumbleweed | they're easy enough to make up, too - with the right crimper | 08:12 |
| tumbleweed | so, yes, at that level, cat 5e is easier | 08:13 |
| tumbleweed | but every camera with internet will do it differently | 08:13 |
| *** Bertl_zZ is now known as Bertl | 08:13 | |
| tumbleweed | and we haven't bought any such cameras, yet | 08:13 |
| tumbleweed | err with ethernet, not with internet :P | 08:13 |
| mithro | tumbleweed: any camera you have can be converted to a "ethernet camera" with a computer, right? | 08:14 |
| *** rohitksingh1 has joined #timvideos | 08:14 | |
| tumbleweed | yes, but then we've got to transport more gear around | 08:14 |
| tumbleweed | we have cameras with SDI | 08:14 |
| tumbleweed | and CCC is reporting great success with SDI | 08:14 |
| tumbleweed | so, we're giving it a shot | 08:14 |
| *** rohitksingh has quit IRC | 08:15 | |
| mithro | tumbleweed: The CCC has a bit more access to stuff than the rest of us | 08:15 |
| tumbleweed | and if, given that, they selected SDI, doesn't that inspire any confidence in it being a reasonable approach? | 08:16 |
| tumbleweed | if long SDI cable runs are easy (and I agree, we don't know that ourselves, yet) then SDI has the advantage of ubiquitous cameras, and the possibility of only needing one computer per room | 08:18 |
| tumbleweed | we have to ship our gear to every event, so the less we ship, the cheaper | 08:18 |
| tumbleweed | (and the less computers to go wrong, the easier) | 08:18 |
| mithro | tumbleweed: 30m SDI cables are a lot heavier than small computers | 08:19 |
| tumbleweed | right, but you can make those up on site, too | 08:19 |
| tumbleweed | HDMI2Ethernet would also fit our needs very well | 08:19 |
| mithro | tumbleweed: then you run into the problem is that you need to be reasonably sure that the cables you make don't suck :P | 08:19 |
| tumbleweed | and I suspect SDI cables wolud go missing from our equipment less frequently than laptops :P | 08:20 |
| mithro | tumbleweed: Have a chat with network guys about how much dodgy cables cause them issues :P | 08:20 |
| tumbleweed | right now, we're reasonably sure that all our firewire cables suck | 08:21 |
| mithro | tumbleweed: If you are shipping SDI cables, your cost argument doesn't really make sense. If you are making the cables onsite then you are going to need some good diagnostic tools. | 08:21 |
| ssk1328 | mithro: So for changing any pixel, for example in the pattern.c file there is framebuffer variable which stores all the pixel values, while copying the pixel values to this variable we can make appropriate changes. Is this correct? | 08:22 |
| tumbleweed | I'm not convinced the diagnostic tools are required - but I also have no experience with these, yet | 08:22 |
| mithro | tumbleweed: I'm pretty sure that SDI cables are not an order of magnitude more reliable than Ethernet cables of similar length | 08:24 |
| tumbleweed | and I find ethernet cables to be pretty reliable | 08:25 |
| tumbleweed | if there's aproblem, it's usually immediately obvious | 08:25 |
| mithro | tumbleweed: so, I'm just going off experience with long Ethernet cables at conferences like LCA | 08:25 |
| tumbleweed | and fixed by a recrimp or two | 08:25 |
| mithro | tumbleweed: so, it's too late for the next debconf | 08:25 |
| tumbleweed | I've never needed the fancy ethernet cable testers | 08:26 |
| tumbleweed | just successfully negotiating gigabit is usually a pretty good sign that the cable is fine | 08:26 |
| tumbleweed | and the basic continuity testers seem good enough, too | 08:27 |
| mithro | ssk1328: I'm not sure I understand | 08:27 |
| mithro | tumbleweed: but my general argument is that "Ethernet is cheap, ubiquitous and well understood by everyone" verse "SDI is expensive and only understood by a small number of people" | 08:27 |
| tumbleweed | mithro: yep, but getting the video onto ethernet adds complexity | 08:28 |
| tumbleweed | I'd much prefer ethernet to SDI, but until you can plug ethernet into the camera, you can't directly compare them | 08:29 |
| mithro | tumbleweed: I think you guys are trading a known set of complexity for an unknown one | 08:30 |
| tumbleweed | we are | 08:30 |
| mithro | tumbleweed: Why? You must believe the unknown one is significantly less effort than the known one? | 08:30 |
| tumbleweed | there are unknowns on both sides | 08:31 |
| tumbleweed | you're jsut talking about one component of the stack | 08:31 |
| tumbleweed | but that defines bits of the rest of the stack, nad there are unknowns there too | 08:31 |
| tumbleweed | so, if you use ethernet for your long runs | 08:32 |
| ssk1328 | mithro: So what I am trying to do is change pixel values while copying pixel data from hdmi input to output. Now if we select pattern as the source for lets say hdmi_out0, the pattern.c file is storing appropriate pixel values in framebuffer variable. So if am able to change pixel values of the variable framebuffer this can do the job. Correct? (Why I am | 08:32 |
| ssk1328 | talking about pattern as source here instead of hdmi_in is because I figured out the framebuffer variable defined in pattern.c file) | 08:32 |
| tumbleweed | you have to capture video from the camera | 08:32 |
| tumbleweed | that means HDMI->SDI + blackmagic or HDMI into blackmagic or SDI into blackmagic | 08:33 |
| tumbleweed | or HD firewire (ick) | 08:33 |
| tumbleweed | or opsis, which we don't have enough of, and can't do audio | 08:34 |
| mithro | ssk1328: okay, yes that is correct | 08:34 |
| ssk1328 | mithro: So on the similar lines I can do the same for hdmi_in as well. Correct? | 08:37 |
| mithro | ssk1328: so, somewhere in the code it is telling the hdmi_out to use the pattern frame buffer as the source, right? | 08:38 |
| mithro | ssk1328: find that first | 08:38 |
| ssk1328 | mithro: But there is not explicit framebuffer variable in hdmi_in files, so I was not sure how to do this for hdmi_in | 08:38 |
| tumbleweed | mithro: oh, and multiple HD streams into the mixing computer quickly gets bigger than a gigabit NIC can handle, so you either need multiple ones, or a 10gig NIC + switch in the room | 08:38 |
| mithro | tumbleweed: you are currently doing a blackmagic card per SDI stream? | 08:39 |
| ssk1328 | mithro: Yeah I found that in the main.c file. | 08:39 |
| ssk1328 | #ifdef CSR_HDMI_OUT0_BASE | 08:39 |
| ssk1328 | processor_set_hdmi_out0_source(VIDEO_IN_PATTERN); | 08:39 |
| ssk1328 | #endif | 08:39 |
| tumbleweed | mithro: you say currently - this is going to be the first time we've ever done it :P | 08:39 |
| mithro | ssk1328: nope! | 08:40 |
| tumbleweed | but yes, that'd be the plan | 08:40 |
| mithro | tumbleweed: How is that different than a Gigabit Ethernet card per stream? | 08:40 |
| tumbleweed | more complexity | 08:40 |
| mithro | tumbleweed: SDI card == horrible complex and poorly understood verse gigabit ethernet card == extremely simple and well understood | 08:44 |
| tumbleweed | mithro: right, but you aren't advocating dropping the SDI cards | 08:44 |
| tumbleweed | you're advocating moving them closer to the cameras | 08:44 |
| tumbleweed | we still have to *capture* from the cameras | 08:44 |
| ssk1328 | mithro: Going for lunch, will be back in 30 mins or so. | 08:44 |
| mithro | ssk1328: I probably won't be around then | 08:45 |
| ssk1328 | Later today? | 08:45 |
| mithro | ssk1328: probably not | 08:45 |
| ssk1328 | mithro: Okay, just point me to the right file for above. I suppose processor.c might be used for that. | 08:47 |
| mithro | ssk1328: what does that function do? | 08:48 |
| mithro | tumbleweed: you can already capture from these cameras, right? | 08:49 |
| tumbleweed | what does that question mean? | 08:50 |
| tumbleweed | we currently capture over firewire, into dvswitch. We want to leave all of that behind | 08:50 |
| mithro | tumbleweed: so currently you go "Camera ---Firewire--> dvgrab ---Ethernet---> dvswitch" right? | 08:51 |
| ssk1328 | mithro: The function processor_update sets the source for each of the hdmi_out as per the various CSRs. | 08:52 |
| tumbleweed | mithro: yep | 08:52 |
| tumbleweed | skipping the ethernet for the camera by the mixing desk | 08:52 |
| mithro | tumbleweed: so, first step - replace dvgrab+dvswitch with voctomix ? | 08:53 |
| mithro | ssk1328: that function is one line - take a look at https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/firmware/lm32/processor.c#L485 | 08:53 |
| tpb | Title: HDMI2USB-misoc-firmware/processor.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 08:53 |
| tumbleweed | mithro: right, but you want HD, if your cameras are capable of it. And you don't want to use hdv over firewire, because hd over firewire is already too unreliable for us | 08:55 |
| mithro | tumbleweed: well, first you want to get video over not getting any video :) | 08:55 |
| tumbleweed | firewire has that undebuggable quality you describe | 08:55 |
| mithro | Yes | 08:56 |
| mithro | HDMI also has that quality I describe for the moment | 08:56 |
| mithro | I'm actually currently working on making that less so right now | 08:56 |
| ssk1328 | mithro: Okay I understand this. But this just sets the source for hdmi_out0. | 08:56 |
| ssk1328 | mithro: Which part of the code copies pixel data from source to hdmi_out0 | 08:57 |
| mithro | ssk1328: it sets a single variable to an int value, so next thing is to figure out where that value is used | 08:57 |
| ssk1328 | Yeah | 08:57 |
| ssk1328 | In the processor_update function | 08:58 |
| ssk1328 | https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/firmware/lm32/processor.c#L511 | 08:59 |
| tpb | Title: HDMI2USB-misoc-firmware/processor.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 08:59 |
| mithro | ssk1328: okay, follow that down | 09:00 |
| ssk1328 | Things seem to be clearing up now. | 09:00 |
| mithro | ssk1328: you know how to use grep, right? | 09:03 |
| ssk1328 | Haven't used before :( I am using ctrl+f in each file to find the specific instances of a particular function or variable | 09:04 |
| mithro | ssk1328: you should learn grep | 09:04 |
| mithro | ssk1328: otherwise you will never find where "hdmi_out0_fi_base0_write" is defined | 09:05 |
| ssk1328 | Sure thing. | 09:05 |
| mithro | grep -R "hdmi_out0_fi_base0_write" . | 09:05 |
| ssk1328 | Can't test that right now, I am on windows, my Ubuntu is overheating and randomly shuts down the laptop. But will surely check that out. | 09:08 |
| ssk1328 | One more thing, why the multiplication with 2 here, https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/firmware/lm32/hdmi_in0.c#L24 | 09:09 |
| tpb | Title: HDMI2USB-misoc-firmware/hdmi_in0.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 09:09 |
| mithro | ssk1328: how big is a pixel? | 09:09 |
| ssk1328 | 3*8bit values = 24 bit per pixel? | 09:10 |
| *** G33KatWork has quit IRC | 09:10 | |
| mithro | ssk1328: in RGB with 8bits per pixel | 09:11 |
| *** G33KatWork has joined #timvideos | 09:12 | |
| ssk1328 | mithro: I guess this is different for YCbCr | 09:12 |
| mithro | ssk1328: yeah | 09:13 |
| mithro | ssk1328: https://github.com/timvideos/HDMI2USB-misoc-firmware/tree/master/gateware/csc | 09:13 |
| tpb | Title: HDMI2USB-misoc-firmware/gateware/csc at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 09:13 |
| ssk1328 | Okay, will figure that out. | 09:15 |
| ssk1328 | Also, https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/firmware/lm32/hdmi_in0.c#L20 | 09:16 |
| tpb | Title: HDMI2USB-misoc-firmware/hdmi_in0.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 09:16 |
| ssk1328 | Any significance of number 4 here | 09:16 |
| ssk1328 | I understand this defines we can store 4 frames of 1920*1080 | 09:16 |
| mithro | ssk1328: that I'm unsure of | 09:17 |
| mithro | ssk1328: I think because you have 3 potential outputs | 09:17 |
| mithro | ssk1328: each output could have a frame buffer "locked" so you need one more buffer to write into | 09:18 |
| mithro | ssk1328: but I could be totally wrong there | 09:18 |
| ssk1328 | mithro: The 3 potential output you talk about is Y, Cb and Cr. Correct? | 09:19 |
| mithro | ssk1328: no | 09:19 |
| mithro | ssk1328: hdmi_out0, hdmi_out1, encoder | 09:19 |
| ssk1328 | mithro: Okay. So the fourth one might be just an extra, for us to add more outputs | 09:20 |
| ssk1328 | Or extra buffer for the new frame inputs arriving. | 09:21 |
| mithro | ssk1328: you might want to look at https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/gateware/hdmi_out/format.py#L65 and http://labs.domipheus.com/blog/designing-a-cpu-in-vhdl-part-11-vram-and-hdmi-output/ | 09:21 |
| tpb | Title: HDMI2USB-misoc-firmware/format.py at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 09:21 |
| mithro | ssk1328: the second one I think | 09:21 |
| mithro | ssk1328: as you don't want to modify a frame while it is being output | 09:22 |
| mithro | ssk1328: and https://github.com/mithro/tmds_encoding/blob/master/vga.py which I've actually been working on today | 09:22 |
| tpb | Title: tmds_encoding/vga.py at master · mithro/tmds_encoding · GitHub (at github.com) | 09:22 |
| ssk1328 | mithro: Will look into all this today. | 09:24 |
| mithro | ssk1328: so, it looks like there might not be a trigger on the hdmi output in the C code | 09:26 |
| ssk1328 | mithro: I guess so | 09:28 |
| mithro | ssk1328: but there is one for the HDMI input you just saw, right? | 09:28 |
| ssk1328 | trigger as in something which initiates the HDMI input code? | 09:30 |
| mithro | ssk1328: you pointed me to https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/firmware/lm32/hdmi_in0.c#L20 | 09:30 |
| tpb | Title: HDMI2USB-misoc-firmware/hdmi_in0.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 09:30 |
| ssk1328 | Yeah? | 09:31 |
| mithro | ssk1328: see the hdmi_in0_isr | 09:32 |
| ssk1328 | mithro: Okay, so the trigger is the calling of hdmi_in0_isr function | 09:35 |
| ssk1328 | and function later call the processor_update function which connects the output to specific input | 09:36 |
| *** se6astian|away is now known as se6astian | 09:43 | |
| mithro | ssk1328: what do you mean by "trigger"? | 09:43 |
| mithro | ssk1328: when you make a statement, make sure you have some proof to back it up :) | 09:43 |
| ssk1328 | mithro: be back in 10mins | 09:45 |
| _florent_ | mithro: sorry, I'm there now | 10:07 |
| mithro | _florent_: Couple of questions | 10:42 |
| mithro | _florent_: (a) Where are we at with "porting to the new migen/misoc" (and what do we actually mean by that?) | 10:43 |
| mithro | _florent_: (b) What state is liteDRAM in and can you help me fill in some remaining stats in my spreadsheet at https://docs.google.com/spreadsheets/d/1q5CUI289TjGw9c66wAesOHlvH8RVo-OK6_yJ4btzZPA/edit#gid=150757850 | 10:43 |
| tpb | Title: lite* Supported boards & Interfaces - Google Sheets (at docs.google.com) | 10:44 |
| mithro | _florent_: (c) I have code which should generate a "hdmi bit stream" from pixel data - how should we hook that up to the simulator / use it to test the HDMI module? | 10:46 |
| mithro | _florent_: (d) I'm assuming that we haven't made any progress on the HDMI over GTP situation | 10:47 |
| cr1901_modern | mithro: I'm not florent, but... I can give some insight (a). Porting to the new migen SHOULD be as simple as changing imports. It's porting to the new MiSoC that I suspect is more difficult, b/c the way that targets are build was completely overhauled. | 10:52 |
| mithro | cr1901_modern: Yes, it's more complicated - _florent_ has been doing some work on it | 10:52 |
| cr1901_modern | The problem is that a lot of stuff in the old migen got moved to the new misoc, so it's kinda tightly coupled :/ | 10:52 |
| cr1901_modern | I'm happy to help _florent_ work on this in the interim if it'll expediate the process | 10:54 |
| cr1901_modern | expedite* bleh | 10:54 |
| mithro | ssk1328: any last questions before I go in search for dinner? | 10:56 |
| _florent_ | mithro: (a) I think it was alsmost done (opsis-soc was working), I started some refactoring around others things (LiteDRAM, LiteVideo) that I have to finish, going to work on that today | 10:56 |
| mithro | _florent_: That doesn't include the Atlys board though, right? | 10:57 |
| mithro | _florent_: (nor the miniSpartan6+)? | 10:57 |
| _florent_ | mithro: (b) LiteDRAM is working, I just want to add asynchronous and variable width ports and then use it in the HDMI2USB design (would avoid doing that for each DRAM port we use) | 10:58 |
| _florent_ | mithro: (a) yes only opsis now, I'd like to get some help maintaining others targets if possible once opsis will be working | 10:58 |
| mithro | _florent_: When you say "LiteDRAM is working" - obviously you haven't tested on an Atlys recently because you destroyed yours, right? | 10:59 |
| _florent_ | It's working on Opsis/Nexys/Arty/KC705, I don't think there will be problem with Atlys | 10:59 |
| _florent_ | but yes, while porting to new API, we have to revalidate everything with incremental steps | 11:00 |
| mithro | _florent_: with liteDRAM you were mentioning adding a whole bunch more tests? | 11:01 |
| _florent_ | yes going to do that too | 11:01 |
| _florent_ | it just takes a bit of time :) | 11:02 |
| mithro | _florent_: going too, or have already? | 11:02 |
| _florent_ | I already rewritten the DMA Generator/Checker | 11:02 |
| _florent_ | now I need to improve it | 11:02 |
| _florent_ | and create more complex tests | 11:02 |
| _florent_ | (c) for HDMI in simulation, you can try hacking code here: https://github.com/enjoy-digital/litex/blob/master/litex/build/sim/dut_tb.cpp#L192 | 11:03 |
| mithro | _florent_: does it make sense to use the micron DDR models in verilator running setup and then memtest like operations? | 11:03 |
| tpb | Title: litex/dut_tb.cpp at master · enjoy-digital/litex · GitHub (at github.com) | 11:03 |
| _florent_ | it's for vga and can be probably be adapted for HDMI | 11:03 |
| mithro | _florent_: this is input rather than output, but I guess I also have output code too | 11:04 |
| _florent_ | mithro: for input yes it would be a bit similar | 11:05 |
| _florent_ | mithro: for serial and ethernet we are doing input | 11:05 |
| _florent_ | mithro (d): no, not yet | 11:06 |
| mithro | _florent_: this is kind of where I'm at with the tmds_encoding -> https://github.com/mithro/tmds_encoding/blob/master/vga.h#L37 | 11:08 |
| tpb | Title: tmds_encoding/vga.h at master · mithro/tmds_encoding · GitHub (at github.com) | 11:08 |
| mithro | _florent_: I use some Python code to generate a lookup table - means it should be pretty fast | 11:09 |
| *** rohitksingh1 has quit IRC | 11:10 | |
| *** rohitksingh has joined #timvideos | 11:11 | |
| mithro | _florent_: for (b) - I'd like to fill in all the red squares | 11:14 |
| mithro | _florent_: so, for (a) - what are our next steps? | 11:15 |
| mithro | ssk1328: btw - Did you see http://librecores.org/designcontest ? | 11:16 |
| tpb | Title: LibreCores (at librecores.org) | 11:16 |
| mithro | _florent_: BTW Any idea how to the memory on a Zynq is connected up / how the FPGA can access it? | 11:17 |
| _florent_ | mithro: on the Zynq you memory is connected through AXI | 11:28 |
| _florent_ | mithro: for (b), ok I'll have a look | 11:28 |
| _florent_ | mithro: for (a) I'm going to work on this afternoon, but I'm going to lunch, see you later | 11:29 |
| *** rohitksingh has quit IRC | 11:41 | |
| *** rohitksingh has joined #timvideos | 12:13 | |
| *** CarlFK has quit IRC | 12:33 | |
| *** ssk1328 has quit IRC | 12:33 | |
| *** se6astian is now known as se6astian|away | 12:55 | |
| *** Bertl is now known as Bertl_oO | 14:14 | |
| *** rohitksingh has quit IRC | 14:33 | |
| *** sb0 has joined #timvideos | 14:47 | |
| *** rohitksingh has joined #timvideos | 15:37 | |
| *** rohitksingh has quit IRC | 16:56 | |
| *** rohitksingh has joined #timvideos | 17:07 | |
| *** se6astian|away is now known as se6astian | 17:23 | |
| *** rohitksingh has quit IRC | 17:27 | |
| *** rohitksingh has joined #timvideos | 18:03 | |
| *** rohitksingh has quit IRC | 18:20 | |
| *** ssk1328 has joined #timvideos | 18:21 | |
| *** kaalikahn has quit IRC | 18:37 | |
| *** tariq786 has joined #timvideos | 18:42 | |
| *** rohitksingh has joined #timvideos | 19:11 | |
| *** rohitksingh has quit IRC | 19:14 | |
| ssk1328 | mithro: Will be back with few more questions tomorrow. Haven't heard of this competition though, can I submit my gsoc designs for the competition? | 20:32 |
| *** sb0 has quit IRC | 20:38 | |
| *** puck has joined #timvideos | 21:03 | |
| *** se6astian is now known as se6astian|away | 21:22 | |
| *** Bertl_oO is now known as Bertl_zZ | 23:12 | |
| *** ssk1328 has quit IRC | 23:23 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
