| *** tpb has joined #timvideos | 00:00 | |
| xobs | cr1901_modern: It works by poking instructions into the softcore and reading whatever register gets updated, so it's whatever the vexriscv sees. | 01:28 |
|---|---|---|
| cr1901_modern | I would have to see an example, but 0xe0000000-part of the address space is uncached, so a read from the serial port reg shouldn't return a stale value | 01:30 |
| *** rohitksingh_work has joined #timvideos | 03:47 | |
| *** sb0 has quit IRC | 04:13 | |
| xobs | Actually, it might just be me not understanding how the serial port works. I think that for some reason the serial port is starting out with data in the fifo. I'm adding something to uart_init() to drain the fifo to see if that helps things. | 06:23 |
| thaytan | secret startup codez | 06:49 |
| thaytan | "It turned out that each time the device was booted, my long dead grandmother could send me 16 bytes of ASCII message" | 06:50 |
| thaytan | xobs, the fifo indices not being initialised, or something actually sending bytes somehow? | 06:51 |
| xobs | thaytan: I haven't figured that out yet. Definitely some garbage in the fifo. It's nice that it's not a cache problem. | 06:52 |
| _florent_ | xobs: maybe you can try the workaround i provided yesterday to reset the fifo | 06:55 |
| _florent_ | sorry not the fifo, but the uart | 06:55 |
| _florent_ | you can also connect this reset to a button of pin if it's easier | 06:56 |
| xobs | _florent_: I'll add that and see if it helps. | 06:58 |
| *** sb0 has joined #timvideos | 07:12 | |
| *** sb0_ has joined #timvideos | 07:19 | |
| xobs | _florent_: Initial tests seem to show that helps quite a bit. Thanks! | 07:21 |
| _florent_ | xobs: ok, but i still don't understand why you get the data you send in the rx fifo | 07:28 |
| cr1901_modern | I'm guessing the design isn't public? | 07:30 |
| xobs | It is, but I haven't pushed anything in a while. The goal was to get it reliable before pushing. | 07:31 |
| xobs | Also, I feel I need to rewrite my openocd<->vexriscv bridge. I'm not very good with Python so I wrote it first in C. | 07:31 |
| cr1901_modern | _florent_: Here is a super-important and definitely-not-bikeshedding PR: https://github.com/enjoy-digital/litex/pull/76 | 07:44 |
| tpb | Title: Update README by cr1901 · Pull Request #76 · enjoy-digital/litex · GitHub (at github.com) | 07:44 |
| _florent_ | cr1901_modern: what incompatibilities have you seen? | 08:02 |
| cr1901_modern | _florent_: I'm handwaving "incompatibilities" as "sometimes ppl only send PRs to Litex or Migen, but not both, for board files, so they can sometimes go out of sync. Then eventually cr1901 fixes them :P." | 08:04 |
| cr1901_modern | Right now, arty s7 is incompatible b/c I haven't made a PR to sync recent Migen changes back to LiteX. | 08:05 |
| cr1901_modern | _florent_: I don't remember any particular instance offhand where someone _deliberately_ introduced an incompatibility, if that's what you're asking | 08:06 |
| _florent_ | ok, i'll reformulate your PR and will add it the README and will also sync platforms file | 08:07 |
| cr1901_modern | _florent_: Also Arty A7 differs, and Idk if you remember, but we agreed that you'd sync the Migen changes (rgb leds) back to LiteX | 08:11 |
| cr1901_modern | Thanks for saving me the trouble, btw | 08:11 |
| _florent_ | cr1901_modern: on the rgb_led, that's not really an incompatibility, just that the plarforms are different | 08:14 |
| _florent_ | you can still use the platform from Migen with Litex, just that you have to request the rgb_leds in a different way | 08:15 |
| cr1901_modern | _florent_: By incompatibility, I mean "the Migen platform can't be used in LiteX as-is (or vice versa!) without you having to change your source code that uses Migen/Litex." | 08:17 |
| cr1901_modern | So in my eyes, rgb layout _is_ an incompatibility b/c you can't interchange platform files if you use rgb leds | 08:17 |
| cr1901_modern | In any case, I'll stop complaining for tonight :) | 08:18 |
| _florent_ | yes but that's not what we want to do | 08:19 |
| _florent_ | platforms/targets in LiteX should be working together | 08:20 |
| _florent_ | not plaforms from Migen and targets from LiteX | 08:20 |
| _florent_ | otherwise, i should just move all platforms to Migen | 08:20 |
| _florent_ | so the design can choose, to use the platforms/targets from LiteX | 08:21 |
| _florent_ | or use the platform from Migen and create is own SoC | 08:21 |
| cr1901_modern | And then a user who mostly uses LiteX decides to try Migen, and thinks the board files are the same and quickly finds out they aren't, and then has to memorize all the places where they aren't | 08:22 |
| cr1901_modern | if they choose to switch between Migen and Litex | 08:22 |
| cr1901_modern | (in a word, me! Though tbf, I don't really use MiSoC much anymore) | 08:23 |
| cr1901_modern | _florent_: Even if you can't swap litex and migen boards, I still think it's fair that I/O in each file should have the same format between migen and litex | 08:27 |
| cr1901_modern | Which, migen and litex _do_, except for rgb leds | 08:27 |
| _florent_ | cr1901_modern: i agree on the idea and i'm ok to try to keep things compatible | 08:28 |
| _florent_ | that's just that when someone improves something in Migen for example | 08:28 |
| _florent_ | i'm not able to get things in sync immediately, since it potentially breaks things for me and for some private projects | 08:29 |
| cr1901_modern | okay, that's fair >> | 08:29 |
| _florent_ | so i first have to do the changes in the design | 08:30 |
| cr1901_modern | Well I don't mind making PRs and leaving them there until you're ready | 08:30 |
| cr1901_modern | https://irclog.whitequark.org/~h~openfpga/2018-07-05#1530774422-1530774481; | 08:30 |
| tpb | Title: ##openfpga on 2018-07-05 — irc logs at whitequark.org (at irclog.whitequark.org) | 08:31 |
| _florent_ | and that's also one of the reason i prefer to have the platforms i generally used defined in LiteX | 08:31 |
| _florent_ | cr1901_modern: i'm trying to sync things now | 08:31 |
| cr1901_modern | _florent_: Right. Feel free to change the wording of my PR if you take issue w/ "incompatibilities". | 08:32 |
| cr1901_modern | Those IRC messages were tonight, I have a few litex PRs incoming that will fix a few bugs once migen accepts them (so it's a copy/paste job ;)...) | 08:32 |
| cr1901_modern | I'm basically trying to finish a number of "low effort" PRs that have been on my todo list for months b/c... well, easy things pile up! | 08:33 |
| cr1901_modern | LiteX will soon get preliminary cygwin support and a patch for Mimasv2 PMODs | 08:33 |
| _florent_ | but just one thing, why is the initial copyright removed on arty on Migen? | 08:34 |
| xobs | cr1901_modern: What's cygwin support for? | 08:48 |
| xobs | Also, I'm going to clean up my vexriscv debugging patches and submit a PR. | 08:49 |
| cr1901_modern | _florent_: Oversight I guess (I didn't commit that) | 08:50 |
| cr1901_modern | xobs: https://github.com/m-labs/migen/pull/88#issuecomment-402575108 | 08:50 |
| tpb | Title: xilinx/ise: Add Cygwin path to Windows conversion in xst files. by cr1901 · Pull Request #88 · m-labs/migen · GitHub (at github.com) | 08:50 |
| xobs | Ick | 08:53 |
| cr1901_modern | xobs: Idk if "ick" is the word I'd use. It's mainly that There's Ten Ways To Shoehorn *nix Into Windoze | 09:07 |
| cr1901_modern | since most open source projects have decided that *nix is the One True OS | 09:07 |
| _florent_ | cr1901_modern: everything should be fine now regarding platforms | 09:22 |
| _florent_ | cr1901_modern: i also added a comment in the README | 09:22 |
| cr1901_modern | _florent_: https://github.com/enjoy-digital/litex/commit/d35dc5cdeae97c51b066e54d9cfbc0a3bc204cc8#diff-5bc78ceadf12ce9f8b5ce6dd88f81642R245 Hmmm I think 0.750 was in fact correct | 09:27 |
| tpb | Title: platforms/arty: merge with Migen · enjoy-digital/litex@d35dc5c · GitHub (at github.com) | 09:27 |
| * cr1901_modern should've caught this before the Migen PR was merged, but didn't :/ | 09:27 | |
| cr1901_modern | _florent_: Tyvm for your work | 09:27 |
| _florent_ | cr1901_modern: if the DDR3 is using 1.35v, then 0.675v is fine | 09:28 |
| _florent_ | 1.35/2=0.675v | 09:28 |
| _florent_ | 0.750 is for 1.5v | 09:29 |
| cr1901_modern | Right, but I thought DDR3 on Arty A7 was using 1.5v | 09:29 |
| cr1901_modern | and Arty S7 was using 1.35v | 09:29 |
| _florent_ | in the schematic it's 1.35v | 09:30 |
| cr1901_modern | Oh, then nevermind... maybe it's the old Arty (before Arty A7) that used 1.5v | 09:30 |
| _florent_ | Arty A7 is the same than Arty A7 no? | 09:31 |
| cr1901_modern | https://reference.digilentinc.com/reference/programmable-logic/arty/reference-manual Apparently so | 09:31 |
| tpb | Title: Arty Reference Manual [Reference.Digilentinc] (at reference.digilentinc.com) | 09:31 |
| cr1901_modern | (1.35V) | 09:32 |
| cr1901_modern | Note this is the old manual | 09:32 |
| _florent_ | ok so we are fine | 09:33 |
| cr1901_modern | I think so | 09:33 |
| cr1901_modern | _florent_: mithro wanted an ArtyS7 port to litex-buildenv. He may want arty s7 back in litex, but he should be the one to say something not me :P. >> | 09:38 |
| cr1901_modern | Additionally, there's a bug in the Arty S7 file in migen, so you just fixed a bug by removing the file ;) | 09:38 |
| cr1901_modern | Thank you for your help | 09:38 |
| _florent_ | Let's avoid duplicating too much things, if we make sure platforms are compatible between Migen/LiteX, let's use the platforms from Migen | 09:39 |
| cr1901_modern | Fine w/ me | 09:40 |
| _florent_ | I still want to have platforms in LiteX for non-regression on the boards i'm using | 09:40 |
| _florent_ | What's the bug in Arty S7? | 09:41 |
| cr1901_modern | I accidentally put PMODs under I/O instead of _connectors | 09:41 |
| _florent_ | should i fix that now? | 09:42 |
| cr1901_modern | _florent_: Actually, yes, I would appreciate that if you did. It would help me a lot | 09:43 |
| cr1901_modern | ...oh wait | 09:43 |
| cr1901_modern | hmmm | 09:43 |
| _florent_ | i'm looking at that but not sure to see what's the problem | 09:44 |
| cr1901_modern | _florent_: I'm checking something | 09:45 |
| cr1901_modern | https://github.com/m-labs/migen/commit/fd7ce92c2408eb6ce44003ca5bce2946156f3997 Okay, it was already done, so nevermind | 09:45 |
| tpb | Title: Moved pmods to _connectors, removed _1x from spiflash · m-labs/migen@fd7ce92 · GitHub (at github.com) | 09:45 |
| cr1901_modern | the idea was I wanted to commit that fix back to litex, but never did | 09:45 |
| cr1901_modern | _florent_: Btw, I think this is going to break any migen platforms that use diamond but aren't in litex: https://github.com/enjoy-digital/litex/blob/c3652935d9f0560ac32d55335b56a11199c45878/litex/build/lattice/diamond.py#L19-L23 | 09:49 |
| tpb | Title: litex/diamond.py at c3652935d9f0560ac32d55335b56a11199c45878 · enjoy-digital/litex · GitHub (at github.com) | 09:49 |
| cr1901_modern | isinstance is going to return False for litex.build.generic_platform.Pins b/c a migen platform will use migen.build.generic_platform.Pins | 09:50 |
| cr1901_modern | I think the easiest solution right now is to just recommit s7 (with the fix from migen) and live w/ the duplication for now. :/ | 09:54 |
| _florent_ | ok done | 10:07 |
| cr1901_modern | cool! You agree w/ my analysis, btw? (Easy way to fix it would be to check for migen _or_ litex Pins) | 10:08 |
| cr1901_modern | In the future I'd be happy to test which platforms work fine in litex using the migen platforms, just not prepared to do so tonight | 10:08 |
| _florent_ | i need to look at that | 10:30 |
| *** tinyfpga has quit IRC | 11:29 | |
| *** tinyfpga has joined #timvideos | 11:29 | |
| *** sb0 has quit IRC | 12:13 | |
| *** rohitksingh_work has quit IRC | 12:33 | |
| *** sb0 has joined #timvideos | 13:14 | |
| mithro | Yes, I'm after all the Arty boards in litex BuildEnv | 15:40 |
| CarlFK | mithro: I owe you an Opsis purchase. I bought $1000 worth of NeTV2s, 1 Arty for Aeva - if I buy myself one more and bug someone other than you about hooking it to my Jenkins tester, would that cover my lack of Opsis purchasing? | 15:48 |
| *** sb0 has quit IRC | 15:56 | |
| mithro | One more NeTV2 or Opsis? | 16:06 |
| mithro | One more NeTV2 or Opsis? | 16:06 |
| CarlFK | Arty boards | 16:12 |
| CarlFK | really I want one handy to give out next time someone wants to try your Linux on FPGA thing | 16:13 |
| CarlFK | mithro: ^^ | 16:17 |
| mithro | CarlFK: I would prefer you had an opsis for hooking up to jenkins | 17:00 |
| mithro | CarlFK: I can probably get you ~5 Arty's to have spares to hand out | 17:00 |
| CarlFK | mithro: I have an Opsis hooked up to jenkins, and I think I got my one test running | 17:31 |
| *** thaytan has quit IRC | 18:32 | |
| *** Kamilion has quit IRC | 18:47 | |
| *** Kamilion has joined #timvideos | 18:52 | |
| cr1901_modern | tinyfpga: https://github.com/m-labs/migen/pull/111 The internal oscillator stuff has actually been quite difficult to get right. Hopefully migen/litex will have this platform soon | 19:45 |
| tpb | Title: build/platforms: Add tinyfpga_a platform. by cr1901 · Pull Request #111 · m-labs/migen · GitHub (at github.com) | 19:45 |
| *** thaytan has joined #timvideos | 20:07 | |
| *** ChanServ sets mode: +v thaytan | 20:07 | |
| *** CarlFK has quit IRC | 21:39 | |
| *** CarlFK has joined #timvideos | 21:43 | |
| *** ChanServ sets mode: +v CarlFK | 21:43 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!