<tpb>
Title: Antmicro · Running Linux with Quad-core SMP in LiteX/VexRiscv on Arty A7 (at antmicro.com)
<futarisIRCcloud>
Does anyone have the dhrystone output from that?
<futarisIRCcloud>
1.44 DMIPS/MHz to 1.57 DMIPS/MHz, 4 cores @ 100MHz, so roughly 600 DMIPS ?
peepsalot has quit [Ping timeout: 260 seconds]
st-gourichon-fid has joined #litex
peepsalot has joined #litex
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Ping timeout: 246 seconds]
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Ping timeout: 272 seconds]
nrossi has joined #litex
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Ping timeout: 272 seconds]
<_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.
st-gourichon-f has joined #litex
st-gourichon-fid has quit [Ping timeout: 260 seconds]
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Ping timeout: 260 seconds]
<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.
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Ping timeout: 240 seconds]
st-gourichon-f has quit [Ping timeout: 258 seconds]
CarlFK has joined #litex
st-gourichon-fid has joined #litex
Dolu has joined #litex
<_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
<zyp>
wiring up jtag to my cle-215 now, can somebody confirm which end of the connector is pin 1?
<zyp>
nevermind, I measured it out, pin 1 is closest to the m.2 connector edge
st-gourichon-fid has quit [Ping timeout: 260 seconds]
st-gourichon-fid has joined #litex
st-gourichon-fid has quit [Ping timeout: 256 seconds]
anuejn_ is now known as anuejn
st-gourichon-fid has joined #litex
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Ping timeout: 272 seconds]
st-gourichon-fid has quit [Ping timeout: 272 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<somlo>
building with litesdcard now, will report back on how that one turns out
HoloIRCUser1 has quit [Ping timeout: 264 seconds]
<somlo>
`length` is 13126480, so I think it all works more or less OK up to that point.
xobs1 has joined #litex
FFY00 has quit [*.net *.split]
xobs has quit [*.net *.split]
disasm[m] has quit [*.net *.split]
david-sawatzke[m has quit [*.net *.split]
st-gourichon-fid has joined #litex
FFY00 has joined #litex
disasm[m] has joined #litex
david-sawatzke[m has joined #litex
david-sawatzke[m has joined #litex
david-sawatzke[m has quit [Changing host]
<somlo>
_florent_: litesdcard booting hangs after three rounds of printing out the parameters (CID register, manufacturer ID, application ID, product name, etc.)
<zyp>
what does the ERRORS col in the dma_test indicate? is that normal?
Dolu has quit [Remote host closed the connection]
<_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.
<_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.
<_florent_>
zyp: do you always have the errors? Are you able to test on another machine?
<zyp>
and no, I don't have anything else with a m.2 socket available
<zyp>
looks to me like in the failing case, the read and write streams goes out of sync and therefore keeps accumulating errors
<_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.
<somlo>
_florent_: it appears that `f_read()` fails right away, from the first iteration
<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?
tpearson-mobile has joined #litex
<tpearson-mobile>
Hi all, I'm looking for any documentation that might exist on how to add our custom peripherals to the LiteX framework
<_florent_>
somlo: for the f_read fails it's with litesdcard?
<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?
<tpearson-mobile>
our cores are not Wishbone compatible (yet) and I'm wondering if we should just implement the direct internal bus
<_florent_>
tpearson-mobile: LiteX currently uses a wishbone bus for the main bus of the SoC
<tpearson-mobile>
Oh, OK
<_florent_>
in the future, it will be also possible to use AXI
<tpearson-mobile>
the diagram seems to show something different
<tpearson-mobile>
ah
<tpearson-mobile>
any plans for something fast like AXI that isn't proprietary licensed?
<_florent_>
but we can currently bridge the main bus to/from AXI and to a simplified CSR bus used for the registers
<somlo>
_florent_: f_read fails with spi-mode
<somlo>
I've added an extra printf to get me the actual error code, should have it in a few minutes
<_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
<tpb>
Title: GitHub - SpinalHDL/SaxonSoc: SoC based on VexRiscv and ICE40 UP5K (at github.com)
<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?
<tpearson-mobile>
Looking on the ARM site the docs don't seem to be behind a firewall any more
<somlo>
_florent_: maybe tpearson-mobile is referring to the CSR bus (where all/most mmio hardware registers are bridged to the "main" wishbone bus)?
<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)
<tpearson-mobile>
they're all 32 bit native (can be 64 bit native) already
<_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.
<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
<somlo>
_florent_: first call to f_read for my 13126480 byte boot.bin returns 9 (FR_INVALID_OBJECT)
<somlo>
_florent_: this is with spi-mode, to be clear
<_florent_>
somlo: ah ok i see, i also had this before forcing the mount when doing f_mount
<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
<somlo>
tpearson-mobile: it's `somlo` (s/i/l/) -- only mentioning it b/c hexchat won't highlight it :)
<tpearson-mobile>
ah, sorry about that!
<tpearson-mobile>
not sure how I saw an i there
<_florent_>
somlo: would you mind doing a quick review the way i integrated FatFs in copy_image_from_sdcard_to_ram?
<somlo>
_florent_: sure, am I to look at the current master, or do you have a pending patch?
<_florent_>
somlo: current master is fine. I tested it on various boards here (but always with Vexriscv)
<somlo>
tpearson-mobile: LiteX has an AXI-to-WB converter in case you have axi-capable IP blocks you want to attach to LiteX
<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
<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
<tpearson-mobile>
is the use of that converter documented anywhere?
<_florent_>
somlo: BTW, in case you want to investigate on f_read, if you want to rebuild and load a bios easily:
<_florent_>
somlo: add this to your target: self.add_ram("firmware_ram", 0x20000000, 0x8000)
<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?
tpearson-mobile has quit [Remote host closed the connection]
<keesj>
is openocd now used to install software on the arty board?
<daveshah>
It can be, although xc3sprog is probably faster
<daveshah>
oh sorry I thought this was a general question not litex-specific
HoloIRCUser has quit [Read error: Connection reset by peer]
HoloIRCUser1 has joined #litex
<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
<zyp>
a quick fix is probably just to delete or rename vivado's libusb.so
<keesj>
litex works mostly if I just add the bin directory to the path so .. i might be safe
<keesj>
(for reference it shows) INFO: [Common 17-206] Exiting Vivado at Wed Jun 10 14:24:32 2020...
<keesj>
openocd: symbol lookup error: openocd: undefined symbol: libusb_get_port_numbers
<tpb>
Title: core: Add a new public libusb_get_port_numbers function · libusb/libusb@4d7789b · GitHub (at github.com)
<keesj>
(and this is also inside a vm......)
<keesj>
works .. now .. thanks guys
<mithro>
_florent_: The pythondata-XXX modules are on PyPi now
<somlo>
_florent_: litex_term.py stuck at "[LXTERM] Starting...". Is that a frequent "unfamiliar user" type of problem? :)
<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?
<zyp>
if so, is there any ways to get around this without installing a newer rust?
<zyp>
found the obvious solution: grab the precompiled version of wishbone-tool :)
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Read error: Connection reset by peer]
CarlFK has quit [Quit: Leaving.]
<keesj>
gerring access to non standards pin (in a pmod or ck_io) appears to be non trivial
<keesj>
yea I was looking into that but ...then I end up redifining the pins or using... Pins("CK_IO:45") or similar?
<zyp>
yes
<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
<keesj>
(as can be done with serial)
<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
<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
<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
<keesj>
right so bypassing the double indirection and directly using pin names