_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
shoragan has quit [Ping timeout: 250 seconds]
shoragan has joined #litex
<mc6808> _florent_: I've created PR for litex and litex-boards with some efinix tweaks and basic xyloni support
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
Degi has quit [Ping timeout: 252 seconds]
Degi has joined #litex
RaYmAn has quit [Remote host closed the connection]
RaYmAn has joined #litex
RaYmAn has quit [Client Quit]
RaYmAn has joined #litex
<mc6808> _florent_: tristates don't seem to be generated correctly for spiflash on any of the efinix boards. I get:
<mc6808> [EFX-0265 ERROR] Bi-directional port 'spiflash_mosi' is not supported in this device.
<trabucayre> mc6808: in fact you have to provides at top verilog IN, OUT, OE pins instead of inout ...
<trabucayre> but for iface.py you have to provides spi_flash_mosi ...
<mc6808> trabucayre: Yes: The signals in .peri.xml are actually: spiflash_mosi_{IN,OUT,OE}. I'm not sure how to tweak the verilog generation...
<trabucayre> I've spent time this week-end to find a way to fix this issue...
<trabucayre> maybe copy io dict in get_verilog to replace spiflash_{mosi,miso} by the 3 required signals ...
<_florent_> mc6808, trabucayre: For now Bi-directionnal IOs are indeed not yet supported. I'll also have a closer look at it. With the Efinix toolchain, you are not doing instances of the IOs/PLL primitives in your HDL but you have to expose the primitives' ports at the top level, which is a bit different than traditionnal approaches and so need to be integrated correctly in the LiteX flow. _franck_ already did this work for the PLL, but we have to
<_florent_> also do it for the IOs and other eventual primitives requiring it.
<_franck_> It's not automated for now
<_franck_> mc6808, trabucayre: ^
<indy> hi all, any update on ecp5 pcie?
FabM has joined #litex
FabM has joined #litex
_franck_5 has joined #litex
_franck_ has quit [Ping timeout: 245 seconds]
_franck_5 is now known as _franck_
<_florent_> _franck_: Thanks. I think it should be possible to encapsulate this in a SDRTristate special as we are doing with the other toolchains (but without requiring passing the platform as you suggested when we discussed together). I'll try to do a test on this (QSPI Flash / I2C are good candidate to test this).
<tnt> err, this is just awful ... ( the efinix approach ) ...
zjason` is now known as zjason
<_florent_> tnt: This is clearly not simplifying things... and should probably have been handled by the toolchain. With LiteX/Python we still have some flexibility to abstract this and make it similar to the other toolchains but this is going to be more painful when doing regular Verilog/SV/VHDL designs where you'll have almost similar constraints than when designing ASICs with an IO Pad Ring.
<_florent_> tnt: But even with LiteX, it will only works fine for native LiteX code, when importing external code, we'll also have to modify it (integrating a verilog core with a tristate IO will not be possible without modification).
<_florent_> Maybe they'll reconsider this choice later and will revisit the toolchain to handle this
<tnt> Yeah ... PLL instances signals having to be brought to top-level IO ... iewww ... Is it the same for instances of BRAMs ?
<_florent_> tnt: no, RAM/DSPs are considered in the fabric/digital part :)
<_florent_> Hi indy, PCIe on ECP5 is not currently supported in LiteX. It would requires using the use of the proprietary Lattice PHY or the one from PLDA ($$$) or having an open-source PCIe PHY (which would probably be something between 3-6 months full time work to have something usable).
<_florent_> I already used the one from PLDA on ECP3/ECP5, it's working fine but you have to pay $$$ for it... :)
<indy> _florent_, i was watching https://codeberg.org/ECP5-PCIe/ECP5-PCIe and it looked promising
<tpb> Title: ECP5-PCIe/ECP5-PCIe: A PCIe interface for the ECP5 FPGA written in nMigen - ECP5-PCIe - Codeberg.org (at codeberg.org)
<_florent_> indy: This is interesting yes but this would still requires probably requires a few weeks/months of work.
<_florent_> indy: This would be interesting to explore this further, but for now I'm not aware of anyone looking at it.
<_florent_> One of the aims of the Acorn baseboard is also to be able to capture/record SerDes based links and being able to capture PCIe with it could be useful to create a PCIe PHY
mc6808_ has joined #litex
<mc6808_> _florent_: a special for SDRTristate sounds good, I was hoping it could be done like this in some way and was going to have a look. But I've got a bit of learning to do feel truely useful in this space :)
mc6808_ has quit [Client Quit]
kgugala has quit [Quit: WeeChat 3.3]
Guest78 has quit [Quit: Client closed]
mc6808 has quit [Quit: Client closed]
indy has quit [Read error: Connection reset by peer]
indy has joined #litex
indy has quit [Ping timeout: 260 seconds]
indy has joined #litex
C-Man has quit [Ping timeout: 258 seconds]
<mntmn> quick risc-v noob question: when using CROSS_COMPILE=riscv64-linux-gnu-, how do i make sure the binary targets rv32ima?
<cr1901> I thought litex chooses the right arch for you based on the core/variant you chose
<cr1901> the right set of riscv extensions*
<mntmn> yeah, but my goal is to cross compile some extra binaries outside of litex to run on the target
<mntmn> possibly i want crosstool-ng and a special toolchain for rv32ima?
<cr1901> Oh, I think I misunderstand what you want and can't help you, sorry :(
<mntmn> ok, no problem
<cr1901> (As in "I don't know", not "I don't want to help" :P)
<mntmn> ah i see now that buildroot already built/checked out a riscv32-... toolchain
<tnt> mntmn: -march=rv32i -mabi=ilp32
<tnt> or rv32ima I guess in your case.
<mntmn> tnt: thanks. i tried that and it _almost_ works.
<tnt> almost ?
andresmanelli has joined #litex
<mntmn> tnt: yeah
<mntmn> tnt: i need to point it to the 32 bit libs etc
<mntmn> currently i get problems when linking with libc like "ABI is incompatible with that of the selected emulation"
<mntmn> > target emulation `elf64-littleriscv' does not match `elf32-littleriscv'
<mntmn> i guess i should rather build a rv32 toolchain from scratch
<tnt> That should work just fine ...
<tnt> But if you're doing compilation and linking in separate steps, you'll need equivalent options for the linker I guess.
<tnt> I just give all my sources to gcc in one call and directly produce the output binary, so it knows how to call the linker properly.
<mntmn> yeah, in my case i was trying to cross compile an existing package and that would be a bit more involved
<tnt> did you make sure you had the march and mabi option in LDFLAGS too ?
<mntmn> no, let me try
<mntmn> tnt: the remaining problem is that i have to tell ld the path to the 32 bit libc.so.6 somehow
<mntmn> by default it wants to use /lib32/libc.so.6 which is x86
<mntmn> i guess the risc64 toolchain in debian is not "multilib"
<tnt> huh, if it's trying to read x86 that's nothing to do with risc32 vs riscv64
<tnt> you probably need a -sysroot something or some other cross compile magic. I only build embedded firmware nothing "applicative" that links dynamically.
<acathla> I have 4 instances of the same module, how can I access them in a loop? Something like "self.submodules.name[i] = MYMODULE()" would be nice
<tnt> you might have to encode the name ... setattr(self.submodules, 'name_%d' % i, MYMODULE()) and getattr(self.submodules, 'name_%d' % i)
<acathla> That seems to work, thanks tnt
<acathla> except that I need to getattr(self, ... instead of self.submodules, same as usual in migen
<mntmn> tnt: in the meantime i built a riscv32 toolchain and it works fine
andresmanelli has quit []
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
<mntmn> are there any usb (1/2/3) host controller solutions compatible with linux-on-litex-vexriscv?
<mntmn> assuming i have an external ULPI PHY
<mntmn> i guess i would need some kind of generic UTMI implementation in FPGA and a host controller driver for that?
C-Man has joined #litex
shenki has quit [Ping timeout: 268 seconds]
<DerekKozel[m]> _florent_: Does the --flash option work on the CLE-215+ via JTAG? I get:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/3c1a0a85e0dbb231aad19cafcd774c5c4ebfe1e6)
shenki has joined #litex
photon70 has joined #litex
photon70 has quit [Quit: Lost terminal]
Wolf0 has quit [Ping timeout: 240 seconds]
Wolf0 has joined #litex
zjason` has joined #litex
zjason has quit [Ping timeout: 252 seconds]
<ilia__s> DerekKozel[m]: does not work for me yet; detects s25fl256s, modifies some content but fails at verification
<ilia__s> with latest openocd
<_florent_> DerekKozel[m]: IIRC it was working (with https://github.com/enjoy-digital/openocd)
<_florent_> I could test tomorrow
<_florent_> mntmn: For USB 1, there is the USB OHCI core: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/usb_ohci.py
<_florent_> already validated with Linux-on-Litex-Vexriscv
<mntmn> _florent_: can it be used as a host?
<_florent_> yes
<mntmn> _florent_: ah that's awesome... the only problem is that i have an ULPI phy chip in the way
<DerekKozel[m]> I'll grab your openocd and try it
<DerekKozel[m]> Thanks
<DerekKozel[m]> Thanks ilia__s for the info as well
<DerekKozel[m]> I'm rushing a little to update our setup here for a student's final demo. We have a known working setup, but hoping to get a small processing block connected to the LitePCIe and show that it all works with the latest.
<_florent_> mntmn: Otherwise, a few weeks ago I started playing with Ultraembedded's USB CDC device core, havent' spent enough time to got it working, but it can maybe be useful to create a wrapper around the USB Host core:
<ilia__s> _florent_: your fork of openocd fails the same way
<_florent_> mntmn: I think Melkhior here is also using it
<DerekKozel[m]> Bother. building OpenOCD is triggering errors.
<_florent_> ilia__s: I'm not sure, but that's possible there was a software write protection enabled by default on the Acorn
<ilia__s> well, I for sure modified some flash content, it does not boot anymore
<_florent_> ilia__s: I remember having troubles flashing the Acorn at some point, I'll do a test tomorrow
<DerekKozel[m]> solved build error by adding -no-pie
<DerekKozel[m]> Thanks Florent
<DerekKozel[m]> I'm noticing that the kernel module isn't logging any messages to dmesg, but I can see with modprobe -vv that it's registering a custom logger. Have the messages moved?
<mntmn> _florent_: thanks, that gist is interesting
<_florent_> DerekKozel[m]: the driver code hasn't been modified recently
<DerekKozel[m]> Oh! it found the flash but dies with errors during writing.
<tpb> Title: make: Leaving directory '/home/dkozel/src/litex/build/sqrl_acorn/software/bios' - Pastebin.com (at pastebin.com)
<DerekKozel[m]> Thanks for the confirmation. I'll dig more into my setup for the kernel module.
<_florent_> DerekKozel[m]: That's possible doing something similar to https://github.com/enjoy-digital/openocd/commit/d481b0ac66c97881a4301c175748153a25c63e6b to the SPI Flash used on the Acorn would allow you to write correctly
<DerekKozel[m]> Ok. I'll try that, thanks
Guest78 has joined #litex
<_florent_> change 0xdc to 0xd8
<ilia__s> _florent_: this worked!
<_florent_> ilia__s: Thanks, I'll push the change to the repo tomorrow
mc6808 has joined #litex
<DerekKozel[m]> Worked here too. And Flashing successfully worked around getting the kernel to persist the image despite thunderbolt power cycling even on a hot reboot
<DerekKozel[m]> edit-> image persists, thus kernel picks it up correctly.