*** tpb has joined #litex | 00:00 | |
*** peepsalot has quit IRC | 00:46 | |
*** peepsalot has joined #litex | 00:47 | |
*** Skip has quit IRC | 01:31 | |
*** futarisIRCcloud has quit IRC | 02:23 | |
*** Degi has quit IRC | 02:31 | |
*** Degi has joined #litex | 02:33 | |
*** futarisIRCcloud has joined #litex | 03:52 | |
futarisIRCcloud | https://antmicro.com/blog/2020/05/multicore-vex-in-litex/ | 03:53 |
---|---|---|
tpb | Title: Antmicro · Running Linux with Quad-core SMP in LiteX/VexRiscv on Arty A7 (at antmicro.com) | 03:53 |
futarisIRCcloud | Does anyone have the dhrystone output from that? | 03:54 |
futarisIRCcloud | 1.44 DMIPS/MHz to 1.57 DMIPS/MHz, 4 cores @ 100MHz, so roughly 600 DMIPS ? | 04:27 |
*** peepsalot has quit IRC | 05:05 | |
*** st-gourichon-fid has joined #litex | 05:22 | |
*** peepsalot has joined #litex | 05:24 | |
*** HoloIRCUser has joined #litex | 06:06 | |
*** HoloIRCUser1 has quit IRC | 06:07 | |
*** HoloIRCUser1 has joined #litex | 06:38 | |
*** HoloIRCUser has quit IRC | 06:41 | |
*** nrossi has joined #litex | 07:12 | |
*** HoloIRCUser has joined #litex | 07:13 | |
*** HoloIRCUser1 has quit IRC | 07:16 | |
_florent_ | futarisIRCcloud: the version tested in the link was working but not optimized: there was a bottleneck in the memory interface between the VexRiscv SMP Cluster and LiteDRAM, which was preventing the cores to work efficiently. The bottleneck has been removed so the results should be better now. | 08:05 |
*** st-gourichon-f has joined #litex | 08:17 | |
*** st-gourichon-fid has quit IRC | 08:17 | |
*** HoloIRCUser1 has joined #litex | 08:28 | |
*** HoloIRCUser has quit IRC | 08:32 | |
futarisIRCcloud | _florent_ : Cool. I'll try and boot it up on a Arty tomorrow. The version running in Renode seems to have a Timer issue, when the RTC doesn't update. | 08:40 |
*** HoloIRCUser has joined #litex | 09:14 | |
*** HoloIRCUser1 has quit IRC | 09:16 | |
*** st-gourichon-f has quit IRC | 09:22 | |
*** CarlFK has joined #litex | 09:33 | |
*** st-gourichon-fid has joined #litex | 09:46 | |
*** Dolu has joined #litex | 09:52 | |
_florent_ | somlo: the boot from SDCard in SPI Mode should now work correctly with reasonable speed (>1MB/s), if you have time i would be interested to have your feedback | 09:56 |
zyp | wiring up jtag to my cle-215 now, can somebody confirm which end of the connector is pin 1? | 10:06 |
zyp | nevermind, I measured it out, pin 1 is closest to the m.2 connector edge | 10:15 |
*** st-gourichon-fid has quit IRC | 10:30 | |
*** st-gourichon-fid has joined #litex | 10:46 | |
*** st-gourichon-fid has quit IRC | 11:11 | |
*** anuejn_ is now known as anuejn | 11:22 | |
*** st-gourichon-fid has joined #litex | 11:43 | |
*** HoloIRCUser1 has joined #litex | 11:48 | |
*** HoloIRCUser has quit IRC | 11:51 | |
*** st-gourichon-fid has quit IRC | 12:06 | |
*** futarisIRCcloud has quit IRC | 12:43 | |
*** HoloIRCUser has joined #litex | 12:49 | |
somlo | _florent_: with SPI-Mode, I get "file read error" here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/boot.c#L580 | 12:51 |
tpb | Title: litex/boot.c at master · enjoy-digital/litex · GitHub (at github.com) | 12:51 |
somlo | building with litesdcard now, will report back on how that one turns out | 12:51 |
*** HoloIRCUser1 has quit IRC | 12:53 | |
somlo | `length` is 13126480, so I think it all works more or less OK up to that point. | 12:53 |
*** xobs1 has joined #litex | 13:00 | |
*** FFY00 has quit IRC | 13:01 | |
*** xobs has quit IRC | 13:01 | |
*** disasm[m] has quit IRC | 13:01 | |
*** david-sawatzke[m has quit IRC | 13:01 | |
*** st-gourichon-fid has joined #litex | 13:02 | |
*** FFY00 has joined #litex | 13:03 | |
*** disasm[m] has joined #litex | 13:07 | |
*** david-sawatzke[m has joined #litex | 13:12 | |
*** david-sawatzke[m has joined #litex | 13:12 | |
somlo | _florent_: litesdcard booting hangs after three rounds of printing out the parameters (CID register, manufacturer ID, application ID, product name, etc.) | 13:20 |
*** futarisIRCcloud has joined #litex | 14:07 | |
zyp | got the cle-215 up and running: https://paste.jvnv.net/view/PSoJH | 14:24 |
tpb | Title: JVnV Pastebin View paste – Untitled (at paste.jvnv.net) | 14:24 |
zyp | what does the ERRORS col in the dma_test indicate? is that normal? | 14:25 |
*** Dolu has quit IRC | 15:03 | |
_florent_ | somlo: thanks for the test, not sure i tested with a binary that is as big as yours, i will do some tests. The boot with litesdcard is indeed still currently broken, i will work on it soon. | 15:29 |
_florent_ | zyp: the dma_test is reading data from the Host's Memory and doing a loopback in the FPGA that re-writes it to the Host Memory. The errors indicate a mismatch between the data that was read and data that was re-written. | 15:34 |
_florent_ | zyp: do you always have the errors? Are you able to test on another machine? | 15:35 |
zyp | no, not always | 15:46 |
zyp | https://paste.jvnv.net/view/N8EIq | 15:46 |
tpb | Title: JVnV Pastebin View paste – Untitled (at paste.jvnv.net) | 15:46 |
zyp | and no, I don't have anything else with a m.2 socket available | 15:46 |
zyp | looks to me like in the failing case, the read and write streams goes out of sync and therefore keeps accumulating errors | 15:48 |
_florent_ | zyp: yes that what's i'm also thinking, i could to more tests next time i use the Acorn to see if i reproduce the issue. | 15:50 |
somlo | _florent_: it appears that `f_read()` fails right away, from the first iteration | 15:55 |
dkozel | _florent_: Have you looked at or used Tandem loading with litepcie in order to guaranteed meet the 120ms startup time? Separately, have you looked at direct loading an FPGA image over PCIe? | 15:59 |
*** tpearson-mobile has joined #litex | 16:05 | |
tpearson-mobile | Hi all, I'm looking for any documentation that might exist on how to add our custom peripherals to the LiteX framework | 16:07 |
_florent_ | tpearson-mobile: hi, we still need to write a wiki page for that, but you can have a look at https://github.com/litex-hub/fpga_101/tree/master/lab003 | 16:12 |
tpb | Title: fpga_101/lab003 at master · litex-hub/fpga_101 · GitHub (at github.com) | 16:12 |
_florent_ | and https://github.com/litex-hub/fpga_101/tree/master/lab004 | 16:12 |
tpb | Title: fpga_101/lab004 at master · litex-hub/fpga_101 · GitHub (at github.com) | 16:12 |
tpearson-mobile | OK thanks! | 16:12 |
_florent_ | somlo: for the f_read fails it's with litesdcard? | 16:12 |
tpearson-mobile | It looks like LiteX uses some internal bus that isn't Wishbone, but you can stick wishbone peripherals on a LiteX system with a bridge, correct? | 16:13 |
tpearson-mobile | our cores are not Wishbone compatible (yet) and I'm wondering if we should just implement the direct internal bus | 16:13 |
_florent_ | tpearson-mobile: LiteX currently uses a wishbone bus for the main bus of the SoC | 16:15 |
tpearson-mobile | Oh, OK | 16:15 |
_florent_ | in the future, it will be also possible to use AXI | 16:15 |
tpearson-mobile | the diagram seems to show something different | 16:15 |
tpearson-mobile | ah | 16:15 |
tpearson-mobile | any plans for something fast like AXI that isn't proprietary licensed? | 16:15 |
_florent_ | but we can currently bridge the main bus to/from AXI and to a simplified CSR bus used for the registers | 16:16 |
somlo | _florent_: f_read fails with spi-mode | 16:18 |
somlo | I've added an extra printf to get me the actual error code, should have it in a few minutes | 16:19 |
_florent_ | tpearson-mobile: the main plans are Wishbone and AXI, we'll probably have bridge to/from the BMB bus used in VexRiscv/SaxonSoC to ease integration | 16:19 |
_florent_ | https://github.com/SpinalHDL/SaxonSoc#bmb-spec-wip | 16:20 |
tpb | Title: GitHub - SpinalHDL/SaxonSoc: SoC based on VexRiscv and ICE40 UP5K (at github.com) | 16:20 |
tpearson-mobile | _florent_: Actually I should ask because the last time I looked at this was several years back -- is AMBA/AXI still licensed or did ARM make it a "proper" open standard at this point? | 16:20 |
tpearson-mobile | Looking on the ARM site the docs don't seem to be behind a firewall any more | 16:20 |
somlo | _florent_: maybe tpearson-mobile is referring to the CSR bus (where all/most mmio hardware registers are bridged to the "main" wishbone bus)? | 16:22 |
tpearson-mobile | somio: that sounds right, actually -- our peripherals are memory mapped and we don't want to go through Wishbone if we don't need to (lots of extra cycles) | 16:22 |
tpearson-mobile | they're all 32 bit native (can be 64 bit native) already | 16:23 |
_florent_ | tpearson-mobile: i honestly think you can consider AXI as an open standard, it's already used in lots of open source projects and it's probably not in the interest of ARM to restrict its use. | 16:23 |
tpearson-mobile | _florent_: I'm reading through the documents now -- something did change in the last 4 years, it does seem to be a "proper" open standard at this point | 16:23 |
somlo | _florent_: first call to f_read for my 13126480 byte boot.bin returns 9 (FR_INVALID_OBJECT) | 16:26 |
somlo | _florent_: this is with spi-mode, to be clear | 16:26 |
_florent_ | somlo: ah ok i see, i also had this before forcing the mount when doing f_mount | 16:27 |
tpearson-mobile | somio: from what I can see though thus far I'm guessing the main supported way of adding peripherals is via Wishbone, so that may be the route we end up taking | 16:27 |
somlo | tpearson-mobile: it's `somlo` (s/i/l/) -- only mentioning it b/c hexchat won't highlight it :) | 16:29 |
tpearson-mobile | ah, sorry about that! | 16:29 |
tpearson-mobile | not sure how I saw an i there | 16:29 |
_florent_ | somlo: would you mind doing a quick review the way i integrated FatFs in copy_image_from_sdcard_to_ram? | 16:29 |
somlo | _florent_: sure, am I to look at the current master, or do you have a pending patch? | 16:30 |
_florent_ | somlo: current master is fine. I tested it on various boards here (but always with Vexriscv) | 16:31 |
somlo | tpearson-mobile: LiteX has an AXI-to-WB converter in case you have axi-capable IP blocks you want to attach to LiteX | 16:32 |
somlo | "native" LiteX peripherals (written in migen) tend to use the CSR bus, and that is then connected to wishbone for access to all their collective MMIO reigsters | 16:33 |
tpearson-mobile | somlo: good to know...so basically for "fast" peripherals it might be better to implement AXI then downconvert to Wishbone via that converter for now | 16:33 |
tpearson-mobile | is the use of that converter documented anywhere? | 16:33 |
_florent_ | somlo: BTW, in case you want to investigate on f_read, if you want to rebuild and load a bios easily: | 16:34 |
_florent_ | somlo: add this to your target: self.add_ram("firmware_ram", 0x20000000, 0x8000) | 16:34 |
_florent_ | somlo: then rename rom to firmware_ram in https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/linker.ld | 16:35 |
tpb | Title: litex/linker.ld at master · enjoy-digital/litex · GitHub (at github.com) | 16:35 |
_florent_ | somlo: regenerate the bios for your target: ./target.py (without the --build) | 16:35 |
_florent_ | somlo: and load it with lxterm: lxterm /dev/ttyUSBX --kernel=PATH/TO/bios.bin --kernel-adr=0x20000000 --no-crc | 16:36 |
somlo | _florent_: oh, nice, that should save a lot of time :) | 16:36 |
_florent_ | somlo: reset the board, and it will load the updated bios | 16:36 |
_florent_ | tpearson-mobile: you can find some examples of the converters in the code: | 16:40 |
_florent_ | https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_gen.py#L106-L115 | 16:40 |
tpb | Title: litex/litex_gen.py at master · enjoy-digital/litex · GitHub (at github.com) | 16:40 |
_florent_ | https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc_zynq.py#L204-L208 | 16:40 |
tpb | Title: litex/soc_zynq.py at master · enjoy-digital/litex · GitHub (at github.com) | 16:40 |
_florent_ | https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1065-L1113 | 16:41 |
tpb | Title: litex/soc.py at master · enjoy-digital/litex · GitHub (at github.com) | 16:41 |
tpearson-mobile | thanks! | 16:42 |
tpearson-mobile | I'll start looking through the info. One other question -- does the Microwatt / POWER system still need an embedded RISC-V CPU for DRAM setup or was that fixed? | 16:42 |
*** tpearson-mobile has quit IRC | 17:10 | |
keesj | is openocd now used to install software on the arty board? | 18:10 |
daveshah | It can be, although xc3sprog is probably faster | 18:11 |
daveshah | oh sorry I thought this was a general question not litex-specific | 18:11 |
daveshah | I don't know what litex uses | 18:11 |
keesj | this is on a fresh install . np | 18:11 |
keesj | yea https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/arty.py#L279 | 18:17 |
tpb | Title: litex-boards/arty.py at master · litex-hub/litex-boards · GitHub (at github.com) | 18:17 |
*** HoloIRCUser has quit IRC | 18:22 | |
*** HoloIRCUser1 has joined #litex | 18:22 | |
keesj | I am using vivado (for the Arty) on an older ubuntu *18.04* this .. the previous LTS release and vivado's build-in libusb won't work with openocd from the package manager (hence I can not . settings64.sh) or similar this must be a known issue | 18:25 |
zyp | a quick fix is probably just to delete or rename vivado's libusb.so | 18:26 |
keesj | litex works mostly if I just add the bin directory to the path so .. i might be safe | 18:27 |
keesj | (for reference it shows) INFO: [Common 17-206] Exiting Vivado at Wed Jun 10 14:24:32 2020... | 18:28 |
keesj | openocd: symbol lookup error: openocd: undefined symbol: libusb_get_port_numbers | 18:28 |
zyp | https://github.com/libusb/libusb/commit/4d7789b <- that's a function that was added seven years ago, so the vivado bundled libusb is older than that :) | 18:30 |
tpb | Title: core: Add a new public libusb_get_port_numbers function · libusb/libusb@4d7789b · GitHub (at github.com) | 18:30 |
keesj | (and this is also inside a vm......) | 18:30 |
keesj | works .. now .. thanks guys | 18:33 |
mithro | _florent_: The pythondata-XXX modules are on PyPi now | 18:49 |
somlo | _florent_: litex_term.py stuck at "[LXTERM] Starting...". Is that a frequent "unfamiliar user" type of problem? :) | 18:53 |
zyp | xobs1, trying to build wishbone-tool on my test board results in an error from one of the dependencies: https://paste.jvnv.net/view/rZsBq, I suspect this is because the rust shipped with debian stable is too old or something? | 18:53 |
zyp | if so, is there any ways to get around this without installing a newer rust? | 18:54 |
zyp | found the obvious solution: grab the precompiled version of wishbone-tool :) | 18:58 |
*** futarisIRCcloud has quit IRC | 19:07 | |
*** HoloIRCUser has joined #litex | 19:41 | |
*** HoloIRCUser1 has quit IRC | 19:41 | |
*** CarlFK has quit IRC | 20:10 | |
keesj | gerring access to non standards pin (in a pmod or ck_io) appears to be non trivial | 20:31 |
keesj | getting that is | 20:31 |
zyp | what do you mean? | 20:39 |
keesj | well how to get https://github.com/enjoy-digital/litex/blob/master/litex/boards/platforms/arty.py#L183 ck_io26 | 20:40 |
tpb | Title: litex/arty.py at master · enjoy-digital/litex · GitHub (at github.com) | 20:40 |
zyp | use platform.add_extension() | 20:41 |
keesj | yea I was looking into that but ...then I end up redifining the pins or using... Pins("CK_IO:45") or similar? | 20:42 |
zyp | yes | 20:42 |
keesj | the board file already shows the name... hence it would be nice to do platform.request("ck_io") and being able do ck_io.ck_io36 or similar | 20:43 |
keesj | (as can be done with serial) | 20:43 |
zyp | the point of using the connector/extension mechanism is that they'll have a generic name in the connector definition, and then the extension can regroup them for a new specific function | 20:44 |
zyp | https://paste.jvnv.net/view/sEqqc <- e.g. I've got this in one of my projects, and this can then be used by existing stuff that requests a serial port | 20:45 |
tpb | Title: JVnV Pastebin View paste – Untitled (at paste.jvnv.net) | 20:45 |
keesj | yes. I see but .. I was trying to make a point that .. is is not very easy to use like that. I appreciate/know that platform.request also locks resources and hence doing platfom.request("ck_io") is also not great | 20:46 |
keesj | right so bypassing the double indirection and directly using pin names | 20:47 |
zyp | no, j5/j7 are connectors | 20:47 |
zyp | ref. https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/colorlight_5a_75b.py#L198 | 20:48 |
tpb | Title: litex-boards/colorlight_5a_75b.py at master · litex-hub/litex-boards · GitHub (at github.com) | 20:48 |
keesj | A.. then it becomes.. an indexed and that is .. non trivial in this case | 20:49 |
keesj | A cool it looks like I can use pin names now ! | 20:56 |
keesj | e.g. Subsignal("rx", Pins("ck_io:ck_io27"), IOStandard("LVCMOS33")) works nice | 21:04 |
*** HoloIRCUser1 has joined #litex | 21:31 | |
*** HoloIRCUser has quit IRC | 21:31 | |
*** futarisIRCcloud has joined #litex | 21:41 | |
*** HoloIRCUser has joined #litex | 22:31 | |
*** HoloIRCUser1 has quit IRC | 22:35 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!