#timvideos

mithro: opsis, lots of jitter

mithro: 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's

oh hey, unplugging / replugging the input cable .. no errors now

faulteh: Poke me later today and I'll help you figure out what is going on

tumbleweed: Do you have a list of things you guys are going at the Debconf Video sprints next week?

mithro: I don't know of an agenda, yet

_florent_: ping?

shenki: Ping?

mithro: pong

_florent_: Did you see https://github.com/enjoy-digital/opsis-soc/issu... ? -- There are two options there and we need to figure out which one we want to merge

Title: printfs are all screwy for some builds · Issue #28 · enjoy-digital/opsis-soc · GitHub (at github.com)

mithro: we are not going to send on uart and telnet at the same time, so first solution seems fine

_florent_: I can see plenty of reasons you might want to send on both the uart and telnet at the same time?

mithro: on my side I don't need that, but maybe you have others usecases

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.

_florent_: With the second one, when ethernet is disabled the wrapping effectively disappears - that does seem like it could be useful?

mithro: I think it's better to consider that we can only have one console session active

mithro: UART is default

mithro: if telnet is connected, the active session is telnet

mithro: and fall back to UART when disconnected

_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?

mithro: this is a specific debug case but I don't think we'll need that latter

_florent_: I definitely found it really weird to open the telnet port and have the serial uart stop working

later

_florent_: Well, if you want to merge the first version - I can send a pull request

mithro: ok, but in this case are you also going to handle inputs from telnet and uart too?

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 UART

_florent_: I guess we would need to modify "readstr" at https://github.com/enjoy-digital/opsis-soc/blob... for that to work

Title: opsis-soc/ci.c at master · enjoy-digital/opsis-soc · GitHub (at github.com)

_florent_: Looking at that code, does telnet not do remote echo?

mithro: it should, not sure

_florent_: I can't see any code in readstr which sends the incoming char back to the telnet session - but I could be blind

_florent_: Looking at the `man telnet` it seems like telnet might do local echo by default....

mithro: yes that's probably why I removed the echo

_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 similar

Otherwise I know I'm going to hit my head against this in the future and I'll have forgotten this conversation :-)

mithro: yes we can do that for now

The lack of "unknown command" type error message still bites me every now and then....

mithro: you can add it

I'm sometimes hopeless at doing the simple things :-P

mithro: but is we only press enter, please do not print "unknown command" :)

and throw in some tab auto-completion while you're at it :P

_florent_: so after all that, I'll just send the first diff as a pull request?

mithro: that's fine for me

_florent_: so, the next question is, how confident are you that litedram to will work on the Atlys (with its DDR2)?

And I assume you haven't had a chance to look at the minispartan?

mithro: I don't see any reason litedram will not work on the Atlys

mithrp: no haven't looked at the minispartan yet

mithro: I'll try the minispartan6 today

Well, there shouldn't have been any reason the minispartan didn't work?

mithro: what is the problem? crashing while executing the firmware from dram?

mithro: executing formware from dram was not tested before on the minispartan

The firmware would randomly lock up.

Memtest seemed to pass

(after we added a constraint)

Title: Comparing enjoy-digital:master...shenki:minispartan6 · enjoy-digital/opsis-soc · GitHub (at github.com)

shenki: was looking at adding a flashing led as kind of a watchdog I think

Let me see if I can find the logs

_florent_: Any thoughts on how a memtest could test for this type of problem?

mithro: memtest is really a simple dram test

mithro: to fully test the controller we need to generate a specific soc with bist generator/checker

_florent_: bist?

built-in self-test

with a dma writer/dma reader

and wishbone writer/wishbone reader

working simultaneously at different location of the dram

okay

I was also wondering about https://github.com/enjoy-digital/opsis-soc/issu...

Title: hdmi_out not working correctly when all inputs/outputs are enabled · Issue #39 · enjoy-digital/opsis-soc · GitHub (at github.com)

_florent_: What is the behaviour you were seeing in that issue?

the output dissappears and reappears

_florent_: Okay, you didn't see the little white/black squares like in this recording -> https://www.youtube.com/watch?v=aEqNSR1CgLk

mithro: not, but I'm not sure I'll done enough test on the opsis to see it

Yeah - I haven't investigated enough yet to verify if it does / doesn't happen on the new opsis-soc

It only really happen significantly when multiple inputs+outputs are all enabled

mithro: yes, probably an arbitration issue on the controller or a timing that is not respected

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

mithro: we only have console notification for overflow on the input

mithro: here the issue is in the controller, which is not able to report thing to the CPU

_florent_: I'm guessing the issue is something like it tries to read something from the buffer fifo and it is empty?

mithro: no that can be inside the controller of the dram that is returning incorrect data since we don't respect a timing

ahh

_florent_: Is the controller likely to "know" that it has screwed up?

_florent_: I assume there isn't any checksums or anything

mithro: no, the sdram is not going to reports problems

mithro: pong

shenki: I was looking at your github and I see your playing with the lm32 linux port?

mithro: heh yeah. i got a bit sucked into it

shenki: How far did you get?

mithro: ive rebased on v4.8, and now im working through fixes to make it build

shenki: Cool!

the quality of the port is pretty poor by modern kernel standards

it will probably be easier to start over if we want to get it upstream

but ive not done a new arch before, so we will see

shenki: are you planning on using qemu?

mithro: hadn't thought about that yet. probably

shenki: Guess compiling is the first task :-P

mithro: is the qemu support upstream?

shenki: I believe so...

mithro, shenki: if you need qemu with misoc/litex, please ask key2 on m-labs channel

i compiled the old tree with the toolchain we have. it's based on 3.15. so i could try booting that too

Title: Using QEMU - Milkymist Wiki (at m-labs.hk)

he's porting NuttX on lm32 using it

oh cool

Mico32 support is available in the QEMU source tree and in QEMU releases since 0.10

mithro: yes, but it's using some old milkymist stuff

shenki: Is there an easy way to see the "delta" for adding lm32?

mithro: key2 just updated all that to work with misoc/LiteX

_florent_: The difference would be the devices / device driver side of thing - right?

mithro: with my current tree, 106 files changed, 9082 insertions(+), 366 deletions(-)

that incldues thinks like the milkymist ethernet driver

shenki: I was more interested in seeing the actual code :-P

Title: key2 / qemu Bitbucket (at bitbucket.org)

mithro: git checkout lm32; git diff v4.8

Title: untitled - asciinema (at asciinema.org)

hi

Someone should write a qemu + verilator cosimulator :-P

thought about it

key2: shenki is working on a linux port for lm32, he can probably be interested by what you've done with qemu & misoc/litex

but there would be timing issue

key2: What is your interest in nuttx on misoc/litex

_florent_: nuttx

misoc/litex have cpu that look more like cortex M3-4

and less like an arm with mmu

a linux is overkill

slow

yep

but it's for fun

well, have fun :)

key2: What is your interest in nuttx on misoc/litex? Fun or do you have an actual project?

i mean it has no real interrest as long as you dont have a powerfull cpu

mithro: for the momment, fun