| *** tpb has joined #timvideos | 00:00 | |
| CarlFK | xfxf: new problem - if we use firewire, how do we get audio? | 00:07 |
|---|---|---|
| xfxf | CarlFK: the same way, ALSA? | 00:08 |
| CarlFK | I just showed deeprave my ... alsa mux client stuff, he is going to try to add that to your fw script | 00:08 |
| xfxf | it won't be hard to change | 00:08 |
| xfxf | there's two ways to do it | 00:16 |
| xfxf | actually i'm pretty sure i can make what needs to happen | 00:17 |
| xfxf | i'll do it now and commit up | 00:17 |
| xfxf | i obv can't test tho | 00:17 |
| deeprave | i can though | 00:28 |
| xfxf | https://github.com/xfxf/video-scripts/tree/master/ryan/lca/other/firewire-capture | 00:28 |
| tpb | Title: video-scripts/ryan/lca/other/firewire-capture at master · xfxf/video-scripts · GitHub (at github.com) | 00:28 |
| xfxf | haven't tested them but they should be a start | 00:28 |
| xfxf | also in tim's directly he had a version of the alsa only script that tee'd off the audio and pushed it into a video generator which showed a waveform | 00:29 |
| xfxf | it's probably a good idea if not too computationally expensive | 00:29 |
| xfxf | (obviously watch CPU with all of this too, should never exceed 80% - DV on the i5's for me was eating up a lot, i couldn't run voctocore/voctomix/DV on the same i5...) | 00:29 |
| xfxf | s/directly/directory/ | 00:30 |
| xfxf | if the scripts don't make sense, ask Tim to show you what he showed me a few nights ago, that plus playing with a few pipelines and i now kinda grok how it all works | 00:31 |
| CarlFK | xfxf: why? | 00:37 |
| xfxf | why wht | 00:37 |
| xfxf | what* | 00:38 |
| CarlFK | why write video generator which showed a waveform | 00:38 |
| xfxf | it's not required, but it's just a nice to have tim added | 00:38 |
| xfxf | i believe the logic is to show the source has audio visually | 00:39 |
| xfxf | but the VU meter also achieves that | 00:39 |
| CarlFK | I don't see that being used. | 00:39 |
| xfxf | if doing this seperate ALSA thing i'd suggest putting the ALSA source first anyway, like we did with dvswitch, so it's the default one chosen | 00:39 |
| xfxf | a step of 'select the audio source' is another thing volunteers will forget | 00:39 |
| xfxf | CarlFK: you'll observe i didn't add it to my script, i dunno why you're arguing that with me :) | 00:40 |
| CarlFK | that would be 3 streams over cat5. | 00:40 |
| xfxf | not at all | 00:40 |
| xfxf | you run that on the voctocore/mix machine... | 00:40 |
| CarlFK | well, ok. still not sure why | 00:40 |
| xfxf | i'm happy if it's muxed in with the DV source, all i'm giving you guys are options for testing | 00:40 |
| CarlFK | "if the scripts don't make sense, ask Tim..." <- that is direction to do something. not "if you are bored and run out of things to do.. bother tim so he stops doing what he is doing." | 00:42 |
| CarlFK | so stop that | 00:42 |
| xfxf | why are you being argumentative, i'm not doing anything that opposes you | 00:43 |
| xfxf | if you don't want my scripts, shrug, fine - i'm attempting to help. please be positive | 00:44 |
| CarlFK | yes you are | 00:44 |
| CarlFK | tumbleweed says 682Mbs is coming into the core from 2 clients | 00:54 |
| mithro | xfxf: what is your work address? | 01:41 |
| *** rohitksingh has joined #timvideos | 05:03 | |
| mithro | _florent_: ping me when you get up / ready to work | 06:05 |
| tumbleweed | CarlFK: /etc/openntpd/ntpd.conf | 07:12 |
| tumbleweed | CarlFK: content: server $NAME (repeat times n) | 07:12 |
| *** Bertl_zZ is now known as Bertl | 07:13 | |
| micolous | uhh | 07:26 |
| micolous | these have isc dhcp | 07:26 |
| micolous | err ntp | 07:26 |
| *** hyades has joined #timvideos | 08:00 | |
| cr1901_modern | _florent_: Ping? | 08:00 |
| cr1901_modern | _florent_: I could use a second pair of eyes on this. This is the core to a frequency counter w/ FIFO storage. Before I try hooking it up to the CSR bus, do you see anything egregious? https://gist.github.com/cr1901/7dd73f989bada9c01c27 | 08:55 |
| tpb | Title: Migen Frequency Counter · GitHub (at gist.github.com) | 08:55 |
| *** hyades has quit IRC | 10:10 | |
| _florent_ | mithro/cr1901_modern: pong | 10:14 |
| mithro | morning _florent_ | 10:14 |
| _florent_ | evening :) | 10:15 |
| _florent_ | ok, so what are the news? | 10:15 |
| mithro | _florent_: I fixed the ROM problem | 10:17 |
| mithro | _florent_: and the version info problem | 10:17 |
| mithro | _florent_: It appears that the HV30 you have is in NTSC mode, while everything here is in PAL mode | 10:18 |
| mithro | _florent_: I switched my HV30 (also tested HV20) to NTSC mode and then got this -> | 10:18 |
| mithro | _florent_: https://goo.gl/photos/icLZAX5t7CnN12GD9 | 10:19 |
| _florent_ | are you testing with both Opsis and Atlys? or just Opsis? | 10:19 |
| mithro | _florent_: mainly Opsis, just about to try with an Atlys board | 10:20 |
| _florent_ | because I don't understand why there are some differences between Opsis and Atlys boards with some camera | 10:20 |
| cr1901_modern | _florent_: Hi. I'm here. Just wanted a second pair of eyes on my freq counter. Although it seems the problem is solved :O? | 10:25 |
| _florent_ | cr1901_modern: yes I'm looking at the code | 10:26 |
| _florent_ | why are you using a fifo? | 10:26 |
| _florent_ | here is something I use on another design: | 10:27 |
| _florent_ | http://pastebin.com/TDRtmBK5 | 10:27 |
| tpb | Title: [Python] class FrequencyMeasurement(Module, AutoCSR): def __init__(self, pulse): - Pastebin.com (at pastebin.com) | 10:27 |
| mithro | _florent_: with the version info being incorrect, it was hard to understand what firmware versions the Atlys/Opsis are using | 10:27 |
| _florent_ | ok | 10:27 |
| mithro | _florent_: I'm still trying to get an Atlys onto the exact same firmware we have been testing the Opsis with | 10:28 |
| mithro | _florent_: should have it working in the next 10-15 minutes | 10:28 |
| _florent_ | ok | 10:28 |
| _florent_ | I'm just trying to understand why we have different behaviour | 10:29 |
| mithro | _florent_: Yes, so am I :) | 10:29 |
| _florent_ | so for the HV30, you are going to use it in PAL right? | 10:29 |
| mithro | _florent_: That is the current plan, but its open to discussion | 10:30 |
| mithro | _florent_: It is easy to switch back and forth between the two versions now I've figured out how | 10:30 |
| cr1901_modern | _florent_: The idea w/ a FIFO was to be able to take a sliding average every so often w/o needing to use the CPU to move data to main memory | 10:31 |
| _florent_ | ok, but we have to use very little ressource for that since we already have problem getting P&R done | 10:32 |
| cr1901_modern | Very well, I'll get rid of it | 10:32 |
| _florent_ | it's probably better to just have a register where the cpu can take actual frequency from time to time | 10:32 |
| mithro | _florent_: would it free up resources to punt the firmware rom onto the SPI flash | 10:32 |
| mithro | _florent_: I'd like to know if the frequency duty cycle isn't even too | 10:33 |
| cr1901_modern | Well, we need multiple freq counters, so we need multiple registers | 10:33 |
| _florent_ | mithro: yes, but that would only save blockrams | 10:34 |
| _florent_ | what do you mean by : "the frequency duty cycle isn't even too"? | 10:34 |
| _florent_ | cr1901_modern: yes of course, one frequency counter for each measure we want to do | 10:35 |
| mithro | _florent_: if the positive period is longer or shorter then the negative period | 10:35 |
| cr1901_modern | I forget exactly how to do this, but I seem to recall that old Migen has a BankArray class for combining very similar registers into a single module on the CSR bus? | 10:36 |
| _florent_ | you can just create registers with CSR/CSRStorage/CSRStatus | 10:37 |
| cr1901_modern | I'll need to make my own test signals since minispartan HDMI isn't ready yet | 10:39 |
| cr1901_modern | mithro: Where should I put the freq counter module? I was thinking under gateware/hdmi_in/analysis? | 10:39 |
| cr1901_modern | I can try to synthesize HDMI2USB on the minispartan as well, so I can test w/ real signals. Right now, all I can do is get to the MiSoC BIOS b/c I haven't figured out how to use flterm.py yet | 10:40 |
| *** se6astian|away is now known as se6astian | 10:41 | |
| cr1901_modern | _florent_: Your version of the freq counter gets the period. Is that gonna work w/ signals as fast as HDMI? | 10:42 |
| cr1901_modern | My version gets the frequency (divided by a constant factor) | 10:42 |
| _florent_ | i think it's enough to get a period, since the cpu is aware of the frequency it saves ressources letting the cpu computing the frequency | 10:44 |
| _florent_ | but you can keep your version | 10:45 |
| _florent_ | we'll do something simpler only if needed | 10:45 |
| mithro | _florent_: I'd really like to improve the debugging information we get from the firmware so we can better understand what the differences going on here are | 10:47 |
| cr1901_modern | I don't actually know which way is better lol. I do need to reiterate: I cannot actually test the freq counters w/ HDMI2USB. What I can do is synthesize signals from a separate FPGA of known freqs, and test via the MiSoC BIOS (which hopefully will be out of phase as well as not the same freq) | 10:47 |
| mithro | bblr - getting dinner | 10:47 |
| cr1901_modern | _florent_: One last req for advice when you have a minute? | 11:00 |
| mithro | back | 11:20 |
| mithro | _florent_: any idea why the Atlys board has a much harder time then the Opsis with routing? | 11:20 |
| _florent_ | hmm difficult to say, higher system frequency & different DDR controller | 11:21 |
| mithro | _florent_: any reason to not drop the system frequency so the Atlys and Opsis are the same? | 11:22 |
| _florent_ | we could do this now yes since the jpeg encoder is not working asynchronously | 11:23 |
| _florent_ | I've tried reconfiguring my HV30 | 11:23 |
| _florent_ | but I don't have a mini-SD card here... | 11:23 |
| _florent_ | and when plugged to the computer is does nothing | 11:24 |
| _florent_ | when you are in NTSC, do you think we are running the same firmware (on the HV30)? | 11:24 |
| mithro | _florent_: You shouldn't need a mini-SD card | 11:24 |
| _florent_ | hmm at least when I do what you described in the issue, it does nothing | 11:25 |
| mithro | _florent_: Let me check the camera here | 11:25 |
| mithro | _florent_: you turned the dial on the top to the "play" mode and the little switch on the side to the "card" side, right? | 11:25 |
| _florent_ | yes | 11:26 |
| mithro | _florent_: so, what does the screen show? | 11:26 |
| mithro | _florent_: do you have a HV20 (silver) or HV30 (black)? | 11:26 |
| _florent_ | HV30 | 11:26 |
| _florent_ | the screen shows NO SDCARD | 11:27 |
| _florent_ | and then a kind of menu with a sdcard blinking in red | 11:27 |
| _florent_ | the I plug it to my computer and nothing... | 11:27 |
| mithro | _florent_: testing now, give me a moment | 11:28 |
| _florent_ | ok | 11:28 |
| _florent_ | can you try without sdcard? | 11:28 |
| mithro | yes, I'm getting the same here | 11:30 |
| mithro | _florent_: apparently you do need a SD card :( | 11:31 |
| _florent_ | ok | 11:31 |
| _florent_ | but just to understand | 11:31 |
| _florent_ | when you are switching to NTSC | 11:31 |
| seaLne | in camera mode i get hdmi out when connected to a monitor | 11:31 |
| _florent_ | you are using a custom firmware? | 11:31 |
| seaLne | with no sd card | 11:31 |
| _florent_ | hi seaLne: thanks, same for me | 11:32 |
| _florent_ | but I wanted to update the firmware | 11:32 |
| seaLne | ah, so that wasn't what you were wanting then? sorry | 11:32 |
| mithro | _florent_: so - I think the quickest thing is we debug with the NTSC mode | 11:34 |
| mithro | xfxf just confirmed the HV30 he sent you should have the same firmware as the one sitting in front me | 11:34 |
| _florent_ | hmm interesting | 11:34 |
| _florent_ | I realized that when I was doing my test, the little switch was in the tape position | 11:35 |
| _florent_ | when setting it to sdcard it seems the hdmi output is not the same | 11:35 |
| mithro | _florent_: that is the correct position for using the device | 11:35 |
| _florent_ | can you test with switch in tape position? | 11:35 |
| mithro | _florent_: yes | 11:36 |
| mithro | _florent_: can you check which mode the camera is in | 11:36 |
| _florent_ | how can I check that? | 11:36 |
| mithro | _florent_: put the camera in "camera mode" via the top switch | 11:37 |
| mithro | _florent_: put the slide on the side to the tape icon | 11:37 |
| mithro | _florent_: click the func button and use the job switch to go to the bottom item (label menu) | 11:37 |
| mithro | _florent_: then go down to the second icon in the full screen menu "REC/IN SETUP" | 11:38 |
| mithro | The HD Standard option | 11:39 |
| _florent_ | ok I'm there | 11:39 |
| mithro | _florent_: what does it say? | 11:40 |
| _florent_ | it says what I've set :) | 11:40 |
| _florent_ | but all are working | 11:40 |
| _florent_ | with video_mode 12 | 11:40 |
| mithro | _florent_: In NTSC mode, the options are HDV, HDV PF30 and HDV PF24? | 11:40 |
| _florent_ | I have: HDV/HDV(PF30)/HDV(PF24)/DV(WIDE)/DV(NORMAL) | 11:41 |
| mithro | _florent_: yes, I have the same | 11:43 |
| mithro | _florent_: you are using your Opsis board right? | 11:43 |
| _florent_ | yes | 11:43 |
| mithro | _florent_: I'm using an Opsis board too | 11:44 |
| mithro | _florent_: This is what I'm seeing -> https://photos.google.com/photo/AF1QipNEAZupoVT_H81osAGxtIZh28HwtzIVeQR4aa97 | 11:44 |
| tpb | Title: Sign in - Google Accounts (at photos.google.com) | 11:44 |
| mithro | _florent_: This I mean -> https://goo.gl/photos/XNDfvLyxArouuQ8w9 | 11:45 |
| mithro | _florent_: status is showing; | 11:45 |
| mithro | input0: 720x0 | 11:45 |
| mithro | _florent_: so its continually showing 720x0, then 0x0, then occasionally 0x480 or 720x480 | 11:50 |
| _florent_ | that's strange | 11:51 |
| mithro | _florent_: so it seems like it is *almost* in sync | 11:51 |
| _florent_ | here it's always working | 11:51 |
| _florent_ | but I'm not able to test your firmware (I'm using the UART hack with the SD cards pins) | 11:52 |
| mithro | _florent_: whitequark suggested that we could just connect all the RX/TX pins together to get multiple UARTs working? | 11:52 |
| cr1901_modern | _florent_: In MiSoC, I noticed that region 7 of the CSR map is unused. Do you remember what that was used for/if free to override? | 11:53 |
| _florent_ | spare probably | 11:53 |
| mithro | _florent_: As well, the memory bandwidth used seems a bit weird | 11:53 |
| mithro | write: 165Mbps | 11:53 |
| mithro | ddr: read: 657Mbps write: 166Mbps all: 823Mbps | 11:54 |
| _florent_ | yes, maybe having a shared UART can be useful | 11:54 |
| _florent_ | this way I'll be able to test your firmware | 11:54 |
| _florent_ | too bad we don't have a switch on the baor | 11:54 |
| _florent_ | board | 11:54 |
| _florent_ | we could have done a simple uart mux | 11:54 |
| mithro | _florent_: Well, if there is nothing connected to my SD pins, it doesn't matter right? | 11:55 |
| _florent_ | no, but we will need to set a pullup on the pin | 11:56 |
| _florent_ | we can share the UART is we do a AND between the two pins | 11:57 |
| _florent_ | for RX | 11:57 |
| _florent_ | and for TX nothing to do | 11:57 |
| _florent_ | I'm going to do that in a branch | 11:59 |
| mithro | okay | 12:01 |
| mithro | I'm trying to test with an Atlys board | 12:05 |
| cr1901_modern | mithro: In about an hour or so, would you be willing to apply a patch from me to your own personal tree? | 12:08 |
| cr1901_modern | If things go right, I should have this done by this morning. | 12:08 |
| mithro | cr1901_modern: sure | 12:09 |
| mithro | _florent_: okay, this Atlys board works with the camera | 12:09 |
| _florent_ | hmmm | 12:09 |
| _florent_ | I'm really wondering if that's not a hw issue on your opsis | 12:09 |
| _florent_ | I just did that; | 12:10 |
| _florent_ | https://github.com/timvideos/HDMI2USB-misoc-firmware/commit/5aa628227667 | 12:10 |
| tpb | Title: opsis: share uart pads between FX2 and SD card pins · timvideos/HDMI2USB-misoc-firmware@5aa6282 · GitHub (at github.com) | 12:10 |
| _florent_ | with that we should be able to test the same bitstream | 12:10 |
| mithro | _florent_: I can test a different Opsis board - I have 10 here | 12:11 |
| _florent_ | and with others video sources, is this opsis working fine? | 12:12 |
| mithro | I'm testing the exact same setup with a different opsis | 12:13 |
| _florent_ | ok | 12:14 |
| _florent_ | mithro: can you cancel build 411? :), thanks | 12:14 |
| mithro | _florent_: how do we adjust the IODELAY objects in the FPGA? | 12:15 |
| _florent_ | software I think | 12:16 |
| mithro | _florent_: IIRC, errors in the 8B10 encoding cause the delay to be adjusted | 12:17 |
| _florent_ | are there changes on the opsis production board and the one I have around the hdmi inputs? | 12:19 |
| mithro | _florent_: I have my preproduction board here too | 12:23 |
| mithro | _florent_: I'm connecting up my preproduction board here now | 12:28 |
| mithro | _florent_: okay, my preproduction board does the same thing here..... | 12:32 |
| mithro | _florent_: exact same firmware as the production board | 12:32 |
| mithro | mibuild.generic_platform.ConstraintError: Resource not found: serial:None | 12:33 |
| _florent_ | same results with another hdmi cable? | 12:38 |
| mithro | _florent_: Okay, it seems to be dependent on cable and which input I'm using | 12:45 |
| _florent_ | okay (at least we are progressing :) | 12:46 |
| *** tvCommitBot has joined #timvideos | 12:46 | |
| tvCommitBot | [streaming-system] micolous opened pull request #110: Update for LCA2016, more bootstrap (master...master) https://git.io/vzSM9 | 12:46 |
| *** tvCommitBot has left #timvideos | 12:46 | |
| mithro | _florent_: okay, so what I've figured out so far | 12:59 |
| mithro | _florent_: is we have invented a HDMI cable quality tester :P | 12:59 |
| _florent_ | hehe | 13:00 |
| _florent_ | so with others cable it's OK? | 13:00 |
| * seaLne wonders if thats why he has never got any inputs to work... | 13:00 | |
| mithro | _florent_: I have 1 cable which works, and 5 which don't in varying degrees | 13:02 |
| mithro | _florent_: they all seem to work "marginally" as the the picture kind of works at the start of the frame and slowly gets out of sync | 13:03 |
| cr1901_modern | mithro: I got a frequency counter into the verilog code using MiSoC, but for some reason the code that's supposed to generate the addresses that are placed into C headers isn't doing so | 13:03 |
| mithro | _florent_: kind of "drifts" a bit | 13:03 |
| cr1901_modern | Looking into it now | 13:03 |
| cr1901_modern | _florent_: Did you create cpuif? | 13:03 |
| _florent_ | did some change in it | 13:04 |
| cr1901_modern | Hrm... cpuif isn't generating constants for my frequency counter, even though I subclasses AutoCSR and it appears in the Verilog output | 13:04 |
| cr1901_modern | (it == the freq counter module) | 13:04 |
| _florent_ | can you share the code? | 13:05 |
| _florent_ | for modules with autocsr, you cannot do: self.submodules += mymodule, you have to do self.submodules.mymodule = ... | 13:06 |
| mithro | _florent_: another interesting point | 13:08 |
| cr1901_modern | Oh... well that might possibly explain it | 13:08 |
| mithro | _florent_: input 0 seems to be less reliable on *both* the Atlys and the Opsis | 13:08 |
| cr1901_modern | indeed I did the former | 13:08 |
| _florent_ | I'm not able to see that, I probably have high quality cables :) | 13:09 |
| cr1901_modern | _florent_: That fixed it, thanks | 13:11 |
| _florent_ | cool | 13:14 |
| mithro | _florent_: yeah, xfxf buys cheap cables ;-) | 13:16 |
| xfxf | mithro: actually if it's the stripey cables they weren't cheap at all | 13:17 |
| mithro | _florent_: so - its *really* weird that on the Atlys and the Opsis, both input 0 are having issues | 13:17 |
| mithro | _florent_: I'm going to check another Atlys board | 13:17 |
| xfxf | mithro: that said if different cables fixes this i'm happy to buy more | 13:18 |
| _florent_ | mithro/xfxf: it's can also be the hdmi output of the camera that is not very good | 13:19 |
| _florent_ | it will be interesting to test these cables with others video sources | 13:19 |
| _florent_ | and really use validated cables with the hv30 | 13:19 |
| _florent_ | it will also be interesting to test teh XA20 with the "working" cables | 13:21 |
| _florent_ | mithro: | 13:23 |
| _florent_ | "I plug the XA20 into Tim's Digitech 2-way HDMI splitter, plug it into the Opsis, set video_mode to 10 (720p), power cycle the splitter/XA20, and now it works." | 13:23 |
| _florent_ | can you do that also with the HV30? | 13:23 |
| cr1901_modern | Why does CSR only use the LSByte of each 32-bit data word? | 13:32 |
| mithro | cr1901_modern: I was wondering WTF was going on there last night too | 13:32 |
| mithro | cr1901_modern: That confused the hell out of me | 13:32 |
| cr1901_modern | I guess it's to simplifying connections to a 32-bit CPU, but it feels like an utter waste of address space :P | 13:35 |
| _florent_ | because CSR is 8 bits with used with csr_data_width=8 | 13:35 |
| _florent_ | and it reduce ressource to have a 8bit bus | 13:35 |
| mithro | _florent_: okay, with the *best* cable I have here, the Atlys board works fine with the HV30 on input 1, but does not work at all with the HV30 on input 0 | 13:35 |
| _florent_ | strange | 13:35 |
| _florent_ | and with you splitter in between? | 13:35 |
| cr1901_modern | In any case, I'm not reading any data back from the CSR bus... all zeros :( | 13:35 |
| cr1901_modern | so something's wrong | 13:35 |
| _florent_ | HV30 camera --> splitter --> input0? | 13:36 |
| mithro | _florent_: I now have my computer connected to input 0 and not getting anything | 13:38 |
| cr1901_modern | In any case, I have to break for now... be back later | 13:39 |
| mithro | _florent_: it detects the Atlys fine, but the Atlys doesn't see the computer | 13:39 |
| mithro | _florent_: input0 works fine on the Opsis from my laptop | 13:42 |
| _florent_ | but input0 on | 13:44 |
| _florent_ | sorry | 13:44 |
| _florent_ | input0 on atlys is not buffered right? | 13:44 |
| _florent_ | I remember there is a limitation with this input, but I'm not able to remember it | 13:45 |
| mithro | input0 on? | 13:48 |
| _florent_ | not sure | 13:48 |
| _florent_ | can you test build 414 on opsis? | 13:48 |
| _florent_ | it it works with your setup I can merge it | 13:49 |
| _florent_ | (it works here) | 13:49 |
| _florent_ | https://github.com/timvideos/HDMI2USB-firmware-prebuilt/blob/master/archive/v0.0.0-580-g9ac8965/opsis/hdmi2usb/opsis_hdmi2usb-hdmi2usbsoc-opsis.bit | 13:49 |
| tpb | Title: HDMI2USB-firmware-prebuilt/opsis_hdmi2usb-hdmi2usbsoc-opsis.bit at master · timvideos/HDMI2USB-firmware-prebuilt · GitHub (at github.com) | 13:49 |
| mithro | input0 on/off commands don't exist | 13:49 |
| _florent_ | "input0 on atlys is not buffered right?" | 13:51 |
| mithro | I'm pretty sure it is? I think only the second output is not buffered | 13:54 |
| _florent_ | ah ok | 13:55 |
| mithro | _florent_: but the production Opsis board isn't working with my laptop | 13:57 |
| mithro | _florent_: it's getting the weirdly corrupted input too | 13:58 |
| _florent_ | strange | 14:00 |
| mithro | https://goo.gl/photos/icLZAX5t7CnN12GD9 | 14:00 |
| _florent_ | but that's the old ones no? | 14:01 |
| mithro | _florent_: Looks like this -> https://goo.gl/photos/QdbzAtrVXipzuvj27 | 14:01 |
| _florent_ | ok | 14:02 |
| _florent_ | maybe we have a timing issue | 14:03 |
| _florent_ | can you test https://github.com/timvideos/HDMI2USB-firmware-prebuilt/blob/master/archive/v0.0.0-580-g9ac8965/opsis/hdmi2usb/opsis_hdmi2usb-hdmi2usbsoc-opsis.bit? | 14:03 |
| tpb | Title: HDMI2USB-firmware-prebuilt/opsis_hdmi2usb-hdmi2usbsoc-opsis.bit at master · timvideos/HDMI2USB-firmware-prebuilt · GitHub (at github.com) | 14:03 |
| mithro | _florent_: I'm thinking so too | 14:03 |
| _florent_ | but that's strange it's working with pre-production board and not with production boards | 14:04 |
| mithro | _florent_: Using the other input https://goo.gl/photos/4stPm84zBXep6pfBA | 14:06 |
| mithro | _florent_: "WARNING:Par:468 - Your design did not meet timing. The following are some suggestions to assist you to meet timing in your design." | 14:07 |
| mithro | _florent_: TS_hdmi2usbsoc_crg_pll_5_ | 14:08 |
| mithro | _florent_: this is on the firmware I'm using on the Atlys | 14:08 |
| mithro | Placer: Placement generated during map. | 14:09 |
| mithro | Routing: Completed - No errors found. | 14:09 |
| mithro | Timing: Completed - 4 errors found. | 14:09 |
| mithro | _florent_: however, the Opsis doesn't have any issues | 14:10 |
| mithro | _florent_: okay, I need to test your serial thing on an Opsis right? | 14:11 |
| _florent_ | yes | 14:11 |
| _florent_ | this way we will be able to run the same bitstreams | 14:12 |
| mithro | _florent_: Did you see I merged seaLne's "make download-prebuilt" ? | 14:14 |
| _florent_ | no | 14:14 |
| _florent_ | what is is doing? | 14:14 |
| mithro | _florent_: means you can download the travis built firmware | 14:14 |
| _florent_ | ah ok cool | 14:15 |
| mithro | _florent_: UART is working for me on git commit: 9ac8965527d26eb9f763080531cf7650f7cc7946 | 14:17 |
| mithro | _florent_: shall we merge it? | 14:19 |
| _florent_ | yes | 14:19 |
| _florent_ | it's working here too | 14:19 |
| mithro | _florent_: great | 14:20 |
| _florent_ | so I'm going to merge it | 14:24 |
| mithro | _florent_, seaLne's download-prebuilt was how I tracked down the romboot failure to https://github.com/timvideos/HDMI2USB-misoc-firmware/commit/ca3f01c0db490ed459143aa49c8a60e42e25a90d | 14:24 |
| tpb | Title: targets: Move common stuff in targets files to a common file. · timvideos/HDMI2USB-misoc-firmware@ca3f01c · GitHub (at github.com) | 14:24 |
| _florent_ | yes that's really a good idea to have that! | 14:25 |
| *** Bertl is now known as Bertl_oO | 14:26 | |
| *** tvCommitBot has joined #timvideos | 14:27 | |
| tvCommitBot | [streaming-system] mithro closed pull request #110: Update for LCA2016, more bootstrap (master...master) https://git.io/vzSM9 | 14:27 |
| *** tvCommitBot has left #timvideos | 14:27 | |
| mithro | _florent_: BTW If you have anything else which does rombooting, take a look at https://github.com/timvideos/HDMI2USB-misoc-firmware/commit/254c281dc669f174de47855aff002f1d91f94f4e | 14:28 |
| tpb | Title: gateware/targets: Make firmware a real gateware object. · timvideos/HDMI2USB-misoc-firmware@254c281 · GitHub (at github.com) | 14:28 |
| mithro | _florent_: FYI, the Opsis production boards actually have a pin header on the SD card - so it is easy of other people to connect serial port there | 14:30 |
| _florent_ | good | 14:30 |
| _florent_ | ok except understanding the strange behaviour on the hdmi inputs, what are the plans now? | 14:31 |
| _florent_ | are you going to do some capture tests with the HV30? | 14:31 |
| _florent_ | (or maybe sleep too...) | 14:31 |
| mithro | _florent_: I have no plans at the moment except helping figure out the issues with the HDMI inputs | 14:31 |
| mithro | _florent_: btw, did you get shipping notification from Crowd Supply about the prod board? | 14:32 |
| _florent_ | yes | 14:32 |
| _florent_ | I got the notification, but the board are not already there | 14:32 |
| mithro | _florent_: how long ago? | 14:33 |
| _florent_ | let me check that | 14:33 |
| mithro | _florent_: would be interested to know if/when they might possibly turn up | 14:33 |
| _florent_ | 6 days ago | 14:33 |
| mithro | any idea how long shipping might take? :P | 14:34 |
| mithro | I would guess minimum 7, maximum 14? | 14:34 |
| mithro | so likely to turn up Friday next week just when its no longer useful :P | 14:34 |
| _florent_ | but I don't understand why behaviour is not similare between pre-prod and prob boards | 14:35 |
| _florent_ | was is re-routed? | 14:35 |
| _florent_ | or are there some changes on hdmi input buffers? | 14:35 |
| mithro | _florent_: there should have only been minor changes to the HDMI (connecting the power supplies correctly) | 14:36 |
| seaLne | my production opsis boards got to uk customs this morning | 14:38 |
| seaLne | so _florent_ might not be long either | 14:39 |
| mithro | _florent_: shall I try and see if I can drop the Atlys frequency to 50MHz from the 75MHz? | 14:43 |
| _florent_ | yes if you want | 14:57 |
| cr1901_modern | back. Found a nice bug in my freq counter module that made it essentially wasted silicon. Let's see what happens now... | 15:02 |
| cr1901_modern | Okay, I now have something that works :D | 15:08 |
| mithro | _florent_: what are you looking into? | 15:15 |
| _florent_ | nothing for now, others things | 15:15 |
| mithro | _florent_: Is there anything you can do regarding the hdmi inputs? | 15:16 |
| _florent_ | since my hardware seems to be working fine that's a bit difficult | 15:17 |
| _florent_ | on your side, it would be interesting to do a bisect with prebuild bitstream and a configuration that is not working correctly now | 15:17 |
| mithro | _florent_: is there any extra debugging we can add to gateware/hdmi_in/chansync.py || gateware/hdmi_in/charsync.py which would give insight into where things are going wrong / it is loosing sync? | 15:18 |
| _florent_ | I'll look at that | 15:18 |
| cr1901_modern | mithro: I have a working frequency counter on my end. It's giving fairly accurate results, but something's a bit off | 15:20 |
| cr1901_modern | E.g. I'm feeding a 40MHz signal into one of the inputs. The frequency that's being read back is consistently 40040960 Hz | 15:21 |
| cr1901_modern | I mean, that's 0.1% error I think? But I would've expected 0% error | 15:22 |
| mithro | _florent_: question, why do the misoclib.soc.SoCs have a integrated_rom_size argument? | 15:22 |
| mithro | _florent_: is that for the bios? | 15:24 |
| _florent_ | yes for the bios | 15:25 |
| mithro | _florent_: should the firmware ROM be read only? | 15:26 |
| mithro | _florent_: (doesn't it make a difference?) | 15:26 |
| cr1901_modern | I think creating a ROM on FPGA is just using a block RAM and not connecting the write signals | 15:27 |
| mithro | _florent_: also, why does the Atlys have 1024 FIFOs but the Opsis only 512? - is that just an oversight? | 15:30 |
| _florent_ | IIRC it was needed because the Atlys have less DDR throughput | 15:30 |
| mithro | _florent_: that would increase the difficult in routing right? | 15:32 |
| _florent_ | maybe but that's not sure (maybe 1024 fits in a single bram, if so then there is no difference between 512 and 1024) | 15:37 |
| *** se6astian is now known as se6astian|away | 15:53 | |
| cr1901_modern | mithro: https://gist.github.com/cr1901/0ae23f42867c6703f686 First version of the patch. Try playing with this | 15:56 |
| tpb | Title: HDMI2USB Frequency Counter Patch · GitHub (at gist.github.com) | 15:56 |
| cr1901_modern | I'm curious to see if you get the same 0.1% error that I do on one of your boards... | 15:57 |
| mithro | cr1901_modern: send a pull request? | 16:01 |
| mithro | _florent_: dropping the frequency of the Atlys board seems to have made things worse.... | 16:05 |
| cr1901_modern | mithro: Not sure if I should do that right now b/c: A. Idk if there's a bug or not, and B. The code that I added to minispartan6 is a debug target that probably shouldn't actually be used by anyone else right now | 16:05 |
| mithro | _florent_: Timing: Completed - 17 errors found. | 16:05 |
| cr1901_modern | Do you want me to send a pull request anyway and we'll fix bugs/remove the debug code later? | 16:06 |
| mithro | _florent_: I added something to the ci to re-enable the debug print from the input | 16:09 |
| _florent_ | ok | 16:09 |
| mithro | _florent_: http://paste.ubuntu.com/14679974/ | 16:10 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 16:10 |
| mithro | _florent_: I'm not 100% sure how to read it - but it seems like the charsync is true but chansync doesn't appear to lock? | 16:11 |
| mithro | I assume the first 3 ph numbers are the phase adjustment of the rgb channels? | 16:13 |
| mithro | I would guess WER is some type of W??? Error Rate? | 16:16 |
| mithro | _florent_: this is what I'm seeing with the HV30 camera connected with my "good" cable -> http://paste.ubuntu.com/14680059/ | 16:19 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 16:19 |
| mithro | _florent_: okay, it seems like the PLL is getting lock, even when no signal is getting through | 16:25 |
| *** rohitksingh has quit IRC | 16:26 | |
| _florent_ | it seems WER counts errors in the transitions, but I'm not well aware of the lower layers of HDMI | 16:26 |
| mithro | _florent_: http://paste.ubuntu.com/14680164/ | 16:27 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 16:27 |
| *** cyrozap-ZNC has joined #timvideos | 16:28 | |
| *** cyrozap has quit IRC | 16:29 | |
| mithro | _florent_: so, any ideas were we go from here? | 16:41 |
| *** rohitksingh has joined #timvideos | 16:41 | |
| mithro | ahh, WER == Word Error Rate | 16:45 |
| mithro | _florent_: is there any chance that the lm32 running at 50MHz is too slow at servicing the hdmi_in0_adjust_phase stuff? | 16:48 |
| _florent_ | sorry mithro, I'm doing some administrative stuff | 17:03 |
| _florent_ | first we should do a bisect to see if it was working before | 17:04 |
| _florent_ | (because I don't think we saw that before on the atlys) | 17:04 |
| _florent_ | it will maybe give use some indications | 17:05 |
| mithro | _florent_: you don't have an Atlys board any more, right? | 17:11 |
| mithro | GAH?! How can having *less* logic in your design cause *more* timing errors.... | 17:12 |
| _florent_ | I have it... but not working... | 17:12 |
| _florent_ | ISE is sometimes a bit difficult to predict... | 17:12 |
| mithro | _florent_: I disabled the ethernet on the HDMI2USB target on the Atlys, I went from 2 timing errors to 12 :( | 17:13 |
| _florent_ | arf... | 17:13 |
| mithro | I probably need to got to sleep soon | 17:13 |
| mithro | it's 4am here... | 17:13 |
| _florent_ | yes probably | 17:15 |
| _florent_ | have a good night | 17:15 |
| mithro | Not yet, I'm trying another build | 17:15 |
| mithro | The Atlys firmware does only take 5 minutes to report those errors now though... | 17:15 |
| mithro | so, with the current gateware the PLL doesn't get lock on input0 on the Atlys board at all | 17:20 |
| mithro | I'd really like to fix https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/191 and then turn timing errors back on.... | 17:21 |
| tpb | Title: Fix CLOCK_DEDICATED_ROUTE disable on the HDMI outputs · Issue #191 · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 17:21 |
| mithro | input1 is working fine | 17:22 |
| mithro | It's clear in the error message that the timing failure is on input0's PLL I believe? | 17:22 |
| _florent_ | the error is for the output no? | 17:24 |
| mithro | _florent_: oh you are correct - it is unrelated here to inputs | 17:25 |
| _florent_ | mithro: best thing to do first is probably to test old bitstreams | 17:26 |
| _florent_ | I'm pretty sure this was working before | 17:26 |
| _florent_ | we probably introduced something that cause this | 17:26 |
| mithro | _florent_: problem seems to exist all the way back too Fri Oct 9 18:28:35 2015 +1100 | 17:46 |
| _florent_ | ok | 17:47 |
| mithro | _florent_: then I start running out of prebuilt firmware to download | 17:47 |
| _florent_ | so that's something that is quite old | 17:47 |
| _florent_ | but I don't remember having these kind of issues at that time | 17:48 |
| mithro | I do remember Ryan / Carl having issues with one of the inputs | 17:49 |
| mithro | and us discovering something having to be done with the jumpers | 17:49 |
| _florent_ | yes, you have the link? | 17:50 |
| _florent_ | I did a capture | 17:50 |
| _florent_ | CarlFK put it somewhere but I don't remember where exactly | 17:51 |
| mithro | Wasn't that the SCL/SDA issue? | 17:51 |
| _florent_ | yes I think | 17:53 |
| mithro | https://logs.timvideos.us/%23timvideos/%23timvideos.2015-10-15.log.html#t2015-10-15T21:20:54 | 17:53 |
| _florent_ | what are you trying by the way? a computer or the HV30? | 17:54 |
| mithro | The computer reliably detects the output it seems, it's the Atlys which isn't detecting the computer.... | 17:54 |
| mithro | https://github.com/timvideos/HDMI2USB/wiki/Atlys-Cabling | 17:54 |
| tpb | Title: Atlys Cabling · timvideos/HDMI2USB Wiki · GitHub (at github.com) | 17:54 |
| mithro | _florent_: a computer | 17:54 |
| _florent_ | from what I remember, you did a presentation with the atlys capturing it | 17:57 |
| mithro | ffs - it appears to be JP5 | 17:57 |
| _florent_ | what is JP5? | 17:58 |
| _florent_ | (don't remember what it's supposed to do) | 17:58 |
| mithro | Apparently it pulls ~OE high, causing the input buffer to be enabled | 18:02 |
| _florent_ | ah | 18:03 |
| mithro | _florent_: okay input0 is working perfectly with the camera and two cables I have tested | 18:15 |
| _florent_ | ok cool | 18:16 |
| mithro | _florent_: zero WER on all channels | 18:16 |
| _florent_ | time to stop and go to sleep probably :) | 18:16 |
| mithro | input1 is also working on this Atlys | 18:17 |
| *** rohitksingh has quit IRC | 18:17 | |
| mithro | _florent_: also zero WER | 18:17 |
| _florent_ | now we will have to understand why one input does not seems to be working fine on opsis production | 18:17 |
| mithro | _florent_: the high WER rate here I think is key | 18:25 |
| mithro | _florent_: can you pull my patches in https://github.com/timvideos/HDMI2USB-misoc-firmware/pull/201 onto your Opsis and see if you are getting any WER? | 18:27 |
| tpb | Title: Adding HDMI debugging back in. by mithro · Pull Request #201 · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 18:27 |
| *** hyades has joined #timvideos | 18:27 | |
| _florent_ | ok I'll test that | 18:27 |
| mithro | I'm going to get some sleep for now | 18:32 |
| _florent_ | ok, good night | 18:44 |
| *** se6astian|away is now known as se6astian | 19:21 | |
| *** hyades has quit IRC | 20:40 | |
| *** cyrozap-ZNC has quit IRC | 20:56 | |
| *** cyrozap has joined #timvideos | 20:56 | |
| *** se6astian has left #timvideos | 22:50 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!