#timvideos

Help !

nancy: please post your question too.

er... please just post a question instead of "help"

sorry sir

net not so good , had a doubt regarding last year's work , The run length encoding adopted

sir was looking at the scripts and didnt understand , what we wanted , we have to code it upto 3 level deep!

And sir for the image size conversion-padding/cropping : python script which imports PIL library and than we integrate it with the existing HDMI Litex firmware

Sir for Image size conversion , a script importing PIL library and than , integrating with existing Litex Firmware ( In case the message has been missed)

is it in right direction . correct me sir

nancy_: I don't think you can import PIL in the micro python environment

also, that isn't what I was thinking.

nancy_: I recommend staring with the most simple case: same input resolution as output, what we have now, but instead of transferring the whole frame, loop over it and transfer one row at a time

ok sir , we cant either do it with ffmpeg ?

nancy_: what cpu would run ffmpeg?

sir as far as i know the CPU will affect the speed of the process.

what CPU?

sir that i didnt check

I found it : hardware requirements are basically any cpu

only speed will vary according to hardware

nancy_: did you think the fpga would run ffmpeg?

nancy_: there is no traditional cpu to work with here...

You do have the softcpu though

ok sir

nancy_: can you find me the code that copies the input frame?

<+CarlFK> nancy_: can you find me the code that copies the input frame?

nancy: ^

sir , looking

hey look, I made a test. :) https://github.com/CarlFK/HDMI2USB-litex-firmwa...

Title: HDMI2USB-litex-firmware/ck_version.py at master · CarlFK/HDMI2USB-litex-firmware · GitHub (at github.com)

http://paste.ubuntu.com/p/2Qp3hzrx7s/ "expected version test passed."

Title: Ubuntu Pastebin (at paste.ubuntu.com)

now to figure out how to do that with jenkins

but after I go to the store to get milk for breakfast

nancy: where did you see last years work? "looking at last year's work , the pixels are copied using the existing DMA engine in the gateware"

sir , yes was looking at code https://github.com/timvideos/HDMI2USB-litex-fir...

Title: HDMI2USB-litex-firmware/firmware at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com)

sorry for late reply , was in other tab ..

was trying to understand the firmware code

nancy: so you're looking at the current code? Just checking that you're not working off an old version lying around somewhere

https://github.com/timvideos/HDMI2USB-litex-fir... checking this

Title: HDMI2USB-litex-firmware/gateware at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com)

nancy: yup, that's the one

Title: HDMI2USB-litex-firmware/pattern.c at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com)

Title: HDMI2USB-litex-firmware/hdmi_in0.c at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com)

last 2 , possible inputs

nancy: hdmi_in1.{h,c} is another input (the second HDMI input)

https://github.com/timvideos/HDMI2USB-litex-fir... is it related to this issue sir

Title: Replace hdmi_in0.c with template thing · Issue #383 · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com)

nancy: yeah, it is a horrible hack

yes sir

G'nigy

Grr... Let's try that again

G'night all

Hi everybody! I'm trying to flash the HDMI2USB firmware onto a nexys video. Flashing the gateware (via python flash.py --mode=gateware) works fine, but the firmware throws an "AssertionError: File is too big! -32768 file does not fit in 67992 space".

I'm assuming that there is a missing value in the calculation at https://github.com/timvideos/HDMI2USB-litex-fir...

Title: HDMI2USB-litex-firmware/flash.py at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com)

Here's where the error comes from: https://github.com/timvideos/HDMI2USB-litex-fir...

Title: HDMI2USB-litex-firmware/flash.py at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com)

Hmm, if `address_start = platform.gateware_size + make.BIOS_SIZE` and `address_end = platform.gateware_size` and finally `file_end = address_start+file_size`, the assertion `file_end < address_end` can't possibly hold, can it?

felix[m]1: stand by....

Sure! Please let me know if there's anything I can try. I'd have thought that the additions for address_start and address_end were swapped, but that's where the bios is supposed to go, right?

felix[m]1: -32768 is ... I think 111 111 111 111 signed 2 byte int ?

Hmm, that seems a bit too high a value?

not so much high, just unlikely that it is a meaningful number

it is the result of address_end - address_start - right?

Title: Wolfram|Alpha: Computational Intelligence (at www.wolframalpha.com)

Title: Wolfram|Alpha: Computational Intelligence (at www.wolframalpha.com)

thats a little more telling..

Yes, that was a much better idea :-)

address_start = 16809984 address_end = 16777216

the end is before the start, right ?

16 809 984 16 777 216

Could it have something to do with the `gateware_size = 0x1000000` at https://github.com/timvideos/HDMI2USB-litex-fir...

I suspect our 111... thing is the result of "overflow error"

Title: HDMI2USB-litex-firmware/nexys_video.py at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com)

But that goes into both values? I'm confused (and utterly incapable of doing arithmetic :-) )

forget the math, the start/end descriptions don't make sense to me

im assuming start should be less than end

Yes, I think you're right. FWIW, the `bios_size` is 32768, which would explain the difference, because it's added only to `address_start`?

nancy: I have another task for you to help get you started understanding the code: add a 3rd test pattern to https://github.com/timvideos/HDMI2USB-litex-fir...

Title: HDMI2USB-litex-firmware/pattern.c at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com)

felix[m]1: um.. im not going to pretend to understand your question ...

address_start = platform.gateware_size + make.BIOS_SIZE # -> 0x1000000 + 32768

address_end = platform.gateware_size # -> 0x1000000

so address_end - address_start -> -32768

address_end = platform.gateware_size

address_start = ... that looks odd to me

Yes, that's what I was thinking (sorry for causing confusion)

But adding the value of make.BIOS_SIZE to address_end instead of address_start would overwrite the bios, right?

So BIOS_SIZE should be added to both, plus an additional offset for the size of the firmware?

um.. something like that

(which is only added to address_end)

Or, more generally, since this route (via flash.py) can't possibly work, how do you flash your board? There must be another way, right?

my guess (never even considered this before) is the bios goes from 0 to bios_size, and then the gateware? from bios_size+1 to.. how ever much it needs

I use mode-switch to flash Atlys and Opsis

those are the only 2 boars I have

Ok, I'll open an issue for this, and try mode-switch. Thanks a lot!

And sorry for being obtuse -- I should be heading to bed. I'm super-thankful for your helping me confirming this, I was starting to question my sanity, not to mention my basic math capabilities :-)

felix[m]1: no problem - happy to help, even if I am not sure whats going on either

felix[m]1: this is how I flash: https://github.com/timvideos/HDMI2USB/wiki/Flas...

Title: Flashing Firmware · timvideos/HDMI2USB Wiki · GitHub (at github.com)

Ah, awesome, thanks! I was trying to reverse-engineer the `make flash` command. I've been digging through the mode-switch code, looks like it only supports the opsys and altys, though

I'll search the wiki more thoroughly, chances are I've missed something.