Saturday, 2015-11-07

*** tpb has joined #timvideos00:00
CarlFKmithro did the atlys stuff  in the last few weeks.  about the time I put it in my ppa.  a week or so later his work got accepted upstream00:31
mithrotumbleweed: I assume you are probably asleep now?03:34
mithrotumbleweed: For openocd, you should just package the latest upstream git version03:34
mithroBertl_zZ: ping?06:13
mithroseaLne: ping?06:13
mithroxfxf: ping?06:13
mithroG33KatWork: ping?06:13
xfxfpong, am out atm tho06:23
mithroxfxf: you going to be around later tonight at all?07:03
xfxfshould be but it'll be much later - 150km out from home atm07:22
mithrookay07:38
mithroI'll probably be around till midnight07:38
*** rohitksingh has joined #timvideos08:10
*** tvCommitBot has joined #timvideos09:32
tvCommitBot[dvsource-v4l2-other] stefanor created rationalize-imports (+1 new commit): http://git.io/v8nNG09:32
tvCommitBotdvsource-v4l2-other/rationalize-imports 0ed02c1 Stefano Rivera: Clean up imports...09:32
*** tvCommitBot has left #timvideos09:32
*** tvCommitBot has joined #timvideos09:32
tvCommitBot[dvsource-v4l2-other] stefanor opened pull request #14: Clean up imports (master...rationalize-imports) http://git.io/v8nNn09:32
*** tvCommitBot has left #timvideos09:32
*** tvCommitBot has joined #timvideos09:37
tvCommitBot[dvsource-v4l2-other] stefanor created 43-pal (+1 new commit): http://git.io/v8nA809:37
tvCommitBotdvsource-v4l2-other/43-pal 510ce94 Stefano Rivera: In 4:3 PAL, Y41B confuses ffmpeg2theora, and dvswitch PinP09:37
*** tvCommitBot has left #timvideos09:37
*** tvCommitBot has joined #timvideos09:38
tvCommitBot[dvsource-v4l2-other] stefanor opened pull request #15: In 4:3 PAL, Y41B confuses ffmpeg2theora, and dvswitch PinP (master...43-pal) http://git.io/v8nAR09:38
*** tvCommitBot has left #timvideos09:38
* tumbleweed must still test those - we are currently using something hackier09:39
*** travis-ci has joined #timvideos09:39
travis-ci[mithro/HDMI2USB-misoc-firmware/master#48] (4f2aac2): The build passed. (https://travis-ci.org/mithro/HDMI2USB-misoc-firmware/builds/89792313)09:39
*** travis-ci has left #timvideos09:39
*** Bertl_zZ is now known as Bertl09:41
Bertlmithro: pong09:41
mithroBertl: couple of questions - do you have a shopping list for Digikey for the Dual PMOD, HDMI and PMOD boards?09:42
Bertlnope, not yet09:42
mithroBertl: what about element14?09:43
Bertlpartially, the HDMI plugin should have a BOM09:43
Bertlhttps://wiki.apertus.org/index.php/Axiom_Beta_Plugin_Module_1x_HDMI_v0.509:44
tpbTitle: Axiom Beta Plugin Module 1x HDMI v0.5 - apertus° wiki (at wiki.apertus.org)09:44
Bertlcheck the google doc, I even see some digikey entries09:44
Bertlbut the BOM is not checked/corrected yet09:45
Bertlit still contains a lot of bugs/missing fields09:45
Bertlif you do a BOM with digikey parts, please drop us an email with the partlist, we will add them to our BOMs09:50
*** se6astian|away is now known as se6astian10:00
ysionneaumithro ping?10:31
mithroysionneau: pong10:31
mithroBertl: okay10:32
ysionneaumithro: I don't know if you read my last email, but I have better news now.10:32
mithroBertl: I also wanted to ask what your thoughts was on the TOFE->axiom link10:32
mithroBertl: did you see the stuff I pushed?10:32
mithroBertl: and the comment that I couldn't count10:32
ysionneauI implemented the i2c slave in hw, and it seems to work pretty well, at least with the arduino master10:32
mithroysionneau: yes, I've been meaning to reply10:33
ysionneauI didn't push it yet, but I will push it today10:33
ysionneauI bet you have tons of stuff to handle because of the production run?10:33
*** tvCommitBot has joined #timvideos10:35
tvCommitBot[dvsource-v4l2-other] mithro pushed 1 new commit to master: http://git.io/v8cUF10:35
tvCommitBotdvsource-v4l2-other/master 2dd7a73 Tim Ansell: Merge pull request #14 from timvideos/rationalize-imports...10:35
*** tvCommitBot has left #timvideos10:35
mithroysionneau: More trying to get this USB stuff reliable + understandable at the moment10:35
ysionneauso far I have a working prototype of the arduino fetching the content of some SRAM in the FPGA via I2C, the SRAM being addressable on wishbone bus10:38
ysionneauI could write to the SRAM memory from the BIOS (using mw command) and see the Arduino output change live10:38
ysionneauso we'll only need to do a memcpy() at boot to fill the SRAM with the fw10:39
ysionneauonly thing to sort out is ... will the firmware fit in there.10:39
ysionneauif you have some fw somewhere I could need an ls -l on it :)10:39
mithroysionneau: at the moment the SPI flash has no structure on it10:40
ysionneauwhat do you mean?10:41
ysionneaufpga bitstream starts at 0x0, then after the fpga bitstream you put the lm32 fw, then you put some room for improvement and put the fx2 fw ?10:42
mithroysionneau: that is the idea, but we haven't done anything like that yet10:42
ysionneauok10:43
ysionneauI don't think that would be hard to do :o10:43
*** rohitksingh has quit IRC10:43
mithroNote: Although FX2LP can perform C2 load from EEPROMs as large as 64 KB, code can be downloaded only to onchip RAM (16 KB) by the hardware bootloader.10:44
ysionneauok so 16 KB is the max code size10:45
ysionneauthx10:45
ysionneauon my test I only use 128 Bytes ram :p10:45
ysionneauI guess you can't do much with 128B of code :'10:45
mithroysionneau: http://www.cypress.com/file/138911/download10:47
ysionneauthx10:48
mithroysionneau: see the I2C section10:48
mithroI'm assuing that is 16kilobytes ?10:49
ysionneau2.18.2 says 16 KB of RAM10:50
mithroI wish everyone was forced to write kilobit or kilobyte10:50
ysionneauoh10:51
ysionneaucapital B is supposed to always be byte10:51
ysionneaufor me it's not ambiguous, it's 16 kBytes10:51
mithroysionneau: yes but people arn't perfect :)10:51
mithroysionneau: and get it wrong all the time10:51
ysionneauTable 7  2.18.1 , max eeprom size here is 16 k bytes (and this time they wrote Bytes entirely)10:52
ysionneauanyway, eeprom accesses are by bytes , not by bit10:52
ysionneauthat would not make that much sense I think to speak in bits10:52
ysionneauI think :o10:52
ysionneauso we can pretty safely assume it's 16 k Bytes10:52
mithroyeah10:54
ysionneaumithro: if I send you an fpga bitstream which should upload the fw to the fx2, you could test it on your board?10:55
mithroysionneau: yes10:56
ysionneaucool10:56
mithroysionneau: if you want a fx2 firmware to test with, use what is in the HDMI2USB-mode-switch repo10:57
mithroysionneau: https://github.com/timvideos/HDMI2USB-mode-switch/tree/master/fx2-firmware/opsis10:57
tpbTitle: HDMI2USB-mode-switch/fx2-firmware/opsis at master · timvideos/HDMI2USB-mode-switch · GitHub (at github.com)10:57
ysionneauyep got it10:58
ysionneauallright10:58
ysionneauI would probably have to transform it to .bin format then10:59
Bertlmithro: no, didn't see what you pushed10:59
*** rohitksingh has joined #timvideos10:59
Bertlmithro: what's the comment issue?10:59
mithroBertl: well, it turns out that I didn't push things in the end :P11:00
mithroBertl: https://github.com/timvideos/HDMI2USB-TOFE-HiLink11:00
tpbTitle: timvideos/HDMI2USB-TOFE-HiLink · GitHub (at github.com)11:00
Bertlseems pretty empty :)11:00
mithroBertl: I ran into the problem that I totally missed a LVDS pair11:00
mithroBertl: so it doesn't fit nicely like I thought11:01
Bertlokay?11:01
mithroBertl: so, wanted to understand what the best mapping you thought of11:01
mithroBertl:  https://usercontent.irccloud-cdn.com/file/ALJavW7R/tofe-hilink11:05
mithroBertl:  https://usercontent.irccloud-cdn.com/file/XtGn92Lz/tofe-hilink-axiom-side11:06
mithroBertl: I also pushed a bunch of stuff to the repository11:06
mithroNeed to concentrate on this USB stuff, but also conscious that PCB take time to manufacture :)11:07
Bertlhmm ... I think it would be way better to make that a dual slot plugin11:08
Bertlthe problem is, we have 6 LVDS pairs per slot11:08
Bertlthat gives a nice 3x4 pairs on the dual slot, for 3 DP links11:08
mithroBertl: yeah - well, started with one slot + mDP pair11:08
Bertl(which also fits better space wise)11:09
mithrothen just replicate it for the south slot11:09
Bertlwe can still use medium/low speed I/Os for filling up the config/aux11:09
*** rohitksingh has quit IRC11:12
Bertlbut we shouldn't use any of the low speed I/Os for the DP pairs11:15
tumbleweedmithro: bah. One of my patches didn't work. Need to figure out which11:16
Bertlas they won't be able to handle anything beyond 300MHz11:16
Bertloff for now ... bbl11:17
*** Bertl is now known as Bertl_oO11:17
Bertl_oOmithro: anyway, don't worry too much, I'll do the axiom side in the near future11:21
xfxfmithro: i'm sort of around now11:42
*** ivodd has joined #timvideos11:47
ysionneaumithro: code pushed https://github.com/fallen/i2cslave/commit/438053fafd3b1eecf85338ebcc063ac7b8d71f4411:50
tpbTitle: handle i2c slave in gateware · fallen/[email protected] · GitHub (at github.com)11:50
ysionneauI heavily copy pasted from the edid hdmi in code11:52
seaLnemithro: pong11:54
mithroseaLne: just wondering how things are going11:54
mithroysionneau: This isn't how I would do this in hardware as it only enables implementing an  RAM device?11:56
ysionneausorry I don't understand11:56
ysionneauwhat do you mean?11:56
mithroysionneau: this is a hardware implementation on an EEPROM - I would have done this as creating an i2c UART and then still doing the majority of the work, except the shifting, in software11:57
ysionneauah I see11:58
ysionneausoftware driven but hw assisted11:58
mithroysionneau: yes, that is what I meant from the "start with software then add hardware as needed"11:58
ysionneauok11:58
ysionneaudo you see any issue with doing it the way I did?11:59
ysionneauyou can still interface software in front of that, and do uart or ethernet upload of fx2 fw11:59
ysionneauas long as the code ends up writing the fx in the on-chip SRAM11:59
ysionneau-fx+fw11:59
ysionneauit's like a "uart" i2c except the FIFO length is not just 1 byte but has the length of the entire firmware basically12:01
mithroysionneau: you have a full address / I2C command decode happening in hardware?12:02
ysionneauI tested two ways of reading the eeprom so far12:02
seaLnemithro: life has been getting a bit in the way. with the opsis i still don't get any video. the view script gives up after a while. last tried 3 days ago just noticed there have been some changes by _florent_ so will try again building just now12:02
ysionneau1°) the arduino only issues reads to the 0x50 slave, no address is asked. So address starts at 0 and auto increments12:03
ysionneau2°) the arduino issues the address it wants to read12:03
ysionneauboth work12:03
ysionneauso yes there is either address "decoding" (latching) or auto increment12:03
mithroysionneau: yes - all happening in your hardware block, right12:04
mithro?12:04
ysionneauall happening in the FSM in the gateware yes12:04
ysionneausame as the EDID read in fact12:04
ysionneauexcept this time you can control the RAM content, since it's attached to the wishbone bus12:06
ysionneauyou can upload content in it via whatever protocole you need12:07
mithroysionneau: for example, you could send a "write" command via I2C which would currently fail because the hardware doesn't understand it,12:11
ysionneauyes, the "byte write" would not work, but the fx2 would not send such a command, would it?12:16
mithroysionneau: sure - but what I was getting at is that this works for the very specific case, but is very inflexible / hard to extend12:18
*** rohitksingh has joined #timvideos12:19
ysionneauI agree it's less flexible12:20
ysionneaubut I don't see what kind of extension you would want to add12:20
ysionneauif this is really an "eeprom emulation" feature12:21
mithroysionneau: https://plus.google.com/+StephenWarren/posts/7SH3Dn4y4go12:22
ysionneauwhat he is talking about is supported by my code12:23
ysionneaui2c write != byte write12:23
ysionneauindeed, in order to select the address of the eeprom you want to read, you need to issue an i2c write12:23
ysionneauthis write latches the address in the eeprom12:23
ysionneauand this is supported by the i2cslave FSM I pushed on github12:23
ysionneauthat's the 2 scenarios I talked about12:24
ysionneaueither 1°) the master only issues reads12:24
ysionneauor 2°) the master issues writes to latch the address and then reads12:24
seaLnehmm after updating third_party i don't have a misoc/make.py12:25
mithroseaLne: hrm?12:26
ysionneauthird_party is following the misoc upstream?12:26
mithroysionneau: does your eeprom support double byte and single byte reads?12:26
seaLnei ran update.sh and then tried make clean and which tries to run misoc/make.py which doesn't exist anymore?12:26
mithroseaLne: update.sh?12:27
ysionneauhttps://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/third_party/update.sh12:27
mithroseaLne: why did you run update.sh?12:27
tpbTitle: HDMI2USB-misoc-firmware/update.sh at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com)12:27
mithroseaLne: update.sh is to update the submodules to newer upstream12:27
seaLneshould i not have been?12:27
ysionneaufyi, upstream misoc/migen changed a LOT those last days12:27
ysionneauso your current code won't work with current upstream misoc/migen12:28
mithroseaLne: not unless you intended on sending a pull request with new submodule references12:28
seaLneoh12:28
ysionneaufor instance make.py does not exist anymore upstream indeed12:28
ysionneaunow the way to build is to *run* the target file, which is now executable12:28
* seaLne deletes and starts again12:29
mithroysionneau: so, the idea was to try and keep as much in software as possible because, more people understand C code, it's much quicker to fix / modify / extend12:31
ysionneaumithro: it supports random reads and sequential reads12:32
ysionneauI don't see "double byte" reads in the eeprom datasheet I'm looking at right now12:32
mithroysionneau: sorry, I mean double width addresses for the reads - IE more then 256 bytes12:33
ysionneauah ok12:33
ysionneauno it supports only 1 byte width addresses12:34
ysionneaulike a small eeprom would12:34
mithroysionneau: that is needed for 16kilobyte EEPROM support12:34
ysionneauah right12:34
ysionneauI need to change that, good point12:34
ysionneauok let me think about some more software based implem then12:35
mithroysionneau: I think we want hardware which looks like this ->  https://usercontent.irccloud-cdn.com/file/Uyi3ddyn/PIC%20I2C%20module12:35
mithroysionneau: basically a shift register and start/stop bit stuff?12:36
ysionneauyes that's what I was thinking about12:37
ysionneaua read and a write register12:37
ysionneauyou would prefill the read register with the data you want the master to get on the next "master read"12:37
ysionneauand when the master issues a write, it fills your "write" register and you get an irq12:38
ysionneauyou would also get an irq upon read register being empty12:38
ysionneauso that sw can refill it12:38
ysionneauI hope the sw can go fast enough ... but maybe with some "PAUSE" trick it can work (pause being slave keeping SDA low at the end of the transfer, blocking everything)12:39
mithroysionneau: https://cdn.sparkfun.com/assets/5/f/5/a/1/51adff65ce395ff71a000000.png12:43
ysionneauwell, yes ok12:43
ysionneauI think you need 2 registers in fact for this to work well12:44
ysionneaubecause you don't know if the next transaction will be a read or a write12:44
ysionneauso you need to be ready for a read anytime, so you need to have some data in a read register12:44
ysionneauwell, with the PAUSE trick that could work with just 1 register in fact12:45
mithroysionneau: doesn't the read/write just determine who is writing onto SDA?12:46
ysionneauyes12:46
ysionneauread means the slave owns SDA, write means master owns SDA12:46
mithroysionneau: looking at http://www.atmel.com/Images/doc2583.pdf for example SMBUS (I2C derivative) commands12:47
ysionneauyes that's the kind of drawings I had in mind12:49
mithroysionneau: the problem you where having with your bitbanging was the "acknowledge" ?12:49
ysionneauyes12:49
ysionneauthe ACK seemed to be late12:50
ysionneauso it resulted in a NACK :/12:50
mithroysionneau: you had a picture of that, right?12:50
ysionneauyes it's linked in my email12:50
ysionneauyou want the link?12:50
mithroysionneau: this one -> https://framapic.org/TPcDnWIl2uuE/Jt3IOGOj12:50
ysionneauyes12:51
ysionneauthat's an i2c write, to slave 812:52
mithroysionneau: this the C code?12:52
mithroysionneau: https://github.com/fallen/i2cslave/blob/master/i2cslave/software/i2c.c12:52
tpbTitle: i2cslave/i2c.c at master · fallen/i2cslave · GitHub (at github.com)12:52
ysionneauyes12:52
ysionneaui2c_slave_read_byte() is able to read correctly the 0x812:53
ysionneaubut it does not seem to send the ACK on time, weirdly12:53
ysionneauas you can see I also tried optimizing the assembly code, with the same result :/12:57
mithroysionneau: looking at https://cdn.sparkfun.com/assets/6/4/7/1/e/51ae0000ce395f645d000000.png12:57
ysionneauyep ?12:58
*** se6astian is now known as se6astian|away12:59
mithroysionneau: you want to read / write the bits when scl is high, right?12:59
ysionneauyes12:59
ysionneauwell12:59
ysionneauin want to read when scl is high12:59
ysionneaubut I want to setup the bit when scl is low, but so far anyway I only read12:59
mithroysionneau: have you tried just replicating the SCL signal on a separate pin?13:03
mithroysionneau: IE every time i2c_r_read() changes, write the value to an IO pin13:03
*** se6astian|away is now known as se6astian13:03
mithroysionneau: see what your scope shows13:03
ysionneauhmmmm not sure I see where you want to go but I can do that13:04
ysionneauso in my while loops I would just write some register mapped to an IO pin with the SCL pin value?13:05
ysionneaureplicate SCL on a separate pin via software13:05
mithroysionneau: that should let you see what type of delay there is going via software, right?13:06
ysionneauah ok13:07
mithroysionneau: I'd also write a some c code which just toggles a pin on/off as fast as it can13:07
ysionneauso I can basically do while(1) { write_to_pin(read_scl()); }13:07
ysionneauand check the width of the IO spikes13:08
seaLnewhen i've been looking at the specs for video cameras none seem to mention outputing 720p. is it not very common?13:08
ysionneauif it's short it means I don't have much time budget13:08
mithroysionneau: you should get a SCL which lags behind the real SCL by some amount?13:10
ysionneauyes13:10
ysionneaubut possibly with a different width13:11
ysionneauI mean a different frequency13:11
ysionneaudepends on the number of samples I can get while SCL is, say, high. and on the time it takes to output those samples to the replicating pin13:12
ysionneaubut yes, the latency can give me a hint of the speed of a read/write13:13
ysionneauwhat's bothering me is that, in the current code, I output the ACK right after sampling the last bit, so while SCL is still high in theory. I don't wait for it to go low13:13
ysionneauso I should have plenty of time...13:13
mithroysionneau: actually, maybe just ask on #m-labs about manipulating GPIO pins from the lm32 core?13:14
ysionneauI should have some remaining time where SCL is high + the time where scl is low13:14
ysionneauwhat do you want to ask? I know how to manipulate a GPIO from the lm32 core13:15
ysionneauI can just do a CSRStorage bit tied to an IO13:15
mithroysionneau: delays in reading/writing to the GPIO pins?13:15
ysionneauI don't think anyone will know that :/13:15
ysionneaudepends on so much things13:15
mithroysionneau: I13:16
ysionneauif you do XIP or execute from SDRAM, depends on cache size, cache or not, sys clock frequency13:16
ysionneauetc13:16
mithroysionneau: There should be a constant delay from "write to CSR x" and having the change appear GPIO pin?13:17
ysionneauoh that, yes13:17
ysionneauthat's the deterministic part13:17
ysionneauI would say 1 or 2 clock cycles13:17
ysionneaunot more13:17
ysionneauI can easily look that up in the code13:18
ysionneauin fact it depends on what you call "write to CSR", if you directly tie the CSR to the IO, then it's less than a clock cycle upon the CSR is actually written to13:19
ysionneauif you want the time between the wishbone write and the IO change then I guess there is one buffer in the way between the wishbone bus and wishbone_to_csr bridge13:20
ysionneauso that would add 1 clock cycle13:20
mithroysionneau: and reads in the other direction?13:20
ysionneauI would say it's the same13:21
mithroysionneau: so, something which reads the GPIO value and then writes a GPIO in a tight loop should have that speed, no?13:22
ysionneauwell, you need to account for branch misprediction, cache misses, wishbone bus occupation etc13:23
ysionneaubut it should be related yes13:23
mithroysionneau: in a tight loop everything is going to be in cache and shouldn't be any branch misprediction or anything?13:23
ysionneauyes for cache13:24
ysionneaulet me check for branch prediction13:24
ysionneauok, backward pointing branches are predicted taken13:29
ysionneauso that should be OK13:29
ysionneauanyway I can do the test of a tight write loop, and another test of a tight read/write loop13:29
*** tvCommitBot has joined #timvideos13:37
tvCommitBot[dvsource-v4l2-other] stefanor force-pushed 43-pal from 510ce94 to a1a4acf: http://git.io/v8c1P13:37
tvCommitBotdvsource-v4l2-other/43-pal a1a4acf Stefano Rivera: In 4:3 PAL, Y41B confuses ffmpeg2theora, and dvswitch PinP13:37
*** tvCommitBot has left #timvideos13:37
ysionneauso, to sum up, next in my todo list : investigate the sw gpio toggling frequency, then replicate scl to see by how much I lag behind, and then we can make the decision to either spend time debugging this or go the sw controlled more hw assisted way (with shift registers)13:41
mithroysionneau: I think we do want to go the hw assisted way with shift registers, but it would be good to figure out *why* your bit banging doesn't work13:42
ysionneauok13:43
ysionneaufair enough13:43
ysionneauAFK fetching some food13:51
*** tvCommitBot has joined #timvideos14:26
tvCommitBot[dvsource-v4l2-other] stefanor pushed 1 new commit to 43-pal: http://git.io/v8cF314:26
tvCommitBotdvsource-v4l2-other/43-pal 757a7fc Stefano Rivera: American spelling14:26
*** tvCommitBot has left #timvideos14:26
tumbleweedmithro: btw, we're using this 43-pal branch, now, successfully.14:26
mithrotumbleweed: you are doing PAL right?14:27
mithrotumbleweed: CarlFK normally does NTSC IIRC14:27
mithrotumbleweed: merged!14:28
*** tvCommitBot has joined #timvideos14:28
tvCommitBot[dvsource-v4l2-other] mithro deleted 43-pal at 757a7fc: http://git.io/v8cFF14:28
*** tvCommitBot has left #timvideos14:28
tumbleweedmithro: yeah14:30
tumbleweedno idea why anyone would use NTSC for anything14:30
tumbleweedbut yes, he does14:30
mithrotumbleweed: great, I guess that means we have testing with PAL and NTSC on that tool14:31
tumbleweedmithro: so, multiples of 25Hz might be nice to have in the available modes14:31
tumbleweedbut we're doing fine now, with 60Hz capture, fed into a 50Hz dvswitch14:32
mithrotumbleweed: They are defined here -> https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/firmware/lm32/processor.c#L6314:32
tpbTitle: HDMI2USB-misoc-firmware/processor.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com)14:32
mithrotumbleweed: I got most of the way through adding support so you could just dump a modeline for a "custom" mode too14:33
mithrotumbleweed: https://github.com/timvideos/HDMI2USB-misoc-firmware/commit/60f49a111650305fa780001d5c836be3305d55e914:34
tpbTitle: Add support for setting custom EDID mode. · timvideos/[email protected] · GitHub (at github.com)14:34
mithroAll C code for that :)14:34
tumbleweedmithro: ah, that's fairly simple14:35
tumbleweedassuming I could generate modelines :P14:35
mithrotumbleweed: yeah - super simple :)14:35
mithroysionneau is going to work on some edid stuff once we get the fx2 eeprom stuff working14:36
ysionneauedid plan on doing it (sorry could not refrain from saying it)14:41
ysionneaupardon the non native speaker jokes :'14:41
tumbleweedheh14:41
mithro_florent_: the bitstream generation is soooo much faster without that giant FIFO on the encoder14:47
mithro_florent_: Total REAL time to PAR completion: 3 mins 47 secs14:48
ysionneauo/14:55
mithroseaLne: can you try the fx2-refactor branch in a second?15:10
mithroseaLne: https://github.com/mithro/HDMI2USB-misoc-firmware/tree/fx2-refactor15:18
tpbTitle: mithro/HDMI2USB-misoc-firmware at fx2-refactor · GitHub (at github.com)15:18
mithroseaLne: well, I think I've finally gotten the fx2 firmware into a place where I can understand what is going on15:30
mithroxfxf: Oh, I can also fix your 30fps issue in the descriptors too!15:31
*** kaalia has joined #timvideos15:58
seaLnemithro: where should linux/ch9.h be coming from?16:43
mithroseaLne: third_party/fx2lib/include/linux16:44
mithroseaLne: The Makefile didn't run "git submodule update --recursive --init" ?16:45
seaLneeven running that manually i still don't have third_party/fx2lib/include/linux16:45
seaLneno linux dir16:46
mithrohrm16:47
mithroseaLne: what does "git status" show?16:47
seaLnesorry just noticed there was an error in the submodule update https://paste.kde.org/pp41yjko916:48
tpbTitle: KDE Paste (at paste.kde.org)16:48
mithroseaLne: oh, I see the problem16:50
mithroseaLne: try submodule update again now16:51
seaLneerrors gone16:52
seaLneconnect-lm32 not responding though16:53
mithroseaLne: did you rebuild the gateware / fx2 firmware?16:53
seaLnenot after the submodule init?16:54
seaLnewell i did make load-fx2 which built it16:54
seaLnepower cycled and in16:55
seaLneview-hdmi2usb.sh still not getting anything though after enableing/connecting encoder16:57
mithroseaLne: what is dmesg and view-hdmi2usb.sh outputting?16:57
mithroseaLne: you can't run view-hdmi2usb.sh while connected to the lm32 either16:57
seaLneyeah i was killing the connect before trying the view?16:58
mithroseaLne: good17:00
mithroseaLne: but still no view?17:00
seaLnenope https://paste.kde.org/pdblpv2np https://paste.kde.org/p2ly47hro17:00
tpbTitle: KDE Paste (at paste.kde.org)17:00
seaLnei was trying that on trusty17:00
mithroseaLne: do you have v4l-info installed?17:04
seaLnehttps://paste.kde.org/pshcmfkxh17:06
tpbTitle: KDE Paste (at paste.kde.org)17:06
mithroseaLne: did you just install it then?17:13
seaLneyes17:13
mithroseaLne: the ./scripts/view-hdmi2usb.sh requires the v4l-info to work...17:13
seaLneoh17:13
mithroseaLne: try running that script now?17:13
seaLnenov video yet but its doing something17:14
seaLnev4l2 select timeout17:14
mithroseaLne: and anything in dmesg now?17:14
seaLnestarting load from scratch17:15
seaLnevideo!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!17:17
mithroseaLne: \o/17:17
mithroseaLne: I think you are the third person in the whole world to get video out of an Opsis board :)17:17
mithroseaLne: myself and florent are the only other people IIRC17:17
mithroseaLne: hamster hasn't played with the HDMI2USB firmware stuff17:17
mithroIt's bed time for me17:19
mithro(should have been bed time hours ago :P)17:19
seaLnemithro: thanks17:19
mithroxfxf: the fx2-refactor branch in my repo has the UVC FPS fix17:19
mithroseaLne: Now I understand both UVC stuff and the FX2 stuff a lot better, I'm going to work on making our stuff actually standards compliant :P17:20
*** rohitksingh has quit IRC17:44
seaLnemithro: just to confirm that this also works on my wily desktop17:45
tumbleweedmithro: what's the story of vizzini and upstream linux? bwh is making my life hard :P bugs.debian.org/80435017:49
mithrotumbleweed: I should be asleep17:51
mithrotumbleweed: but what happened is that the exar guys effectively forked an in tree kernel driver and made it work with their crappy device17:52
mithrotumbleweed: shenki then fixed it to work with modern kernels17:52
mithrotumbleweed: It needs to be rewritten as something that can be merged into the upstream driver.17:53
mithro(The CDC-ACM driver)17:54
tumbleweedmithro: thanks!17:54
tumbleweedI'll paste that at him17:54
mithroThat is never going to happen as nobody has the time or will power to do it17:55
tumbleweedgo to sleep17:55
mithroWho is bwh?17:55
tumbleweeddvswitch author, and linux kernel maintainer17:55
mithroIt won't be needed for the HDMI2USB stuff, even on the Atlys shortly.17:55
tumbleweedoh, ok, so no point packaging17:56
tumbleweedpresumably useful for others17:56
tumbleweedbut not for me to maintain it :P17:56
mithroIf he wants to take a stab at making the driver upstreamable then he is welcome to do it17:56
mithroIt's super frustrating they (exar) didn't just implement a real CDC-ACM serial port like sane people17:57
*** rohitksingh has joined #timvideos17:58
mithroI have more useful things for Linux kernel hackers to help with if they want to contribute though :-)17:58
mithro(IE Getting Linux running on the lm32 core)17:59
mithroAnyway really going to sleep now.17:59
seaLnemithro: so i can run connect-lm32 fine after starting view, seems happy changing video_mode during that18:02
*** travis-ci has joined #timvideos18:02
travis-ci[mithro/HDMI2USB-misoc-firmware/fx2-refactor#51] (9bda758): The build passed. (https://travis-ci.org/mithro/HDMI2USB-misoc-firmware/builds/89837352)18:02
*** travis-ci has left #timvideos18:02
seaLnemithro: in fact i can start view while connected18:05
*** rohitksingh has quit IRC20:05
*** rohitksingh has joined #timvideos21:01
*** rohitksingh has quit IRC21:28
*** se6astian is now known as se6astian|away22:20
mithroseaLne: it only seems to be the first view that causes problems.23:01

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!