#timvideos

Title: voctomix-outcasts/mock-stack.sh at master · CarlFK/voctomix-outcasts · GitHub (at github.com)

that is one source, one core, one sink

except I am pretty sure it doesn't work

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

currently "no working" makes me wonder which of the 3 parts the problem is in

ooh, and throws gst-criticals

ummm. sounds good

stefanor: atlys gateware seems to be ready :)

I'll re-start all the things I cancelled, now

stefanor: sorry this was for tumbleweed

they're both me

tumbleweed: maybe you can test before just on the atlys, because if it's not good we'll have to do another test

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/ff9af88c6abecdf...

Title: gist:ff9af88c6abecdfc66e10ccc72d4aacd · GitHub (at gist.github.com)

the only real difference is including matroskamux in the "server" pipeline

which applies timestamps and caps to the buffers it's receiving

_florent_: it works \o/

thanks

great

Title: HDMI2USB-mode-switch/libusb_eeprom.py at master · timvideos/HDMI2USB-mode-switch · GitHub (at github.com)

thaytan: thank - I figured it was something simple -

_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

Title: boards/platforms: Add Arty S7 Board. by cr1901 · Pull Request #63 · enjoy-digital/litex · GitHub (at github.com)

mithro: Hopefully SD card fixes done by tonight too

cr1901_modern: thanks for the pull request. No problem, take your time for the ddr3 controller and feel free to ask questions

cr1901_modern: this script can be useful for you:

Ty, and will do. I'll def have a few LOL

cr1901_modern: https://github.com/enjoy-digital/arty-soc/blob/...

Title: arty-soc/test_sdram.py at master · enjoy-digital/arty-soc · GitHub (at github.com)

cr1901_modern: also, in case this script does not report valid bitstlip/delays, you can try to adjust the sys4x_dqs phase

_florent_: Can we get that test_sdram.py script merged into the litedram repo?

mithro: i'm planning to do it yes

_florent_: Awesome!

_florent_: Q's like, for instance: What is a bitslip in the context of DDR? :P

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

_florent_: So it's like HDMI, where the clock is 10x faster? Why doesn't HDMI need something similar?

cr1901_modern: there is: https://github.com/enjoy-digital/litevideo/blob...

Title: litevideo/charsync.py at master · enjoy-digital/litevideo · GitHub (at github.com)

Huh... I thought it was the PLL's job to ensure that data was aligned to the clock

cr1901_modern: do you want to merge the s7 board now or wait you get ddr3 support?

_florent_: Well, the pinouts are correct, might as well merge it

cr1901_modern: yes, but that's not the same thing

it's not?

cr1901_modern: you have to be sure you are sampling your data correctly

cr1901_modern: and then align this data to your user clock

cr1901_modern: run the script i was linking with debug=True and you will understand :)

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)

_florent_: Will do. I'll do that and come back w/ q's

rohitksingh-demo: do you want to do some hack on netv2 after lunch?

rohitksingh-demo: i tried to find the xilinx cable this morning but was not able to find it

_florent_: Yeah!

_florent_: we will try to find it out

rohitksingh-demo: https://github.com/peteut/migen-misc

Title: GitHub - peteut/migen-misc: Some Migen/MiSoC modules (at github.com)

rohitksingh-demo: https://github.com/jordens/redpid/blob/master/g... (that can't be used due to the license)

Title: redpid/pitaya_ps.py at master · jordens/redpid · GitHub (at github.com)

https://github.com/shenki/linux/commit/9e4dd384... is probably the right driver for the exar chips

Title: usb-serial: Add vizzini driver for Exar USB 2 serial adapters · shenki/linux@9e4dd38 · GitHub (at github.com)

mithro: ^

that one?

paddatrapper: I think you have been making commits?

rohitksingh-demo: Looks like your pull request passes -> https://travis-ci.org/timvideos/HDMI2USB-litex-... \o/

mithro: \o/

mithro: where are you currently?

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

paddatrapper: Ahh cool

hi

I'm having massive trouble getting our opsis board to sync on an hdmi input

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

with the test pattern fed to itself and then routed to a monitor output, the picture is mostly there, but "fizzly"

I have tried all variations of firmware, power supply, hdmi cable, etc, to no avail

it is somewhat better at lower resolutions (= lower pixel clocks), but even then not 100% stable

so my question: is this a known problem? is our opsis board defective?

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

felix_: unfortunately not anymore sorry, car is still full of equipment and still need to pack equipment tomorrow

I would like to do something in the afternoon but need to spend the morning at UTS

ok

yeah, sleeping a bit longer will probably good... ;)

so we'll go by train there

update re. my opsis hdmi sync problems: I can get a stable image at "mode 0: 640x480@72.80Hz"; with a raspi as the source. only mode that worked so far

danielki: are you using a redmere/amplified cable? the opsis requires them

amplified cable?

oh well, I didn't find anything about that in the docs anywhere :)

I'm using a 0.5m standard cable currently

the docs mentioned somewhere that output cables need to be short

btw increasing the output drive of the raspi didn't make any difference

we use the above with conferences, they work well. even longer ones are fine

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

non-amplified HDMI will give you headaches

you also probably want to firmware/gateware flash your opsis to a newer build too if you're running the factory firmware/gateware

already flashed several different versions

running 0.0.4-122 now

ah, cool

get yourself some redmere cables then, you should have much more success

we just used the opsis's in 6 rooms at a conference to record about 160 talks so they certainly work well

alright, thank you, I will have them ordered right away

I'll be in at UTS by around 9.45 by the way

_florent_: Tentatively I figured out a solution to my SD card woes.

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

Is litesdcard is capable of supporting this while a read is in progress?

cr1901_modern: since you are targeting an old sd card, so are not wanting performance, i would suggest using single write/reads

cr1901_modern: it's always difficult to support all the features of a specification and we need to choose

cr1901_modern: here for low performance and good retro compatibility, i suggest using SPI mode of sd card

cr1901_modern: litesdcard was mainly designed for high speeds and assume we are using new sd cards

cr1901_modern: i'll add some informations about that in the README

_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

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.

_florent_: Does the core itself prevent you from sending another command before the current command finishes?

cr1901_modern: we can probably do that

_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

cr1901_modern: i think it's already supported but needs to be checked

_florent_: In the meantime, I'll write the code to detect whether SET_BLOCK_COUNT is supported

Since I have the spec open and it's "just" checking a specific register.

cr1901_modern: feel free to add features to support old sd cards to the core

Will do. Also this is an incredibly stupid question, but if _not_ using the BIST, how does code write to the source/sink buffers?

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...

_florent_: Or do you attach the source/sink to an existing memory on the CSR/wishbone bus?

you have to have a module that generates 512bytes blocks for writes

and that consume them for reads

So potentially FIFO in/out CSRs would work

Or more likely, 512 byte memory buffers exposed on the wishbone bus.