Tuesday, 2016-11-08

*** tpb has joined #timvideos00:00
*** paradisaeidae_ has joined #timvideos00:06
*** CarlFK has joined #timvideos01:18
*** ChanServ sets mode: +v CarlFK01:18
CarlFKmithro: opsis, lots of jitter01:40
CarlFKmithro: but the MP cables that don't say redmere but do say "active" seem to work.  kinda. jitter = WER numbers on and off.  0's for 5 - 10 seconds, then 2 or 3 seconds of10,000 then back to 0's01:43
CarlFKoh hey, unplugging / replugging the input cable .. no errors now01:51
*** paradisaeidae_ has quit IRC02:04
mithrofaulteh: Poke me later today and I'll help you figure out what is going on02:07
mithrotumbleweed: Do you have a list of things you guys are going at the Debconf Video sprints next week?02:13
tumbleweedmithro: I don't know of an agenda, yet02:16
*** 7YUAAKJNN has joined #timvideos02:55
*** 7YUAAKJNN has quit IRC03:05
*** rohitksingh_work has joined #timvideos03:49
*** CarlFK has quit IRC04:57
*** miselin has quit IRC05:00
*** miselin has joined #timvideos05:04
*** CarlFK has joined #timvideos05:38
*** ChanServ sets mode: +v CarlFK05:38
*** Bertl_oO is now known as Bertl_zZ06:18
mithro_florent_: ping?07:11
mithroshenki: Ping?08:10
_florent_mithro: pong08:13
mithro_florent_: Did you see https://github.com/enjoy-digital/opsis-soc/issues/28#issuecomment-257133779 ? -- There are two options there and we need to figure out which one we want to merge08:14
tpbTitle: printfs are all screwy for some builds · Issue #28 · enjoy-digital/opsis-soc · GitHub (at github.com)08:14
_florent_mithro: we are not going to send on uart and telnet at the same time, so first solution seems fine08:18
mithro_florent_: I can see plenty of reasons you might want to send on both the uart and telnet at the same time?08:19
_florent_mithro: on my side I don't need that, but maybe you have others usecases08:20
*** hyades has joined #timvideos08:21
_florent_mithro: but I think we have to keep things simple for the baremetal firmware, in case we swich to an OS later we could have something better.08:22
mithro_florent_: With the second one, when ethernet is disabled the wrapping effectively disappears - that does seem like it could be useful?08:26
*** hyadez has joined #timvideos08:28
_florent_mithro: I think it's better to consider that we can only have one console session active08:33
_florent_mithro: UART is default08:34
_florent_mithro: if telnet is connected, the active session is telnet08:34
_florent_mithro: and fall back to UART when disconnected08:34
mithro_florent_: When debugging things like the telnet, don't you have both the telnet and uart connected at the same time and compare the output?08:35
_florent_mithro: this is a specific debug case but I don't think we'll need that latter08:38
mithro_florent_: I definitely found it really weird to open the telnet port and have the serial uart stop working08:38
mithro_florent_: Well, if you want to merge the first version - I can send a pull request08:40
_florent_mithro: ok, but in this case are you also going to handle inputs from telnet and uart too?08:40
_florent_mithro: I'm ok for both, but then if we print on the UART while telnet is active we should still be able to interact with the UART08:41
mithro_florent_: I guess we would need to modify "readstr" at https://github.com/enjoy-digital/opsis-soc/blob/master/firmware/ci.c#L151 for that to work08:43
tpbTitle: opsis-soc/ci.c at master · enjoy-digital/opsis-soc · GitHub (at github.com)08:43
mithro_florent_: Looking at that code, does telnet not do remote echo?08:46
_florent_mithro: it should, not sure08:47
mithro_florent_: I can't see any code in readstr which sends the incoming char back to the telnet session - but I could be blind08:47
mithro_florent_: Looking at the `man telnet` it seems like telnet might do local echo by default....08:47
_florent_mithro: yes that's probably why I removed the echo08:51
mithro_florent_: If we don't support telnet and uart at the same time, the uart should probably respond to any input with something like "uart disabled - telnet session open" or similar08:51
mithroOtherwise I know I'm going to hit my head against this in the future and I'll have forgotten this conversation :-)08:52
_florent_mithro: yes we can do that for now08:53
mithroThe lack of "unknown command" type error message still bites me every now and then....08:53
_florent_mithro: you can add it08:56
mithroI'm sometimes hopeless at doing the simple things :-P08:56
_florent_mithro: but is we only press enter, please do not print "unknown command" :)08:56
faultehand throw in some tab auto-completion while you're at it :P08:58
mithro_florent_: so after all that, I'll just send the first diff as a pull request?08:58
_florent_mithro: that's fine for me09:00
mithro_florent_: so, the next question is, how confident are you that litedram to will work on the Atlys (with its DDR2)?09:01
mithroAnd I assume you haven't had a chance to look at the minispartan?09:01
_florent_mithro: I don't see any reason litedram will not work on the Atlys09:02
_florent_mithrp: no haven't looked at the minispartan yet09:02
_florent_mithro: I'll try the minispartan6 today09:04
mithroWell, there shouldn't have been any reason the minispartan didn't work?09:04
_florent_mithro: what is the problem? crashing while executing the firmware from dram?09:04
_florent_mithro: executing formware from dram was not tested before on the minispartan09:05
mithroThe firmware would randomly lock up.09:05
mithroMemtest seemed to pass09:06
mithro(after we added a constraint)09:07
tpbTitle: Comparing enjoy-digital:master...shenki:minispartan6 · enjoy-digital/opsis-soc · GitHub (at github.com)09:08
mithroshenki: was looking at adding a flashing led as kind of a watchdog I think09:09
mithroLet me see if I can find the logs09:09
mithro_florent_: Any thoughts on how a memtest could test for this type of problem?09:13
_florent_mithro: memtest is really a simple dram test09:20
_florent_mithro: to fully test the controller we need to generate a specific soc with bist generator/checker09:21
mithro_florent_: bist?09:21
_florent_built-in self-test09:22
_florent_with a dma writer/dma reader09:22
_florent_and wishbone writer/wishbone reader09:23
_florent_working simultaneously at different location of the dram09:23
mithroI was also wondering about https://github.com/enjoy-digital/opsis-soc/issues/3909:33
tpbTitle: hdmi_out not working correctly when all inputs/outputs are enabled · Issue #39 · enjoy-digital/opsis-soc · GitHub (at github.com)09:33
mithro_florent_: What is the behaviour you were seeing in that issue?09:33
_florent_the output dissappears and reappears09:35
mithro_florent_: Okay, you didn't see the little white/black squares like in this recording -> https://www.youtube.com/watch?v=aEqNSR1CgLk09:37
_florent_mithro: not, but I'm not sure I'll done enough test on the opsis to see it09:38
mithroYeah - I haven't investigated enough yet to verify if it does / doesn't happen on the new opsis-soc09:39
mithroIt only really happen significantly when multiple inputs+outputs are all enabled09:39
_florent_mithro: yes, probably an arbitration issue on the controller or a timing that is not respected09:40
mithro_florent_: Yeah - it "feels like" an underflow or overflow type issue - but I was sure we use to get console notifications when that occurred previously...09:41
_florent_mithro: we only have console notification for overflow on the input09:42
_florent_mithro: here the issue is in the controller, which is not able to report thing to the CPU09:42
mithro_florent_: I'm guessing the issue is something like it tries to read something from the buffer fifo and it is empty?09:43
_florent_mithro: no that can be inside the controller of the dram that is returning incorrect data since we don't respect a timing09:44
mithro_florent_: Is the controller likely to "know" that it has screwed up?09:47
mithro_florent_: I assume there isn't any checksums or anything09:48
_florent_mithro: no, the sdram is not going to reports problems09:51
*** danielki has joined #timvideos09:56
shenkimithro: pong09:56
mithroshenki: I was looking at your github and I see your playing with the lm32 linux port?09:56
shenkimithro: heh yeah. i got a bit sucked into it09:57
mithroshenki: How far did you get?09:57
shenkimithro: ive rebased on v4.8, and now im working through fixes to make it build09:59
mithroshenki: Cool!09:59
shenkithe quality of the port is pretty poor by modern kernel standards09:59
shenkiit will probably be easier to start over if we want to get it upstream09:59
shenkibut ive not done a new arch before, so we will see09:59
mithroshenki: are you planning on using qemu?10:01
shenkimithro: hadn't thought about that yet. probably10:01
mithroshenki: Guess compiling is the first task :-P10:01
shenkimithro: is the qemu support upstream?10:01
mithroshenki: I believe so...10:01
_florent_mithro, shenki: if you need qemu with misoc/litex, please ask key2 on m-labs channel10:02
shenkii compiled the old tree with the toolchain we have. it's based on 3.15. so i could try booting that too10:02
tpbTitle: Using QEMU - Milkymist Wiki (at m-labs.hk)10:02
_florent_he's porting NuttX on lm32 using it10:02
shenkioh cool10:02
mithroMico32 support is available in the QEMU source tree and in QEMU releases since 0.1010:03
_florent_mithro: yes, but it's using some old milkymist stuff10:04
mithroshenki: Is there an easy way to see the "delta" for adding lm32?10:04
_florent_mithro: key2 just updated all that to work with misoc/LiteX10:04
mithro_florent_: The difference would be the devices / device driver side of thing - right?10:04
shenkimithro: with my current tree,  106 files changed, 9082 insertions(+), 366 deletions(-)10:05
shenkithat incldues thinks like the milkymist ethernet driver10:05
mithroshenki: I was more interested in seeing the actual code :-P10:05
tpbTitle: key2 / qemu Bitbucket (at bitbucket.org)10:05
shenkimithro: git checkout lm32; git diff v4.810:05
tpbTitle: untitled - asciinema (at asciinema.org)10:06
*** key2 has joined #timvideos10:07
mithroSomeone should write a qemu + verilator cosimulator :-P10:08
key2thought about it10:08
_florent_key2: shenki is working on a linux port for lm32, he can probably be interested by what you've done with qemu & misoc/litex10:08
key2but there would be timing issue10:08
mithrokey2: What is your interest in nuttx on misoc/litex10:08
key2_florent_: nuttx10:08
key2misoc/litex have cpu that look more like cortex M3-410:09
key2and less like an arm with mmu10:09
key2a linux is overkill10:09
shenkibut it's for fun10:09
key2well, have fun :)10:09
mithrokey2: What is your interest in nuttx on misoc/litex? Fun or do you have an actual project?10:10
key2i mean it has no real interrest as long as you dont have a powerfull cpu10:10
key2mithro: for the momment, fun10:10
key2I mean i have no real goal so far10:11
key2i was frustrated to have misoc wihtout a proper os10:11
key2and drivers10:11
key2and so on10:11
key2the reason I did the qemu port is to have a proper debugger10:11
mithroshenki and myself played with running micropython on litex a while back10:11
key2but osless10:12
key2what is interesting is to have uPy running as a task10:12
key2in nuttx for example10:12
key2with proper drivers10:12
key2so far in qemu I ported the timer and uart of litex10:13
key2i should be able to add ethernet ho10:13
mithrokey2: Cool10:14
mithrokey2: I'd be really interested in input/output frame buffer support too10:15
key2based on what core10:16
mithrokey2: We use litex/misoc on this -> https://hdmi2usb.tv/10:16
mithrokey2: We use a slightly modified version of the misoc HDMI input / output cores currently10:16
key2what are the mods?10:17
mithrokey2: Support for color space conversion (rgb -> yuv) IIRC10:18
key2qemu helped me debug the port of the OS10:19
mithroOur old firmware can be found at https://github.com/timvideos/HDMI2USB-misoc-firmware which uses the old legacy misoc10:19
tpbTitle: GitHub - timvideos/HDMI2USB-misoc-firmware: A version of the HDMI2USB firmware based around the misoc+migen tools produced by m-labs. (at github.com)10:19
mithroWe are now attempting to move to https://github.com/enjoy-digital/opsis-soc to get back in sync with the latest version10:19
tpbTitle: GitHub - enjoy-digital/opsis-soc: Opsis SoC based on LiteX (at github.com)10:19
key2but now i'd rather get my work done in simulator (verilator)10:19
mithrokey2: Not having to lug around hardware is always good :)10:19
mithrokey2: Out of interest, why are you using the lm32 rather than the or1k?10:20
key2very good question10:20
key2i went to ask sb0 what would be the best to port10:20
key2he said "i don't know"10:20
key2i tool the one litex was compiling on by default10:20
key2but why would or1k be better than lm32 ?10:21
mithrokey2: I believe the #m-labs guys are using the or1k as their primary CPU - so, maybe better testing?10:21
key2yeah but would have to re-do a complete port10:22
mithrokey2: We use lm32 at the moment but have been investigating or1k because it has "more out of the box Linux support" in theory10:22
key2i don't believe that any of those cpu are interesting to use for linux, honestly10:22
key2the amount of int/syscall that linux has to deal with makes it really slow10:23
key2it's just "fun" to port a linux10:23
key2but thats it10:23
key2honestly, i think that most ppl are gonna use risc-v10:23
key2on fpga10:23
mithrokey2: All your speed critical stuff is running on the FPGA in gates10:24
key2so why would you need linux then ?10:24
mithroFor all the non-critical stuff10:24
key2and I was not talking about the critical stuff10:24
key2even non critical stuff as you say10:24
key2how fast would a lm32/or1k run10:25
key2concidering that it has only 1 line of interruption10:25
mithroFor example, in our case - Linux is useful for all the EDID / DisplayPort processing10:25
mithroOtherwise we have to duplicate all the hacks / work arounds for the broken monitors and stuff out there10:25
mithroWe are more starved on developer time than on CPU cycles :)10:26
mithrokey2: risc-v would also be another option10:27
key2but still no linux10:27
key2on risc-v10:27
key2no mmu10:27
mithroor j-core10:27
mithrokey2: Eventually it'll probably end up being something like a Zynq10:28
*** hyadez has quit IRC10:28
key2would have much more sense10:29
key2to use a zync10:29
key2if you need a linux10:29
mithroIn theory a lot of the drivers can be shared between lm32/or1k/risc-v10:29
key2as long as they are on the wishbone bus10:29
key2i don't see why not all of them in fact10:29
mithrokey2: oh - why Nuttx rather than RTEMS?10:30
key2ask that to google and samsung ;)10:30
key2they both use nuttx10:31
tpbTitle: GitHub - projectara/nuttx: NuttX with Project Ara bridge ASIC and board support (at github.com)10:32
tpbTitle: Build for NuttX · Samsung/iotjs Wiki · GitHub (at github.com)10:32
key2nuttx is really the linux of IoT10:32
key2but I'd say that for your project it would make more sense to use a zync + linux10:33
* mithro works at Google10:33
key2ah so u might have the answer ;010:33
mithroWouldn't say that we always make the right decisions :-P10:33
key2mithro: u are ie based ?10:34
mithroNope, I'm in Sydney / Australia10:34
key2and timvideos is fo rfun ?10:35
mithroYeah, it's my hobby project10:35
*** hyadez has joined #timvideos10:36
mithrokey2: Dunno if interested to you, but I did get the or1k jtag<->gdb bridge working with verilator on the old legacy misoc10:51
key2well maybe i should do the same on lm32 first10:51
key2then will try to do or1k port eventually10:51
mithroallowed you to do things like single step the or1k cpu running in verilator10:51
key2it would have been nice to get devices simulated by verilator in qemu10:52
key2but it would be really too slow10:52
key2also in verilator, your main loop has to issue 1 tick everytime10:52
key2hard to sync that with qemu10:52
key2how did you do the jtag<>gdb bridge in verilator ?10:53
mithrooh - I got it working in hardware too it seems.....10:53
mithrokey2: https://github.com/timvideos/misoc/compare/legacy...timvideos:or1k-gdb10:55
tpbTitle: Comparing legacy...or1k-gdb · timvideos/misoc · GitHub (at github.com)10:55
mithroThat is the real hardware side of things -- still trying to dig up the verilator side...10:56
tpbTitle: Comparing master...adv_dbg_if · mithro/HDMI2USB-misoc-firmware · GitHub (at github.com)10:58
key2so you use adv_dbg_if10:59
mithrokey2: Apparently :-P10:59
mithroAs you can see, it was apparently 7 months ago :-P11:00
mithrokey2: I'm sure I had a bunch of other changes somewhere11:02
mithrokey2: But I can't find them now...11:03
mithroOh wait!11:03
tpbTitle: Comparing enjoy-digital:master...mithro:adv_debug_sys · enjoy-digital/opsis-soc · GitHub (at github.com)11:03
key2what about that11:05
mithroI'm pretty sure that wasn't from a month ago....11:05
tpbTitle: Comparing enjoy-digital:master...mithro:adv_debug_sys · enjoy-digital/litex · GitHub (at github.com)11:06
key2that was for mo1kx ?11:07
mithroI even wrote some kind of README :-P11:08
tpbTitle: litex/README.md at 58b55a9b1b986a39c200928bfcb09a08ddb92805 · mithro/litex · GitHub (at github.com)11:08
mithroApril 19th -- that seems closer to the date...11:09
mithroIIRC it made the verilator simulation *very* slow11:09
mithroBut I was pretty sure the slowness was because I was doing something stupid11:09
mithroWell, I'm going to head out for the night11:10
key2so actually his thing is not only jtag'ing the cpu, but also has a wishbone mater on the bus11:14
key2if I get it well11:14
mithrokey2: yeah, you can load stuff into ram directly and poke at things on the bus11:15
* mithro is walking home now11:15
*** rohitksingh_work has quit IRC11:20
*** rohitksingh_work has joined #timvideos11:23
mithrokey2: Anyway, I'm definitely interested in following your nuttx port11:37
mithrokey2: You very welcome to hang out here and chat about it to others who might be directly or indirectly interested11:37
key2i was reading your port11:37
key2in fact, lm32 has already a JUART11:37
key2so I am trying to see if that simplifies the thing11:38
key2mithro: I'm trying to understand, what part is emulated with verilator ?11:42
key2basically how does adv communicate with verilator11:42
mithrokey2: basically a bunch of pins emulating a JTAG interface which verilator maps to a socket to openocd can connect to it11:43
mithroBut it has been a long while since I looked at it11:43
key2yes but is there a core somewhere that verilator can interface to ?11:43
key2that does a jtag master11:43
key2or emulate for example the xilinx bscan interface ?11:43
mithroSee the submodules11:44
tpbTitle: GitHub - olofk/adv_debug_sys: Advanced Debug System (at github.com)11:45
tpbTitle: adv_debug_sys/Hardware/adv_dbg_if/rtl/verilog at master · olofk/adv_debug_sys · GitHub (at github.com)11:46
mithroIs that what you are looking for?11:47
key2i've seen that11:55
key2but that is supposed to be connected to the jtag block of the fpga11:55
*** hyades has quit IRC11:55
mithrokey2: In real hardware it connects to a hard block inside the FPGA11:56
key2what I was looking for is to emulate the jtag block of the fpga11:56
key2what about it "fake" verilator ?11:56
tpbTitle: GitHub - rdiez/jtag_dpi: JTAG DPI module for OpenRISC simulation with Verilator (at github.com)11:56
mithroYes, it uses something like that - I think there are a couple of different versions of that11:59
*** key2 has quit IRC12:10
sb0bah, we run rust code on misoc, with things like libfringe. who needs an OS :-)12:23
sb0there were a shitload of ugly llvm issues though12:23
*** miselin has quit IRC12:43
*** miselin has joined #timvideos12:45
*** danielki has quit IRC12:46
*** rohitksingh_work has quit IRC13:00
*** Bertl_zZ is now known as Bertl13:07
*** miselin has quit IRC13:21
*** miselin has joined #timvideos13:24
shenkimithro: got it to link13:29
shenkiand crash13:44
shenki(gdb) bt13:44
shenki#0  0x4007ae04 in __delay (loops=240) at arch/lm32/include/asm/delay.h:3613:44
shenki#1  udelay (usecs=<optimised out>) at arch/lm32/include/asm/delay.h:7313:44
shenki#2  panic (fmt=<optimised out>) at kernel/panic.c:26213:44
shenki#3  0x4000a1a0 in mark_bootmem (start=262999, end=0, reserve=0, flags=0) at mm/bootmem.c:38713:44
shenkiprogress \o/13:44
*** rohitksingh has joined #timvideos13:55
*** CarlFK has quit IRC17:23
*** CarlFK has joined #timvideos17:54
*** ChanServ sets mode: +v CarlFK17:54
*** CarlFK has quit IRC19:18
*** rohitksingh has quit IRC19:36
*** CarlFK has joined #timvideos19:46
*** ChanServ sets mode: +v CarlFK19:46
*** CarlFK has quit IRC19:51
*** CarlFK has joined #timvideos20:42
*** ChanServ sets mode: +v CarlFK20:42
*** wanig has quit IRC21:31
*** Bertl is now known as Bertl_oO22:06

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