<somlo>
jon_: the trellisboard is not available via *retail* -- the idea is you contract with a PCB manufacturer to have the design at https://github.com/gatecat/TrellisBoard custom made, so that's probably not what you want. If you want to stay on the Free/Libre side of things with ECP5, then the lambdaconcept ECPIX5 board (make sure it's the 85k version) is your best bet. They are occasionally sold out, so check back with them every week or two
<nickoe>
How can I make the --load arg to the programmer use the running jtag connection of the litex_server? Having to stop it every time I need to load the bitstream is a bit tedious for me, I assume there is a way to make it use the litex_server.
<geertu>
Melkhior: feel free to complain to the people that removed hardware accelerated console support...
<Melkhior>
@geertu I can already guess the answer... "put up or shut up", and I don't have the time to maintain fbcon...
<Melkhior>
too bad, that was the one part of Linux where I had contributed (wrote an accelerated driver waaaaaaaaaay back to get a decent console in PPC Linux for my PowerMac 7500)
<Melkhior>
idly wondering whether you can expose some acceleration feature through fbdev that could be used in X11
<Melkhior>
first I have to finish compiling X11 on my SoC :-)
<Melkhior>
@geertu In the 'weird idea' category ... ever thought if a M68K core (from the numerous recreation project for Atari/Amiga/Mac/...) could be integrated in Litex so we could get some NetBSD/68k with somewhat higher performance than the 'real thing' ? No idea whether any open FPGA softcore supports SMP though, which is kind of useful nowadays.
<Melkhior>
(I'd suggest SPARC but Columbia's ESP soft-SoC supports LEON in SMP already:-) )
<_florent_>
Also you don't need to do everything in the fabric, the DMA have optional CSRs to allow software control
<_florent_>
this way in the SoC you only have to connect the DMAReader.source to the DMAWriter.sink: ex: dma_reader.source.connect(dma_writer.sink)
<_florent_>
you can also provide default values for all or some of the CSRs (useful for example if you are always doing the accesses are fixed addresses, with fixed lengths, etc... ), in this case, the software intervention can be limited to enable th transfer
<_florent_>
Melkhior: BTW, Charles is working on a USB Host core and already got keyboard, mouse and usb stick working, this will be useful for the single board computer case :)
<Melkhior>
_florent_ Thanks for the pointers; the goal was to be able to do rectangle/copy - write the (x,y) origin point, the (width, height) of the rectangle, and the (x',y') destination point in CSRs and then let the DMAs do the 'copy' (and if there's overlaps it gets complicated) . The address generators would use the CSRs value to generate two streams
<Melkhior>
of addresses to feed to the two back-to-back DMAs. The driver would then just have to write in the CSRs (+ some 'start bit') when a copy is needed.
<Melkhior>
Many moons ago it would have enabled the Linux console to have hardware scrolling...
<Melkhior>
_florent_ oh nice; but none of my boards have USB PHYs which is why I went with PS/2
<Melkhior>
Other might in the same case so maybe there's still some value there ?
<Melkhior>
I ordered myself a splitter cable to see if I can get two PS/2 devices from the same PMod and add mouse support as well, if i ever find a PS/2 mouse
<Melkhior>
but indeed USB is probably the best way :-)
<_florent_>
Melkhior: OK I see for the DMA. The easier for that will probably then to use the WishboneDMAWriter/Reader without the CSRs, still connect them together, but have your own logic to generate the addresses/handle the software control
<geertu>
Melkhior: Of course I thought about that ;-) It's a pity the APOLLO CORE 68080 is not FLOSS
<cr1901_modern>
The maintainers of 68k userland have gotten projects like Clang and Boost to compile in QEMU VMs
<Melkhior>
_florent_ As usual the issue will be software:-)
<Melkhior>
I have a nice hw-accelerated AES-256-GCM in FPGA for my SPARCstation, and no good software support in NetBSD - OpenSSL doesn't use the kernel support for GCM (and is buggy for CTR, different interface), so I'm stuck with CBC (which is disabled by default in SSL); then I discovered SSH support is broken (SSL opens the driver device, then SSH closes
<Melkhior>
all FD >= 3 ...)
<Melkhior>
Now the hardware console is gone in Linux...
<geertu>
Melkhior: I used to have an accelerated X server on ATI RAGE II+, using the MMIO region exposed by atyfb
<Melkhior>
@geertu yes it seems most of the FLOSS cores are 68000 only, and you really want 68020+68851 or 68030 minimum
<Melkhior>
@geertu Xorg has become quite bloated, not sure if you can still use only very basic acceleration (and not need a full-fledged GL support:-( )
<Melkhior>
@_florent_ BTW it's mixed with my other changes, but I will try to clean-up my patch to add cache information in the DTS (so lscpu see the VexRiscv caches as shown above)
<Melkhior>
cr1901_modern Yes Qemu is often the right answer - pkgsrc on NetBSD/sparc is easier to deal with in emulation than on the real thing, mostly because I/O is much, much faster and you can have more memory
<geertu>
Melkhior: Indeed, the new qemu m68k has 3.2 GiB, my vexriscv on OrangeCrab has only 128 MiB ;-)
<Melkhior>
@geertu have you considered a VCU128 ? plenty of memory and you should be able to fit a lot of cores :-)
pftbest_ has quit [Remote host closed the connection]
pftbest has joined #litex
<geertu>
Melkhior: Does it have a FLOSS FPGA toolchain?
* geertu
hasn't touched the de0nano and Quartus since the advent of Project IceStorm
<Melkhior>
geertu probably not... it's UltraScale+ so not even sure it fits in the '7-series' descriptot of project X-Ray
<Melkhior>
and in any case it's probably not a primary (or secondary or tertiary...) target, $9k boards aren't easy to access...
<geertu>
Melkhior: Would be cool to implement a heterogenous vexriscv + openrisc + microwatt + lean, ... cluster ;-)
<geertu>
s/lean/leon/
<Melkhior>
@geertu Not sure an OS would deal with that properly... but it could be fun to try :-)
<leons>
Melkhior: yeah, SMP would for sure not work haha. But having a coprocessor of a different arch could be really cool (although probably impractical most of the time)
<Melkhior>
yes one could use a extra core as an accelerator for Linux's binfmt_misc
<geertu>
leons: There are plenty of SoCs with CPU cores of different archs
<geertu>
You cannot run a single Linux OS on them, though.
<leons>
geertu: yeah, that's what I was trying to say
<_florent_>
zyp: nice, thanks for your efforts to simplify nMigen cores integration in LiteX, that will be very useful
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
Bertl_zZ is now known as Bertl
nats` has joined #litex
<Melkhior>
@_florent_ Just saw there was a Linux DRM driver for a "litex,litevideo" device ; but I don't see anything like that in litex_json2dts.py
<Melkhior>
Do you know what it does? I think only reocnfigure the video output
<geertu>
Melkhior: simple-framebuffer?
<Melkhior>
@geertu you don't need that driver, and indeed in the DTS it's 'compatible ="simple-framebuffer"' (and works fine)
<geertu>
Melkhior: There's also a new simpledrm in the works, using
<geertu>
simple-framebuffer
<Melkhior>
it seems the driver will only change timings and resolution
<Melkhior>
@geertu Could it use simple-acceleration as well ?
<Melkhior>
'some simple acceleration' I should say
<Melkhior>
something that could give X11 a bit of boost for 'solid' and 'copy' at least...
<Melkhior>
not that I have the time :-)
<Melkhior>
thanks for the simpledrm hint, will look at it
<shoragan>
Melkhior, on which FPGA do you have your 4 core vexriscv?
jon_ has joined #litex
<Melkhior>
@shoraga Artix-7 100T, fit nicely even with full B and K support and a shared FPU for all 4 cores
<Melkhior>
~$90 Qmtech Wukong from aliexpress IIRC
<Melkhior>
Adding some of P would probably limit to 2-3 cores only and cut down the frequency (my P stuff isn't very good, I just wanted a feel of the extension)
<Melkhior>
100 MHz with no issue, too slow for Gigabit Ethernet I think so I limit the switch to Fast and it's 100% reliable; micro-sd card running perfectly at 25 MHz (didn't move to the interrupt-enabled version yet)
<Melkhior>
@shoragan sorry for the typo
<Melkhior>
the only issue is that 256 MiB is not enough RAM :-)
<shoragan>
Melkhior, nice. I've trying it on a 85k ECP
<shoragan>
IX-5, but the bios only boots in the single core variant
<Melkhior>
... also I'm running with Vivado
<Melkhior>
@shoragan up-to-date linux-on-litex-vesriscv & litex should have no issue with basic SMP (I only added instructions, the SMP stuff is unchanged)
<Melkhior>
if the cores fit in the FPGA it should run, but you need to double check that everything was built with the same version/configuration: the DTS/DTB, BIOS, OpenSBI, SMP support in Linux, ...
<shoragan>
the frequency and utilization is fine for the 2 core config
<Melkhior>
mmm, i use native mode not wishbone ; normally the toolchain can generate the appropriate core, but you need "sbt" installed otherwise it fails cryptically
<Melkhior>
is wishbone mode (_Wm) required on your system ?
<Melkhior>
yes I was looking at the make.py and it defaults to Wishbone on the Versa
<shoragan>
i'm try to build it in OE, using meta-hdl. perhaps there's some issue with the toolchain for building the BIOS? but as the single-core variant works fine, i wouldn't think so
<Melkhior>
you'll have to ask @_florent_ for that, I don't know
<Melkhior>
(the Wishbone stuff I mean)
<Melkhior>
Yes if the single-core variant works then it's likely the toolchain is fine...
<Melkhior>
And if the BIOS fails it's not the DTS or kernel
<shoragan>
yes
<Melkhior>
Sorry I don't know :-(
<shoragan>
thanks anyway :)
<_florent_>
Melkhior: Regarding the litevideo linux driver, it was indeed required with the VideoOutput core from LiteVideo to configure the timings, but it's no longer required with the new simple VideoFramebuffer directly integrated in LiteX (that comes with timings pre-initialized). A driver would only be useful to update/change the timings.
<Melkhior>
shoragan Maybe you can have a try w/o the wishbone to see if it reaches the BIOS, even if it's not stable enough for e.g. ? it would pinpoint the issue...
<Melkhior>
@_florent_ OK thanks, make sense ; indeed in my config I fix the timings in the 'target' based on the requested resolution
<shoragan>
Melkhior, ok. i thought there would be no chance of that working.
<Melkhior>
@shoragan I don't know either but it migth be worth a shot...
<Melkhior>
Hopefully you can get better help from others... I'm just a (happy) user of the SMP mode
<Melkhior>
there has been improvement since in litedram, but you may need the speed to be 'high enough' for the DRAM to work
<_florent_>
shoragan: can you provide the build command you are using? I can try to build on my side and share it with you
<shoragan>
Melkhior, but in that case, you'd still have the initial output from the bios even in the bad case?
<Melkhior>
yes, the BIOS was still working in that case
<shoragan>
_florent_, i'm building using meta-hdl (updated to current litex, yosys, ... repos). basically it should be ./make.py --board ecpix5 --cpu-count 2 --build
<shoragan>
ok, so I now have two things to try. build without wishbone and also build without meta-hdl
<_florent_>
shoragan: ok, I'll build it with this command line
<shoragan>
_florent_, do you think the _Wm variants will be needed for longer? then it may be useful to add those to the pythondata package to avoid the need for sbt?
<_florent_>
shoragan: on some boards, the data mask are grounded (ex SDS1104XE + ColorLight I5 IIRC) so this will be kept yes
<_florent_>
shoragan: I could try to add more config to the pythondata package
<shoragan>
thanks, that would also make it easier to use with meta-hdl, as running sbt in yocto doesn't work right at the moment
<_florent_>
sorry I'm not able to generate default version now
<shoragan>
_florent_, yes, that works on mine as well.
<shoragan>
_florent_, this is with the manual change from Wishbone to litedram?
<_florent_>
so you can try to rebuild it and see if it also works with yours, if so, this could be an issue with cpu_count > 1 and the wishbone interface
jon_ has quit [Ping timeout: 252 seconds]
jon_ has joined #litex
<shoragan>
_florent_, ok. build without the l2_size line works for me
<cr1901_modern>
_florent_: Is there a way to completely override (not just append) to a build script before it's generated? The context is "Microwatt blows up the autonaming pass in yosys, and it probably shouldn't be done for now"
<shoragan>
_florent_, a mem_test 0x40000000 0x20000000 works fine
SpaceCoaster has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
SpaceCoaster has joined #litex
jon_ has quit [Ping timeout: 260 seconds]
<acathla>
is it normal gdb doesn't stop on breakpoints I put and other strange behaviors on a vexriscv? Is it a minimal implementation of gdb?
<acathla>
oh, no hardware breakpoints...
<tcal>
acathla: correct; you can rebuild VexRiscv setting the DebugPlugin's `hardwareBreakpointCount` to 2 or greater (don't use 1; there's a known issue that I don't think has been fixed).
jon_ has joined #litex
<_florent_>
cr1901_modern: I don't think this is possible currently
<nickoe>
In the litex_sim.py there is self.submodules.crg = CRG(platform.request("sys_clk"))
<nickoe>
can I easily simulate the CRG generating different clock frequencies?
rj has joined #litex
rj has quit [Ping timeout: 240 seconds]
rj has joined #litex
sorear has quit [Ping timeout: 245 seconds]
davidlattimore has quit [Ping timeout: 260 seconds]
_florent_ has quit [Ping timeout: 260 seconds]
davidlattimore has joined #litex
sorear has joined #litex
_florent_ has joined #litex
rj has quit [Ping timeout: 240 seconds]
rj has joined #litex
pftbest has quit [Remote host closed the connection]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 268 seconds]
kgugala has joined #litex
pftbest has joined #litex
kgugala_ has quit [Ping timeout: 240 seconds]
kgugala_ has joined #litex
kgugala has quit [Read error: No route to host]
kgugala has joined #litex
rj has quit [Ping timeout: 240 seconds]
pftbest has quit [Ping timeout: 260 seconds]
kgugala_ has quit [Ping timeout: 246 seconds]
rj has joined #litex
kgugala_ has joined #litex
kgugala__ has joined #litex
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has quit [Ping timeout: 240 seconds]
kgugala__ has quit [Read error: Connection reset by peer]