*** tpb has joined #timvideos | 00:00 | |
thaytan | CarlFK, I don't remember what's inside vocto-core well enough | 00:01 |
---|---|---|
thaytan | but we could dump the pipeline graph and use that as a reference | 00:01 |
CarlFK | https://github.com/CarlFK/voctomix-outcasts/blob/master/tests/mock-stack.sh | 00:02 |
tpb | Title: voctomix-outcasts/mock-stack.sh at master · CarlFK/voctomix-outcasts · GitHub (at github.com) | 00:02 |
CarlFK | that is one source, one core, one sink | 00:02 |
CarlFK | except I am pretty sure it doesn't work | 00:03 |
CarlFK | would like have something like that so I can swap one of the 3 parts out for a real part that doesn't seem to be working | 00:04 |
CarlFK | currently "no working" makes me wonder which of the 3 parts the problem is in | 00:04 |
thaytan | ooh, and throws gst-criticals | 00:05 |
CarlFK | ummm. sounds good | 00:05 |
_florent_ | stefanor: atlys gateware seems to be ready :) | 00:07 |
tumbleweed | I'll re-start all the things I cancelled, now | 00:09 |
_florent_ | stefanor: sorry this was for tumbleweed | 00:09 |
tumbleweed | they're both me | 00:10 |
_florent_ | tumbleweed: maybe you can test before just on the atlys, because if it's not good we'll have to do another test | 00:10 |
thaytan | CarlFK, this one works for me (with some gst warnings that don't seem to break anything but I'll look at) https://gist.github.com/thaytan/ff9af88c6abecdfc66e10ccc72d4aacd | 00:20 |
tpb | Title: gist:ff9af88c6abecdfc66e10ccc72d4aacd · GitHub (at gist.github.com) | 00:20 |
thaytan | the only real difference is including matroskamux in the "server" pipeline | 00:21 |
thaytan | which applies timestamps and caps to the buffers it's receiving | 00:21 |
tumbleweed | _florent_: it works \o/ | 00:23 |
tumbleweed | thanks | 00:23 |
_florent_ | great | 00:24 |
mithro | https://github.com/timvideos/HDMI2USB-mode-switch/blob/master/libusb_eeprom.py | 00:32 |
tpb | Title: HDMI2USB-mode-switch/libusb_eeprom.py at master · timvideos/HDMI2USB-mode-switch · GitHub (at github.com) | 00:32 |
*** rohitksingh-demo has joined #timvideos | 00:37 | |
CarlFK | thaytan: thank - I figured it was something simple - | 00:37 |
cr1901_modern | _florent_: If you don't mind, I'd like to add the DDR3 controller b/c it's about time I learned how to do it: https://github.com/enjoy-digital/litex/pull/63 | 00:45 |
tpb | Title: boards/platforms: Add Arty S7 Board. by cr1901 · Pull Request #63 · enjoy-digital/litex · GitHub (at github.com) | 00:45 |
cr1901_modern | mithro: Hopefully SD card fixes done by tonight too | 00:46 |
_florent_ | cr1901_modern: thanks for the pull request. No problem, take your time for the ddr3 controller and feel free to ask questions | 00:46 |
_florent_ | cr1901_modern: this script can be useful for you: | 00:47 |
cr1901_modern | Ty, and will do. I'll def have a few LOL | 00:47 |
_florent_ | cr1901_modern: https://github.com/enjoy-digital/arty-soc/blob/master/test/test_sdram.py | 00:47 |
tpb | Title: arty-soc/test_sdram.py at master · enjoy-digital/arty-soc · GitHub (at github.com) | 00:47 |
_florent_ | cr1901_modern: also, in case this script does not report valid bitstlip/delays, you can try to adjust the sys4x_dqs phase | 00:48 |
mithro | _florent_: Can we get that test_sdram.py script merged into the litedram repo? | 00:48 |
_florent_ | mithro: i'm planning to do it yes | 00:48 |
mithro | _florent_: Awesome! | 00:49 |
cr1901_modern | _florent_: Q's like, for instance: What is a bitslip in the context of DDR? :P | 00:49 |
_florent_ | cr1901_modern: the controller is working with sys_clk, but the ddr data are 8 time faster, so bitslip allow you to align the datas you get from ddr to the sys_clk | 00:51 |
cr1901_modern | _florent_: So it's like HDMI, where the clock is 10x faster? Why doesn't HDMI need something similar? | 00:52 |
_florent_ | cr1901_modern: there is: https://github.com/enjoy-digital/litevideo/blob/master/litevideo/input/charsync.py | 00:54 |
tpb | Title: litevideo/charsync.py at master · enjoy-digital/litevideo · GitHub (at github.com) | 00:54 |
cr1901_modern | Huh... I thought it was the PLL's job to ensure that data was aligned to the clock | 00:55 |
_florent_ | cr1901_modern: do you want to merge the s7 board now or wait you get ddr3 support? | 00:55 |
cr1901_modern | _florent_: Well, the pinouts are correct, might as well merge it | 00:55 |
_florent_ | cr1901_modern: yes, but that's not the same thing | 00:55 |
cr1901_modern | it's not? | 00:56 |
_florent_ | cr1901_modern: you have to be sure you are sampling your data correctly | 00:56 |
_florent_ | cr1901_modern: and then align this data to your user clock | 00:57 |
_florent_ | cr1901_modern: run the script i was linking with debug=True and you will understand :) | 00:58 |
cr1901_modern | I don't think I understand. In the case of HDMI, the 10x clock should _already_ be aligned to the data (or rather, 180 degrees out of phase w/ where you should sample the data) | 00:58 |
cr1901_modern | _florent_: Will do. I'll do that and come back w/ q's | 00:58 |
_florent_ | rohitksingh-demo: do you want to do some hack on netv2 after lunch? | 01:05 |
_florent_ | rohitksingh-demo: i tried to find the xilinx cable this morning but was not able to find it | 01:05 |
rohitksingh-demo | _florent_: Yeah! | 01:14 |
rohitksingh-demo | _florent_: we will try to find it out | 01:14 |
*** hyadez has joined #timvideos | 02:29 | |
felix_ | rohitksingh-demo: https://github.com/peteut/migen-misc | 03:00 |
tpb | Title: GitHub - peteut/migen-misc: Some Migen/MiSoC modules (at github.com) | 03:00 |
felix_ | rohitksingh-demo: https://github.com/jordens/redpid/blob/master/gateware/pitaya_ps.py (that can't be used due to the license) | 03:00 |
tpb | Title: redpid/pitaya_ps.py at master · jordens/redpid · GitHub (at github.com) | 03:00 |
felix_ | https://github.com/shenki/linux/commit/9e4dd3846226d649a615708791309d17efa4c530 is probably the right driver for the exar chips | 03:15 |
tpb | Title: usb-serial: Add vizzini driver for Exar USB 2 serial adapters · shenki/linux@9e4dd38 · GitHub (at github.com) | 03:15 |
felix_ | mithro: ^ | 03:17 |
felix_ | that one? | 03:17 |
mithro | paddatrapper: I think you have been making commits? | 03:54 |
mithro | rohitksingh-demo: Looks like your pull request passes -> https://travis-ci.org/timvideos/HDMI2USB-litex-firmware/builds/333546932 \o/ | 04:07 |
rohitksingh-demo | mithro: \o/ | 04:25 |
rohitksingh-demo | mithro: where are you currently? | 05:23 |
paddatrapper | mithro: reloaded the OS on my laptop and noticed I had stuff on there I hadn't committed yet. I plan on doing work on the FX2 stuff at the video team sprint next week though | 06:05 |
mithro | paddatrapper: Ahh cool | 06:09 |
*** rohitksingh-demo has quit IRC | 06:39 | |
*** futarisIRCcloud has quit IRC | 07:16 | |
*** sb0 has quit IRC | 08:07 | |
*** futarisIRCcloud has joined #timvideos | 08:45 | |
*** aps has joined #timvideos | 08:55 | |
*** danielki has joined #timvideos | 10:42 | |
danielki | hi | 10:43 |
danielki | I'm having massive trouble getting our opsis board to sync on an hdmi input | 10:43 |
danielki | I've now resorted to feeding the board its own test pattern back to itself, with a super short cable, and it still doesn't get a stable sync | 10:44 |
danielki | with the test pattern fed to itself and then routed to a monitor output, the picture is mostly there, but "fizzly" | 10:45 |
danielki | I have tried all variations of firmware, power supply, hdmi cable, etc, to no avail | 10:46 |
danielki | it is somewhat better at lower resolutions (= lower pixel clocks), but even then not 100% stable | 10:46 |
danielki | so my question: is this a known problem? is our opsis board defective? | 10:47 |
*** CarlFK has quit IRC | 10:48 | |
*** danielki1 has joined #timvideos | 10:51 | |
*** danielki has left #timvideos | 10:52 | |
*** danielki1 is now known as danielki | 10:52 | |
*** danielki has quit IRC | 10:54 | |
*** danielki has joined #timvideos | 10:55 | |
*** futarisIRCcloud has quit IRC | 10:55 | |
*** sb0 has joined #timvideos | 11:06 | |
*** sb0 has quit IRC | 11:32 | |
*** aps has quit IRC | 11:46 | |
felix_ | xfxf: when are you planning to drive to the blue mountains tomorrow? meey at 9:15 at the breakfast room of the hotel? would also good if you could tell rohit when we'll start | 13:21 |
xfxf | felix_: unfortunately not anymore sorry, car is still full of equipment and still need to pack equipment tomorrow | 13:27 |
xfxf | I would like to do something in the afternoon but need to spend the morning at UTS | 13:28 |
felix_ | ok | 13:32 |
felix_ | yeah, sleeping a bit longer will probably good... ;) | 13:32 |
felix_ | so we'll go by train there | 13:33 |
*** TimGremalm has quit IRC | 13:50 | |
*** CarlFK has joined #timvideos | 14:00 | |
*** ChanServ sets mode: +v CarlFK | 14:00 | |
danielki | update re. my opsis hdmi sync problems: I can get a stable image at "mode 0: [email protected]" with a raspi as the source. only mode that worked so far | 14:05 |
xfxf | danielki: are you using a redmere/amplified cable? the opsis requires them | 14:07 |
danielki | amplified cable? | 14:07 |
danielki | oh well, I didn't find anything about that in the docs anywhere :) | 14:08 |
danielki | I'm using a 0.5m standard cable currently | 14:08 |
danielki | the docs mentioned somewhere that output cables need to be short | 14:09 |
danielki | btw increasing the output drive of the raspi didn't make any difference | 14:10 |
xfxf | https://www.monoprice.com/product?c_id=102&cp_id=10255&cs_id=1025507&p_id=9169&seq=1&format=2 | 14:13 |
xfxf | we use the above with conferences, they work well. even longer ones are fine | 14:14 |
xfxf | i attached a 20 metre hdmi cable with a joiner and a short redmere cable at the end the other day and worked perfectly for the ~20 hours straight i ran it for at 720p50 | 14:14 |
xfxf | non-amplified HDMI will give you headaches | 14:14 |
xfxf | you also probably want to firmware/gateware flash your opsis to a newer build too if you're running the factory firmware/gateware | 14:15 |
danielki | already flashed several different versions | 14:17 |
danielki | running 0.0.4-122 now | 14:18 |
xfxf | ah, cool | 14:18 |
xfxf | get yourself some redmere cables then, you should have much more success | 14:18 |
xfxf | we just used the opsis's in 6 rooms at a conference to record about 160 talks so they certainly work well | 14:18 |
danielki | alright, thank you, I will have them ordered right away | 14:18 |
*** TimGremalm has joined #timvideos | 14:25 | |
xfxf | I'll be in at UTS by around 9.45 by the way | 14:34 |
*** sb0 has joined #timvideos | 15:46 | |
*** olasd has quit IRC | 16:02 | |
*** olasd has joined #timvideos | 16:03 | |
cr1901_modern | _florent_: Tentatively I figured out a solution to my SD card woes. | 19:38 |
cr1901_modern | Your firmware assumes that READ_MULTIPLE_BLOCK will terminate by itself. On older SD cards, the correct way to terminate a multiple block read is to send STOP_TRANSMISSION | 19:39 |
cr1901_modern | Is litesdcard is capable of supporting this while a read is in progress? | 19:39 |
_florent_ | cr1901_modern: since you are targeting an old sd card, so are not wanting performance, i would suggest using single write/reads | 22:17 |
_florent_ | cr1901_modern: it's always difficult to support all the features of a specification and we need to choose | 22:19 |
_florent_ | cr1901_modern: here for low performance and good retro compatibility, i suggest using SPI mode of sd card | 22:19 |
_florent_ | cr1901_modern: litesdcard was mainly designed for high speeds and assume we are using new sd cards | 22:21 |
_florent_ | cr1901_modern: i'll add some informations about that in the README | 22:21 |
cr1901_modern | _florent_: Regardless, there should be something in the firmware BIST as-is that detects SD card features and then uses the correct rd/wr commands | 22:26 |
cr1901_modern | I think it's relatively safe to assume that a person who picks out any old SD card from their drawer is gonna find out the hard way that the self-test never terminates. | 22:27 |
cr1901_modern | _florent_: Does the core itself prevent you from sending another command before the current command finishes? | 22:28 |
_florent_ | cr1901_modern: we can probably do that | 22:32 |
cr1901_modern | _florent_: If you do that, then we could tolerate SD cards that don't support SET_BLOCK_COUNT. They can send STOP_TRANSMISSION after the relevant number of bytes are read/written | 22:33 |
_florent_ | cr1901_modern: i think it's already supported but needs to be checked | 22:34 |
cr1901_modern | _florent_: In the meantime, I'll write the code to detect whether SET_BLOCK_COUNT is supported | 22:35 |
cr1901_modern | Since I have the spec open and it's "just" checking a specific register. | 22:35 |
_florent_ | cr1901_modern: feel free to add features to support old sd cards to the core | 22:36 |
cr1901_modern | Will do. Also this is an incredibly stupid question, but if _not_ using the BIST, how does code write to the source/sink buffers? | 22:38 |
cr1901_modern | Looks like w/ the BIST, you start the generator, tell the SDcard command to start a write, and then the SD card core will grab from the BIST one word at a time... | 22:38 |
cr1901_modern | _florent_: Or do you attach the source/sink to an existing memory on the CSR/wishbone bus? | 22:42 |
_florent_ | you have to have a module that generates 512bytes blocks for writes | 22:44 |
_florent_ | and that consume them for reads | 22:45 |
cr1901_modern | So potentially FIFO in/out CSRs would work | 22:54 |
cr1901_modern | Or more likely, 512 byte memory buffers exposed on the wishbone bus. | 22:56 |
*** Peetz0r has quit IRC | 23:07 | |
*** Peetz1r has joined #timvideos | 23:07 | |
*** rohitksingh-demo has joined #timvideos | 23:52 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!