| *** tpb has joined #timvideos | 00:00 | |
| *** nancy has joined #timvideos | 00:12 | |
| *** nancy has quit IRC | 00:21 | |
| *** Ali-Saurus has quit IRC | 01:11 | |
| *** theshaun111 has joined #timvideos | 02:33 | |
| *** theshaun has quit IRC | 02:34 | |
| *** theshaun111 is now known as theshaun | 02:34 | |
| *** CarlFK has quit IRC | 03:14 | |
| *** nancy has joined #timvideos | 03:38 | |
| *** nancy has quit IRC | 03:38 | |
| *** CarlFK has joined #timvideos | 03:48 | |
| *** ChanServ sets mode: +v CarlFK | 03:48 | |
| *** sb0 has quit IRC | 04:12 | |
| *** rohitksingh has joined #timvideos | 04:50 | |
| *** rohitksingh has quit IRC | 04:55 | |
| *** rohitksingh has joined #timvideos | 05:03 | |
| *** rohitksingh has quit IRC | 05:05 | |
| *** rohitksingh has joined #timvideos | 05:08 | |
| *** rohitksingh has quit IRC | 05:12 | |
| *** rohitksingh has joined #timvideos | 05:13 | |
| *** rohitksingh has quit IRC | 05:15 | |
| *** rohitksingh has joined #timvideos | 05:16 | |
| *** nancy_ has joined #timvideos | 06:41 | |
| *** nancy_ has quit IRC | 07:02 | |
| *** nancy_ has joined #timvideos | 07:53 | |
| *** nancy_ has quit IRC | 07:56 | |
| *** CarlFK has quit IRC | 08:49 | |
| *** nancy_ has joined #timvideos | 09:39 | |
| *** nancy_ has quit IRC | 09:52 | |
| *** i___ has joined #timvideos | 10:19 | |
| *** i___ has quit IRC | 10:35 | |
| *** nancy has joined #timvideos | 13:29 | |
| *** nancy has quit IRC | 14:09 | |
| *** sb0 has joined #timvideos | 14:33 | |
| *** CarlFK has joined #timvideos | 15:12 | |
| *** ChanServ sets mode: +v CarlFK | 15:12 | |
| *** sb0 has quit IRC | 15:57 | |
| *** nancy has joined #timvideos | 16:47 | |
| nancy | Help ! | 16:47 |
|---|---|---|
| *** nancy has quit IRC | 16:49 | |
| *** nancy has joined #timvideos | 16:50 | |
| CarlFK | nancy: please post your question too. | 17:02 |
| CarlFK | er... please just post a question instead of "help" | 17:03 |
| nancy | sorry sir | 17:04 |
| nancy | net not so good , had a doubt regarding last year's work , The run length encoding adopted | 17:05 |
| nancy | sir was looking at the scripts and didnt understand , what we wanted , we have to code it upto 3 level deep! | 17:06 |
| nancy | 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 | 17:12 |
| *** nancy_ has joined #timvideos | 17:14 | |
| *** nancy_ has joined #timvideos | 17:15 | |
| nancy_ | Sir for Image size conversion , a script importing PIL library and than , integrating with existing Litex Firmware ( In case the message has been missed) | 17:16 |
| *** nancy has quit IRC | 17:18 | |
| nancy_ | is it in right direction . correct me sir | 17:25 |
| CarlFK | nancy_: I don't think you can import PIL in the micro python environment | 17:31 |
| CarlFK | also, that isn't what I was thinking. | 17:31 |
| CarlFK | 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 | 17:33 |
| nancy_ | ok sir , we cant either do it with ffmpeg ? | 17:38 |
| CarlFK | nancy_: what cpu would run ffmpeg? | 17:42 |
| nancy_ | sir as far as i know the CPU will affect the speed of the process. | 17:45 |
| CarlFK | what CPU? | 17:45 |
| nancy_ | sir that i didnt check | 17:49 |
| nancy_ | I found it : hardware requirements are basically any cpu | 17:54 |
| nancy_ | only speed will vary according to hardware | 17:55 |
| CarlFK | nancy_: did you think the fpga would run ffmpeg? | 17:55 |
| paddatrapper | nancy_: there is no traditional cpu to work with here... | 17:56 |
| paddatrapper | You do have the softcpu though | 17:58 |
| nancy_ | ok sir | 17:59 |
| CarlFK | nancy_: can you find me the code that copies the input frame? | 18:13 |
| *** nancy has joined #timvideos | 18:17 | |
| *** nancy_ has quit IRC | 18:18 | |
| paddatrapper | <+CarlFK> nancy_: can you find me the code that copies the input frame? | 18:19 |
| paddatrapper | nancy: ^ | 18:19 |
| nancy | sir , looking | 18:22 |
| *** nancy has quit IRC | 18:36 | |
| *** nancy has joined #timvideos | 18:37 | |
| CarlFK | hey look, I made a test. :) https://github.com/CarlFK/HDMI2USB-litex-firmware/blob/master/jenkins/tests/ck_version.py | 18:40 |
| tpb | Title: HDMI2USB-litex-firmware/ck_version.py at master · CarlFK/HDMI2USB-litex-firmware · GitHub (at github.com) | 18:40 |
| CarlFK | http://paste.ubuntu.com/p/2Qp3hzrx7s/ "expected version test passed." | 18:40 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 18:40 |
| CarlFK | now to figure out how to do that with jenkins | 18:41 |
| CarlFK | but after I go to the store to get milk for breakfast | 18:41 |
| CarlFK | 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" | 19:26 |
| nancy | sir , yes was looking at code https://github.com/timvideos/HDMI2USB-litex-firmware/tree/master/firmware | 19:37 |
| tpb | Title: HDMI2USB-litex-firmware/firmware at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 19:37 |
| nancy | sorry for late reply , was in other tab .. | 19:37 |
| nancy | was trying to understand the firmware code | 19:38 |
| paddatrapper | nancy: so you're looking at the current code? Just checking that you're not working off an old version lying around somewhere | 20:05 |
| nancy | https://github.com/timvideos/HDMI2USB-litex-firmware/tree/master/gateware checking this | 20:08 |
| tpb | Title: HDMI2USB-litex-firmware/gateware at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 20:08 |
| paddatrapper | nancy: yup, that's the one | 20:09 |
| nancy | https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/firmware/pattern.c | 20:09 |
| tpb | Title: HDMI2USB-litex-firmware/pattern.c at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 20:09 |
| nancy | https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/firmware/hdmi_in0.c | 20:10 |
| tpb | Title: HDMI2USB-litex-firmware/hdmi_in0.c at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 20:10 |
| nancy | last 2 , possible inputs | 20:10 |
| paddatrapper | nancy: hdmi_in1.{h,c} is another input (the second HDMI input) | 20:22 |
| nancy | https://github.com/timvideos/HDMI2USB-litex-firmware/issues/383 is it related to this issue sir | 20:26 |
| tpb | Title: Replace hdmi_in0.c with template thing · Issue #383 · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 20:26 |
| paddatrapper | nancy: yeah, it is a horrible hack | 20:27 |
| nancy | yes sir | 20:29 |
| paddatrapper | G'nigy | 21:05 |
| paddatrapper | Grr... Let's try that again | 21:05 |
| paddatrapper | G'night all | 21:05 |
| felix[m]1 | 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". | 21:23 |
| felix[m]1 | I'm assuming that there is a missing value in the calculation at https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/flash.py#L37 | 21:23 |
| tpb | Title: HDMI2USB-litex-firmware/flash.py at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 21:23 |
| felix[m]1 | Here's where the error comes from: https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/flash.py#L62 | 21:25 |
| tpb | Title: HDMI2USB-litex-firmware/flash.py at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 21:25 |
| felix[m]1 | 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? | 21:30 |
| CarlFK | felix[m]1: stand by.... | 21:35 |
| felix[m]1 | 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? | 21:37 |
| CarlFK | felix[m]1: -32768 is ... I think 111 111 111 111 signed 2 byte int ? | 21:38 |
| felix[m]1 | Hmm, that seems a bit too high a value? | 21:40 |
| CarlFK | not so much high, just unlikely that it is a meaningful number | 21:40 |
| CarlFK | it is the result of address_end - address_start - right? | 21:41 |
| felix[m]1 | https://www.wolframalpha.com/input/?i=11111111111+from+binary | 21:41 |
| tpb | Title: Wolfram|Alpha: Computational Intelligence (at www.wolframalpha.com) | 21:41 |
| * felix[m]1 sent a long message: felix[m]1_2018-04-07_21:40:42.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/uUZSDKmQKBrjZEEItPzWwqJE> | 21:44 | |
| CarlFK | https://www.wolframalpha.com/input/?i=-32768+in+binary | 21:44 |
| tpb | Title: Wolfram|Alpha: Computational Intelligence (at www.wolframalpha.com) | 21:44 |
| CarlFK | thats a little more telling.. | 21:45 |
| felix[m]1 | Yes, that was a much better idea :-) | 21:45 |
| CarlFK | address_start = 16809984 address_end = 16777216 | 21:45 |
| CarlFK | the end is before the start, right ? | 21:45 |
| CarlFK | 16 809 984 16 777 216 | 21:46 |
| felix[m]1 | Could it have something to do with the `gateware_size = 0x1000000` at https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/platforms/nexys_video.py#L251 | 21:46 |
| CarlFK | I suspect our 111... thing is the result of "overflow error" | 21:46 |
| tpb | Title: HDMI2USB-litex-firmware/nexys_video.py at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 21:46 |
| felix[m]1 | But that goes into both values? I'm confused (and utterly incapable of doing arithmetic :-) ) | 21:47 |
| CarlFK | forget the math, the start/end descriptions don't make sense to me | 21:48 |
| CarlFK | im assuming start should be less than end | 21:48 |
| felix[m]1 | 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`? | 21:49 |
| CarlFK | 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-firmware/blob/master/firmware/pattern.c | 21:50 |
| tpb | Title: HDMI2USB-litex-firmware/pattern.c at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 21:50 |
| CarlFK | felix[m]1: um.. im not going to pretend to understand your question ... | 21:51 |
| felix[m]1 | address_start = platform.gateware_size + make.BIOS_SIZE # -> 0x1000000 + 32768 | 21:51 |
| felix[m]1 | address_end = platform.gateware_size # -> 0x1000000 | 21:51 |
| felix[m]1 | so address_end - address_start -> -32768 | 21:51 |
| CarlFK | address_end = platform.gateware_size | 21:51 |
| CarlFK | address_start = ... that looks odd to me | 21:52 |
| felix[m]1 | Yes, that's what I was thinking (sorry for causing confusion) | 21:53 |
| felix[m]1 | But adding the value of make.BIOS_SIZE to address_end instead of address_start would overwrite the bios, right? | 21:54 |
| felix[m]1 | So BIOS_SIZE should be added to both, plus an additional offset for the size of the firmware? | 21:55 |
| CarlFK | um.. something like that | 21:55 |
| felix[m]1 | (which is only added to address_end) | 21:55 |
| felix[m]1 | 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? | 21:56 |
| CarlFK | 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 | 21:56 |
| CarlFK | I use mode-switch to flash Atlys and Opsis | 21:57 |
| CarlFK | those are the only 2 boars I have | 21:57 |
| felix[m]1 | Ok, I'll open an issue for this, and try mode-switch. Thanks a lot! | 21:59 |
| felix[m]1 | 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 :-) | 22:01 |
| CarlFK | felix[m]1: no problem - happy to help, even if I am not sure whats going on either | 22:08 |
| CarlFK | felix[m]1: this is how I flash: https://github.com/timvideos/HDMI2USB/wiki/Flashing-Firmware | 22:09 |
| tpb | Title: Flashing Firmware · timvideos/HDMI2USB Wiki · GitHub (at github.com) | 22:09 |
| felix[m]1 | 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 | 22:11 |
| felix[m]1 | I'll search the wiki more thoroughly, chances are I've missed something. | 22:12 |
| CarlFK | well... | 22:19 |
| CarlFK | chances are what you are looking for hasn't been written or documented | 22:19 |
| CarlFK | tumbleweed: ^^^ "trying to flash the HDMI2USB firmware onto a nexys video. " | 22:20 |
| felix[m]1 | Ok, opened an issue at https://github.com/timvideos/HDMI2USB-litex-firmware/issues/425 | 22:45 |
| tpb | Title: Support flashing to board on nexys_video platform / check flash addresses · Issue #425 · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 22:45 |
| CarlFK | thanks | 23:12 |
| felix[m]1 | No problem, though I'm thinking about just submitting a pull request instead. | 23:37 |
| felix[m]1 | But even with all the changes in place, flashing fails consistently -- the image on the board doesn't seem to get overwritten at all. | 23:38 |
| felix[m]1 | I must be missing something; what could that be? | 23:38 |
| felix[m]1 | The jumper is set to JTAG programming | 23:38 |
| felix[m]1 | Here's the output of make image-flash-py: https://paste.ubuntu.com/p/88Tnnm426M/ | 23:43 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 23:43 |
| felix[m]1 | Ok, `make gateware-flash-py` works, and contents match. | 23:47 |
| felix[m]1 | ... and so does `make firmware-flash-py`. | 23:49 |
| felix[m]1 | How can I find out whether the nexys video needs a bios? | 23:49 |
| felix[m]1 | (`make bios-flash` says 'unsupported') | 23:49 |
| felix[m]1 | So after flashing gateware and firmware individually, `flterm --port=/dev/ttyUSB0 --speed=115200` doesn't work (though the TX led shows that characters are reaching the board). | 23:52 |
| felix[m]1 | Same result for `flterm --port=/dev/ttyUSB0 --kernel=build/nexys_video_video_lm32/software/firmware/firmware.bin --speed=115200` | 23:54 |
| felix[m]1 | Temporary loading via `openocd` also continues to work. | 23:56 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!